From nobody Mon Jul 3 08:40:49 2017 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 C320C13168A; Mon, 3 Jul 2017 08:40:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149909644776.22718.16227939850699261560@ietfa.amsl.com> Date: Mon, 03 Jul 2017 08:40:47 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:40:48 -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 : IPv6 Node Requirements Authors : Tim Chown John Loughney Timothy Winters Filename : draft-ietf-6man-rfc6434-bis-01.txt Pages : 38 Date : 2017-07-03 Abstract: This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6434-bis-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 Mon Jul 3 10:31:32 2017 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 CECDB1316E3; Mon, 3 Jul 2017 10:31:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc4291bis-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910308281.22762.8371820426530467229@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:31:22 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:31:23 -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 : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering Filename : draft-ietf-6man-rfc4291bis-09.txt Pages : 35 Date : 2017-07-03 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 10:36:16 2017 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 6FED6129B77 for ; Mon, 3 Jul 2017 10:36:15 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 2e7iolcVvMc5 for ; Mon, 3 Jul 2017 10:36:13 -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 36BC31316C4 for ; Mon, 3 Jul 2017 10:36:13 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i127so115641939wma.0 for ; Mon, 03 Jul 2017 10:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=hf36UkPzxuWRJrTGwKr23sLeoLOjTN30O42mDyjSkEQ=; b=e+m0irZ4j1flGzLER+4L1RIPonGOQNU2mwZ4IBSEypKs4KEwOk0yyv3tMvxXGqURqa nuxTXoWsgZZVrzfcpIGDxycOGZmpuSRItWcpVBxCZGfkN1SCsUmWCaUP+DhqYI4sGd1y Lg7XeU2inxlFJwDpoPWPg7K4eur1Nmvw50PjqFlC4Tlh4YqTaC11LVqf7F/a5Zv9Vzb+ mYXCEbe/6dJM0xXI6XY2HOA8YVD/GqywC6YvK0ZC7FKCJ5OnA8xY3ZB0cghG3gsnZEbA nBIoCg8vttNFI0GzBGcNlXnb5eptBnLX7+bD42nKQvYMYihnGWekagpw/9irIJwC7NCY Xkmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=hf36UkPzxuWRJrTGwKr23sLeoLOjTN30O42mDyjSkEQ=; b=TwbsJQ6y/XoOBQhiV+AnC5TJEf8XRpOIrpAtQDkz1YyxfYujgYQaFa+SCjusN/7kTO 3uOoiVgbxlKWDfcMMDS3qUuyqTV7tgX9NjRonKLGYB+UCfLeOMfIJ5VqiIwt0U7t1RyJ maki2H9nv/+SL6gyx1Qp2mciQPEWH8Xm1jrMxAE80wJX2hS443FIf3V7dOLzboRZR1bj 0yBF5H4Lc37jSEI1SYJ0Mna98IN3HcvASa9eCqeAZHcVP8aQsHKS7YID0Tiy/yJyXppn NfijDU5ZsILubUAbN+1k41tjTnFwljTQQwRhJOccPVgtLpFBKGKnhhxFKdOsovPQ2J9i w8yg== X-Gm-Message-State: AKS2vOyzr8br27OqSKcwCkidwS5XZsWsrxtaRNOJyQX9etWYaTDKNpmH B/icdM+TMnA10cCynR8= X-Received: by 10.28.54.217 with SMTP id y86mr17089564wmh.81.1499103371405; Mon, 03 Jul 2017 10:36:11 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:49ff:6a26:d532:d577? ([2601:647:4d01:db10:49ff:6a26:d532:d577]) by smtp.gmail.com with ESMTPSA id v8sm10093830wrd.28.2017.07.03.10.36.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 10:36:10 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_FBA0F0BD-5740-44E2-997B-7EE7823032EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Date: Mon, 3 Jul 2017 10:36:06 -0700 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> Cc: Bob Hinden To: IPv6 List Message-Id: <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:36:15 -0000 --Apple-Mail=_FBA0F0BD-5740-44E2-997B-7EE7823032EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new 6man w.g. version (-09) of the RFC4291bis draft. See = links below. The summary of the changes are: o Added text to the last paragraph in Section 2.1 to clarify the differences on how subnets are hangled in IPv4 and IPv6, includes a reference to RFC5942 "The IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes". o Removed short paragraph about manual configuration in Section 2.4.1 that was added in the -08 version. o Revised "Changes since RFC4291" Section to have a summary of changes since RFC4291 and a separate subsection with a change history of each Internet Draft. This subsection will be removed when the RFC is published. o Editorial changes. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-09 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc4291bis > Revision: 09 > Title: IP Version 6 Addressing Architecture > Document date: 2017-07-03 > Group: 6man > Pages: 35 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-09 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". >=20 --Apple-Mail=_FBA0F0BD-5740-44E2-997B-7EE7823032EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZWoCGAAoJEK7rdBF357uotPEH/RVv7cIS0S/YMxwIJ/Sbcwrx XhOEtFBOl4Vyee/7FrFgJTA9Io8OOo5oTQtsE3wzFzgQHFhzb4kU7PDcJUD/Bzuy YUEEGV0p3dWHrjuEPtqGWnTeIIovM9ngtZzj3Zpjtekea4zQcnbAXVFunTVXpSC4 L4Ei8RNRXC3HyW8sywDT+DRySwDp2e0ywhBfxhhIfnSq1D1sEBzzQykn9hnTSo87 hLqCNw8e7dCuFyn6w/NT/QQmFL1p1SBmk26ILzHP/v8gwVj7/Q/Gjuiy7IesyQby 0pvs4neNsFsxE7DI2P2LMaLejh28gxcwWnJQgJNnAVl8EdOlgCJ3ddIHl0unloE= =h54b -----END PGP SIGNATURE----- --Apple-Mail=_FBA0F0BD-5740-44E2-997B-7EE7823032EA-- From nobody Mon Jul 3 13:22:30 2017 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 4F3701243F3 for ; Mon, 3 Jul 2017 13:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfV_EfK8FQVt for ; Mon, 3 Jul 2017 13:22:27 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C119127868 for ; Mon, 3 Jul 2017 13:22:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id AEDB09DC for ; Mon, 3 Jul 2017 20:22:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH5itj5OcI49 for ; Mon, 3 Jul 2017 15:22:26 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 7D7CDAB for ; Mon, 3 Jul 2017 15:22:26 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id i63so74955860vkh.0 for ; Mon, 03 Jul 2017 13:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L6irSxYauCV9fgJklFNEHdnZ6op0xfAAj5WlJb0w0tQ=; b=CZiLmQI0eE7+/IGAOoK1IF23LcSzet57sK3rCJeHy+4e8jIdBBXDRyQ0VaMRgmwvIk ZOsKdHaORjUmPZYUDEhLociyLs5T88cxIEPP5vZvxT30NgG0tRxOrmHm03Q2/OMI2Pj/ EAJmLT3hHYZMSBFFaXk54tXoKd42adxoZo7+oDSLYYKM80HFsuaxNUppfq3QTa0YWq5b 1/KQ/orzE2ANcVrYVIO8HAYZ7Ad2uEHHcg/0FWZYILRPfjKXF7anZWNxUCNlaX8dyga9 0hsfQ4m59o6j+PrZ2xbkXA9fLeoEFHHgaqMmXvuYb3veIJ1hLF3Wcez4egM6WJdnZufs A7Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L6irSxYauCV9fgJklFNEHdnZ6op0xfAAj5WlJb0w0tQ=; b=dDQCdDsvAhv4tCZ/GPdImsNtYjVnSAbHsrVaBUzS/njPL7l8xkDzzTJ0tKCSITy9ER Lz1hKnxBaD31doKyrasZGRdgiF0esbSG7Hkpjld/WURSC+l4amXJQRdDOhi0gUuoXKTN JfqbBQTQ+TfGSVEc9YpWHKp0FDJfkuEeAytrAJd0sEZXXt5tRdqcJb8zhtbUEpFr2hH9 hKhLZIoXMz7qYly9XNjwJEaaS6g3A6G1gUAolxiID5yMztXTtn7FI6EkSZfyk+Vf7B8a f1eueTlvxOK/nm1XX9OEwQ/PSI0KYVedrawobye09sCIDwJoPWkp1NzIJZN8WDLdGcpM 2GCQ== X-Gm-Message-State: AKS2vOwXu+6Tg2UFQu+xE/2UznG4iI6VtH3v6jA62yivDZxhJ7kd2nft trkKUx/I/dCCTUoCAx1XD2j/Fo7nNc+flA+su2d8g73vaqV6TIFk1APrSBUgt1imxD30h2lG81k mGb01RLpe8EpUa3o= X-Received: by 10.31.114.75 with SMTP id n72mr19925159vkc.24.1499113345734; Mon, 03 Jul 2017 13:22:25 -0700 (PDT) X-Received: by 10.31.114.75 with SMTP id n72mr19925147vkc.24.1499113345495; Mon, 03 Jul 2017 13:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 3 Jul 2017 13:22:24 -0700 (PDT) In-Reply-To: <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: David Farmer Date: Mon, 3 Jul 2017 15:22:24 -0500 Message-ID: Subject: Re: To: Bob Hinden Cc: IPv6 List Content-Type: multipart/alternative; boundary="94eb2c14949a6fcc9f05536f8645" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:22:29 -0000 --94eb2c14949a6fcc9f05536f8645 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 3, 2017 at 12:36 PM, Bob Hinden wrote: > Hi, > > I published a new 6man w.g. version (-09) of the RFC4291bis draft. See > links below. > > The summary of the changes are: > > o Added text to the last paragraph in Section 2.1 to clarify > the differences on how subnets are hangled in IPv4 and IPv6, > includes a reference to RFC5942 "The IPv6 Subnet Model: The > Relationship between Links and Subnet Prefixes". > I was thinking about suggesting a reference to RFC5942 "The IPv6 Subnet Model", but I wasn't sure where to put it, I really like were you put it. However, I still think the following paragraph is still too easily misunderstood to imply subnets must be /64 or 64 bits for both address generation and on-link determination. Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links. How about a note clarifying the intent of the this paragraph, something like this; Note: While the previous paragraph does imply 64 bit subnet prefixes are typically assigned to most links. It does not imply anything about what portion, if any, of a subnet is considered to be on-link, see Section 2.1 for more discussion. However, Router Advertisements [RFC4861] specifying 64 bit on-link prefixes are typically configured on most links. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c14949a6fcc9f05536f8645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 3, 2017 at 12:36 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
H= i,

I published a new 6man w.g. version (-09) of the RFC4291bis draft.=C2=A0 Se= e links below.

The summary of the changes are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 =C2=A0Added text to the last paragraph i= n Section 2.1 to clarify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the differences on how subnets are= hangled in IPv4 and IPv6,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0includes a reference to RFC5942 &q= uot;The IPv6 Subnet Model: The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Relationship between Links and Sub= net Prefixes".

I was thinking abou= t suggesting a reference to RFC5942 "The IPv6 Subnet Model", but = I wasn't sure where to put it, I really like were you put it.=C2=A0

However, I still think the following paragraph is sti= ll too easily misunderstood to imply=C2=A0= subnets must be /64 or 64 bits for both address generation=C2=A0and on-link= determination.=C2=A0

   Interface Identifiers are 64 bit long=
 except if the first three bits
   of the address are 000, or when the addresses are manually
   configured, or by exceptions defined in standards track documents.
   The rationale for using 64 bit Interface Identifiers can be found in

   [RFC7421].=
  An example of a standards track exception is [RFC6164]
   that standardises 127 bit prefixes on inter-router point-to-point
   links.

How about a note clarifying the intent of t= he this paragraph, something like this;

=C2=A0 =C2=A0 =C2=A0 Note: While the previous paragraph d= oes imply 64 bit subnet prefixes=C2=A0
=C2=A0 =C2=A0 =C2=A0 are=C2=A0typically assigned to most links. It does no= t imply anything=C2=A0
=C2=A0 =C2=A0 =C2=A0 about=C2=A0what=C2=A0portion,=C2=A0if any, of a subnet is considered to be on-link,
= =C2=A0 =C2=A0 =C2=A0=C2=A0<= /span>see=C2=A0Section 2.1 for=C2=A0more discussion. However, Route= r Advertisements=C2=A0
=C2=A0 =C2=A0 =C2=A0 [RFC4861] specifying=C2=A064 bit on-link prefixes are=C2=A0typically=C2=A0=
=C2=A0 =C2=A0 = =C2=A0 configured on most links.=C2=A0
=C2=A0 =C2=A0 =C2=A0=C2=A0
T= hanks

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815=
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c14949a6fcc9f05536f8645-- From nobody Mon Jul 3 16:15:37 2017 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 2A44B1317B0; Mon, 3 Jul 2017 16:15:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-maxra-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912373515.15965.2496263529110027605@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:15:35 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:15:35 -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-03.txt Pages : 6 Date : 2017-07-03 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-maxra-03 https://datatracker.ietf.org/doc/html/draft-ietf-6man-maxra-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-maxra-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 13:00:17 2017 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 74394131DCA for ; Wed, 5 Jul 2017 13:00:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for 6man WG X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149928481647.13001.15902078366608626568.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 13:00:16 -0700 From: IETF Secretariat Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:00:16 -0000 Changed milestone "Develop approach for IPv6 Fragmentation", resolved as "Done". Changed milestone "Develop approaches for IPv6 Extension Headers (Hop-by-Hop and Destination)", resolved as "Done". Changed milestone "Plan for advancing core IPv6 core specifications to Internet Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/6man/about/ From nobody Wed Jul 5 13:34:43 2017 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 EE8B5131DD0 for ; Wed, 5 Jul 2017 13:34:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 P9v0gMtfbJkG for ; Wed, 5 Jul 2017 13:34:40 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 28CED131575 for ; Wed, 5 Jul 2017 13:34:40 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k67so355148wrc.2 for ; Wed, 05 Jul 2017 13:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rmyu1kFVzxRy5RBos3CsuL4LYp5pSGbifdHOZrWOnOw=; b=ThTi12eY7Ihk/c8oFrCrsAWYwyPfGRle+1IFIwMnzxRgHJOfvoZbn32BofB41X5WOM Q6zyeaXgZB7L31FIn4gFv51Eh/JqhvcpdfCZ+KrV+ZfTUz1HiQPC+9SKPXUCg/UscSKM irz+6bUlm4jeoirJLKmvIgQP0KIOG0aC58qFB33GaMKT6TsHC7GPz5b711oV48JMFZjb 9gf1QlWrg3+pnGm8KVtxt+j+oQtntcBzhTYLv4uwF/hWPVPH+PDUVGN36qpoWDkZeQak bpDKIX1shNdXSJh0oRPj6qGKegtPcbLOjIUvQwb2+TLZegp6CqzbCIqNkr6mjSA0+4CM wELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rmyu1kFVzxRy5RBos3CsuL4LYp5pSGbifdHOZrWOnOw=; b=gSqGfxs+LwjwEp1sZ9QqPEOUGeh5zY3smQh52dcJ18lGQ6aEqDZddejCRoqRh/LHxa ubCF4ZlknqKzhuetUtXWQyz3wyWr6xQ2qa/fiFstHXNl9dUFU/amz2vHS9vNIevw59ar XcZj4wdT8wTMGhlEc54iMmxWzl8UUknvMB9RznZWfF9tQpiRI4sXxPkYJq+CGE4V2iKh HUwXwu2TBBh8guYPfNRT3kixuVvl1/XdJ7QpSdSnoj4ljDWf3HdxAKgwtOFQCcVfl4Fg eyjWEhFw9BsOqrEvpiMPgvNxv+TNnDMGqAO9BhB2Y3HZ9ULj/DXcrbdj50RUcsE/wzgq XYpQ== X-Gm-Message-State: AKS2vOzqZHhq88pFGLaoa7w7TX7PKunztIc5q9vI32TGH50xNr4SIQHT V/Lh1jjizKv5Z7Wg8MQ= X-Received: by 10.223.139.24 with SMTP id n24mr42904476wra.116.1499286878680; Wed, 05 Jul 2017 13:34:38 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 22sm8144wru.29.2017.07.05.13.34.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 13:34:37 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7F54715D-A8B2-4EE2-B793-0EAF6727D436"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 5 Jul 2017 13:34:32 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List To: David Farmer References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:34:42 -0000 --Apple-Mail=_7F54715D-A8B2-4EE2-B793-0EAF6727D436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, > On Jul 3, 2017, at 1:22 PM, David Farmer wrote: >=20 >=20 >=20 > On Mon, Jul 3, 2017 at 12:36 PM, Bob Hinden = wrote: > Hi, >=20 > I published a new 6man w.g. version (-09) of the RFC4291bis draft. = See links below. >=20 > The summary of the changes are: >=20 > o Added text to the last paragraph in Section 2.1 to clarify > the differences on how subnets are hangled in IPv4 and = IPv6, > includes a reference to RFC5942 "The IPv6 Subnet Model: The > Relationship between Links and Subnet Prefixes". >=20 > I was thinking about suggesting a reference to RFC5942 "The IPv6 = Subnet Model", but I wasn't sure where to put it, I really like were you = put it. Good, thanks. >=20 > However, I still think the following paragraph is still too easily = misunderstood to imply subnets must be /64 or 64 bits for both address = generation and on-link determination. >=20 > Interface Identifiers are 64 bit long except if the first three = bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > The rationale for using 64 bit Interface Identifiers can be found = in >=20 > [RFC7421]. An example of a standards track exception is [RFC6164] > that standardises 127 bit prefixes on inter-router point-to-point > links. >=20 >=20 > How about a note clarifying the intent of the this paragraph, = something like this; >=20 > Note: While the previous paragraph does imply 64 bit subnet = prefixes > are typically assigned to most links. It does not imply anything > about what portion, if any, of a subnet is considered to be = on-link, > see Section 2.1 for more discussion. However, Router = Advertisements > [RFC4861] specifying 64 bit on-link prefixes are typically > configured on most links. Now that the text you refer to is in Section 2.4.1. "Interface = Identifiers=E2=80=9D, it is about Interface Identifiers, very little is = said about prefixes (except that IIDs are required to be unique on a = prefix, but even that is about IIDs). I don=E2=80=99t think it is = implying anything one way or about on-link properties. I think that is = covered pretty well in the new paragraph in Section 2.1 "Addressing = Model=E2=80=9D that includes the link to RFC5942. Thanks, Bob >=20 > Thanks >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_7F54715D-A8B2-4EE2-B793-0EAF6727D436 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXU1ZAAoJEK7rdBF357uoJx0H/iiWSJv/eqlQXZmlR1Y1TQsy TY2BU2NOobyUae1I+PY8Xn2hJoXncfuBjB25NkUMr8PPBLvNDDgYlvCgqINmDm+9 S130Ss6ASWkLWs0wVeKaV7mgWekxCVadKWq/DgapgAkhUDxjrFWLkWNWMpyIEwHK IDvrKfqKSSvIsca6NtN8DWJiVqjx4B97CB/mEnSK3hyiMPQKXKDwquRreY0rks0U X5KWsbU1wFNRECOgllXqqkEAOvp6jIoWmh+nGAosXfDhIMb7RUpRHdBnRw24hZ82 HBTEEtymfiHzrNNIyJupg/5kryFRkpWlMJSBkCr0gTcdvT5ElU7OyUkycMPGVcU= =aIj6 -----END PGP SIGNATURE----- --Apple-Mail=_7F54715D-A8B2-4EE2-B793-0EAF6727D436-- From nobody Wed Jul 5 14:50:48 2017 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 8A74813169F for ; Wed, 5 Jul 2017 14:50:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 P7djlY_p0tBU for ; Wed, 5 Jul 2017 14:50:45 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 D75BB131555 for ; Wed, 5 Jul 2017 14:50:44 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id k67so2739940wrc.2 for ; Wed, 05 Jul 2017 14:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=n7Uj+wEAGXX/G8J9CjrOGZSLPyj4ynHDMAEMRr+D35I=; b=iBZ4ZbLMhf05iQC/UApEhCUka5TLjn+DkdPmaFKMEIchwlwUegSjLQoshCqZflgOih DqmQ8rVJq21XbD35SpC92++yecYNfYBA4XspQwxZ9wwA8xActtRJkeZlCFHZBK1+Hbxr 7snQrwaTQSc6VtGIv2KmhsMlT6LYM6x2avok/73u6NQ4QSEwapo2EzzSLw775CTd9a1g O/OmweP38Vv1beESTx/iddSEHXx/txdkM6i5JMnskIMMopOZWL6qj2Leep1P7hYX2Utt VEhpcCGQfgqTpDZoaP0J+joLXo2lcAOJjxI6leKMzoXIXeptnaU3Hg0YwM5N3nQy5sEK mp2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=n7Uj+wEAGXX/G8J9CjrOGZSLPyj4ynHDMAEMRr+D35I=; b=IB2SwBa7IUCzRtx+aF5juMCx98m3PybdneyaES9we6WCBtjCSEu377lpX2c4GWLx4Q BUB5cpKOcBN19jjwPYQqjE9j01G3uV1gaQ00a1nmn/G9mX55FbU4U3j+d4sUb9wSNdG4 x+BssZFoBheqKEcEnc9XYEY0cZ9qYTHfjJtUw8Ls76B6ieNoedcpdRlMO3iWfcTlFSkN yXlKyRPcJlR8yKJFlmaJqRcT1fiODcoQBveT7f5cX1o8tqs9dV4hdUJP4yK2V5JvyeMA xKqqfiR1iPA9pbedzJmpS2lj0IHvCxHKrd0YhXTHWzDAsN09FV5PPjZ9pDssf4VGFL1p x3TQ== X-Gm-Message-State: AKS2vOzhVy353RVFCKBazlwQ7K877nHq0zC1ZN6hny5+nPVszIBzzC4k 3mo8q97z662bJIKvpjA= X-Received: by 10.223.136.116 with SMTP id e49mr42339341wre.14.1499291443221; Wed, 05 Jul 2017 14:50:43 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id t204sm16536604wme.2.2017.07.05.14.50.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 14:50:41 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_91B65321-3762-4B9F-A7BC-09B59EA0EA18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 6man IETF99 Agenda Message-Id: Date: Wed, 5 Jul 2017 14:50:37 -0700 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:50:46 -0000 --Apple-Mail=_91B65321-3762-4B9F-A7BC-09B59EA0EA18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The agenda can be found at https://datatracker.ietf.org/meeting/99/agenda/6man/ We tried to accommodate all of the requests we received, hopefully we = did not miss any. Please let us know if that was the case. It is organized in three sections, Working Group drafts, Active = Individual drafts, and New Individual drafts. We gave priority to the = requests in that order. Active individual drafts are drafts that have = seen active discussion on the IPv6 list, and the New Individual drafts = are ones that are new and/or have not seen a lot of discussion. We also need a minute taker and a jabber scribe. Volunteers are very = much appreciated. Thanks, Bob & Ole --Apple-Mail=_91B65321-3762-4B9F-A7BC-09B59EA0EA18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXV8uAAoJEK7rdBF357uoO00H/RQueZGfua0P0PVsgUD9fw/e wuNgH/FGIHRQoIKqZ6ylkMMuoWnIC3NTTsRCwINeK00Dv3DuEzJ7qTu8GQZbcPiL DoQgMQM3au+zRpzbboxLrsZ3Rfkb6bL1wwjnVScdYh4gmki04+8+rT1U/S/Wbik/ UMpH7bHjcombmkUkHqjkTtd33v9Inrqw38Sg92gF5slKNtHPPLI/Ri2W0F/226Jn KwIWpSjY5P5wDe+p+BZYFIv/3YU7fUr14XxMepGB53/TFcRqzMmcR/ARNr8jXOu2 1vyrVEGJImgupLowajksQXLly4bIDsBBX8rdNIUW7X6ELTAbbc5YvT46X/JYB6Q= =1vk2 -----END PGP SIGNATURE----- --Apple-Mail=_91B65321-3762-4B9F-A7BC-09B59EA0EA18-- From nobody Wed Jul 5 23:40:48 2017 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 E032412420B for ; Wed, 5 Jul 2017 23:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5qxvWMyR6KG for ; Wed, 5 Jul 2017 23:40:44 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 A359B124D6C for ; Wed, 5 Jul 2017 23:40:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id E96D4C3A for ; Thu, 6 Jul 2017 06:40:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsB-8VSGV5VX for ; Thu, 6 Jul 2017 01:40:43 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id AEC67C10 for ; Thu, 6 Jul 2017 01:40:43 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id 46so3123583uai.11 for ; Wed, 05 Jul 2017 23:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cGfy24G9U7EviVmCFO+LFpcNrC9DJaNkTLCZtxfFg5c=; b=k2euomOPyO2Mn7afhFT+JfWGhnqEyCxyiTHdvuPVR0j4WeI4UN/Vjiit83wwxDBZmC 0H95MJXOz8/FCggxNB/aHAe2aozbNkQDqyDT/6BpEMoPTYruw0YyVE2eeqG8OC/KuarE SvmGOGjcyvMaqP14oevktEeaFGGvqZJeyun2Vy9ruMxy5ZJlNszs2Bz02VRYp2FYq975 v1VpQdtPxZMVaVILjpyWRLm9WM0e3emBDT2SU5+IwLzzi/c68lyGMz08dLuSDCe+E/QO oKAhESWe/pZU2LOF1rAEyR/8hmZhF2M7md5MytDLUXgzlMX2VqaRy71rnpKO2pQoxy23 WHgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cGfy24G9U7EviVmCFO+LFpcNrC9DJaNkTLCZtxfFg5c=; b=ma6OKg0x9rCU+udwZIk9GXtdsgcWwv/oBMZ1jHL/bSVJPFi15fj4AUPg73AAUBd8wi lkdc3PpIFTquWys3rbgqPE8det0JToUTH+MfCvz5x8qU67T6DOfp5YkxlCFrUJFz6M/0 GXVsZO4D72FAgS3LklElWh3k6PGhd7KidTOBjCBO/48HVuCNqjfgnw4y5i9F6wnc39ng W0VfPd/Aj2D0A1W+tYIDpDgkpp6B0Alr7Qhy0KJlDKev5tO/vl+HiA6yFAHolQPSYqis jXwRPaleu6xgRLiwvqiaVQ9XlH9VfB9oIl6240Hwl5hMVFOKvnEcacMw3uQNMhQCtNqN CKSQ== X-Gm-Message-State: AKS2vOwMVMzSlhnhK/iVJE8awi4lKv/NBlJoJ97d0/WH/dfPeaF/rLkY ry3I37atia2i5AlFPyvPIjSu2IgFNCGJ4FSq+wFClvOmkvkVUykYQUq35j1wTF0ifBMMDGICCAi Mj1ufS+5ZcJVfSnk= X-Received: by 10.176.23.213 with SMTP id p21mr24888453uaf.24.1499323242927; Wed, 05 Jul 2017 23:40:42 -0700 (PDT) X-Received: by 10.176.23.213 with SMTP id p21mr24888450uaf.24.1499323242757; Wed, 05 Jul 2017 23:40:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Wed, 5 Jul 2017 23:40:42 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: David Farmer Date: Thu, 6 Jul 2017 01:40:42 -0500 Message-ID: Subject: Re: To: Bob Hinden Cc: IPv6 List Content-Type: multipart/alternative; boundary="f403043c35ac49dda00553a065f6" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 06:40:47 -0000 --f403043c35ac49dda00553a065f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 3:34 PM, Bob Hinden wrote: > Hi David, > > > On Jul 3, 2017, at 1:22 PM, David Farmer wrote: > > > However, I still think the following paragraph is still too easily > misunderstood to imply subnets must be /64 or 64 bits for both address > generation and on-link determination. > > > > Interface Identifiers are 64 bit long except if the first three bits > > of the address are 000, or when the addresses are manually > > configured, or by exceptions defined in standards track documents. > > The rationale for using 64 bit Interface Identifiers can be found in > > > > [RFC7421]. An example of a standards track exception is [RFC6164] > > that standardises 127 bit prefixes on inter-router point-to-point > > links. > > > > > > How about a note clarifying the intent of the this paragraph, something > like this; > > > > Note: While the previous paragraph does imply 64 bit subnet > prefixes > > are typically assigned to most links. It does not imply anything > > about what portion, if any, of a subnet is considered to be > on-link, > > see Section 2.1 for more discussion. However, Router Advertisemen= ts > > [RFC4861] specifying 64 bit on-link prefixes are typically > > configured on most links. > > Now that the text you refer to is in Section 2.4.1. "Interface > Identifiers=E2=80=9D, it is about Interface Identifiers, very little is s= aid about > prefixes (except that IIDs are required to be unique on a prefix, but eve= n > that is about IIDs). I don=E2=80=99t think it is implying anything one w= ay or > about on-link properties. I think that is covered pretty well in the new > paragraph in Section 2.1 "Addressing Model=E2=80=9D that includes the lin= k to > RFC5942. > As long as the others that who were insisting that the statement "IIDs MUST be 64" means that subnets must be 64 bits for both address generation and on-link determination are satisfied that this is not the case for on-link determination based on what has been added to section 2.1, then I could live without this. However, I like the idea of having some kind of recommendation for the on-link prefix. I don't think there is guidance anywhere else as to what the on-link prefix should normally be, at least explicitly, and the addressing architecture seems like as good of a place as any to recommend something in this regard. Instead of directly recommending 64 bits, maybe in section 2.1 recommend that in most cases on-link prefixes are configured the same as the subnet prefixes they are associated with. Combined this with 64 bit IIDs and therefore 64 bit subnet prefixes, you get a recommendation for 64 bit on-link prefixes in most cases. While IIDs were the primary controversy, there were several other points raised during the Last Call discussion, is there a plan to revisit any of these as well? Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --f403043c35ac49dda00553a065f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 5, 2017 at 3:34 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
Hi= David,

> On Jul 3, 2017, at 1:22 PM, David Farmer <farmer@umn.edu> wrote:

> However, I still think the following paragraph is still too easily mis= understood to imply subnets must be /64 or 64 bits for both address generat= ion and on-link determination.
>
>=C2=A0 =C2=A0 Interface Identifiers are 64 bit long except if the first= three bits
>=C2=A0 =C2=A0 of the address are 000, or when the addresses are manuall= y
>=C2=A0 =C2=A0 configured, or by exceptions defined in standards track d= ocuments.
>=C2=A0 =C2=A0 The rationale for using 64 bit Interface Identifiers can = be found in
>
>=C2=A0 =C2=A0 [RFC7421].=C2=A0 An example of a standards track exceptio= n is [RFC6164]
>=C2=A0 =C2=A0 that standardises 127 bit prefixes on inter-router point-= to-point
>=C2=A0 =C2=A0 links.
>
>
> How about a note clarifying the intent of the this paragraph, somethin= g like this;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Note: While the previous paragraph does impl= y 64 bit subnet prefixes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are typically assigned to most links. It doe= s not imply anything
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about what portion, if any, of a subnet is c= onsidered to be on-link,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0see Section 2.1 for more discussion. However= , Router Advertisements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC4861] specifying 64 bit on-link prefixes= are typically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0configured on most links.

Now that the text you refer to is in Section 2.4.1. "Interface Identif= iers=E2=80=9D, it is about Interface Identifiers, very little is said about= prefixes (except that IIDs are required to be unique on a prefix, but even= that is about IIDs).=C2=A0 I don=E2=80=99t think it is implying anything o= ne way or about on-link properties.=C2=A0 I think that is covered pretty we= ll in the new paragraph in Section 2.1 "Addressing Model=E2=80=9D that= includes the link to RFC5942.

As long = as the others that who were insisting that the statement "IIDs MUST be= 64" means that subnets must be 64 bits for both address generation an= d on-link determination are satisfied that this is not the case for on-link= determination based on what has been added to section 2.1, then I could li= ve without this.

However, I like the idea of havin= g some kind of recommendation for the on-link prefix.=C2=A0 I don't thi= nk there is guidance anywhere else as to what the on-link prefix should nor= mally be, at least explicitly, and the addressing architecture seems like a= s good of a place as any to recommend something in this regard.=C2=A0
=

Instead of directly recommending 64 bits, maybe in= section 2.1 recommend that in most cases on-link prefixes are configured t= he same as the subnet prefixes they are associated with.=C2=A0 Combined thi= s with 64 bit IIDs and therefore 64 bit subnet prefixes, you get a recommen= dation for 64 bit on-link prefixes in most cases.

While IIDs were the primary controversy, there were several other poi= nts raised during the Last Call discussion, is there a plan to revisit any = of these as well?

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043c35ac49dda00553a065f6-- From nobody Thu Jul 6 08:27:48 2017 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 106D11201FA for ; Thu, 6 Jul 2017 08:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 8X0daRV1gmTK for ; Thu, 6 Jul 2017 08:27:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 5108712EBF4 for ; Thu, 6 Jul 2017 08:27:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v66FRgP9003349 for ; Thu, 6 Jul 2017 17:27:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5B813202D00 for ; Thu, 6 Jul 2017 17:27:42 +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 526C0202CC3 for ; Thu, 6 Jul 2017 17:27:42 +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 v66FRfUL012530 for ; Thu, 6 Jul 2017 17:27:42 +0200 Subject: Re: To: ipv6@ietf.org References: <7370FF51-5B19-49BB-A849-435B11F9A2CC@gmail.com> From: Alexandre Petrescu Message-ID: <5aa80068-1d9d-909a-49db-aa6480a1d268@gmail.com> Date: Thu, 6 Jul 2017 17:27:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7370FF51-5B19-49BB-A849-435B11F9A2CC@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:27:47 -0000 Hi, There is s typo in there: > 8. Differences from RFC 4291 ^^^^ > > This document has the following changes from RFC2464, "Transmission > of IPv6 Packets over Ethernet Networks ". Numbers identify the > Internet-Draft version that the change was made.: There is a question about this: > 4. Stateless Autoconfiguration > > The default approach to create stable Interface Identifiers > [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet > interface should be based on [RFC7217]. > > It is not recommended that Interface Identifiers for an Ethernet > interface be based on stable IEEE MAC-layer addresses. The question is the following: in case I manually change the MAC address on the interface, will SLAAC form a new address based on that MAC address that I create? I am not asking whether it is recommended or not (because I understand the above text recommends against MAC-in-IP). But I am asking whether or not when I manually change the MAC address will SLAAC generate a new address? By 'MAC address' I mean a 48bit number that can be generated out of the blue (1234...), or can be even starting with an OUI reserved in oui.txt. Alex Le 09/01/2017 à 21:24, Bob Hinden a écrit : > Hi, > > I published a new version of rfc2464bis . Links below. > > This draft brings in the two updates and errata. The changes include: > > Incorporate update from draft-ietf-6man-default-iids > (currently in RFC Editor queue). Revised Section 4 to say > IIDs should be formed based on RFC7217 and that it not > recommended to use hardware based IIDs. > > Incorporate update from RFC6085. Added to Section 7 that an > IPv6 multicast packet may be mapped to a unicast Ethernet > Link layer address and that nodes receiving packets with this > address mapping should not drop these packets. > > Updates to resolve the open Errata on RFC2464. These are: > > Errata ID: 430: Correct reference to EUI-64. Note, the > corrected URL specified in the Errata isn't working, the > reference now points to one that does work. > > Errata ID: 4855: This errata is not correct, and will be > marked as rejected. No change is required. Also, the > text that this Errata proposed to change was removed when > the update from draft-ietf-6man-default-iids was > incorporated. > > Editorial changes. > > A diff from the previous version can be found at: > > https://tools.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc2464bis-01.txt > > I plan to send separate emails on each update, explaining the changes and asking a few questions. > > This is part of the project to move the core IPv6 specifications to Internet Standard. > > Thanks, > Bob > >> >> A new version of I-D, draft-hinden-6man-rfc2464bis-01.txt >> has been successfully submitted by Robert M. Hinden and posted to the >> IETF repository. >> >> Name: draft-hinden-6man-rfc2464bis >> Revision: 01 >> Title: Transmission of IPv6 Packets over Ethernet Networks >> Document date: 2017-01-09 >> Group: Individual Submission >> Pages: 9 >> URL: https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc2464bis-01.txt >> Status: https://datatracker.ietf.org/doc/draft-hinden-6man-rfc2464bis/ >> Htmlized: https://tools.ietf.org/html/draft-hinden-6man-rfc2464bis-01 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-rfc2464bis-01 >> >> Abstract: >> This document specifies the frame format for transmission of IPv6 >> packets and the method of forming IPv6 link-local addresses and >> statelessly autoconfigured addresses on Ethernet networks. It also >> specifies the content of the Source/Target Link-layer Address option >> used in Router Solicitation, Router Advertisement, Neighbor >> Solicitation, Neighbor Advertisement and Redirect messages when those >> messages are transmitted on an Ethernet. >> >> This document replaces RFC 2464 "Transmission of IPv6 Packets over >> Ethernet Networks", which will become historic. >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Thu Jul 6 08:43:07 2017 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 A37EA1317CF for ; Thu, 6 Jul 2017 08:43:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2Aytc2-Yp-ZN for ; Thu, 6 Jul 2017 08:43:03 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 3DF9713153C for ; Thu, 6 Jul 2017 08:43:03 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id c11so8064870wrc.3 for ; Thu, 06 Jul 2017 08:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=iyfTiCDwSehqZlrdhc6u3hWD8moFUjShNDO83nisCXA=; b=WJ7yrrw0HGjPO9hmhn1tL/PRU0WjpjJNXtURaOJ8+BhZCGgMDB0+XJ0pFTyfRaKGL8 EcU9GerfBMqlYPursi+n+zO4CLaKWXLFJtmzga1aZxTgpdXb1JVTGjwaNfSk8rjgnQlV eFXj55mNATbE1RZ8clMx5S9e5QplrxviUMonvWhiJxbN0jDi6GUOD9OyFJPIXTdieObb thbP97Ipu8+TOot3zSu+Kr65gGszfHoRt6tVNrZlic/o4HqeuJWVukPxtLMMsbu5U1ne iH738In+ZYkrE3Q7jwnlnASMftaH9WrwhjWWGAG7ukp6hmKIY+KqeHP8m1edHNPcCvUx HiIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=iyfTiCDwSehqZlrdhc6u3hWD8moFUjShNDO83nisCXA=; b=OKoEq9RsyxXMfZVUnPABgfkh8dkxJefIjyA6NZjauWJi5pJUbMvCq4Gb0mrsTNqrOf boWXaw/iIaXCh/1WYUSgVCGNSYD4oE+9iKBOWXU7fpd4Fk/zBHNQrLpNWg2d5zfSwrtX lda+mMqlHEW+mJgTNGKLyTNTlHdcC2j5gZgekzisr5RPWHMNIu4/UpDAt0jS8GDw+iiE it5qCFz5jXxbR+qd3zUdw5brp9GWZa2E33m1uipUWkmCZL69m0QruLKuVMuHtCKG+6ls yZ8Gl3NMFVI5m9YdJ08872MVWDZ2HwZp/KtVfbEHI9iQyfsavT7kmfOy5JGjqvzyZ/4i c/0A== X-Gm-Message-State: AIVw113hxEI/Pnl/DqvuMlWWRfRxk4TkifBCh00cl2TetSWMO9iWv94v tZtguzbojGc8akeXDZ8= X-Received: by 10.28.107.131 with SMTP id a3mr6230584wmi.60.1499355780374; Thu, 06 Jul 2017 08:43:00 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:8f1:49a4:9574:af8c? ([2601:647:4d01:db10:8f1:49a4:9574:af8c]) by smtp.gmail.com with ESMTPSA id 139sm728959wmq.16.2017.07.06.08.42.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 08:42:55 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_9883975B-20F9-41CD-AA72-6C853420D5A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: I-D Action: draft-ietf-6man-maxra-03.txt Date: Thu, 6 Jul 2017 08:42:49 -0700 References: <149912373515.15965.2496263529110027605@ietfa.amsl.com> Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= To: IPv6 List Message-Id: <44A66E3C-E15E-4E8F-902F-26AEB83DBED6@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:43:06 -0000 --Apple-Mail=_9883975B-20F9-41CD-AA72-6C853420D5A8 Content-Type: multipart/alternative; boundary="Apple-Mail=_79C913A0-C60D-4AF6-A94A-EEC94438E167" --Apple-Mail=_79C913A0-C60D-4AF6-A94A-EEC94438E167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The authors think this new draft closes issues raised in the w.g. last = call. Given the time since the last draft, we want to the w.g. to take = a look before advancing it to the IESG. Please let us know if you see = any remaining issues. If we don=E2=80=99t hear any issues, we plan to advance it next Tuesday. Thanks, Bob & Ole > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-6man-maxra-03.txt > Date: July 3, 2017 at 4:15:35 PM PDT > To: > > Cc: ipv6@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > 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-03.txt > Pages : 6 > Date : 2017-07-03 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-maxra-03 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-maxra-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-maxra-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_79C913A0-C60D-4AF6-A94A-EEC94438E167 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

The authors think this new draft closes issues raised in the = w.g. last call.  Given the time since the last draft, we want to = the w.g. to take a look before advancing it to the IESG.   Please = let us know if you see any remaining issues.

If we don=E2=80=99t = hear any issues, we plan to advance it next Tuesday.

Thanks,
Bob & Ole


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-ietf-6man-maxra-03.txt
Date: = July 3, 2017 at 4:15:35 PM = PDT
To: = <i-d-announce@ietf.org>
Cc: ipv6@ietf.org


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
=             &n= bsp;           &nbs= p;Jouni Korhonen
=             &n= bsp;           &nbs= p;Samita Chakrabarti
=             &n= bsp;           &nbs= p;Erik Nordmark
=             &n= bsp;           &nbs= p;Andrew Yourtchenko
Filename =        : = draft-ietf-6man-maxra-03.txt
Pages =           : 6
= Date =            : = 2017-07-03

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 are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-6man-maxra-03
https://datatracker.ietf.org/doc/html/draft-ietf-6man-maxra-03<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-maxra-03

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

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

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

= --Apple-Mail=_79C913A0-C60D-4AF6-A94A-EEC94438E167-- --Apple-Mail=_9883975B-20F9-41CD-AA72-6C853420D5A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXlp5AAoJEK7rdBF357uojqMH+wR9yPHylTlbLmY+7nkQfyTx ZEJggQjQUoJ1pSAE8ttmb5RcowPIOInZ0h3Qi3v3lGqxyrZu2jII2ypZpu5+tYd4 Kb+b7A2HuGqBKVmHS7J6wawmuuzaGxdQjftYYOA+pEeB4YPkogW2qt7l87xwF32q +2e1q2E6QHPJaWH1M4k2MKGx6EEjgS5gYl+DnSsAk/QtMxYY6ftHLu9ciZ9LFfMl /WwpoEEcrcLsqAc3T9EeBxIcda4H5TnaVOZ+OB+pzODK8gZxnCgUQ5NAPbqKbqY+ 6cYQhbDL/DUrc6XOSKWey7H51HNmpHiCLH7yTOuEsYWmgAX7tdlIvYeOAEdAhz8= =xXZr -----END PGP SIGNATURE----- --Apple-Mail=_9883975B-20F9-41CD-AA72-6C853420D5A8-- From nobody Thu Jul 6 12:12:15 2017 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 D8321126C3D for ; Thu, 6 Jul 2017 12:12:13 -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] 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 ienIHGg9fos0 for ; Thu, 6 Jul 2017 12:12:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3D1316E3 for ; Thu, 6 Jul 2017 12:12:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dTCC8-0000DqC; Thu, 6 Jul 2017 21:12:08 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> In-reply-to: Your message of "Thu, 6 Jul 2017 01:40:42 -0500 ." Date: Thu, 06 Jul 2017 21:12:07 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 19:12:14 -0000 I find the presentation in Sections 2.4, 2.4.1, and 2.5 very confusing. Technically, the text is not wrong, but I really wonder if for somebody new to IPv6 we should explain the address architecture this way. Section 2.4 starts by explaining that all addresses have a subnet prefix / IID split. This reinforces the IPv4 notion that address assignment and router are connected. For extra confusion it describes how some hosts may not be aware of the split. Then Section 2.4.1 says "It is recommended that the same interface identifier not be assigned to different nodes on a link." Later Section 2.5 says that some addresses that look like unicast addresses are actually anycast addresses and then Section 2.5 has a lot of confusing text on how anycast is supposed to work. In practice, ND just has an 'O' flag which essentially specifies an anycast address when clear. Practical suggestion, remove all of the routing talk from Section 2.5, redefine anycast to be within a single subnet and move 2.5 to be just before 2.4.1 But the main issue is that Section 2.4.1 implicitly talks about SLAAC without actually saying so. And then in the middle of a sentence, it say, oh yeah, if you are doing manual configuration, all this doesn't apply. I assume that DHCPv6 IA_NA is considered manual configuration in this context. Otherwise there is no sensible way of reading that RFC. Practical suggestion, in Section 2.4, describe that address assignment is separate from routing. That onlink prefixes can learned from RA or be configured manually. Then that some address assignment mechanisms, such as SLAAC have an prefix / IID split. Other assignment mechanisms such as manual config (and RFC 6164) or DHCPv6 IA_NA treat the address as an opague 128-bit value. (then have the section on anycast) And then the section that describes how IIDs are used in SLAAC. From nobody Thu Jul 6 13:43:29 2017 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 BD9EF131882 for ; Thu, 6 Jul 2017 13:43:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WAsOKXNNyC7W for ; Thu, 6 Jul 2017 13:43:26 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 08DD1131563 for ; Thu, 6 Jul 2017 13:43:26 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c73so6387219pfk.2 for ; Thu, 06 Jul 2017 13:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cZK509lpt87xvrpqUqVRyuy9XHSbJSWtnxH6BCLGtoI=; b=OcqOFdq5o9YAtfMDRw6/aUv0+gKkPxPD06mPUot9+Z2ADgza/EF54+4Dn3UAQG0B/s h5Kj1FDaNwQfWO/Ujgmzp8fUGEPJ0trv9agvYtUzs4/WVcXgffaWNvxTQghVDSik28nT ECYBMQKQc9vIlSDnid/Y+8adq76gcJrEd4CJlFrC0lMTGSyCqzV4pXjgPgQm0CiZnIQV 6rMKF43X1Tzz8a5Az+LNzYEMZ5EIWxd2FiRZcF53qf9e65lHCT6YvwzAgEiwsHs5Qlqz s5ry5XiAjFOZdDqg1VJz37qX3kuj+cKJg0EXqbPRwswtjoglxszPRCNSdDkvAb8sOsn7 FcpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cZK509lpt87xvrpqUqVRyuy9XHSbJSWtnxH6BCLGtoI=; b=J+2SvqRNWIEe/LZQJPcrfxGH96SI3p2tITcYaXevb5IfykzzNKQPqHWi7HLGgfKoND 2y70qNBTi/JBEQooxuZOyR0vGe1AElqmyNVa2qYTnEyubjKUgAgM8v2JUhX0lS2OH1ng Qkr70fJIEJO4YgBehqqd0GJiaJNbzBWo9S/j3dgf7R3MB8atkPy2xOx+wQ5xgBNOBX8a BQRGlgPo2VhEW4Q/xrj7H7avon7p5MhYWa5x/j6L8xEjZm0NESyoNhgN19eHR2cpBD1W r/ce7pS0zD1iTz/KnbeZhMt8P08zHognr4WBhLZt7c4fK/e5chH1INGcmnu5TcSMBg0S +Nbw== X-Gm-Message-State: AIVw111J4Uq1/NKQ8s6x6LdhsFW0TQgAXdiEis2eBBM89tSVE18ovbkv L4knmLVVAkQgnwqA X-Received: by 10.84.231.197 with SMTP id g5mr17242457pln.71.1499373805464; Thu, 06 Jul 2017 13:43:25 -0700 (PDT) Received: from ?IPv6:2406:e001:3f46:1:28cc:dc4c:9703:6781? ([2406:e001:3f46:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a79sm2185849pfj.5.2017.07.06.13.43.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 13:43:24 -0700 (PDT) Subject: Re: To: Philip Homburg , ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 7 Jul 2017 08:43:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:43:28 -0000 On 07/07/2017 07:12, Philip Homburg wrote: ... > redefine anycast to be within a single subnet What does that mean? I can't attach any meaning to those words. Apart from that, I believe it's way past time to stop wordsmithing this document. It now seems to to define reality, including the reality that IPv6 routing is classless. Brian From nobody Thu Jul 6 14:22:20 2017 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 593F1131963 for ; Thu, 6 Jul 2017 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEnbUNw4tJ4J for ; Thu, 6 Jul 2017 14:22:16 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 6760112EC2B for ; Thu, 6 Jul 2017 14:22:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id E6156CDE for ; Thu, 6 Jul 2017 21:22:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5hwTMlI3xaj for ; Thu, 6 Jul 2017 16:22:15 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id B3534D1D for ; Thu, 6 Jul 2017 16:22:15 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 64so4928452uag.8 for ; Thu, 06 Jul 2017 14:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aPR4Rb5KcGr3pB/RvMPH4HT1Pemxpqles08KVdD9R4w=; b=fBGXcEWdOOqTOzj0bAV2Q2xLErUFNdsANCIcR0d/RyWoFM1feFhPSXP6cW7LmyGTRq +gaCTS9/obulp6H4cmKXC5l+52ABjcOv+Y4g6l0fblr/sxMa0sAvZ30bNGFSHPnuDgQt Js2ALwzxE4L44ApEGyvM7J5otZKoUmxzzesf0SnTp3SJFCgiOMpSeqO6i/ZPBM0ykLBe vEk6of2jQjvZlb57eszhTsxcPp3Z0Akwm8k28kg/k4UjpqIfXOb0R8+gyyDSvDcL4Ek7 4S+XXsy31PsOsRbwGVfTc1nYX84N5bl63bIq2718zpHG+i0GesKnXsIp8Nn9z32BjnVX aQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aPR4Rb5KcGr3pB/RvMPH4HT1Pemxpqles08KVdD9R4w=; b=jhdNAqybhaSqBxnXoEazw33W69ntSo/hoJyOZJJ75sQKpPc5Rtf7CFqu27l4hVxVgM VcC1b3QQ2JGK/BsFceC7LuRg/y7e6E2ALuZ2dimL8OFPljTn/TsP/QEeesEtgV+0uKiL PcGt8Oy9jjB4kw0SUctSjpE1evg95xZjoLXF9SZipM3JCwCUAbPQVb2aeTVRlb44sQPy MKjUU1b6/9kgVScG14SLmHigD7pcy1cTHGKeKXANVfRrv0k2vyPBCzqhSb1Tzm9rbh3N Q5233AHDSrEmkIun3Vjz4Hyvza5G5Jjmuz/JGZMi9tu4EKTdn7nVhD2BO9X+jwPFlwi9 kymQ== X-Gm-Message-State: AKS2vOwmcIypMKWJSpGTe7JX6iNWGJ8za6gtgIuYD7hxySHYf5YEclRj VDWRMXyDm/AJ3/RzAu7qVg+UxXxopAAxDAYDLHxuhhBy5Iw7ffArbvlikgtE9dnPLONTRdXTO1z 4+BcKLEiMdFy/oig= X-Received: by 10.176.23.213 with SMTP id p21mr26725818uaf.24.1499376135000; Thu, 06 Jul 2017 14:22:15 -0700 (PDT) X-Received: by 10.176.23.213 with SMTP id p21mr26725812uaf.24.1499376134790; Thu, 06 Jul 2017 14:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Thu, 6 Jul 2017 14:22:14 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: David Farmer Date: Thu, 6 Jul 2017 16:22:14 -0500 Message-ID: Subject: Re: To: Brian E Carpenter Cc: Philip Homburg , 6man WG Content-Type: multipart/alternative; boundary="f403043c35ace6386f0553acb5d6" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:22:18 -0000 --f403043c35ace6386f0553acb5d6 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 3:43 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 07/07/2017 07:12, Philip Homburg wrote: > ... > > redefine anycast to be within a single subnet > > What does that mean? I can't attach any meaning to those words. > > Apart from that, I believe it's way past time to stop wordsmithing this > document. > It now seems to to define reality, including the reality that IPv6 routing > is classless. > I'm sympathetic to Philip's thesis; Technically, the text is not wrong, but I really wonder if for somebody new to IPv6 we should explain the address architecture this way. But the unfortunate answer is; that is not the purpose of this document. This document is a specification, not a document meant to teach anyone about IPv6. In fact in the Introduction the document says this is a specification, but maybe it would help if it also said what it isn't, that is an Introduction to IPv6 and maybe even include a reference to the ISOC IPv6 tutorial. https://www.internetsociety.org/tutorials/exploring-ipv6/ Put another way, you don't learn to drive by reading the state traffic ordinances, you read a drivers manual or guide, this document is much more the state traffic ordinances in this analogy, than it is intended to be a drivers manual or guide. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403043c35ace6386f0553acb5d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 6, 2017 at 3:43 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
On 07/07/2017 07:12, Philip Homburg wrote:
...
> redefine anycast to be within a single subnet

What does that mean? I can't attach any meaning to those words.

Apart from that, I believe it's way past time to stop wordsmithing this= document.
It now seems to to define reality, including the reality that IPv6 routing<= br> is classless.

I'm sympathetic to Ph= ilip's thesis;

=C2=A0 Technically, the text is not wrong, but I really wonder if for som= ebody
=C2=A0 new to IPv6 we should explain the address architecture this way.
=C2=A0
But the unfortunate answer is; that is = not the purpose of this document. This document is a specification, not a d= ocument meant to teach anyone about IPv6. In fact in the Introduction the d= ocument says this is a specification, but maybe it would help if it also sa= id what it isn't, that is an Introduction to IPv6 and maybe even includ= e a reference to the ISOC IPv6 tutorial. =C2=A0

https:/= /www.internetsociety.org/tutorials/exploring-ipv6/

Put another way, you don't learn to drive by reading the state= traffic ordinances, you read a drivers manual or guide, this document is m= uch more the state traffic ordinances in this analogy, than it is intended = to be a drivers manual or guide.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapol= is, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043c35ace6386f0553acb5d6-- From nobody Thu Jul 6 14:24:23 2017 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 CDE0812EC2B for ; Thu, 6 Jul 2017 14:24:21 -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] 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 iT71rWJBaypK for ; Thu, 6 Jul 2017 14:24:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 975EA12EA6A for ; Thu, 6 Jul 2017 14:24:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dTEFy-0000ECC; Thu, 6 Jul 2017 23:24:14 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> In-reply-to: Your message of "Fri, 7 Jul 2017 08:43:30 +1200 ." Date: Thu, 06 Jul 2017 23:24:14 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:24:22 -0000 In your letter dated Fri, 7 Jul 2017 08:43:30 +1200 you wrote: >On 07/07/2017 07:12, Philip Homburg wrote: >... >> redefine anycast to be within a single subnet > >What does that mean? I can't attach any meaning to those words. It should be obvious that Section 2.5 really tries to define 2 separate concepts. If other people find those sections readable, then fine with me. To me this reads like a piece of code from the 90s, that has seen 2 decades of hacking. Techincally it does the right thing, but only an expert recognizes all the magic hidden inside. From nobody Thu Jul 6 14:55:56 2017 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 37AC9124217 for ; Thu, 6 Jul 2017 14:55:54 -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] 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 108ooBG_Rhry for ; Thu, 6 Jul 2017 14:55:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D1C951200E5 for ; Thu, 6 Jul 2017 14:55:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dTEka-0000FlC; Thu, 6 Jul 2017 23:55:52 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> In-reply-to: Your message of "Thu, 6 Jul 2017 16:22:14 -0500 ." Date: Thu, 06 Jul 2017 23:55:48 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 21:55:54 -0000 >But the unfortunate answer is; that is not the purpose of this document. >This document is a specification, not a document meant to teach anyone >about IPv6. In fact in the Introduction the document says this is a >specification, but maybe it would help if it also said what it isn't, that >is an Introduction to IPv6 and maybe even include a reference to the ISOC >IPv6 tutorial. It used to be that RFCs were quite readable. It makes me sad if we now produce RFCs that essentially require you to read all the previous versions of the same RFC and the mailing list discussions surrounding it, to understand what the RFC really tries to say. If somebody needs auxiliary materials just to understand an RFC as basic as addressing architecture, then we are only a small step removed from the mostly unreadable telco specs. From nobody Thu Jul 6 17:10:21 2017 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 B496A12F28A for ; Thu, 6 Jul 2017 17:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 pCkH5HVYTAPQ for ; Thu, 6 Jul 2017 17:10:18 -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 D70F112EC4A for ; Thu, 6 Jul 2017 17:10:17 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r125so9469706vkf.1 for ; Thu, 06 Jul 2017 17:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=obv+EZ6//c4YBwoMfyLpFQGieoXmrhtlQhO7O2rQHbI=; b=k68NAd2uKTYQ0ro3hgzRkh88neqLmvvuPaIW0A8K3mFiyqN6/pgIUSN8ttiuxvlUrg sNPIwWYFU6ZJQJuSC0vIxzPIv16huau+838S+WdJBYBT/ecS2UvasswKC86Beg9WHxvB kbHrsGjZ7BknebmU3KDBYRVbL8bKkA/rkhvgEacZgx/tTtqRjNFFGHYs+WlXPp8DoC0n WoN9n7puIX1tets2mclpL+PomaYRvdirn8RvTggWbJ1DHwTgdQ6pzU5hdbwRJKForGvk h93fFoGnqXAEDswmf72Lu0Kv/c/zcnz+Ju3Upg/0oAHmwA+AjuGaHeXGys/Cey6hsrtO QaGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=obv+EZ6//c4YBwoMfyLpFQGieoXmrhtlQhO7O2rQHbI=; b=n6NocLo6pW9F0NAssTdYpGZuc+eupaxNvREoq3csan+qs1rJK/9URAMIZhBYesP9es 1fBcxXXElSmyKxByAD8EpBw9/m350hFBIZDlZ8RXGxtQDDxKoD6EpEPNNy08rOBJyOs5 Ga3iataTXpGi3dgM0xFdEmwwtbQ6ku7KIGZ47U0x75F7KLymfc/XR/fdGCH8nep83vjY gjcbA7IfBqy9RdzZmavdmxCatYx+CeZKnFEqLOpNnK1jad/XAX3l5KqAzW3ulmzwqAMN 8L5RQGKmXinNavJyUmkoNKRzZdm4Pu00712S9vRK9imAn5Wbid52HiuZwvQnvamxS+CL 8mwg== X-Gm-Message-State: AKS2vOxcZJW9d/Maqk81HwXGg+Kiix9uKeCc7LqC4CtogRbScRIFQnR6 nHkttwDJw/D25U5wkQXUj/GBdbDOfA== X-Received: by 10.31.180.80 with SMTP id d77mr28520895vkf.110.1499386216906; Thu, 06 Jul 2017 17:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Thu, 6 Jul 2017 17:09:46 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Mark Smith Date: Fri, 7 Jul 2017 10:09:46 +1000 Message-ID: Subject: Re: To: David Farmer Cc: Bob Hinden , IPv6 List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 00:10:20 -0000 On 6 July 2017 at 16:40, David Farmer wrote: > > > On Wed, Jul 5, 2017 at 3:34 PM, Bob Hinden wrote: >> >> Hi David, >> >> > On Jul 3, 2017, at 1:22 PM, David Farmer wrote: >> >> > However, I still think the following paragraph is still too easily >> > misunderstood to imply subnets must be /64 or 64 bits for both address >> > generation and on-link determination. >> > >> > Interface Identifiers are 64 bit long except if the first three bit= s >> > of the address are 000, or when the addresses are manually >> > configured, or by exceptions defined in standards track documents. >> > The rationale for using 64 bit Interface Identifiers can be found i= n >> > >> > [RFC7421]. An example of a standards track exception is [RFC6164] >> > that standardises 127 bit prefixes on inter-router point-to-point >> > links. >> > >> > >> > How about a note clarifying the intent of the this paragraph, somethin= g >> > like this; >> > >> > Note: While the previous paragraph does imply 64 bit subnet >> > prefixes >> > are typically assigned to most links. It does not imply anything >> > about what portion, if any, of a subnet is considered to be >> > on-link, >> > see Section 2.1 for more discussion. However, Router >> > Advertisements >> > [RFC4861] specifying 64 bit on-link prefixes are typically >> > configured on most links. >> >> Now that the text you refer to is in Section 2.4.1. "Interface >> Identifiers=E2=80=9D, it is about Interface Identifiers, very little is = said about >> prefixes (except that IIDs are required to be unique on a prefix, but ev= en >> that is about IIDs). I don=E2=80=99t think it is implying anything one = way or about >> on-link properties. I think that is covered pretty well in the new >> paragraph in Section 2.1 "Addressing Model=E2=80=9D that includes the li= nk to >> RFC5942. > > > As long as the others that who were insisting that the statement "IIDs MU= ST > be 64" means that subnets must be 64 bits for both address generation and > on-link determination are satisfied that this is not the case for on-link > determination based on what has been added to section 2.1, then I could l= ive > without this. I'm confused by this and have been on the occasions it has been discussed. I also don't understand why it matters and is related to the on-link property of a subnet prefix. "2.4. Unicast Addresses" says that IIDs are 128 bits minus the size of the subnet prefix. If the subnet prefix is a /64, then the IID is 64 bits; for a /127, the IID is 1 bit in size. Of course, conversely, a 64 bit IID results in a 64 bit subnet prefix. If you're describing some other property of the bits that are not part of the subnet prefix, and that part isn't 128-subnet prefix size i.e. the IID, then IID is not the accurate term for it and it needs to be explained at least here if not in the RFC and given another name. > > However, I like the idea of having some kind of recommendation for the > on-link prefix. I don't think there is guidance anywhere else as to what > the on-link prefix should normally be, at least explicitly, and the > addressing architecture seems like as good of a place as any to recommend > something in this regard. > I'm not sure what an "on-link prefix" is in the sense of the above paragrap= h. A subnet-prefix is assigned to a link, which is a statement of where that the set of addresses (or IIDs) that fall within the subnet-prefix are present within the network topology. It is a statement to the forwarding domain as to the network location of a set or range of addresses. On-link or not for a subnet-prefix is a statement to the hosts attached to a link whether they are to try to directly reach other addresses within the subnet-prefix across the link, or whether they're to use their default router to reach them. A host doesn't have to have an address from within the subnet-prefix for it to consider destinations within the subnet-prefix reachable directly across the link. e.g. Host address: 2001:db8::1234 RA PIOs host receives : 2001:db8::/64 [on-link], 2001:db8:abcd::/64 [on-lin= k] With those RA PIOs, the host will attempt to directly send across the link to destinations 2001:db8::5678 and 2001:db8:abcd::fffe, and will do so for all addresses within the 2001:db8::/64 and 2001:db8:abcd::/64 subnet-prefixes. If the host instead had just received RA PIOs host receives : 2001:db8:abcd::/64 [on-link] Then it would only try to directly send across the link to destinations that fall within 2001:db8:abcd::/64. It would not try to directly send to destinations inside 2001:db8::/64, even though its 2001:db8::1234 address is within that same /64, as, per RFC5942, all destinations are by default off-link except for Link-Local destinations. So to me an "on-link prefix" is a subnet-prefix that hosts will attempt to send directly to across the link they're attached to, indicated to the host by RA PIOs, ICMP redirects or manual configuration on the host (per RFC5942). What you and others are describing as an "on-link prefix" sounds like something different to that. > Instead of directly recommending 64 bits, maybe in section 2.1 recommend > that in most cases on-link prefixes are configured the same as the subnet > prefixes they are associated with. Combined this with 64 bit IIDs and > therefore 64 bit subnet prefixes, you get a recommendation for 64 bit > on-link prefixes in most cases. > > While IIDs were the primary controversy, there were several other points > raised during the Last Call discussion, is there a plan to revisit any of > these as well? From nobody Fri Jul 7 02:45:30 2017 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 CFC87129AD3 for ; Fri, 7 Jul 2017 02:45: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rmeeB8Ml9g4O for ; Fri, 7 Jul 2017 02:45:28 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435671204DA for ; Fri, 7 Jul 2017 02:45:28 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 7272E2D5642; Fri, 7 Jul 2017 09:45:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B26B3E8FEBA4; Fri, 7 Jul 2017 11:45:22 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_05045585-39E0-4331-AF8C-FC6B96DEDEF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 6man IETF99 Agenda Date: Fri, 7 Jul 2017 11:45:21 +0200 In-Reply-To: Cc: Bob Hinden To: 6man WG References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 09:45:30 -0000 --Apple-Mail=_05045585-39E0-4331-AF8C-FC6B96DEDEF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Note that 6MAN is meeting the first IETF session, Monday morning 0930. Presenters, can you please ensure we have the presentations by Sunday = 1700 (local time). Best regards, Ole > On 5 Jul 2017, at 23:50, Bob Hinden wrote: >=20 > The agenda can be found at >=20 > https://datatracker.ietf.org/meeting/99/agenda/6man/ >=20 > We tried to accommodate all of the requests we received, hopefully we = did not miss any. Please let us know if that was the case. >=20 > It is organized in three sections, Working Group drafts, Active = Individual drafts, and New Individual drafts. We gave priority to the = requests in that order. Active individual drafts are drafts that have = seen active discussion on the IPv6 list, and the New Individual drafts = are ones that are new and/or have not seen a lot of discussion. >=20 > We also need a minute taker and a jabber scribe. Volunteers are very = much appreciated. >=20 > Thanks, > Bob & Ole >=20 >=20 --Apple-Mail=_05045585-39E0-4331-AF8C-FC6B96DEDEF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZX1gyAAoJEL7aWKiYQt92q+YQAJoWJaXB2r0OzfJpZe15nYmx K/+Au4N6nZQPO7HaogofkGXgUplz/RCDupzBmw7+i5VD31iiXxH0Aky6HveTso+w WhCe2RCJ5JmzLfvRiYVUqPZYGNof+hjxelzhVbjEdkDo9+NqFCsSh3G8c1n6rT98 WJGk4SrijHUCdl9x0HI3bKRXOuVw058/NTami1SoS9prhe/Wzjti/PfpkxhaxxN8 RvYsS9J8g9V4r3Yj1mzK/mgXdq6k3UZRb+2pcIfQDelKN8JNsShEl/1bAf9p2G8z 5t9SNFgu2kDckH2dc6YoEXLfldMJLKK9iPkQrH6veH/u9Ip65japPbF6PnMAXPP5 /wU7HMYhcRD2+TqavxA7XIKP8nZopMSLXoqCifKDWehylZsFKl3jn6NXJtew53ym KAPI3FUwrnj6/AucDIcFjLK5DKyGsH3GG/qf26U8W1M5ElDxHa5qFtI8k4tCtzZK /1zoWMWZCzsVozO7crPEHO4J0GH61xQ8RgGhZ7cicENo/M0JxlCDg3V8vg60zQ5Z 4cP1xOhBTLO0mioItmhYYTEz+vOknlZZLXJyOSgwUj6iTkEoMvwUayuNdEVGPv3d 4zqg/AvhsNKSsUViOx9jor/AgBqIUhhznRPFKuDPl2PHlY5xOzn1BwW/xiQUGLgW YV3zeCySLkCVLT0kijOX =VgQT -----END PGP SIGNATURE----- --Apple-Mail=_05045585-39E0-4331-AF8C-FC6B96DEDEF4-- From nobody Fri Jul 7 03:40:53 2017 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 D0789131699 for ; Fri, 7 Jul 2017 03:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQtZc3JQV1mP for ; Fri, 7 Jul 2017 03:40:49 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A312ECEF for ; Fri, 7 Jul 2017 03:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1499424046; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=KlsGJmqlgsY1gMvc0L8lPb89NltPluxSAhqpTo8YYho=; b=XxHBmFEEv5iPTrzidGy7o+0egkV0Qb2xr5vbq7nGWdLlVFMzQvnpdZtpCv8O6QDZkz79ThjJuQSzPCtM0Wfio8RTPGXL2wR4sgvFlYi8e7hPkRdeQVRfyBCzrFQPkF6FDpqkWLmlVwVFZl2uVzj927s69G+fJ6kRg8C6ItpL5cI= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0239.outbound.protection.outlook.com [213.199.154.239]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-93-Y5Re_h8SO9OG2hUDMf9Jtg-1; Fri, 07 Jul 2017 11:40:43 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1060.eurprd07.prod.outlook.com (10.163.187.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Fri, 7 Jul 2017 10:40:41 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1261.001; Fri, 7 Jul 2017 10:40:41 +0000 From: Tim Chown To: 6man WG Subject: draft-ietf-6man-rfc6434-bis-01 Thread-Topic: draft-ietf-6man-rfc6434-bis-01 Thread-Index: AQHS9w16QhA1xOfVT0ehXsDP4UG+VQ== Date: Fri, 7 Jul 2017 10:40:41 +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.3273) x-originating-ip: [2001:a88:d510:1101:5be:e06f:6c6a:9a87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1060; 20:ebCVGIPbqFsrrPBwbsquWS+COATRj8vbTbbfmUvlMHfhe1qsPMOT8fghOFnl3E/4RVYK9ClU7AOw/+fdEVRp0okmvIY5B6883u5wnN50Du5UPmU8lvs9XegL05OGH5Bh6WQDW2dWNAJEDRyNYzf0RmiQ+JngYfu+SPxB+vrpPIk= x-ms-office365-filtering-correlation-id: 53f14a49-20c7-4ea3-590c-08d4c5249d49 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1060; x-ms-traffictypediagnostic: AM3PR07MB1060: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910062)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1060; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1060; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39410400002)(39840400002)(102836003)(6116002)(50226002)(7736002)(8936002)(81166006)(25786009)(305945005)(5660300001)(82746002)(74482002)(14454004)(50986999)(8676002)(6486002)(6506006)(110136004)(38730400002)(2900100001)(478600001)(3660700001)(99286003)(230783001)(42882006)(83716003)(3280700002)(6436002)(72206003)(53936002)(6512007)(6306002)(2906002)(966005)(86362001)(5250100002)(189998001)(36756003)(33656002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1060; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <87932307F205704D988C580ACF1886E6@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2017 10:40:41.3856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1060 X-MC-Unique: Y5Re_h8SO9OG2hUDMf9Jtg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 10:40:52 -0000 SGksDQoNCldl4oCZdmUgcHVibGlzaGVkIGFuIHVwZGF0ZSB0byB0aGUgUkZDNjQzNGJpcyBkcmFm dCwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQz NC1iaXMtMDENCg0KV2UgaGF2ZSBhIHNsb3QgaW4gUHJhZ3VlIHRvIGRpc2N1c3MgdGhlIGRyYWZ0 LiBUbyBoZWxwIHNlZWQgZGlzY3Vzc2lvbiBiZWxvdyBhcmUgbGlzdHMgb2YgdGhlIG1haW4gb3V0 Y29tZXMgYXMgYSByZXN1bHQgb2YgSUVURjk4LCBjaGFuZ2VzIGluIHRoZSBuZXcgLTAxIHZlcnNp b24sIGFuZCBvcGVuIGlzc3Vlcy4NCg0KT3V0Y29tZXMgZnJvbSBJRVRGOTg6DQotIE1hZGUgTUxE djIgKGFuZCBTU00pIGEgTVVTVCwgc2F5aW5nIG5vdGhpbmcgYWJvdXQgTUxEdjENCi0gUkZDIDgx MDYgaXMgYSBNVVNUIGZvciBjbGllbnRzICh0byBlbnN1cmUgYXQgbGVhc3Qgb25lIG1ldGhvZCBz dXBwb3J0ZWQgZm9yIEROUyBjb25maWd1cmF0aW9uKQ0KLSBNb2JpbGl0eSB0ZXh0IGFkZGVkIGJh Y2sNCi0gQWRkZWQgdGV4dCBvbiBSRkM3ODQ0IGZvciBESENQIGFub255bWl0eSBwcm9maWxlcyAo bm8gbWVudGlvbiBvZiBjb25maWd1cmFiaWxpdHkpDQotIEtlcHQgUkZDIDE5ODEgYXMgYSBTSE9V TEQ7IHJldGFpbmVkIGluZm9ybWFsIFBMUE1UVUQgKFJGQzQ4MjEpIHJlZmVyZW5jZQ0KLSBESENQ LVBEIHdhcyBub3QgaW5jbHVkZWQNCg0KTmV3IGNoYW5nZXMgaW4gLTAxIHZlcnNpb246DQotIFJl b3JnYW5pc2VkIHZhcmlvdXMgc2VjdGlvbnMsIGluY2x1ZGluZyBhZGRyZXNzaW5nIGFuZCBvdGhl ciBjb25maWd1cmF0aW9uDQotIFNvbWUgdGV4dCBvbiBjb25zdHJhaW5lZCBkZXZpY2VzIGFkZGVk DQotIEFkZGVkIHRleHQgb24gWUFORy9ORVRDT05GDQotIFZhcmlvdXMgSUQgbml0cyBmaXhlZA0K LSBtRE5TL0ROUy1TRCB0ZXh0IGFkZGVkDQotIEFkZGVkIFJGQzgwMjggZ3VpZGFuY2UgYXMgYSBT SE9VTEQgaWYgZGV2aWNlIG1heSBiZSBtdWx0aWhvbWVkDQotIEVDTiBSRkMzMTY4IGFkZGVkIGFz IGEgU0hPVUxEIChub3RpbmcgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTAz IGFuZCBub25jZSB1c2UpDQoNCk9wZW4gaXNzdWVzOg0KLSBBZGQgdGV4dCBvbiBJUHY2IEVIIHBy b2Nlc3NpbmcgYnkgcmVjZWl2ZXJzDQotIEFkZCB0ZXh0IG9uIGRhbmdlcnMgb2YgYmxpbmRseSB1 c2luZyAxMjgwIE1UVQ0KLSBDaXRlIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4 LXBlci1ob3N0LTAxPyAoaW4gU2VjdGlvbiA2LjIsIHdpdGggUkZDNzkzNCkNCi0gTWFrZSByb3V0 ZXIgcmVkaXJlY3QgaG9zdCBwcm9jZXNzaW5nIGEgTVVTVD8gKFJGQzQ4NjEgc2F5cyBTSE9VTEQg aW4gc2VjdGlvbiA4LjMpDQotIEtlZXAgSnVtYm9ncmFtIHRleHQgYXMgaXM/DQotIFJldmlldyBE SENQIHZzIFJBIG9wdGlvbnMgdGV4dCAoc2VjdGlvbiA4LjQpDQoNClRoZXJlIGFyZSBtYW55IGJp dHMgb2YgdGV4dCB3ZSBjYW4gb25seSB1cGRhdGUgd2hlbiB0aGUgUkZDMjQ2MCwgMTk4MSBhbmQg NDI5MSB1cGRhdGVzIGFyZSBwdWJsaXNoZWQuDQoNClRpbSANCg0KDQoNCg== From nobody Fri Jul 7 10:40:21 2017 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 0C01F1317B6 for ; Fri, 7 Jul 2017 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RyxSBdyjBm25 for ; Fri, 7 Jul 2017 10:40:18 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 68B501317B2 for ; Fri, 7 Jul 2017 10:40:18 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id r30so32862690qtc.0 for ; Fri, 07 Jul 2017 10:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P7v60CupnhGZMMpCzJd3o5oYGwy3n672MSekoNO55UU=; b=UMHLEeFjecOQB+cvtw3+m70IagIV4GtT/oTe+V1P7XOgXeVA8l5X4AI2MV+hjthiKr CWPyHMzjgLtq5vTzVXh8RXQbxxvnVGM2Pb88chswjBV3H946D0i1B48sOaug3TAcifxG CTO5+cBeJvo612hxAImSPrnnAqLX2Q9u55WrJQDUBinUAi7lolv2eLcnNUPYVGqVaO4J hk4xKeoaHy04Qb7V6pRtfCzwxSUAwCN477qjQB819uYr6KuDDFWvi8STBKVxhcEHcYRc MK+hhpoKqOd1Ubhc9NmroRYr2zC7AGz5mcON5NPxIzz4zVG3noe/EaErDmHIXahkiqu/ u3Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P7v60CupnhGZMMpCzJd3o5oYGwy3n672MSekoNO55UU=; b=eGWt2GtaU8MdxFvRLqQ3Ci5o8LXLM9Huk6FAIFDYY7uRGiZFrcTp3Onyf+lbk9G5Rb SxPAeGBYXiZyMTMb7THfII37vK9A27FE9IwmX1hzbQ0L2XkfUfMWMYmDkGhrFNsmVWkB HzDGm5WhXrlqZYAO6nnzbeJ3nXvSLIKFZL0B32yUguX9ui7OlV3KMQbxjvHxnIKfESGB T+okzufmY2l61Woz7eOJLE7qVkqJLJ6vVhNO1rtMHZKaZbxQto7sZTN02Pqf+Kz2GH4/ ng23RMabky2TnxZ2zxW2oyKN9n7+kr0zn3taGsAfnvtgU/kL7LMEjbq3LfDBrgRDF1xK HMvg== X-Gm-Message-State: AKS2vOwGUBCacIP6dhiLKvk5Zsj8XWcbUdfRHsayBjnYfgCmEs/UZ/Wg 3dI3OqOtvusGgcSjA57Dm6JL4iiTVw== X-Received: by 10.237.43.35 with SMTP id p32mr66029298qtd.86.1499449217116; Fri, 07 Jul 2017 10:40:17 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Fri, 7 Jul 2017 10:40:16 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 7 Jul 2017 10:40:16 -0700 X-Google-Sender-Auth: 6P5avEhjMQ3euQzRMm-aLucEJe8 Message-ID: Subject: Re: To: Mark Smith Cc: David Farmer , IPv6 List , Bob Hinden Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 17:40:20 -0000 At Fri, 7 Jul 2017 10:09:46 +1000, Mark Smith wrote: > > As long as the others that who were insisting that the statement "IIDs MUST > > be 64" means that subnets must be 64 bits for both address generation and > > on-link determination are satisfied that this is not the case for on-link > > determination based on what has been added to section 2.1, then I could live > > without this. > > I'm confused by this and have been on the occasions it has been > discussed. I also don't understand why it matters and is related to > the on-link property of a subnet prefix. [...] > So to me an "on-link prefix" is a subnet-prefix that hosts will > attempt to send directly to across the link they're attached to, > indicated to the host by RA PIOs, ICMP redirects or manual > configuration on the host (per RFC5942). What you and others are > describing as an "on-link prefix" sounds like something different to > that. I can't speak for others, but I believe David's understanding of "on-link prefix" is consistent with yours. My interpretation of his comment is that the current (09) text of rfc4291bis could be misunderstood regarding this point as follows: A. According to Section 2.4.1. IIDs are 64 bit long (with some exceptions) B. Based on this, and according to the format of Section 2.4, subnet prefixes are also 64 bit long (with some exceptions) C. Some readers might jump to the conclusion from A and B that this 64-bit subnet prefix is used by hosts "to send directly to across the link they're attached to", i.e., this prefix is used as an "on-link prefix". Of course, this conclusion is wrong, not least as clarified in RFC5942. Some people (probably including you) don't see the possibility of this misunderstanding, and some others still think the misunderstanding is possible. Personally, I tend to agree with the latter group of people - I still feel the current text is not crystal clear and could be misunderstood by fresh readers. On the other hand I also tend to agree with Brian in that the wordsmith period of this doc is now over (and it's more productive to complete this task as long as we can agree on the high-level content). So I'd rather move on at this point. -- JINMEI, Tatuya From nobody Fri Jul 7 22:48:02 2017 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 E477A129AB8 for ; Fri, 7 Jul 2017 22:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 JbVm5fCX8qKF for ; Fri, 7 Jul 2017 22:47:59 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 B1FE612896F for ; Fri, 7 Jul 2017 22:47:59 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id j53so30782236uaa.2 for ; Fri, 07 Jul 2017 22:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NRgoNYxhQo/3RU5jv7NGrzjmlKr0erBKdVX1CHhv250=; b=WoGQme6/L/bQyFawkh930Gn9VS50CH9sXsGD4/Tt7Peedmn4aAXdZHu+ekYPV1ls2P 5jvwjSSNEuSsfOP1PGA/LZRlbw5RxByTYM8VbEDp8CPkPlQI22EIVufebs/RceldZJ1p CS1e63F9XIp1iDBMU5lpn++dUNN7gfggjBLgbim5XwygKmyus4njN2bDfwM+pSSqsv6G jXdiLSc6VGliuV5vd5HJZXoM5m3QeWtzgkRqdwhS+xMaC+OBAm/GuNStLU+NR24qbmn5 HpPNcDWWwVMzky9q/6nHzNai9GTtUX0FAouHX5DQ020sAAw1nVm2ct4gN57UGbosBCGZ g7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NRgoNYxhQo/3RU5jv7NGrzjmlKr0erBKdVX1CHhv250=; b=gAr7dWfWlrPh4AV39sDDFuJ08bqk5ZX/2zO5CoG5MJk7xbtPx5Fai3f/Oc0gCCCrHY z0v5p49MUcCkQaJXuUr+xZS9MgsOeFfImwN2YNL/EFl1jrb1gVvBG1t05V2Viwbv4/eH H3UEOBSLT28sXhdCapSfboVoaDaPBzkJpUP2LUNUPilc91E0oMvbXKqKeEm5GDFjmcPT kknn0r5hCNlnv49WWoMD1zijpjtodiFwG7BcVqaNekNQW8IClhrG8NPExc9JKcZmgFw4 SXLqvtUfyHX1VYNVKqHpEIT6cKqdGD4wz5scxcWeOW7CDMMczZz8XvEzqGhpJyGK32r5 6W3Q== X-Gm-Message-State: AIVw110Fhq/jfumNl5WA857L+5omnSZK+soyKcVNsn12UQYHMMWB4UqE haVDXqPyeDKGsLB6OnxREkUDOkvv1677 X-Received: by 10.176.2.84 with SMTP id 78mr2671382uas.80.1499492878605; Fri, 07 Jul 2017 22:47:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Fri, 7 Jul 2017 22:47:37 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Lorenzo Colitti Date: Sat, 8 Jul 2017 14:47:37 +0900 Message-ID: Subject: Re: To: David Farmer Cc: Bob Hinden , IPv6 List Content-Type: multipart/alternative; boundary="001a11376f005fb7560553c7e4e7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:48:01 -0000 --001a11376f005fb7560553c7e4e7 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 5:22 AM, David Farmer wrote: > > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > > I don't think we should say "by exceptions defined in standards track documents". Whatever document wants to allow non-64-bit prefixes should formally update RFC 4291. Anything else will be confusing for implementers. --001a11376f005fb7560553c7e4e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 5:22 AM, David Farmer <farmer@umn.edu> wrote= :
   Interface Identifiers are 64 bit lon=
g except if the first three bits
   of the address are 000, or when the addresses are manually
   configured, or by exceptions defined in standards track documents.
=

I don't think = we should say "by exceptions defined in standards track documents"= ;. Whatever document wants to allow non-64-bit prefixes should formally upd= ate RFC 4291. Anything else will be confusing for implementers.
--001a11376f005fb7560553c7e4e7-- From nobody Sat Jul 8 08:00:15 2017 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 0452C12EB5F for ; Sat, 8 Jul 2017 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTAG54880rBx for ; Sat, 8 Jul 2017 08:00:12 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 3448E12EB01 for ; Sat, 8 Jul 2017 08:00:11 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 5C5D5C40 for ; Sat, 8 Jul 2017 15:00:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-NmppYn52BJ for ; Sat, 8 Jul 2017 10:00:11 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 2F695D17 for ; Sat, 8 Jul 2017 10:00:11 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id 79so22528111uae.15 for ; Sat, 08 Jul 2017 08:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hkq+1hdiAUZJv+WN9dUjG7LrPJs5ckOQ5Zq2RIN7qto=; b=DyhtHdnyLZ6TggJhX/6CjUO23LJcASNFCdSkK+unC7nKnCcBmgOWW+ipDsraunUdV/ DdqOFL5h9gxZ2/E12XgKiJCvp/oVQPFz+i0xiBO3K9SxbrzD0NcHO1yL4takVPhwLS1m daLtzqLy8pZMmmselrwJT99dFIFss3aq9YVZBqasiJIzNc7XIlmkrmOMJlNo+ya3edHc TE+hWsPiL+j+EqMwYWdl2mpSrNkpo4aQ4fR5E+iCa/9FnTbPCwNGt2YbeIivIb1PErs1 W13VejcI64ACeTkzwKHszhs89+ioeWij46UTWOQZQMrU6YLqU6qgNec70jeIHLw0ggcu 8GSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hkq+1hdiAUZJv+WN9dUjG7LrPJs5ckOQ5Zq2RIN7qto=; b=nLT7GSqYDPxGuaFr7yPjSAO7Ock1RH+32r7l6myD16qqq7s+TCP6pbwIrL699ivo05 wYNtw3ln7DF4hV8yUR70C4Je2j3vRiWSjlwkF9gz9GgZdZJLnxQBClrh+sGaXKdYt3FY DIeAsuBXL8xDzGHVrq+GLnI3pHlUTLRtKxigbQKhK2aNvU+TYWQiT838R+TTboUAYr4R OjV6CAxBwfDUYf1Uml3LT+Gd4dNtUJJF6LXKYLBe8TZTVwtzFW28bUqPq6pjl5eTP+Kq qV+4gRIqU4mzmfXPHO08CTpDaNoDEpCnSI7km6DvophaTGSPc9MtFv/3K9qa/EKBSRwc F/Gg== X-Gm-Message-State: AIVw1117xHFMXZc6TSwrnFN5iyf0IsjtP2dgWuVfbqZkx/sv3B0i5YY/ NEZzsmgNEaVDKdCfTghTywA2GIOzAN9y6ECwXMHi03wISsrfUpgPe8M4fmfidg+wYFtKL0u2p2+ Xf/Mw+jpKQWtYD18= X-Received: by 10.31.165.150 with SMTP id o144mr3519813vke.37.1499526010151; Sat, 08 Jul 2017 08:00:10 -0700 (PDT) X-Received: by 10.31.165.150 with SMTP id o144mr3519795vke.37.1499526009945; Sat, 08 Jul 2017 08:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sat, 8 Jul 2017 08:00:08 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: David Farmer Date: Sat, 8 Jul 2017 10:00:08 -0500 Message-ID: Subject: Re: To: Lorenzo Colitti Cc: Bob Hinden , IPv6 List Content-Type: multipart/alternative; boundary="001a1142d31027b8ae0553cf9bf3" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 15:00:14 -0000 --001a1142d31027b8ae0553cf9bf3 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 12:47 AM, Lorenzo Colitti wrote: > On Tue, Jul 4, 2017 at 5:22 AM, David Farmer wrote: >> >> Interface Identifiers are 64 bit long except if the first three bits >> of the address are 000, or when the addresses are manually >> configured, or by exceptions defined in standards track documents. >> >> > I don't think we should say "by exceptions defined in standards track > documents". Whatever document wants to allow non-64-bit prefixes should > formally update RFC 4291. Anything else will be confusing for implementers. > Those are not my words, they were added in version 8 of RFC4291bis. I don't like it either, but I think we have much different reasons. I think it is much cleaner to recognize this is a recommendation, then you don't need to enumerate the exceptions at all. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1142d31027b8ae0553cf9bf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 8, 2017 at 12:47 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On T= ue, Jul 4, 2017 at 5:22 AM, David Farmer <farmer@umn.edu> wrote= :
   Interface Identifiers are 64 bit long except if the first three =
bits
   of the address are 000, or when the addresses are manually
   configured, or by exceptions defined in standards track documents.
=

I don't think = we should say "by exceptions defined in standards track documents"= ;. Whatever document wants to allow non-64-bit prefixes should formally upd= ate RFC 4291. Anything else will be confusing for implementers.

Those are not my words, they were added in version 8= of RFC4291bis. I don't like it either, but I think we have much differ= ent reasons. I think it is much cleaner to recognize this is a recommendati= on, then you don't need to enumerate the exceptions at all.=C2=A0
=

Thanks.

= --
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication = Services
Office of Information Technology
University of Minnesota=C2= =A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-= 626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1142d31027b8ae0553cf9bf3-- From nobody Sat Jul 8 13:35:56 2017 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 62A1613154A for ; Sat, 8 Jul 2017 13:35:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 L14aEwitNZVK for ; Sat, 8 Jul 2017 13:35:54 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 0C5CA131549 for ; Sat, 8 Jul 2017 13:35:53 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q85so31943057pfq.1 for ; Sat, 08 Jul 2017 13:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=doHy6jddde5CTlCGrAn8VHuoDblnrL707dTqRJGKfrQ=; b=SuL07qVCOJUwiZ3k/lV7mYcrWJ+eZV+IY3cRgBZgUfgZtl1R8k5uIfUzWtCOHJhwj7 zcZgp29grUal0sP7G6r8PayRQav20Pxv7H9O2+adtwAyUxTTnlD51K488qjOwdql4kUb gLFSYXOnqSl3dmFQi4wtRaI/t02Ec/Sbo+/8b9As8tB21DetO+i0HqOGdEtOhuamvJwp TP9OMRwD4F+p+8RxrVhhC4RA2wNHAWPxRu5NZbynkcqENatuvrdP8/I7jY++z7bF1cH0 +VAfax543rivD8KFPboWiMmFJ4EqB6Bv0RpPv7sd4HL7k5FjthoAzOTRR9tWogZhq2L6 S5Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=doHy6jddde5CTlCGrAn8VHuoDblnrL707dTqRJGKfrQ=; b=VQ7jM1UQooSS30xTMXE30wsiSM9jNzH69y+IBvk2Z7U8iMKF37G3Htry7mrlzvuQCv QvHYCBhZe5bXboF0RPk8m9jcopTD/gAs7jkOAseaDTepo4v3oUWhmRxoxpcS6ZG/unJl ZxLA+oZkLWcV831Vr1gcP+Cc1Ave9qduHr0+2ZfHaOi90XOlyMgAZYAtZn6NnWI7IBBk V0H9rbmA5F1y9YefzTQjzrm7wa6xTS+EllrmmSx/qronqLCEkmvV5BGsUot6dapM2vzF XQsbzwcJrMUbT6OgowaGq2NfpNLYwL6EZDUdYdw2h0LBPW4jEnz2NvC004pK33gWNJr8 Aikw== X-Gm-Message-State: AIVw113Sb7wsfVhZrGPXAd1u42/W/W0zth2E3qZ9sfJn+iHQvjHFuNA4 eeEJKUs7GU2k9Wc3 X-Received: by 10.84.129.69 with SMTP id 63mr10378522plb.0.1499546153347; Sat, 08 Jul 2017 13:35:53 -0700 (PDT) Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i63sm13324749pge.56.2017.07.08.13.35.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 13:35:52 -0700 (PDT) Subject: Re: To: ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <537aa22a-964f-8659-b32f-2cfbf8f2cf00@gmail.com> Date: Sun, 9 Jul 2017 08:35:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 20:35:55 -0000 On 08/07/2017 17:47, Lorenzo Colitti wrote: > On Tue, Jul 4, 2017 at 5:22 AM, David Farmer wrote: >> >> Interface Identifiers are 64 bit long except if the first three bits >> of the address are 000, or when the addresses are manually >> configured, or by exceptions defined in standards track documents. >> >> > I don't think we should say "by exceptions defined in standards track > documents". Whatever document wants to allow non-64-bit prefixes should > formally update RFC 4291. Anything else will be confusing for implementers. We're trying to find a compromise between excessive rigidity and excessive flexibility. I don't see any confusion in the present text: if you've read 4291bis and you come upon a standards track document specifying a value !=64, you can use it. If you've only read RFC4291, you're out of date. You can certainly argue that RFC6164 should have formally updated RFC4291. Brian From nobody Sun Jul 9 14:09:22 2017 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 0F092126CB6 for ; Sun, 9 Jul 2017 14:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jxkJ86XkonZ for ; Sun, 9 Jul 2017 14:09:18 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 2204212EC11 for ; Sun, 9 Jul 2017 14:09:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 8EEACA2E for ; Sun, 9 Jul 2017 21:09:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBhfqe-1idpU for ; Sun, 9 Jul 2017 16:09:16 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 15E617A1 for ; Sun, 9 Jul 2017 16:09:15 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id n31so33541428uai.10 for ; Sun, 09 Jul 2017 14:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=ldcRcklLd1lONw9iczdxFEa/V8ULy5VSxrT6L0tfR+g=; b=Rt08ja0OogrK0ai1KmDJUE9nZZCj2Aats3SCYdTbhfitaMWYLUvwNX3N0JBoOoxfTs Dz3bTJo6GNMr2UiJCLPHQJ09JmfKphfDZfClu2gNGeJdHW2xBx5KfppJ1KH+q7ZmC8Bz Yi9ePDq6wqdhiZs3ks+Xox9zxD85uAOYx4+cncyRkuD3mo/qoS17whAyw9/M0pJO8afw JeUwdXn9kXkq3E86YS3D9S0ZiI68ehsgKmN4vFI7VruuN72xiIikoR+jKkK4QZcLrmuP bJ8D2ukwC2v8FWbGQNPwJGmY77UPEgHAQRAUhcivg21XTn4Rj+amAbYWsgIND8Gpuu+X rBdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ldcRcklLd1lONw9iczdxFEa/V8ULy5VSxrT6L0tfR+g=; b=txPIOR9jJdoZhWOUvVOGuGxe6+z+ClH8rosN/4REnBACZ4w4oevOXlTrG2AjSEuU5D UP2YGYWMMaGtOCNAEvVTvFQ1wOWMcfKfWzG1/YFhbZ+GXy72/wp33bmMoB9MUi/zXJV6 x8h1t+2AHDdlrcPlUryOCJ0dkB28PQxHVNe/hJzZ5WLwMT1dAOqAZ0EVmqppa8+V/YPR Qdi3i8eQ6vEBtSCW7wve9SCqj7CRsVHih0hpmzKiyW07Eq7LCAYZA+dYc/MdL/yuCoHZ t0JcE657zwDlZ0GqEz8pOPV/nSWJcKsoBYzcMDdBIB1652f1cQjRZCVqquaV15sLiIxY l+hA== X-Gm-Message-State: AIVw110rNHz10zVY09iIO252oSm3bmzPHnw3kopoQmy7Z2RAEPwCMaMU GQTk1d2mDO6Iyjqq5nxNbpF/kLSZvmB5Lv5EzyUDz0aaaYywD8YM510gx/cZqdTaHpABu9Z6EF8 qhTsG5UVReODp3wM= X-Received: by 10.31.52.13 with SMTP id b13mr5327916vka.153.1499634555092; Sun, 09 Jul 2017 14:09:15 -0700 (PDT) X-Received: by 10.31.52.13 with SMTP id b13mr5327902vka.153.1499634554686; Sun, 09 Jul 2017 14:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sun, 9 Jul 2017 14:09:14 -0700 (PDT) From: David Farmer Date: Sun, 9 Jul 2017 16:09:14 -0500 Message-ID: Subject: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Brian E Carpenter Cc: 6man WG Content-Type: multipart/alternative; boundary="001a1144015eece1640553e8e012" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 21:09:21 -0000 --001a1144015eece1640553e8e012 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 3:35 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 08/07/2017 17:47, Lorenzo Colitti wrote: > > On Tue, Jul 4, 2017 at 5:22 AM, David Farmer wrote: > >> > >> Interface Identifiers are 64 bit long except if the first three bits > >> of the address are 000, or when the addresses are manually > >> configured, or by exceptions defined in standards track documents. > >> > >> > > I don't think we should say "by exceptions defined in standards track > > documents". Whatever document wants to allow non-64-bit prefixes should > > formally update RFC 4291. Anything else will be confusing for > implementers. > > We're trying to find a compromise between excessive rigidity and excessive > flexibility. I don't see any confusion in the present text: if you've read > 4291bis and you come upon a standards track document specifying a value > !=64, you can use it. If you've only read RFC4291, you're out of date. > > You can certainly argue that RFC6164 should have formally updated RFC4291. > I don't think a simple statement that is a "compromise between excessive rigidity and excessive flexibility" is going to work. I think we need a more nuanced statement that makes clear that address assignment is ridged at 64 bits, but routing is flexible anywhere between 0 and 128 bits. Lets step back from RFC4291bis for a moment and look at how IPv6 subnets, routing, neighbor discovery, SLAAC and addressing are all interrelated. RFC5942 the IPv6 Subnet Model, says compared to IPv4; - The behavior of IPv6 as specified in Neighbor Discovery (ND) [RFC4861] is quite different. The on-link determination is separate from the address assignment. A host can have IPv6 addresses without any related on-link prefixes or can have on-link prefixes that are not related to any IPv6 addresses that are assigned to the host. Any assigned address on an interface should initially be considered as having no internal structure as shown in [RFC4291]. - The assignment of an IPv6 address -- whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration -- MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List. A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] (as modified by this document) or via manual configuration. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861]. RFC4861 Neighbor Discovery (ND), says; - When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor. Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List - Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding link-layer address. - Stateless address autoconfiguration [ADDRCONF] ... may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host. However, the prefix length is still valid for on-link determination when combined with other flags in the prefix option. RFC7608 IPv6 Prefix Length Recommendation for Forwarding, says; - Forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1. RFC4862 IPv6 Stateless Address Autoconfiguration, says; - If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291]. It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. RFC4291 IPv6 Addressing Architecture, say; - IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing. - 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. - A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ Though a very simple router may have no knowledge of the internal structure of IPv6 unicast addresses, routers will more generally have knowledge of one or more of the hierarchical boundaries for the operation of routing protocols. The known boundaries will differ from router to router, depending on what positions the router holds in the routing hierarchy. Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address. ---- The fact that RFC4291 uses the term subnet confuses things a lot, but RFC5942 is quite explicit that the two aspects of a subnet (on-link determination and address assignment) are split in IPv6. So, I'm going to use the terms on-link prefix and address assignment prefix as separate entities, and not the term subnet. What does all that mean: - It can be inferred from the 64 bit IID requirement that address assignment prefixes are 64 bits in length. - SLAAC assigns 64 bit IIDs and they are combined with 64 bit address assignment prefixes. - Routing and neighbor discovery are both based on on-link prefixes of any length, up to 128 bits. - IIDs within an address assignment prefix are not valid neighbors unless they are also covered by an on-line prefix. - Link-local addresses by definition are alway valid neighbors or in other words the on-link prefix for link-local is 64 bits by definition. How is the seeming contradiction between a fixed 64 bit address assignment prefix and a variable length on-link prefix reconciled? The easiest way to reconcile this is; A common 64 bit prefix can be used for both the on-link prefix and the a ddress assignment prefix for a link. However, that is not the only way, another way to reconcile this is to view it is as constraining which links address assignment prefixes and on-link prefixes are associated with. All 64 bit or longer on-link prefixes must be associated with the same link as the covering 64 bit address assignment prefix. And, all of the 64 bit a ddress assignment prefixes must be associated with the same link as a covering 63 bit or shorter on-link prefix. ---- Examples; 1. A link has an address assignment prefix of 2001:db8:1::/64, and on-link prefix of 2001:db8:1::/64 This one is easy and as humans we like easy, so this is going to be the most common situation. However; 2. A link has an address assignment prefix of 2001:db8:1::/64, and on-link prefixes of 2001:db8:1::1:0/112 and 2001:db8:1::2:0/112 So the address 2001:db8:1::4:5 is not on-link in this example. While 2001:db8:1::/64 is assigned to be used for this link, without a covering on-link prefix 2001:db8:1::4:5 is not a valid neighbor. The assignment prefix just means that this address would have to be on this link if it was a valid neighbor, but only on-link prefixes determine what is a valid neighbor. So, If 2001:db8:1::4:5 were assigned to a node, the node could use it's link-local address but no other nodes would be able to communicate with it using the address 2001:db8:1::4:5, again it's not a valid neighbor because there is no covering on-link prefix. 3. A link has an on-link prefix of 2001:db8:0::/63, and address assignment prefixes of 2001:db8:0::/64 and 2001:db8:1::/64 In reality this is almost as simple as #1, just summarize the two address assignment prefixes in to one on-link prefix. ---- A few observations: Except for RFC4291, most of the specification of IPv6 seem clear that on-link prefixes are any length 0-128 bits, even SLAAC seems quite specific that on-link prefixes can be any length. Therefore, it seems unlikely that RFC4291's specification of 64 bit IIDs are intended to be interpreted as saying anything about on-link prefixes or to constrain routing or neighbor discovery in any way. It seems RFC4291's specification of 64 bit IIDs should only be interpreted as constraining address assignment and not on-link determination. Further, this seems consistent with RFC4291's title "IPv6 Addressing Architecture", therefore the scope of it's statements should be constrained to address assignment or addressing in general, unless it specifically says something has a broader scope. It seems clear from RFC5942 that when a prefix length is specified with a manual configured address it should be interpreted as an on-link prefix not an address assignment prefix. If SLAAC is used with an on-link prefix other than 64 bits, all of the available IIDs will not be valid neighbors, this likely not consistent the normal intended use of SLAAC. However, when addresses are assigned with DHCPv6 or manual configuration, it is seems easily possible consider on-link prefixes of any length. Further, the use of a common address assignment prefix and on-link prefix seems the simplest way to resolve the apparent conflict between a fixed 64 bit address assignment prefix and a variable length on-link prefix, However this is not required. Therefore it seems like a good idea to provide general guidance that "on-link prefixes identical to address assignment prefixes are recommended", but again this is not required. ---- So, What should we say in RFC4291bis? Personally I'd prefer we eliminate the term subnet from RFC4291bis, but assuming that won't happen how about the following; Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. The relationship between links and IPv6 subnet prefixes differs from the IPv4 model in that the prefixes used for on-link determination are separate and may differ from the assigned subnet prefixes. However, on-link prefixes identical with assigned subnet prefixes are recommended. A prefix length associated with a manually configured address determines the on-link prefix associated with the manually configured address. See [RFC5942] "The IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for more details. Note: Any on-link prefixes longer than a covering assigned subnet prefix must be associated with the same link as the assigned subnet prefix. Also, any assigned subnet prefixes longer than a covering on-link prefix must be associated with the same link as the on-link prefix. ---- IPv6 unicast routing is based on on-link prefixes of any valid length up to 128 [BCP198], which are not necessarily the same as the subnet prefixes assigned to a link. ---- When forming or assigning unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. Note: the previous paragraph implies nothing about on-link determination which as discussed in section 2.1 is separate from subnet assignment in IPv6. Throw the rotten vegetables now! Thanks! -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1144015eece1640553e8e012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Sat, Jul 8, 2017 at 3:35 PM, Brian E Carpenter <brian.e.carpe= nter@gmail.com> wrote:
On 08/07/2017 17:47, Lorenzo Colitti wrote:
> On Tue, Jul 4, 2017 at 5:22 AM, David Farmer <farmer@umn.edu> wrote:
>>
>>=C2=A0 =C2=A0 Interface Identifiers are 64 bit long except if the f= irst three bits
>>=C2=A0 =C2=A0 of the address are 000, or when the addresses are man= ually
>>=C2=A0 =C2=A0 configured, or by exceptions defined in standards tra= ck documents.
>>
>>
> I don't think we should say "by exceptions defined in standar= ds track
> documents". Whatever document wants to allow non-64-bit prefixes = should
> formally update RFC 4291. Anything else will be confusing for implemen= ters.

We're trying to find a compromise between excessive rigidity and excess= ive
flexibility. I don't see any confusion in the present text: if you'= ve read
4291bis and you come upon a standards track document specifying a value
!=3D64, you can use it. If you've only read RFC4291, you're out of = date.

You can certainly argue that RFC6164 should have formally updated RFC4291.<= br>

I don't think a simple statement th= at is a "compromise between excessive rigidity and excessive flexibili= ty" is going to work.=C2=A0 I think we need a more nuanced statement t= hat makes clear that address assignment is ridged at 64 bits, but routing i= s flexible anywhere between 0 and 128 bits.

Lets step back from RFC4291bis for a moment and look at how IPv6 subn= ets, routing, neighbor discovery, SLAAC and addressing are all interrelated= .
<= br>
RFC5942 the IPv6 Subnet Model, says = compared to IPv4;

-=C2=A0 The behavior of IP= v6 as specified in Neighbor Discovery (ND)
=C2=A0 =C2=A0[RFC4861]= is quite different.=C2=A0 The on-link determination is separate
= =C2=A0 =C2=A0from the address assignment.=C2=A0 A host can have IPv6 addres= ses without
=C2=A0 =C2=A0any related on-link prefixes or can have= on-link prefixes that are
=C2=A0 =C2=A0not related to any IP= v6 addresses that are assigned to the host.=C2=A0 Any
=C2=A0 =C2= =A0assigned address on an interface should initially be considered as
=
=C2=A0 =C2=A0having no internal structure as shown in [RFC4291].
=

- =C2=A0 =C2=A0 =C2=A0The assig= nment of an IPv6 address -- whether through IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0stateless addre= ss autoconfiguration [RFC4862], DHCPv6 [RFC3315],
=C2=A0 =C2=A0 =C2=A0 =C2=A0or manual conf= iguration -- MUST NOT implicitly cause a prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0derived from tha= t address to be treated as on-link and added to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the Prefix List.= =C2=A0 A host considers a prefix to be on-link only
=C2=A0 =C2=A0 =C2=A0 =C2=A0through expl= icit means, such as those specified in the on-link
=C2=A0 =C2=A0 =C2=A0 =C2=A0definition in= the Terminology section of [RFC4861] (as modified
=C2=A0 =C2=A0 =C2=A0 =C2=A0by this docum= ent) or via manual configuration.=C2=A0 Note that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0requiremen= t for manually configured addresses is not explicitly
=C2=A0 =C2=A0 =C2=A0 =C2=A0mentioned = in [RFC4861].

RFC4861=C2=A0Neighbor Discovery (ND), sa= ys;
<= br>
-=C2=A0 When sending a packet to a= destination, a node uses a combination of
=C2=A0 =C2=A0the Destination Cache, the Prefix L= ist, and the Default Router List
=C2=A0 =C2=A0to determine the IP address of the appropriat= e next hop, an operation
=C2=A0 =C2=A0known as "next-hop determination".=C2=A0 On= ce the IP address of the next
=C2=A0 =C2=A0hop is known, the Neighbor Cache is consulted fo= r link-layer
=C2= =A0 =C2=A0information about that neighbor.

= =C2=A0 =C2=A0Next-hop determination for a given unicast destination operate= s as
=C2=A0 =C2=A0follows.=C2=A0 The sender performs a longest pr= efix match against the
=C2=A0 =C2=A0Prefix List to determine whet= her the packet's destination is on- or
=C2=A0 =C2=A0off-link.= =C2=A0 If the destination is on-link, the next-hop address is the
=C2=A0 =C2=A0same as the packet's destination address.=C2=A0 Otherwise= , the sender
=C2=A0 =C2=A0selects a router from the Default Route= r List=C2=A0

- =C2=A0Address resolution is t= he process through which a node determines the
=C2=A0 =C2=A0link-= layer address of a neighbor given only its IP address.=C2=A0 Address
<= div>=C2=A0 =C2=A0resolution is performed only on addresses that are determi= ned to be
=C2=A0 =C2=A0on-link and for which the sender does not = know the corresponding
=C2=A0 =C2=A0link-layer address.
=

- =C2=A0Stateless address autoconfiguration [ADDRCONF] ...=C2=A0may impose=C2=A0
=
=C2=A0 =C2= =A0certain restrictions on the prefix length for=C2=A0address configuration=C2=A0
=C2=A0= =C2=A0purposes.=C2=A0 Therefore, the prefix might be=C2=A0rejected by [ADDRCONF]=C2=A0
=C2=A0 = =C2=A0implementation in the host.=C2=A0 However, the=C2=A0prefix length is still valid for= =C2=A0
=C2=A0 =C2=A0on-link determination when combined=C2=A0with other flags in the prefix op= tion.

RFC7608 IPv6 Prefix Length Recom= mendation for Forwarding,=C2=A0says;

- =C2=A0Forwa= rding processes MUST be designed to process prefixes of any
=C2= =A0 =C2=A0length up to /128, by increments of 1.

=
RFC4862=C2=A0IPv6 Stateless Address Autoconfiguration, says;
=C2=A0 =C2=A0
- =C2=A0 =C2=A0 If the sum of the prefix lengt= h and interface identifier length
=C2=A0 =C2=A0 =C2=A0 does not e= qual 128 bits, the Prefix Information option MUST be
=C2=A0 =C2= =A0 =C2=A0 ignored.=C2=A0 An implementation MAY wish to log a system manage= ment
=C2=A0 =C2=A0 =C2=A0 error in this case.=C2=A0 The length of= the interface identifier is
=C2=A0 =C2=A0 =C2=A0 defined in a se= parate link-type specific document, which should
=C2=A0 =C2=A0 = =C2=A0 also be consistent with the address architecture [RFC4291].
=C2=A0
=C2=A0 =C2=A0 =C2=A0 It is the responsibility of the sys= tem administrator to ensure
=C2=A0 =C2=A0 =C2=A0 that the lengths= of prefixes contained in Router Advertisements
=C2=A0 =C2=A0 =C2= =A0 are consistent with the length of interface identifiers for that
<= div>=C2=A0 =C2=A0 =C2=A0 link type.=C2=A0 It should be noted, however, that= this does not mean
=C2=A0 =C2=A0 =C2=A0 the advertised prefix le= ngth is meaningless.=C2=A0 In fact, the
=C2=A0 =C2=A0 =C2=A0 adve= rtised length has non-trivial meaning for on-link
=C2=A0 =C2=A0 = =C2=A0 determination in [RFC4861] where the sum of the prefix length and
=C2=A0 =C2=A0 =C2=A0 the interface identifier length may not be equ= al to 128.=C2=A0 Thus, it
=C2=A0 =C2=A0 =C2=A0 should be safe to = validate the advertised prefix length here, in
=C2=A0 =C2=A0 =C2= =A0 order to detect and avoid a configuration error specifying an
=C2=A0 =C2=A0 =C2=A0 invalid prefix length in the context of address autoc= onfiguration.

RFC4291 IPv6=C2=A0= Addressing Architecture, say;

- =C2=A0IPv6 unicast addresses are aggregatable with prefixes of = arbitrary
=C2=A0 =C2= =A0bit-length, similar to IPv4 addresses under Classless Inter-Domain
=C2=A0 =C2=A0Routin= g.

- =C2=A0For all unicast addresses, = except those that start with the binary
=C2=A0 =C2=A0value 000, I= nterface IDs are required to be 64 bits long and to be
=C2=A0 =C2= =A0constructed in Modified EUI-64 format.

- = =C2=A0A slightly sophisticated host (but still rather simple) may
=C2=A0 =C2=A0additionally be aware of subnet prefix(es) for the link(s) it= is
=C2=A0 =C2=A0attached to, where different addresses may have = different values for
=C2=A0 =C2=A0n:

=C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n bits =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 128-n bits= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-------= ------------------------+---------------------------------+
=C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 subnet prefix =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface ID =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-------------------------------+= ---------------------------------+

=C2=A0 =C2=A0Though a very simple router = may have no knowledge of the internal
=C2=A0 =C2=A0structure of IPv6 unicast addresses, r= outers will more generally have
=C2=A0 =C2=A0knowledge of one or more of the hierarchical= boundaries for the
=C2=A0 =C2=A0operation of routing protocols.=C2=A0 The known boundari= es will differ
=C2=A0 =C2=A0from router to router, depending on what positions the router= holds
=C2=A0 = =C2=A0in the routing hierarchy.

= =C2=A0 =C2=A0Except for the knowledge of the subnet boundary discussed in t= he
=C2=A0 =C2=A0previous paragraphs, nodes should not make any as= sumptions about the
=C2=A0 =C2=A0structure of an IPv6 address.

----

The fact th= at RFC4291 uses the term subnet confuses things a lot, but RFC5942 is quite= explicit that the two aspects of a subnet (on-link determination and addre= ss assignment) are split in IPv6. So, =C2=A0I'm going to use the terms = on-link prefix and address assignment prefix as separate entities, and not = the term subnet.

What does all that mean:

- =C2=A0It can be inferred from the 64 bit IID requi= rement that address assignment prefixes are=C2=A0
=C2=A0 =C2=A064= bits in length.
=C2=A0
- =C2=A0SLAAC assigns 64 bit II= Ds and they are combined with 64 bit address assignment
=C2=A0 = =C2=A0prefixes.=C2=A0

- =C2=A0Routing and neighbor= discovery are both based on on-link prefixes of any length, up to
=C2=A0 =C2=A0128 bits.=C2=A0

- =C2=A0IIDs within= an address assignment prefix are not valid neighbors unless they are also<= /div>
=C2=A0 =C2=A0covered by an on-line prefix.

- =C2=A0Link-local addresses by definition are alway valid neighbors or = in other words the=C2=A0
=C2=A0 =C2=A0on-link prefix for link-loc= al is 64 bits by definition.

How is the seeming contradiction between a fixed=C2=A064 bit address assignment prefix and a variable length on-link pref= ix=C2=A0reconciled?

The easiest way to=C2=A0reconcile=C2=A0this is;

=C2=A0 A common=C2=A064 bit prefi= x can be used for both the=C2=A0on-link prefix= and the=C2=A0address
=C2=A0 assignment=C2=A0prefix for a link.
=

However, that is not the only way, another way to=C2=A0= reconcile=C2=A0this is to view it is as constrainin= g which links address assignment=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-= size:13.3333px">prefixes=C2=A0and=C2=A0on-link=C2=A0prefixes are= associated=C2=A0with.

=C2=A0 All=C2=A064 bit=C2=A0or=C2=A0longer=C2=A0on-link prefixes=C2=A0must=C2=A0be associated with the same link as
=C2=A0=C2=A0the=C2=A0covering 64 bit=C2=A0address assi= gnment=C2=A0pre= fix.=C2=A0And, all of the=C2=A064 bit=C2=A0address
<= div>=C2=A0 assignment=C2=A0prefixes=C2=A0must=C2=A0be associated=C2=A0with the same link as=C2=A0a=C2=A0covering=C2=A063 bit
=C2=A0 or=C2=A0shorter=C2=A0on-link prefix.=C2=A0

----

Examples;
=C2=A0=
1. A link has an=C2=A0address assignment prefix of=C2=A02001:db8:1::/64<= /span>= , and on-link prefix of=C2=A02001:db8:1::/64

This one is easy and as humans= we like easy, so this is going to be the most common situation. However;

2.=C2=A0A link has an=C2= =A0address assignment prefix of=C2=A02= 001:db8:1::/64, and on-link prefixes=C2=A0of=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-= size:13.3333px">2001:db8:1::1:0/112 and=C2=A02001:d= b8:1::2:0/112

So the address 2001:db8:1::4:5 is not on-link in this exam= ple. While 2001:db8:1::/64 is assigned to be used for this link, without a = covering on-link prefix 2001:db8:1::4:5 is not a valid neighbor. The assign= ment prefix just means that this address would have to be on this link if i= t was a valid neighbor, but only on-link prefixes determine what is a valid= neighbor. So, If 2001:db8:1::4:5 were assigned to a node, the node could u= se it's link-local address but no other nodes would be able to communic= ate with it using the address 2001:db8:1::4:5, again it's not a valid n= eighbor because there is no covering on-link prefix.

3.=C2=A0=C2=A0A link has an=C2= =A0on-link prefix of=C2=A02= 001:db8:0::/63, and=C2=A0address assignment prefixes of=C2=A02001:db8:0::/64 and=C2=A02001:db8:1::/64<= /span>

In= reality this is almost as simple as #1, just summarize the two=C2=A0address assignment prefixes in to one on-link prefix.

----

A few observations:

<= div class=3D"gmail_quote">Except for RFC4291, most of the specification of = IPv6 seem clear that on-link prefixes are any length 0-128 bits, even SLAAC= seems quite specific that on-link prefixes can be any length.=C2=A0 Theref= ore, it seems unlikely that RFC4291's specification of=C2=A064 bit IIDs= are intended to be interpreted as saying anything about on-link prefixes o= r to constrain routing or neighbor discovery in any way. It seems RFC4291&#= 39;s specification of=C2=A064 bit IIDs should only be interpreted as constr= aining address assignment and not on-link determination. Further, this seem= s consistent with RFC4291's title "IPv6=C2=A0Addressing Architectu= re", therefore the scope of it's statements should be constrained = to address assignment or addressing in general, unless it specifically says= something has a broader scope. =C2=A0=C2=A0

It seems = clear from RFC5942 that when a prefix length is specified with a manual con= figured address it should be interpreted as an on-link prefix not an addres= s assignment prefix.

<= div class=3D"gmail_quote">If SLAAC is used with an on-link prefix other tha= n 64 bits, all of the available IIDs will not be valid neighbors, this like= ly not consistent the normal intended use of SLAAC. However, when addresses= are assigned with DHCPv6 or manual configuration, it is seems easily possi= ble consider on-link prefixes of any length.

Further, the use of a common address= assignment prefix and on-link prefix seems the simplest way to resolve the= apparent conflict between a fixed 64 bit address assignment prefix and a v= ariable length on-link prefix, However this is not required.=C2=A0

Therefore it s= eems like a good idea to provide general guidance that "on-link prefix= es identical to address assignment prefixes=C2=A0are recommended", but= again this is not required.

----

So, What should we say in RFC4291bis? Personally I= 9;d prefer we eliminate the term subnet from RFC4291bis, but assuming that = won't happen how about the following;=C2=A0

Currently,=C2=A0IPv6 continues the IPv4 model in th= at a subnet prefix is associated with one link. Multiple subnet prefixes ma= y be assigned to the same link.=C2=A0 The relationship between links and IP= v6 subnet prefixes differs from the IPv4 model in that the prefixes used fo= r on-link determination are separate and may differ from the assigned subne= t prefixes. However, on-link prefixes identical with assigned subnet prefix= es are recommended. A prefix length associated with a manually configured a= ddress determines the on-link prefix associated with the manually configure= d address. See [RFC5942] "The IPv6 Subnet Model: The Relationship betw= een Links and Subnet Prefixes" for more details.

=
Note: Any on-link p= refixes longer than a covering assigned subnet prefix must be associated wi= th the same link as the assigned subnet prefix. Also, any assigned subnet p= refixes longer than a covering on-link prefix must be associated with the s= ame link as the on-link prefix.

----

IPv6 unicast routi= ng is based on on-link prefixes of any valid length up to 128 [BCP198], whi= ch are not necessarily the same as the subnet prefixes assigned to a link.<= /div>

----

<= /div>
When forming or assigning unicast addresses, except those that start with= the binary value 000, Interface IDs are required to be 64 bits long.=C2=A0= The rationale for using 64 bit Interface Identifiers can be found in [RFC7= 421].

Note: the prev= ious paragraph implies nothing about on-link determination which as discuss= ed in section 2.1 is separate from subnet assignment in IPv6.
Throw the rotten vegetables now!

Thanks!
=C2=A0=C2=A0=C2= =A0


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
Networking & Telecommunication Services
Office of Inform= ation Technology
University of Minnesota=C2=A0=C2=A0
2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 5= 5414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1144015eece1640553e8e012-- From nobody Sun Jul 9 19:03:39 2017 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 5853F129503 for ; Sun, 9 Jul 2017 19:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 LbxB_apbHW-v for ; Sun, 9 Jul 2017 19:03:36 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 A35B7127337 for ; Sun, 9 Jul 2017 19:03:36 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id g40so45846894uaa.3 for ; Sun, 09 Jul 2017 19:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G0GSRVojkJvGC+L/trHgPQXZVELq+WrJXD2QGTJF0sk=; b=Ivg5tWfP7FftxW2ie6NcxZVLC5QNuGbkImpJ3mtRfSvCvCf9tZlEBkOv/IK2SFscT0 708/oKxUlYh08fL60K9WyAtuiqt3OTZXrJP0zX1dxdY5v6NILMocZf2cz2IJ574Nq2D7 xpn+kQp+tbFLAIJslkhT+U6d79AGizclTaplBZ6qLrVsIOx2/YxfnDzb+QHC/lL6XkOm b3eh5WPkZRwKlVaM2wYWv1oXWiziNGlGRYwgxHL5DDCr18JA2MrR64ruVGQ9etQVPFWj r/UHBhoja35IBa17k8oujgOkaT+YS+ajdsmhBIYoxRX9YvteFdiFruzszV0ISj4JVkwO VrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G0GSRVojkJvGC+L/trHgPQXZVELq+WrJXD2QGTJF0sk=; b=Zxo+mvdodwIdyxGR+KlqrP2yzab2Utj0p6IL9WfxNRXhuC23zxJhgA8+j9ShElizJL gBvfj473Uzan3Vc2OnMy03S8mK+n6Iuce6eSbhg2QvORbKbnQyFM7qfQelZaqXtaKWf4 jKYPn9oPda5+uBAud9aI54ZEcrpwDB3bEHf6a7tUHfJ7iP5WwyJ5ioDaz9hHU+BoMW/M mwiNwf8wx1KTwP2N+bm5VMjJq83z5BjWKuiL72v/nxPKXDa5FKg2CbVKa+etxsW8NX0o U2fnbaNmKf8oQnR7BH9JFaU6cTKnUgbNqFL/zcrjh2dCWvNfmsKLkX31NYZa8h2+07Dm Dcvw== X-Gm-Message-State: AIVw110/Osha4aswgjOmY3i1piYUfSpFPGKtSsDryxTAZfYK3mjeoCaD PMuhiSMqz62rUEinh+r8tZ2YGZOZyljq X-Received: by 10.176.17.239 with SMTP id q47mr7540121uac.29.1499652215516; Sun, 09 Jul 2017 19:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Sun, 9 Jul 2017 19:03:14 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 10 Jul 2017 11:03:14 +0900 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: David Farmer Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="f403043613d69833cf0553ecfdf9" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 02:03:38 -0000 --f403043613d69833cf0553ecfdf9 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 6:09 AM, David Farmer wrote: > So, What should we say in RFC4291bis? Personally I'd prefer we eliminate > the term subnet from RFC4291bis, but assuming that won't happen how about > the following; > > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned to the > same link. The relationship between links and IPv6 subnet prefixes differs > from the IPv4 model in that the prefixes used for on-link determination are > separate and may differ from the assigned subnet prefixes. However, on-link > prefixes identical with assigned subnet prefixes are recommended. A prefix > length associated with a manually configured address determines the on-link > prefix associated with the manually configured address. See [RFC5942] "The > IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for > more details. > > > Note: Any on-link prefixes longer than a covering assigned subnet prefix > must be associated with the same link as the assigned subnet prefix. Also, > any assigned subnet prefixes longer than a covering on-link prefix must be > associated with the same link as the on-link prefix. > > > ---- > > IPv6 unicast routing is based on on-link prefixes of any valid length up > to 128 [BCP198], which are not necessarily the same as the subnet prefixes > assigned to a link. > > > ---- > > When forming or assigning unicast addresses, except those that start with > the binary value 000, Interface IDs are required to be 64 bits long. The > rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. > > Note: the previous paragraph implies nothing about on-link determination > which as discussed in section 2.1 is separate from subnet assignment in > IPv6. > > Thanks for putting this all together. I think it's the best assessment of the current state of the standards that I've seen so far. I'm not sure the text covers RFC6164 though; I'm not sure whether current deployments of /127 meet the "Any on-link prefixes longer than a covering assigned subnet prefix must be associated with the same link as the assigned subnet prefix" text. I'd expect many networks to number entirely separate links using /127s that are all drawn from one covering /64; at least, I know that I've written addressing plans that do that and are still in use. Cheers, Lorenzo --f403043613d69833cf0553ecfdf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 6:09 AM, David Farmer <farmer@umn.edu> wrot= e:
So, What should we say in RFC4291bis? P= ersonally I'd prefer we eliminate the term subnet from RFC4291bis, but = assuming that won't happen how about the following;=C2=A0

=
Currently,=C2=A0IPv6 continues the IP= v4 model in that a subnet prefix is associated with one link. Multiple subn= et prefixes may be assigned to the same link.=C2=A0 The relationship betwee= n links and IPv6 subnet prefixes differs from the IPv4 model in that the pr= efixes used for on-link determination are separate and may differ from the = assigned subnet prefixes. However, on-link prefixes identical with assigned= subnet prefixes are recommended. A prefix length associated with a manuall= y configured address determines the on-link prefix associated with the manu= ally configured address. See [RFC5942] "The IPv6 Subnet Model: The Rel= ationship between Links and Subnet Prefixes" for more details.
<= div>
Note: Any on-link prefixes longer than a covering assigned subnet prefix m= ust be associated with the same link as the assigned subnet prefix. Also, a= ny assigned subnet prefixes longer than a covering on-link prefix must be a= ssociated with the same link as the on-link prefix.
=

----
=
IPv6 unicast routing is based on on-link prefixes of any valid length up = to 128 [BCP198], which are not necessarily the same as the subnet prefixes = assigned to a link.
<= div class=3D"gmail_extra">

----
When forming or assigning unicast addresses, except t= hose that start with the binary value 000, Interface IDs are required to be= 64 bits long.=C2=A0 The rationale for using 64 bit Interface Identifiers c= an be found in [RFC7421].

=
Note: the previous paragraph implies nothing about on-link determinat= ion which as discussed in section 2.1 is separate from subnet assignment in= IPv6.
<= div>=C2=A0
Thanks for putting this all together. I think it's= the best assessment of the current state of the standards that I've se= en so far.

I'm not sure the text covers RFC616= 4 though; I'm not sure whether current deployments of /127 meet the &qu= ot;Any on-link prefixes longer than a covering assigned subnet prefix must = be associated with the same link as the assigned subnet prefix" text.= =C2=A0I'd expect many networks to number entirely separate links using = /127s that are all drawn from one covering /64; at least, I know that I'= ;ve written addressing plans that do that and are still in use.
<= br>
Cheers,
Lorenzo
--f403043613d69833cf0553ecfdf9-- From nobody Mon Jul 10 08:53:03 2017 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 3D0ED129AD2 for ; Mon, 10 Jul 2017 08:53:02 -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 c4xpVR4jsOIc for ; Mon, 10 Jul 2017 08:53:00 -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 7CC2A129AD1 for ; Mon, 10 Jul 2017 08:53:00 -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 v6AFqw4C019272; Mon, 10 Jul 2017 08:52:59 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6AFqqQr019222 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 10 Jul 2017 08:52:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 08:52:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 10 Jul 2017 08:52:51 -0700 From: "Templin, Fred L" To: Bob Hinden , IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS9CLq2poJvbmwO0u0K0qIX4MZRqJNP64A Date: Mon, 10 Jul 2017 15:52:51 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> In-Reply-To: <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:53:02 -0000 Hi, something that I think is a bit under-specified is whether the address = "fe80::" should be considered as an Anycast address. In particular, the leftmost 10 = bits are "link-local" and the rightmost 118 bits are all-zero. Should fe80:: be considered as the subnet router Anycast address for "link-= local"? If so, I think that it could be mentioned somewhere in Section 2.5 that eve= n the link-local subnet has an Anycast address. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > Sent: Monday, July 03, 2017 10:36 AM > To: IPv6 List > Cc: Bob Hinden > Subject: >=20 > Hi, >=20 > I published a new 6man w.g. version (-09) of the RFC4291bis draft. See l= inks below. >=20 > The summary of the changes are: >=20 > o Added text to the last paragraph in Section 2.1 to clarify > the differences on how subnets are hangled in IPv4 and IPv6, > includes a reference to RFC5942 "The IPv6 Subnet Model: The > Relationship between Links and Subnet Prefixes". >=20 > o Removed short paragraph about manual configuration in > Section 2.4.1 that was added in the -08 version. >=20 > o Revised "Changes since RFC4291" Section to have a summary of > changes since RFC4291 and a separate subsection with a change > history of each Internet Draft. This subsection will be > removed when the RFC is published. >=20 > o Editorial changes. >=20 > A diff from the previous version is available at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-09 >=20 > This is part of the project to move the core IPv6 specifications to Inter= net Standard. >=20 > Thanks, > Bob >=20 > > A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt > > has been successfully submitted by Robert M. Hinden and posted to the > > IETF repository. > > > > Name: draft-ietf-6man-rfc4291bis > > Revision: 09 > > Title: IP Version 6 Addressing Architecture > > Document date: 2017-07-03 > > Group: 6man > > Pages: 35 > > URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rf= c4291bis-09.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc429= 1bis/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-= 09 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-r= fc4291bis-09 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc= 4291bis-09 > > > > Abstract: > > This specification defines the addressing architecture of the IP > > Version 6 (IPv6) protocol. The document includes the IPv6 addressing > > model, text representations of IPv6 addresses, definition of IPv6 > > unicast addresses, anycast addresses, and multicast addresses, and an > > IPv6 node's required addresses. > > > > This document obsoletes RFC 4291, "IP Version 6 Addressing > > Architecture". > > From nobody Mon Jul 10 10:08:43 2017 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 169E1131806 for ; Mon, 10 Jul 2017 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e238JyhMRpVD for ; Mon, 10 Jul 2017 10:08:40 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 42AD11317E0 for ; Mon, 10 Jul 2017 10:08:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 7880593D for ; Mon, 10 Jul 2017 17:08:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzpkqXNkJ2-W for ; Mon, 10 Jul 2017 12:08:39 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 2E339817 for ; Mon, 10 Jul 2017 12:08:39 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id i63so41781813vkh.0 for ; Mon, 10 Jul 2017 10:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vbFwV2LMm/3eEWRJB1JNapa3IhcpCQ7hqD/F6i6sxRk=; b=ZWzS/CoDld3ozLRqfLtQbw0tW71Jb4srZhRm6ya1LG8FMz4eIdcw1m8BP6E0O5u0CZ ym4ukEbhpRM3pg3ry0taVuBJ2evFHRZttbYxTleL20JvNOwUqFYVImFPzzCMImZLwlxK r6oU7puoZMMDu9fV0LaMs6bVf3PkDTwKVlmbHAsEPnPfXjxeueqGUkrEOaREvM9kvmxW FJ8CEGjlBYU766eUnpcOJSK7LFf7cVVKgVmGq+R4It35cBuCbRtiHqH0lkEQbDZ9dOwr 3FI1HEbkkVgr+oy4DsKk9g2aw3avdH+/P4cUb88hUJ3R1xy4NLdf3z17r32BZ5mwuej6 SthA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vbFwV2LMm/3eEWRJB1JNapa3IhcpCQ7hqD/F6i6sxRk=; b=Y5K1KUhKstfJGnUlG20efjTDfLnQOFq66j7LfL+HwSwacInfEvSqTQU1Awmq8S6rzo wxjUsIpu06n4Jf7UrgvuN6Zqh1aq2yAIyqnYs/NLWijmGGhDBcVhzKMi1CA7ZnMRiiOb 6aDbQY//wm1Qtio32/CP3FDF45VUOu75S9aFl04+3Co+2aT+fvbgOV/X4zxtcTlNOgMt wmBz6b9nIpYqKWet4hrgI++WfSDHqeEB9rhEQiEl05iPPd0zdHN0JwQvkkgM+7dhl383 C99ZfWCXlTrCcegziQZMy2hRNt3O2FGH6s48lCLf0iVX991bG3Cqp6+i9GmDE17NXEj6 D7yg== X-Gm-Message-State: AIVw112IJdOFFxeSObRLOA5pbj0EtPW9mXgCiQa1voclSa0aGJYtaHrU UsHoqxPezAS9Z8kOKI5hYJ8a8C1QiNNL25GjdyI3LRWO5MOryhQ5k3lng8QQjGYllokKchOfSYI yAbBjDxHSXd/HfbA= X-Received: by 10.31.165.150 with SMTP id o144mr8446472vke.37.1499706518179; Mon, 10 Jul 2017 10:08:38 -0700 (PDT) X-Received: by 10.31.165.150 with SMTP id o144mr8446466vke.37.1499706517974; Mon, 10 Jul 2017 10:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 10 Jul 2017 10:08:37 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 10 Jul 2017 12:08:37 -0500 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Lorenzo Colitti Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="001a1142d3104580240553f9a206" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 17:08:43 -0000 --001a1142d3104580240553f9a206 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 9:03 PM, Lorenzo Colitti wrote: > On Mon, Jul 10, 2017 at 6:09 AM, David Farmer wrote: > >> So, What should we say in RFC4291bis? Personally I'd prefer we eliminate >> the term subnet from RFC4291bis, but assuming that won't happen how about >> the following; >> >> Currently, IPv6 continues the IPv4 model in that a subnet prefix is >> associated with one link. Multiple subnet prefixes may be assigned to the >> same link. The relationship between links and IPv6 subnet prefixes differs >> from the IPv4 model in that the prefixes used for on-link determination are >> separate and may differ from the assigned subnet prefixes. However, on-link >> prefixes identical with assigned subnet prefixes are recommended. A prefix >> length associated with a manually configured address determines the on-link >> prefix associated with the manually configured address. See [RFC5942] "The >> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for >> more details. >> >> >> Note: Any on-link prefixes longer than a covering assigned subnet prefix >> must be associated with the same link as the assigned subnet prefix. Also, >> any assigned subnet prefixes longer than a covering on-link prefix must be >> associated with the same link as the on-link prefix. >> >> >> ---- >> >> IPv6 unicast routing is based on on-link prefixes of any valid length up >> to 128 [BCP198], which are not necessarily the same as the subnet prefixes >> assigned to a link. >> >> >> ---- >> >> When forming or assigning unicast addresses, except those that start with >> the binary value 000, Interface IDs are required to be 64 bits long. The >> rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. >> >> Note: the previous paragraph implies nothing about on-link determination >> which as discussed in section 2.1 is separate from subnet assignment in >> IPv6. >> >> > Thanks for putting this all together. I think it's the best assessment of > the current state of the standards that I've seen so far. > Glad it was useful. > I'm not sure the text covers RFC6164 though; I'm not sure whether current > deployments of /127 meet the "Any on-link prefixes longer than a covering > assigned subnet prefix must be associated with the same link as the > assigned subnet prefix" text. I'd expect many networks to number entirely > separate links using /127s that are all drawn from one covering /64; at > least, I know that I've written addressing plans that do that and are still > in use. > I agree it doesn't really cover RFC6164, and an exception covering it needs to be added. However, I wasn't sure how narrow or broad of an exception to add. This is basically comes back to Brian's question, where is the right balance point "between excessive rigidity and excessive flexibility". We could add a very narrowly scoped exception basically adding, "or when used for point-to-point router links [RFC6164]", or very broad exception, "or when the addresses are manually configured", or possible something focused on routers only, "or when used on a link with only routers and not any hosts." As you bring up, assigning a bunch of point-to-point router links out of a single /64 could be quite common. However there are other considerations too, like router loopback /128s, maybe /126s for point-to-point, or small networks connecting only routers. I think it could also be quite common to assign router loopbacks out of a common /64, maybe even the same one as the point-to-point router links. And then I've seen some networks use /126s to coincide with /30s for IPv4, instead of /127s with /31s for IPv4. Also, if you connect a small group of routers but no hosts should you have to use /64 assigned subnets? So, what is the right balance? Do we need an RFCs explicitly allowing /128 router loopbacks and small networks connecting only routers? Or, how broad of an exception should we make? Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a1142d3104580240553f9a206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 9:03 PM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
<= div dir=3D"ltr">
On Mo= n, Jul 10, 2017 at 6:09 AM, David Farmer <farmer@umn.edu> wrote= :
So, What should we say in RFC4291bis? Pe= rsonally I'd prefer we eliminate the term subnet from RFC4291bis, but a= ssuming that won't happen how about the following;=C2=A0

<= div class=3D"gmail_quote">
Currently,=C2=A0IPv6 continues the IPv= 4 model in that a subnet prefix is associated with one link. Multiple subne= t prefixes may be assigned to the same link.=C2=A0 The relationship between= links and IPv6 subnet prefixes differs from the IPv4 model in that the pre= fixes used for on-link determination are separate and may differ from the a= ssigned subnet prefixes. However, on-link prefixes identical with assigned = subnet prefixes are recommended. A prefix length associated with a manually= configured address determines the on-link prefix associated with the manua= lly configured address. See [RFC5942] "The IPv6 Subnet Model: The Rela= tionship between Links and Subnet Prefixes" for more details.

= Note: Any on-link prefixes longer than a covering assigned subnet prefix mu= st be associated with the same link as the assigned subnet prefix. Also, an= y assigned subnet prefixes longer than a covering on-link prefix must be as= sociated with the same link as the on-link prefix.
<= /div>

=
----
<= br>
IPv6 unicast routing is based on on-link prefixes of any valid length up t= o 128 [BCP198], which are not necessarily the same as the subnet prefixes a= ssigned to a link.

----

=
When forming or assigning unicast addresses, except th= ose that start with the binary value 000, Interface IDs are required to be = 64 bits long.=C2=A0 The rationale for using 64 bit Interface Identifiers ca= n be found in [RFC7421].

<= div class=3D"gmail_quote">
Note: the previous paragraph implies nothing about on-link determinati= on which as discussed in section 2.1 is separate from subnet assignment in = IPv6.
=C2=A0
Thanks for putting this all together. I think it's = the best assessment of the current state of the standards that I've see= n so far.

Glad it w= as useful.
=C2=A0
I'm not sure the text covers RFC6164 though; I'm not sure = whether current deployments of /127 meet the "Any on-link prefixes lon= ger than a covering assigned subnet prefix must be associated with the same= link as the assigned subnet prefix" text.=C2=A0I'd expect many ne= tworks to number entirely separate links using /127s that are all drawn fro= m one covering /64; at least, I know that I've written addressing plans= that do that and are still in use.

I agree it doesn't really cover RFC6164, and an exception covering it= needs to be added. However, I wasn't sure how narrow or broad of an ex= ception to add. This is basically comes back to Brian's question, where= is the right balance point=C2=A0"bet= ween excessive rigidity and excessive flexibility".

We could add a ve= ry narrowly scoped exception basically adding, "or when used for point= -to-point router links [RFC6164]", or very broad exception, "or w= hen the addresses are manually configured", or possible something focu= sed on routers only, "or when used on a link with only routers and not= any hosts."

As you bring up, assigning a bunch of point-to-point router lin= ks out of a single /64 could be quite common.=C2=A0 However there are other= considerations too, like router loopback /128s, maybe /126s for point-to-p= oint, or small networks connecting only routers.=C2=A0 I think it could als= o be quite common to assign router loopbacks out of a common /64, maybe eve= n the same one as the point-to-point router links. And then I've seen s= ome networks use /126s to coincide with /30s for IPv4, instead of /127s wit= h /31s for IPv4. Also, if you connect a small group of routers but no hosts= should you have to use /64 assigned subnets?

So, what is the right balance? =C2= =A0 Do we need an RFCs explicitly allowing /128 router loopbacks and small = networks connecting only routers?=C2=A0 Or, how broad of an exception shoul= d we make?

Thanks.

--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dav= id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.eduNetworking & Telecommunication Services
Office of Information Tech= nology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1142d3104580240553f9a206-- From nobody Mon Jul 10 10:53:52 2017 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 EB0FE12EB99 for ; Mon, 10 Jul 2017 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 9yOBJubxNWqv for ; Mon, 10 Jul 2017 10:53:49 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4881317E0 for ; Mon, 10 Jul 2017 10:53:48 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6AHrhtI028456 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2017 18:53:44 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <5963BF27.1050300@foobar.org> Date: Mon, 10 Jul 2017 18:53:43 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: David Farmer CC: Lorenzo Colitti , 6man WG Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 17:53:51 -0000 David Farmer wrote: > Or, how broad of an exception should we make? /0 to /128 would work for me. More seriously, the sentence "Interface IDs are required to be 64 bits long" is blocking consensus on this draft, and it is difficult to see the draft progressing with this in place. For static IP address configuration, there no compelling reason to specify any mask length restriction. If someone wants to configure an arbitrary netmask on their network, then let them. If it breaks something, they will learn not to do it again. This is a completely self-policing issue and requires no input from the ietf. Nick From nobody Mon Jul 10 11:53:55 2017 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 6704B13186B for ; Mon, 10 Jul 2017 11:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 tMd6ZgKL09rd for ; Mon, 10 Jul 2017 11:53:47 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 6FDE5131867 for ; Mon, 10 Jul 2017 11:53:46 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p21so81903154qke.3 for ; Mon, 10 Jul 2017 11:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3Tirjsw0Gf4WXsLpVWNRtE9nXTiSc7pATl5/R+St+Fc=; b=In5fW/09QB61yblW+9OJOUBAEUbUD/u0UmSYHe6u7Zbev4bEub9sGUfJe4XJHX3aI4 jDSHohrGIFCRZl/xCgdYu4GVPWxJOs5JRCYTcCh63xY6cTWQuFSc8o/SK3/e8kDN93k/ KcZkF0Tl6jeovmqrv/W6ZOox8au2c8exJWGu10eCm1U5N8PazjdZ8V3bb90xc0IOOlo1 LVGrnUHGw3eRrQ176/SXU7HmVfSyvXTtGj+uqJQ7QhFkAzLzYTwTSuoB7kPxwglgnxoC 7rVuT4X61ThkEk3dOtPtpl1S4OkNB2bLYEspMWqp8xmj6naBayj8qKce/URFJGTSoyh0 yxyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3Tirjsw0Gf4WXsLpVWNRtE9nXTiSc7pATl5/R+St+Fc=; b=TdPjZjW0rGkVFoiWXbHqgcF3LcNYbJGhbncK2qO/MozwIPT5YHDHc01DhJUZIStnQI TbNNp8ycnP0ANuE+gyvdDSFWJen3KeEhP9i0gsCzD3geL5+JlFpVFgRaW/m/Vdotrden DHgUMTxhXAUXPJ4V0PkqoG3/yAwLF8FVmpd3bHdtXtLKaML+G/Z0X74P1iZpHsyvsXZm 3mP9dgvmTRgQWIUtVX1C42Sh23shYiPip/GBYk5aWt85CiNiKFd+sYbWIA+7M15B7B3z hES8JaqywnxK3gCVhzXY0MWL9ld8889B40hpIzqHrt9MImTk0jsrZf2EpHA6ciP5Ogeo lsLg== X-Gm-Message-State: AIVw1108BfLPdrdfoInHYqNLdrkr1qPbIGfgEgwZ2/5VqbyBgs2Wjksv fmJa1MfJd9TUTpbfdz5tbUxW5pKCTw== X-Received: by 10.55.75.204 with SMTP id y195mr6157881qka.183.1499712825427; Mon, 10 Jul 2017 11:53:45 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Mon, 10 Jul 2017 11:53:44 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 10 Jul 2017 11:53:44 -0700 X-Google-Sender-Auth: GsPQ53UwtGAnamIjmriIl61i-Bw Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: David Farmer Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 18:53:48 -0000 At Sun, 9 Jul 2017 16:09:14 -0500, David Farmer wrote: > So, What should we say in RFC4291bis? Personally I'd prefer we eliminate > the term subnet from RFC4291bis, but assuming that won't happen how about > the following; I'm not sure if we still want to continue wordsmith rather than either accept the current text or give up advancing the address architecture, but otherwise I largely like your text. A few comments: > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned to the > same link. The relationship between links and IPv6 subnet prefixes differs > from the IPv4 model in that the prefixes used for on-link determination are > separate and may differ from the assigned subnet prefixes. However, on-link > prefixes identical with assigned subnet prefixes are recommended. A prefix > length associated with a manually configured address determines the on-link > prefix associated with the manually configured address. See [RFC5942] "The > IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for > more details. I'd interpret the last two sentences as RFC5942 indicating: A prefix length associated with a manually configured address determines the on-link prefix associated with the manually configured address. (*) If I'm correct, while I agree on (*) it's not obvious to me that RFC5942 directly suggests this observation. Some more explanation would help here. > Note: Any on-link prefixes longer than a covering assigned subnet prefix > must be associated with the same link as the assigned subnet prefix. Also, > any assigned subnet prefixes longer than a covering on-link prefix must be > associated with the same link as the on-link prefix. I'm afraid the meaning of "associated with" is not very clear here. > When forming or assigning unicast addresses, except those that start with > the binary value 000, Interface IDs are required to be 64 bits long. The > rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. Personally I prefer this text over the one in rfc4291bis-09: Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links. since IMO "a compromise between excessive rigidity and excessive flexibility" is actually already provided in the existing spec and all we need is a clarification rather than tweaking the definition and listing awkward exceptions. But I'm not sure if your version of text is acceptable for "draft-bourbaki-6man-classless-ipv6" authors. Hopefully this note clears any doubt from them: > Note: the previous paragraph implies nothing about on-link determination > which as discussed in section 2.1 is separate from subnet assignment in > IPv6. but we may need to explain it in more detail at the risk of sounding too verbose. -- JINMEI, Tatuya From nobody Mon Jul 10 13:16:54 2017 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 963D8129AE7 for ; Mon, 10 Jul 2017 13:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_dbAyg7VVO9 for ; Mon, 10 Jul 2017 13:16:49 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E2A12EC36 for ; Mon, 10 Jul 2017 13:16:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id C510F40F for ; Mon, 10 Jul 2017 20:16:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDbSC836jhqK for ; Mon, 10 Jul 2017 15:16:48 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 73BE8975 for ; Mon, 10 Jul 2017 15:16:48 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 64so43836844uag.8 for ; Mon, 10 Jul 2017 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ndLpuf2Xnge4B0rNQHxSa6WlU2foRVeFwAUJ3Re+44=; b=PpG7HQisfkurtJtfaMsF3r9E0qEzJwlXI5TtWi2c1Rt3qOfCLdlzxlfTZenn60CuoW tUnBGdVMP5jxZACx2oZF8xN+fY5ejprkNZj+IP4+fAGHvNaA0xpJYOe+HAKghTLlb0YA eBNPOUPmDpczdWkb9XyyyIjD4fiyo+hgGP/NGb0AcFfZolGemy+d4iwNNELroO/vd6jS hbACiZIKDo5dzoxW5WseVRdB6P01XVIGQsbgmpPcSocm8NcVWl9Gbr39xZwzc0hDBxd8 PgjVK3ymZuqwgkNn+QExBXE36vqV9k5l8xzGn4qPM4MKjg+9qHn7hJvc204Mhvx7P9jB q36Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ndLpuf2Xnge4B0rNQHxSa6WlU2foRVeFwAUJ3Re+44=; b=A1UZIQ6+IwC08t5ap8GqJNMXKxrF0kTQSHQKT4LS3zHq1qabr6DOdefNG05kaM/Foh 7pFU0c7VHYHiibdVmP1ti2vxBZgolbzmSjmdD2MOJ54C9OGr42PrUN+L1b69zssR14Lm 5X9eweZQ/LiYZmGaezMvQd+aWThUMf6m/OnXfD1oaaFpf5FiAGiMesgPngB9eGNj4AvV PFak4rMyC0VYtMMcWk41zKPhoOe5k80uIdd8pZE8xYPA4mj0cERonmTEnHHpz2SdaENs KXA91SXvUIUIXOA0TVoJqbmBuZlS5xJcDvkcs+ZLZ/mwG4R01GDMSX/cOM5brfNAYpVJ bH1Q== X-Gm-Message-State: AIVw111XJmIE1Ae3webNzmQKAGXPTqF6l2/lefr+ItBSvDrlD1voBnYZ Qml6uEOL33NX0R0c140HRw+D1u8FxMESAuFvgNcXM/bghJ3MThsBOER/4oZIApayOtbQ83kz5gC 8Sz+WtcVTbJXLJw8= X-Received: by 10.159.52.106 with SMTP id s42mr9747070uab.157.1499717807546; Mon, 10 Jul 2017 13:16:47 -0700 (PDT) X-Received: by 10.159.52.106 with SMTP id s42mr9747066uab.157.1499717807336; Mon, 10 Jul 2017 13:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 10 Jul 2017 13:16:46 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 10 Jul 2017 15:16:46 -0500 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="f403043eee4c2bd7d20553fc43a8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:16:51 -0000 --f403043eee4c2bd7d20553fc43a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 10, 2017 at 1:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Sun, 9 Jul 2017 16:09:14 -0500, > David Farmer wrote: > > > So, What should we say in RFC4291bis? Personally I'd prefer we eliminat= e > > the term subnet from RFC4291bis, but assuming that won't happen how abo= ut > > the following; > > I'm not sure if we still want to continue wordsmith rather than either > accept the current text or give up advancing the address architecture, > but otherwise I largely like your text. A few comments: > > > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > > associated with one link. Multiple subnet prefixes may be assigned to t= he > > same link. The relationship between links and IPv6 subnet prefixes > differs > > from the IPv4 model in that the prefixes used for on-link determination > are > > separate and may differ from the assigned subnet prefixes. However, > on-link > > prefixes identical with assigned subnet prefixes are recommended. A > prefix > > length associated with a manually configured address determines the > on-link > > prefix associated with the manually configured address. See [RFC5942] > "The > > IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" > for > > more details. > > I'd interpret the last two sentences as RFC5942 indicating: > > A prefix length associated with a manually configured address > determines the on-link prefix associated with the manually > configured address. (*) > > If I'm correct, while I agree on (*) it's not obvious to me that > RFC5942 directly suggests this observation. Some more explanation > would help here. > I intended the reference to RFC5942 to cover the whole paragraph, not just the next to the last sentence. As for manual configuration, RFC5942 says; A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] (as modified by this document) or via manual configuration. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861]. While that doesn't explicitly say "A prefix length associated with a manually configured address determines the on-link prefix associated with the manually configured address." in my opinion it strongly implies it. How else would you provide an on-link prefix for a manually configures address otherwise? Also, I think this need to be said explicitly some place. But if you have suggestion to clarify, I'd be interested to here them. > > Note: Any on-link prefixes longer than a covering assigned subnet prefi= x > > must be associated with the same link as the assigned subnet prefix. > Also, > > any assigned subnet prefixes longer than a covering on-link prefix must > be > > associated with the same link as the on-link prefix. > > I'm afraid the meaning of "associated with" is not very clear here. > I'm open to other words, suggestions. > > When forming or assigning unicast addresses, except those that start wi= th > > the binary value 000, Interface IDs are required to be 64 bits long. T= he > > rationale for using 64 bit Interface Identifiers can be found in > [RFC7421]. > > Personally I prefer this text over the one in rfc4291bis-09: > > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > The rationale for using 64 bit Interface Identifiers can be found in > [RFC7421]. An example of a standards track exception is [RFC6164] > that standardises 127 bit prefixes on inter-router point-to-point > links. > > since IMO "a compromise between excessive rigidity and excessive > flexibility" is actually already provided in the existing spec and all > we need is a clarification rather than tweaking the definition and > listing awkward exceptions. But I'm not sure if your version of text > is acceptable for "draft-bourbaki-6man-classless-ipv6" authors. > Hopefully this note clears any doubt from them: > > > Note: the previous paragraph implies nothing about on-link determinatio= n > > which as discussed in section 2.1 is separate from subnet assignment in > > IPv6. > > but we may need to explain it in more detail at the risk of sounding > too verbose. > More detail here? Or, in 2.1? Which is the paragraph above with the reference to RFC5942. > -- > JINMEI, Tatuya > Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --f403043eee4c2bd7d20553fc43a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 1:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <= span dir=3D"ltr"><jinmei@wide.ad.jp> wrote:
At Sun, 9 Jul 2017 16:09:14 -0500,
David Farmer <farmer= @umn.edu> wrote:

> So, What should we say in RFC4291bis? Personally I'd prefer we eli= minate
> the term subnet from RFC4291bis, but assuming that won't happen ho= w about
> the following;

I'm not sure if we still want to continue wordsmith rather than either<= br> accept the current text or give up advancing the address architecture,
but otherwise I largely like your text.=C2=A0 A few comments:

> Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned to = the
> same link.=C2=A0 The relationship between links and IPv6 subnet prefix= es differs
> from the IPv4 model in that the prefixes used for on-link determinatio= n are
> separate and may differ from the assigned subnet prefixes. However, on= -link
> prefixes identical with assigned subnet prefixes are recommended. A pr= efix
> length associated with a manually configured address determines the on= -link
> prefix associated with the manually configured address. See [RFC5942] = "The
> IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes&= quot; for
> more details.

I'd interpret the last two sentences as RFC5942 indicating:

=C2=A0 A prefix length associated with a manually configured address
=C2=A0 determines the on-link prefix associated with the manually
=C2=A0 configured address. (*)

If I'm correct, while I agree on (*) it's not obvious to me that RFC5942 directly suggests this observation.=C2=A0 Some more explanation
would help here.

I intended the referen= ce to RFC5942=C2=A0to cover the whole paragraph, not just the next to the l= ast sentence.

As for manual configuration, RFC5942= says;

=C2=A0 =C2=A0 =C2=A0 =C2=A0A host considers a p= refix to be on-link only
=C2=A0 =C2=A0 =C2=A0 =C2=A0through explicit means= , such as those specified in the on-link
=C2=A0 =C2=A0 =C2=A0 =C2=A0defini= tion in the Terminology section of [RFC4861] (as modified
=C2=A0 =C2=A0 = =C2=A0 =C2=A0by this document) or via manual configuration.=C2=A0 Note that= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0requirement for manually configured addres= ses is not explicitly
=C2=A0 =C2=A0 =C2=A0 =C2=A0mentioned in [RFC4861].

While that doesn't explicitly say "A= prefix length associated with a manually configured address determines the= on-link prefix associated with the manually configured address." in m= y opinion it strongly implies it.=C2=A0 How else would you provide an on-li= nk prefix for a manually configures address otherwise? Also, I think this n= eed to be said explicitly some place. But if you have suggestion to clarify= , I'd be interested to here them.=C2=A0
=C2=A0
> Note: Any on-link prefixes longer than a covering assigned subnet pref= ix
> must be associated with the same link as the assigned subnet prefix. A= lso,
> any assigned subnet prefixes longer than a covering on-link prefix mus= t be
> associated with the same link as the on-link prefix.

I'm afraid the meaning of "associated with" is not very clear= here.

I'm open to other words, sug= gestions.=C2=A0
=C2=A0
> When forming or assigning unicast addresses, except those that start w= ith
> the binary value 000, Interface IDs are required to be 64 bits long.= =C2=A0 The
> rationale for using 64 bit Interface Identifiers can be found in [RFC7= 421].

Personally I prefer this text over the one in rfc4291bis-09:

=C2=A0 =C2=A0Interface Identifiers are 64 bit long except if the first thre= e bits
=C2=A0 =C2=A0of the address are 000, or when the addresses are manually
=C2=A0 =C2=A0configured, or by exceptions defined in standards track docume= nts.
=C2=A0 =C2=A0The rationale for using 64 bit Interface Identifiers can be fo= und in
=C2=A0 =C2=A0[RFC7421].=C2=A0 An example of a standards track exception is = [RFC6164]
=C2=A0 =C2=A0that standardises 127 bit prefixes on inter-router point-to-po= int
=C2=A0 =C2=A0links.

since IMO "a compromise between excessive rigidity and excessive
flexibility" is actually already provided in the existing spec and all=
we need is a clarification rather than tweaking the definition and
listing awkward exceptions.=C2=A0 But I'm not sure if your version of t= ext
is acceptable for "draft-bourbaki-6man-classless-ipv6" autho= rs.
Hopefully this note clears any doubt from them:

> Note: the previous paragraph implies nothing about on-link determinati= on
> which as discussed in section 2.1 is separate from subnet assignment i= n
> IPv6.

but we may need to explain it in more detail at the risk of sounding
too verbose.
=C2=A0
More detail here? Or, in= 2.1?=C2=A0 Which is the paragraph above with the reference to RFC5942. =C2= =A0
=C2=A0
--
JINMEI, Tatuya

Thanks

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
Networking & Telecommunication Services
Office of Inform= ation Technology
University of Minnesota=C2=A0=C2=A0
2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, M= N 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043eee4c2bd7d20553fc43a8-- From nobody Mon Jul 10 13:52:17 2017 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 38B621318A9 for ; Mon, 10 Jul 2017 13:52:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hbaebVpinF5R for ; Mon, 10 Jul 2017 13:52:14 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53ED313187D for ; Mon, 10 Jul 2017 13:52:14 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id q86so55608407pfl.3 for ; Mon, 10 Jul 2017 13:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NanhHvAaC5fpgrKNcU/gutAG3ZTjwZArBxIsPPEVajg=; b=F/V/r43YV6t4J5IYC6I2tqmtb1lH97OYTG0mg58SI6WmtpnnQiIGhXh90FTLxSgbzQ /VPct3TVz2LPw7d4xzpaR7SkAqBzZDk9N1/WR57l3y9ysbLL4faBJ9MExVwaie4mtbxw g5MoIaLItH6XhmanRcz73bbL0BhnKqjtsRqbiUoudlfIBxAeK8NNuJi64zVd+plzojf+ jwHr0v1mEDJjQ8d4h/1Z8rqU8v+E/OTANneFU9c5k0aoPIqBkyevZ44qmgISQc2ACnpV R7KTaxDDxILEplc3G00FnL433yVKgkBc+cZK/P+l4Cg54GrF447mnekbkaxR9pS0LhQW RC1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NanhHvAaC5fpgrKNcU/gutAG3ZTjwZArBxIsPPEVajg=; b=LfAaw5TmBMkuqUQTohT03g9S24NccBrLXBVRw3rcLZDjYURklmp0kkNe+LjR4vk6VF tCHlEHTz2fqbiSe8bVm0AkaY3jDyivcU+z2tIvOVtXGvYzaubYvtEZczZPhiCOrEC8JV jdlNzURP4uFc8itXNbre72HLlhP/jTTKCndlWq9vNyOYIv8m8Q4dBpSJTvyofYGNCrfF a38UzIFulg6bxbt0v8kpMHBIW+j/SlVH6sAXAOqs63S7v4s91mQ3q0geTtHTq60MKZk+ gwhbzd3U3dhAsamVL/4CWE0VoFgqIY0siI0EdyMFj3kepfvoVaT+z7DMOlEgbPGwgf1D geSA== X-Gm-Message-State: AIVw112Z2bfKiZEwIE1/Sy8x1c0xfCpvKBrEiN9Ugh0i2GtDevEhb+Kt R+0rlipHvaCqOA== X-Received: by 10.98.212.19 with SMTP id a19mr47518539pfh.131.1499719933929; Mon, 10 Jul 2017 13:52:13 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id s123sm23305571pgs.2.2017.07.10.13.52.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 13:52:13 -0700 (PDT) Subject: Re: To: "Templin, Fred L" , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Brian E Carpenter Organization: University of Auckland Cc: Bob Hinden Message-ID: <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> Date: Tue, 11 Jul 2017 08:52:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:52:16 -0000 Fred, On 11/07/2017 03:52, Templin, Fred L wrote: > Hi, something that I think is a bit under-specified is whether the address "fe80::" > should be considered as an Anycast address. In particular, the leftmost 10 bits > are "link-local" and the rightmost 118 bits are all-zero. > > Should fe80:: be considered as the subnet router Anycast address for "link-local"? > If so, I think that it could be mentioned somewhere in Section 2.5 that even the > link-local subnet has an Anycast address. I don't think so. The text in 4291 about the Subnet-Router anycast address says: 'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.' fe80::/10 does not identify a specific link, since it applies to every link. Therefore, fe80:: is logically not a subnet-router anycast address. Brian > > Thanks - Fred > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >> Sent: Monday, July 03, 2017 10:36 AM >> To: IPv6 List >> Cc: Bob Hinden >> Subject: >> >> Hi, >> >> I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below. >> >> The summary of the changes are: >> >> o Added text to the last paragraph in Section 2.1 to clarify >> the differences on how subnets are hangled in IPv4 and IPv6, >> includes a reference to RFC5942 "The IPv6 Subnet Model: The >> Relationship between Links and Subnet Prefixes". >> >> o Removed short paragraph about manual configuration in >> Section 2.4.1 that was added in the -08 version. >> >> o Revised "Changes since RFC4291" Section to have a summary of >> changes since RFC4291 and a separate subsection with a change >> history of each Internet Draft. This subsection will be >> removed when the RFC is published. >> >> o Editorial changes. >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >> >> This is part of the project to move the core IPv6 specifications to Internet Standard. >> >> Thanks, >> Bob >> >>> A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt >>> has been successfully submitted by Robert M. Hinden and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-6man-rfc4291bis >>> Revision: 09 >>> Title: IP Version 6 Addressing Architecture >>> Document date: 2017-07-03 >>> Group: 6man >>> Pages: 35 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >>> >>> Abstract: >>> This specification defines the addressing architecture of the IP >>> Version 6 (IPv6) protocol. The document includes the IPv6 addressing >>> model, text representations of IPv6 addresses, definition of IPv6 >>> unicast addresses, anycast addresses, and multicast addresses, and an >>> IPv6 node's required addresses. >>> >>> This document obsoletes RFC 4291, "IP Version 6 Addressing >>> Architecture". >>> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jul 10 14:53:57 2017 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 4E2BA1316F7 for ; Mon, 10 Jul 2017 14:53:55 -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 GIcOiIA4Vt8M for ; Mon, 10 Jul 2017 14:53:53 -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 4838513185F for ; Mon, 10 Jul 2017 14:53:53 -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 v6ALrqMY059285; Mon, 10 Jul 2017 14:53:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6ALrmqb059263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 10 Jul 2017 14:53:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 14:53:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 10 Jul 2017 14:53:47 -0700 From: "Templin, Fred L" To: Brian E Carpenter , IPv6 List CC: Bob Hinden Subject: RE: Thread-Topic: Thread-Index: AQHS9CLq2poJvbmwO0u0K0qIX4MZRqJNP64AgADKMQD//5pBEA== Date: Mon, 10 Jul 2017 21:53:47 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> In-Reply-To: <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:53:55 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgSnVseSAxMCwgMjAxNyAxOjUyIFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+DQo+IENj OiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4NCj4gU3ViamVjdDogUmU6IDxkcmFm dC1pZXRmLTZtYW4tcmZjNDI5MWJpcy0wOS50eHQ+DQo+IA0KPiBGcmVkLA0KPiANCj4gT24gMTEv MDcvMjAxNyAwMzo1MiwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IEhpLCBzb21ldGhpbmcg dGhhdCBJIHRoaW5rIGlzIGEgYml0IHVuZGVyLXNwZWNpZmllZCBpcyB3aGV0aGVyIHRoZSBhZGRy ZXNzICJmZTgwOjoiDQo+ID4gc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgYW4gQW55Y2FzdCBhZGRy ZXNzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbGVmdG1vc3QgMTAgYml0cw0KPiA+IGFyZSAibGluay1s b2NhbCIgYW5kIHRoZSByaWdodG1vc3QgMTE4IGJpdHMgYXJlIGFsbC16ZXJvLg0KPiA+DQo+ID4g U2hvdWxkIGZlODA6OiBiZSBjb25zaWRlcmVkIGFzIHRoZSBzdWJuZXQgcm91dGVyIEFueWNhc3Qg YWRkcmVzcyBmb3IgImxpbmstbG9jYWwiPw0KPiA+IElmIHNvLCBJIHRoaW5rIHRoYXQgaXQgY291 bGQgYmUgbWVudGlvbmVkIHNvbWV3aGVyZSBpbiBTZWN0aW9uIDIuNSB0aGF0IGV2ZW4gdGhlDQo+ ID4gbGluay1sb2NhbCBzdWJuZXQgaGFzIGFuIEFueWNhc3QgYWRkcmVzcy4NCj4gDQo+IEkgZG9u J3QgdGhpbmsgc28uIFRoZSB0ZXh0IGluIDQyOTEgYWJvdXQgdGhlIFN1Ym5ldC1Sb3V0ZXIgYW55 Y2FzdCBhZGRyZXNzIHNheXM6DQo+ICdUaGUgInN1Ym5ldCBwcmVmaXgiIGluIGFuIGFueWNhc3Qg YWRkcmVzcyBpcyB0aGUgcHJlZml4IHRoYXQgaWRlbnRpZmllcyBhIHNwZWNpZmljIGxpbmsuJw0K PiBmZTgwOjovMTAgZG9lcyBub3QgaWRlbnRpZnkgYSBzcGVjaWZpYyBsaW5rLCBzaW5jZSBpdCBh cHBsaWVzIHRvIGV2ZXJ5IGxpbmsuDQo+IFRoZXJlZm9yZSwgZmU4MDo6IGlzIGxvZ2ljYWxseSBu b3QgYSBzdWJuZXQtcm91dGVyIGFueWNhc3QgYWRkcmVzcy4NCg0KSSBhbSBPSyB3aXRoIHRoYXQg YW5zd2VyLCBidXQgaWYgZmU4MDo6IGlzIG5vdCBhbiBhbnljYXN0IGFkZHJlc3Mgd2hhdCBpcyBp dD8NCkZvciBleGFtcGxlLCBpcyBpdCBhdmFpbGFibGUgZm9yIHVzZSBieSBhIHNwZWNpZmljIGxp bmstbGF5ZXI/IElzIGl0IGp1c3QgYW4gb3JkaW5hcnkNCnVuaWNhc3QgYWRkcmVzcyBsaWtlIGFu eSBvdGhlcj8gSXMgaXQgYSByZXNlcnZlZCBhZGRyZXNzIHRoYXQgbXVzdCBuZXZlciBiZQ0KdXNl ZD8gSXMgaXQgYSBub3RoaW5nPw0KDQpJIGFtIGhvcGluZyB5b3Ugd291bGQgc2F5IHRoYXQgaXQg aXMgYXZhaWxhYmxlIGZvciB1c2UgYnkgc3BlY2lmaWMgbGluay1sYXllcnMsDQpiZWNhdXNlIEkg d291bGQgbGlrZSB0byB1c2UgaXQgaW4gdGhhdCB3YXkuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiAg ICAgQnJpYW4NCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJvYiBIaW5kZW4NCj4gPj4gU2VudDogTW9uZGF5LCBKdWx5 IDAzLCAyMDE3IDEwOjM2IEFNDQo+ID4+IFRvOiBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+DQo+ ID4+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4NCj4gPj4gU3ViamVjdDog PGRyYWZ0LWlldGYtNm1hbi1yZmM0MjkxYmlzLTA5LnR4dD4NCj4gPj4NCj4gPj4gSGksDQo+ID4+ DQo+ID4+IEkgcHVibGlzaGVkIGEgbmV3IDZtYW4gdy5nLiB2ZXJzaW9uICgtMDkpIG9mIHRoZSBS RkM0MjkxYmlzIGRyYWZ0LiAgU2VlIGxpbmtzIGJlbG93Lg0KPiA+Pg0KPiA+PiBUaGUgc3VtbWFy eSBvZiB0aGUgY2hhbmdlcyBhcmU6DQo+ID4+DQo+ID4+ICAgICAgICBvICAgQWRkZWQgdGV4dCB0 byB0aGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiAyLjEgdG8gY2xhcmlmeQ0KPiA+PiAgICAg ICAgICAgIHRoZSBkaWZmZXJlbmNlcyBvbiBob3cgc3VibmV0cyBhcmUgaGFuZ2xlZCBpbiBJUHY0 IGFuZCBJUHY2LA0KPiA+PiAgICAgICAgICAgIGluY2x1ZGVzIGEgcmVmZXJlbmNlIHRvIFJGQzU5 NDIgIlRoZSBJUHY2IFN1Ym5ldCBNb2RlbDogVGhlDQo+ID4+ICAgICAgICAgICAgUmVsYXRpb25z aGlwIGJldHdlZW4gTGlua3MgYW5kIFN1Ym5ldCBQcmVmaXhlcyIuDQo+ID4+DQo+ID4+ICAgICAg ICBvICAgUmVtb3ZlZCBzaG9ydCBwYXJhZ3JhcGggYWJvdXQgbWFudWFsIGNvbmZpZ3VyYXRpb24g aW4NCj4gPj4gICAgICAgICAgICBTZWN0aW9uIDIuNC4xIHRoYXQgd2FzIGFkZGVkIGluIHRoZSAt MDggdmVyc2lvbi4NCj4gPj4NCj4gPj4gICAgICAgIG8gICBSZXZpc2VkICJDaGFuZ2VzIHNpbmNl IFJGQzQyOTEiIFNlY3Rpb24gdG8gaGF2ZSBhIHN1bW1hcnkgb2YNCj4gPj4gICAgICAgICAgICBj aGFuZ2VzIHNpbmNlIFJGQzQyOTEgYW5kIGEgc2VwYXJhdGUgc3Vic2VjdGlvbiB3aXRoIGEgY2hh bmdlDQo+ID4+ICAgICAgICAgICAgaGlzdG9yeSBvZiBlYWNoIEludGVybmV0IERyYWZ0LiAgVGhp cyBzdWJzZWN0aW9uIHdpbGwgYmUNCj4gPj4gICAgICAgICAgICByZW1vdmVkIHdoZW4gdGhlIFJG QyBpcyBwdWJsaXNoZWQuDQo+ID4+DQo+ID4+ICAgICAgICBvICAgRWRpdG9yaWFsIGNoYW5nZXMu DQo+ID4+DQo+ID4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCj4gPj4NCj4gPj4gIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLTZtYW4tcmZjNDI5MWJpcy0wOQ0KPiA+Pg0KPiA+PiBUaGlzIGlzIHBhcnQgb2YgdGhl IHByb2plY3QgdG8gbW92ZSB0aGUgY29yZSBJUHY2IHNwZWNpZmljYXRpb25zIHRvIEludGVybmV0 IFN0YW5kYXJkLg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+IEJvYg0KPiA+Pg0KPiA+Pj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtNm1hbi1yZmM0MjkxYmlzLTA5LnR4dA0KPiA+ Pj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQgTS4gSGluZGVuIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+ID4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+Pg0KPiA+Pj4gTmFt ZToJCWRyYWZ0LWlldGYtNm1hbi1yZmM0MjkxYmlzDQo+ID4+PiBSZXZpc2lvbjoJMDkNCj4gPj4+ IFRpdGxlOgkJSVAgVmVyc2lvbiA2IEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlDQo+ID4+PiBEb2N1 bWVudCBkYXRlOgkyMDE3LTA3LTAzDQo+ID4+PiBHcm91cDoJCTZtYW4NCj4gPj4+IFBhZ2VzOgkJ MzUNCj4gPj4+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi02bWFuLXJmYzQyOTFiaXMtMDkudHh0DQo+ID4+PiBTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJm YzQyOTFiaXMvDQo+ID4+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM0MjkxYmlzLTA5DQo+ID4+PiBIdG1saXplZDogICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZj NDI5MWJpcy0wOQ0KPiA+Pj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tcmZjNDI5MWJpcy0wOQ0KPiA+Pj4NCj4gPj4+IEFi c3RyYWN0Og0KPiA+Pj4gICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgYWRkcmVzc2lu ZyBhcmNoaXRlY3R1cmUgb2YgdGhlIElQDQo+ID4+PiAgIFZlcnNpb24gNiAoSVB2NikgcHJvdG9j b2wuICBUaGUgZG9jdW1lbnQgaW5jbHVkZXMgdGhlIElQdjYgYWRkcmVzc2luZw0KPiA+Pj4gICBt b2RlbCwgdGV4dCByZXByZXNlbnRhdGlvbnMgb2YgSVB2NiBhZGRyZXNzZXMsIGRlZmluaXRpb24g b2YgSVB2Ng0KPiA+Pj4gICB1bmljYXN0IGFkZHJlc3NlcywgYW55Y2FzdCBhZGRyZXNzZXMsIGFu ZCBtdWx0aWNhc3QgYWRkcmVzc2VzLCBhbmQgYW4NCj4gPj4+ICAgSVB2NiBub2RlJ3MgcmVxdWly ZWQgYWRkcmVzc2VzLg0KPiA+Pj4NCj4gPj4+ICAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZD IDQyOTEsICJJUCBWZXJzaW9uIDYgQWRkcmVzc2luZw0KPiA+Pj4gICBBcmNoaXRlY3R1cmUiLg0K PiA+Pj4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+DQoNCg== From nobody Mon Jul 10 16:10:30 2017 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 D20FB13193D for ; Mon, 10 Jul 2017 16:10:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cUJVFuTb106P for ; Mon, 10 Jul 2017 16:10:27 -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 066A0131946 for ; Mon, 10 Jul 2017 16:10:27 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e7so57115975pfk.0 for ; Mon, 10 Jul 2017 16:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VvFLDflxAXol7rxUy6w+KOTqDjw8wo1CJV+lFxkUg1w=; b=lGT9gTa7YXOVu0TuA+X2/7B1YBJweBI41fTyb4C0moOcvcSBezhrh7rrxSemjTrUNx v+FLHiR13Y1MKxWXv/4WbGS+249bUxJHwtO6UIqWdKA4F3TmyMGfw3femZYCYRCyv/uk AhHhX+XzMNB2sFEuIqar9PupRiuXWjIqHJDRVl0oDPaK9IdlBngwAS38Qk8Odelqooqm jaV/fI9bDbKbcFkdVUv+1mvjUGIbbOQhj85IRYpBKrxbB8v9h7XEdbqrhPgREByYoWpm ggYGtT99lH0cyvBAiYT3jmIVj4Jb9r52aOPLQH7WrdC8g9YmRZ00PmhUs7t9D15ipsxO XbOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VvFLDflxAXol7rxUy6w+KOTqDjw8wo1CJV+lFxkUg1w=; b=pa4I5j8H5pgdJAT+WBGvyT1Lfwv8H53iUdBwCVOhAlxoQt7nFhbMlYDpYrfuVg0iGX FktMeHCwibcQyt/Sqza2FvncrNppMoE5R8/u98b3pzEEMXOqBDSD8r5/jULLmqqA48lW fEnujOQScWRIkky8fHuUHjOFuodZw68d8wLpyK6nDHvL6yD0RJbmZ91fi8H9/W9HN9Zw HZ7KQIgKmnuK+Je4dY6z7ANS3vqvuy9G4nC9h9pk1asN/zGCcHyIl/DN/8u8kxebMJy1 Z4TqNA8VcHcOABaRETC8TaOBpj/KoAWE3RXqoRCb+Jm7qNbRHr/llzPmcdbl7tnerKYs Abrw== X-Gm-Message-State: AIVw111TRAWEjW1gbR8/4s8FKCZtwNN/QKWyDnQwCO48e7p4MuTJ6sLk uRIpCs+Yhbw8rk1U X-Received: by 10.101.91.137 with SMTP id i9mr16720989pgr.27.1499728226365; Mon, 10 Jul 2017 16:10:26 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id k18sm23226772pgf.5.2017.07.10.16.10.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 16:10:25 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Nick Hilliard , David Farmer Cc: 6man WG References: <5963BF27.1050300@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 11 Jul 2017 11:10:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5963BF27.1050300@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:10:29 -0000 On 11/07/2017 05:53, Nick Hilliard wrote: > David Farmer wrote: >> Or, how broad of an exception should we make? > > /0 to /128 would work for me. > > More seriously, the sentence "Interface IDs are required to be 64 bits > long" is blocking consensus on this draft, and it is difficult to see > the draft progressing with this in place. Agreed. On the other hand, maybe rough consensus could be achieved with s/required/recommended/, even if some objections remain. The IETF does not require consensus, only rough consensus. Neither of our WG Chairs is neutral on this issue; one is the document editor, the other has a clear opinion, to which he is completely entitled. Personally, I think the AD could step in to judge consensus. (Not to say that David Farmer's text is wrong, but Nick is correct about the blocking issue.) Brian > For static IP address configuration, there no compelling reason to > specify any mask length restriction. If someone wants to configure an > arbitrary netmask on their network, then let them. If it breaks > something, they will learn not to do it again. This is a completely > self-policing issue and requires no input from the ietf. > > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Mon Jul 10 16:33:25 2017 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 5649F127977 for ; Mon, 10 Jul 2017 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 A3GdBx_ydJxd for ; Mon, 10 Jul 2017 16:33:21 -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 ED08D1200ED for ; Mon, 10 Jul 2017 16:33:20 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y70so55846221vky.3 for ; Mon, 10 Jul 2017 16:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2ldHoESyRcp9PootEnfn46RkRn2RIIQmyWixALZAZro=; b=efr5srwVnaXdVspE3Db4oG1iS57YSwR7XbXvlZU6zwORFYb+Zn70VS3biofLTFuWoB OZAsUXD9Ai+kmeVOrYMeSM4DfrvPYGG43UJtqVWL0hIwE7dymeZ0PHDLSOr0ws1gHUW1 h5TL/0BYZQ8+9jPE2ej/x1tTVWjLGOrO7QVDfiLLfEwirF/THGm2AQBrshiFd93TV7WB KXK16h6q7Z2w2JjZpDJNKov98nYnwU35PRgrBAkinyZ2rLv5MRH2vpXXRcC9hIZly499 8fy7e8ZgtlGn+ZcpEAAfj5x2uA4b/R83B7nawWKyoXo5ZZFrX8+d7DJCXK1V/VX/PklL QPxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2ldHoESyRcp9PootEnfn46RkRn2RIIQmyWixALZAZro=; b=MT2tguMpIYS91L7OuORZRb7OBmc5qcrnXncP5/sxVZ+zZbVXFmqPECSN0lncXlnZ2b jK2/ATxIXVaCvAZioqUVNbLV2LgwOLrfOsA/PzpkOtcNg6/jfXDqkvzT667PzSlUih8k js4HDtj7Jr2GWGBOh+d7on+JLU7MpLrZP74OnzcXWR/subcs3cbMlGSoCzQ/WKKFJ7Kv FypSG3vEVTVJn4dDkW8yCExTS6iivrmfDQlrfIoJMh7Put7nIkQ3ya9DAoWlD3iMLQUd YIg0z0xYlW2vxHCYuFkEKL4DHV1mOYqkXqUXnX9XMgnYqS0UJdqwVi+ALFt4q/VbQ6l3 o77Q== X-Gm-Message-State: AIVw112JquYdECrQgH2a97mGsFaL+bsJVrMayxgDw7DIJcX+xIMW5Qur KGPo5LuxEj+LZkV3M/Urq412q3E6xg== X-Received: by 10.31.218.196 with SMTP id r187mr9308237vkg.96.1499729599977; Mon, 10 Jul 2017 16:33:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Mon, 10 Jul 2017 16:32:49 -0700 (PDT) In-Reply-To: <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> From: Mark Smith Date: Tue, 11 Jul 2017 09:32:49 +1000 Message-ID: Subject: Re: To: Brian E Carpenter Cc: "Templin, Fred L" , IPv6 List , Bob Hinden Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 23:33:23 -0000 On 11 July 2017 at 06:52, Brian E Carpenter wrote: > Fred, > > On 11/07/2017 03:52, Templin, Fred L wrote: >> Hi, something that I think is a bit under-specified is whether the address "fe80::" >> should be considered as an Anycast address. In particular, the leftmost 10 bits >> are "link-local" and the rightmost 118 bits are all-zero. >> >> Should fe80:: be considered as the subnet router Anycast address for "link-local"? >> If so, I think that it could be mentioned somewhere in Section 2.5 that even the >> link-local subnet has an Anycast address. > > I don't think so. The text in 4291 about the Subnet-Router anycast address says: > 'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.' > fe80::/10 does not identify a specific link, since it applies to every link. > Therefore, fe80:: is logically not a subnet-router anycast address. > I would disagree. fe80::/64 identifies a specific link - it identifies the link the host is attached to - "this" link. fe80::/64 could also be described as an anycast prefix, because it is assigned to multiple links. Other prefixes can be anycast prefixes too. The forwarding system sends to the closest instance of an anycast prefix, which in the case of fe80::/64 is always on-link, for other anycast prefixes it may not and usually won't be. The only thinh special about fe80::/64 in this context is that is automatically configured on all links, so it is never an off-link anycast fe80::/64 prefix. I think this text would have to specifically exclude fe80::/64 if fe80::/128 is not a router-subnet anycast address. "Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces." Regards, Mark. > Brian > >> >> Thanks - Fred >> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >>> Sent: Monday, July 03, 2017 10:36 AM >>> To: IPv6 List >>> Cc: Bob Hinden >>> Subject: >>> >>> Hi, >>> >>> I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below. >>> >>> The summary of the changes are: >>> >>> o Added text to the last paragraph in Section 2.1 to clarify >>> the differences on how subnets are hangled in IPv4 and IPv6, >>> includes a reference to RFC5942 "The IPv6 Subnet Model: The >>> Relationship between Links and Subnet Prefixes". >>> >>> o Removed short paragraph about manual configuration in >>> Section 2.4.1 that was added in the -08 version. >>> >>> o Revised "Changes since RFC4291" Section to have a summary of >>> changes since RFC4291 and a separate subsection with a change >>> history of each Internet Draft. This subsection will be >>> removed when the RFC is published. >>> >>> o Editorial changes. >>> >>> A diff from the previous version is available at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >>> >>> This is part of the project to move the core IPv6 specifications to Internet Standard. >>> >>> Thanks, >>> Bob >>> >>>> A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt >>>> has been successfully submitted by Robert M. Hinden and posted to the >>>> IETF repository. >>>> >>>> Name: draft-ietf-6man-rfc4291bis >>>> Revision: 09 >>>> Title: IP Version 6 Addressing Architecture >>>> Document date: 2017-07-03 >>>> Group: 6man >>>> Pages: 35 >>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt >>>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >>>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09 >>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09 >>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >>>> >>>> Abstract: >>>> This specification defines the addressing architecture of the IP >>>> Version 6 (IPv6) protocol. The document includes the IPv6 addressing >>>> model, text representations of IPv6 addresses, definition of IPv6 >>>> unicast addresses, anycast addresses, and multicast addresses, and an >>>> IPv6 node's required addresses. >>>> >>>> This document obsoletes RFC 4291, "IP Version 6 Addressing >>>> Architecture". >>>> >> >> -------------------------------------------------------------------- >> 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 Mon Jul 10 17:21:39 2017 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 D394B12EC51 for ; Mon, 10 Jul 2017 17:21:37 -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 Pb7NyhaJDm6U for ; Mon, 10 Jul 2017 17:21:36 -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 924B7127201 for ; Mon, 10 Jul 2017 17:21:36 -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 v6B0Lagm030044; Mon, 10 Jul 2017 17:21:36 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6B0LVWN029942 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 10 Jul 2017 17:21:31 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 17:21:30 -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.1263.000; Mon, 10 Jul 2017 17:21:30 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BA Date: Tue, 11 Jul 2017 00:21:30 +0000 Message-ID: <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 00:21:38 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Agreed. On the other hand, maybe rough consensus could be > achieved with s/required/recommended/, even if some objections > remain. The problem I have is mainly that in the ebb and flow of these continuing d= iscussions, one sees the "IIDs must be 64 bits wide" creeping back in, agai= n and again. Where instead, the rough consensus seems to have become, must = be 64-bits wide unless the addresses are statically configured or are provi= ded by DHCPv6. In the latter cases, 64-bit IIDs might still be "recommended= ," but in fact, the on-link prefix length can be from zero to 128 bits, and= the IID must therefore be 128 - prefix length. Why not just state those two exceptions outright? Citing RFCs that mandated= 64-bit IIDs doesn't hold much weight, if the rationale for doing so has be= en deprecated. Or they may be cited, but with that proviso. Yes, LLAs and U= LAs still require 64-bit IIDs, as does SLAAC (to try to thwart a "race to t= he bottom"). I too was impressed with the thoroughness of David Farmer's thesis, but as = far as I can tell, it doesn't change the above. Bert From nobody Mon Jul 10 18:24:29 2017 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 7B49B129AEB for ; Mon, 10 Jul 2017 18:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 5apzJPWLWQWF for ; Mon, 10 Jul 2017 18:24:25 -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 B1CE2126BF3 for ; Mon, 10 Jul 2017 18:24:25 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r126so57284167vkg.0 for ; Mon, 10 Jul 2017 18:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8w8eeunzp/f1Vso78gzBT6WYrsujG424IT7P6bOkApc=; b=AORHeZtbW+i3P5hnBzgUVXpKR9F2spl2keSemdXljMpY0z1WiHTWsbqnJiGC1MoJw/ oa7EYVUdTS0lyvRkoRYh5O2iBp7GvxALGPwdztejEykCQ7mKKERcWLOenaA7kCdeZ2tY PbKYWYWCYSUIQABpQyVnG5S3KAkWQ6dfhYkXwYxLvPM8S/dsc4ARdowqpSmYFIiq4aF+ ar4PADfEkf8fJufNXWP25xqTafWFKrhAKmqabJ+B0hmE7kIU7yRy4JZK65/eJAfHtz8c tO5mXdYi9flZvaSYTvEFd/iGhmPYPqSdwsKohZCjD66yLmd3/rpApqqdLn+TIFaClCmW 1UJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8w8eeunzp/f1Vso78gzBT6WYrsujG424IT7P6bOkApc=; b=R0249Or/RaB63o+8aHc+egac+KtH3QVCvWrmL2P9OpdWI0aUIXRvT0LOzcTxX/lmgT VfYUWfiifOjNw2VwbqRwCpWVXAHLfnC4xQsUjtRrzJM3i5rNBxesHrlHWBPyMBcXZUAn DIjWUJJC+2T/e0O+xjZdTrxVZVpfi3QSe+Utb3aNhrciKPOnIp3stI/PrMWStWE6tjE5 o8WW+LC7t4Op+xrv1kcpYJjD2u79hJtFSJvxb3F6w7xxWVIABSNfsyckifNJFFs3etPw 1WnpEWyMCOz9L3HVQCklO5qxTYL4z3+SzPkwLsjNnccn7NDiV0bu05OB+WTFFxuvGJnz pdag== X-Gm-Message-State: AIVw113BhhKoi5A6FrLy35c6QmR2hAK0HXnq+Tf8bKnb3L4FRRw72S9V 11CKsPnfOx86iQ8rHfQKmMKSwqmWO3Ue X-Received: by 10.31.148.148 with SMTP id w142mr9315929vkd.90.1499736264499; Mon, 10 Jul 2017 18:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Mon, 10 Jul 2017 18:24:03 -0700 (PDT) In-Reply-To: <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Lorenzo Colitti Date: Tue, 11 Jul 2017 10:24:03 +0900 Message-ID: Subject: Re: To: Bob Hinden Cc: IPv6 List Content-Type: multipart/alternative; boundary="001a11465af24e04b20554008fcd" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:24:27 -0000 --001a11465af24e04b20554008fcd Content-Type: text/plain; charset="UTF-8" On Tue, Jul 4, 2017 at 2:36 AM, Bob Hinden wrote: > I published a new 6man w.g. version (-09) of the RFC4291bis draft. See > links below. > Actually, after lots of thought, I object to this document in its current form, specifically due to the text "or by exceptions defined in standards track documents". I feel that this text is a net negative in terms of the functionality provided by the protocol to its users. Allowing IIDs shorter than 64 bits has no value that I can see that is not already covered by the exception for manual configuration. Pretty much the only thing we can do with it is support SLAAC with shorter IIDs, and *nobody* has yet answered the question of how that would be beneficial in the long therm. In the short term we might tell ourselves that shorter IIDs will allow users to extend the network at the edges. But the reality is that in the long term we'll just see some networks provide the minimum allocation that is accepted by hosts. (There are examples of this today, in the case of cable networks that only provide a single /64 to the home.) Because hosts adapt to the lowest-common denominator network, over time the only effect is to move the commonly-used subnet boundary between subnet prefix and IID from 64 towards 128. This will be accelerated by networks whose policies include limiting the number of devices allowed on a particular connection. (Again, there are examples today: enterprise networks that want one GUA per host, mobile carriers have a requirement to allow only x devices to tether behind a smartphone, etc.) I don't think that's a use case. So, what are the other use cases? If there are no use cases, we should not make this change. I understand Brian and David's position that this is just a parameter and that the architecture is inconsistent, but better an inconsistent network architecture than a degradation of function. --001a11465af24e04b20554008fcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 4, 2017 at 2:36 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
I publishe= d a new 6man w.g. version (-09) of the RFC4291bis draft.=C2=A0 See links be= low.

Actually, after lots of thought, I= object to this document in its current form, specifically due to the text = "or by exceptions defined in standards track documents". I feel t= hat this text is a net negative in terms of the functionality provided by t= he protocol to its users.

Allowing IIDs shorter th= an 64 bits has no value that I can see that is not already covered by the e= xception for manual configuration. Pretty much the only thing we can do wit= h it is support SLAAC with shorter IIDs, and *nobody* has yet answered the = question of how that would be beneficial in the long therm.

<= /div>
In the short term we might tell ourselves that shorter IIDs will = allow users to extend the network at the edges. But the reality is that in = the long term we'll just see some networks provide the minimum allocati= on that is accepted by hosts. (There are examples of this today, in the cas= e of cable networks that only provide a single /64 to the home.) Because ho= sts adapt to the lowest-common denominator network, over time the only effe= ct is to move the commonly-used subnet boundary between subnet prefix and I= ID from 64 towards 128. This will be accelerated by networks whose policies= include limiting the number of devices allowed on a particular connection.= (Again, there are examples today: enterprise networks that want one GUA pe= r host, mobile carriers have a requirement to allow only x devices to tethe= r behind a smartphone, etc.) I don't think that's a use case.
=

So, what are the other use cases? If there are no use c= ases, we should not make this change.

I understand= Brian and David's position that this is just a parameter and that the = architecture is inconsistent, but better an inconsistent network architectu= re than a degradation of function.
--001a11465af24e04b20554008fcd-- From nobody Mon Jul 10 18:36:59 2017 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 9E25312F26C for ; Mon, 10 Jul 2017 18:36:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rCJPocrS6an1 for ; Mon, 10 Jul 2017 18:36:54 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 6A48212EC27 for ; Mon, 10 Jul 2017 18:36:54 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id c73so58551501pfk.2 for ; Mon, 10 Jul 2017 18:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z3Ck8sKfBNxrPEM4aiwTfmzNwE6O89295utUZvvvpnY=; b=Tk8rhY5KYhAQswXRz9/xCN0B4hje5hDuuBIWckYY+B1fYr81/6LvYUWoH0BGV2//JT k6cGHZcnrzU51x3cEqNOZQqXeDIadbYn/m6GUsgd+M/QZfNyjxtYxANrW405hackx93Z QBTLcSG7KO122G7X6rK7fmTx6G752CFe8iZG5UqU92e87OOT1flomwv8sQGCN1CVtvon IDKKpkp6el93haC6IkMGnN+OfbZmVGSxGbAmBw+WuMjfJVNm1MUUqmJVOK0L2uRu8GZs 0TW2KFtUjY2xogqtUUlWryvy3axt5jejotmm+eFDQh1bcLppB+HWqxKnm54IoLDXEJoQ ZUPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z3Ck8sKfBNxrPEM4aiwTfmzNwE6O89295utUZvvvpnY=; b=aatVNlG3SO4DY8YmhNCjI1lizdJm/8z/rKnxWU3XVQQmZeYdeJ+7doIhtLDxG91Jca UiL6LvYF50CKRJJOcnMwJeQqTbjaNWp0LTIU5kbTAqQ366D+goy/wAvHQfAxstom/vjx Kvtff2KSghiJEqhA+OPli4GCtNbpQ2/cg5e2BvpL8vc7+GGvX3an2xoXaxYxQOGkYbIY lesEzE3omRKSEgWIAEwXnnUwd7PlBmgYtnojzT9MSAfyGaRAA1puob1RLpj/MIqFFV0t 8EDmwlRVHTrSVi0foLFKa0eSxTK68zGVQ4nej/0HAWcmZpFCk2W+cFSrrA0CZESSef/S QhJg== X-Gm-Message-State: AIVw1100IbEFirCgX7uDwfNCu0snokTN3BCdfbuPBdgj4bTh+nRWzlZi ceorW5aDcBDWig== X-Received: by 10.84.191.131 with SMTP id a3mr21096307pld.279.1499737013855; Mon, 10 Jul 2017 18:36:53 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id e189sm24514784pfe.100.2017.07.10.18.36.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 18:36:53 -0700 (PDT) Subject: Re: To: Mark Smith Cc: "Templin, Fred L" , IPv6 List , Bob Hinden References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <88ca6eb2-cf01-357e-4cbd-c28b655ae851@gmail.com> Date: Tue, 11 Jul 2017 13:36:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:36:57 -0000 On 11/07/2017 11:32, Mark Smith wrote: > On 11 July 2017 at 06:52, Brian E Carpenter wrote: >> Fred, >> >> On 11/07/2017 03:52, Templin, Fred L wrote: >>> Hi, something that I think is a bit under-specified is whether the address "fe80::" >>> should be considered as an Anycast address. In particular, the leftmost 10 bits >>> are "link-local" and the rightmost 118 bits are all-zero. >>> >>> Should fe80:: be considered as the subnet router Anycast address for "link-local"? >>> If so, I think that it could be mentioned somewhere in Section 2.5 that even the >>> link-local subnet has an Anycast address. >> >> I don't think so. The text in 4291 about the Subnet-Router anycast address says: >> 'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.' >> fe80::/10 does not identify a specific link, since it applies to every link. >> Therefore, fe80:: is logically not a subnet-router anycast address. >> > > I would disagree. fe80::/64 identifies a specific link - it identifies > the link the host is attached to - "this" link. fe80::%eth0 specifies an address on an interface. fe80::%eth1 specifies an address on a different interface. Which kind of shows that fe80::/64 in the abstract doesn't specify much of anything. fe80::%eth0/64 is valid syntax under RFC 4007, however. > fe80::/64 could also be described as an anycast prefix, because it is > assigned to multiple links. Other prefixes can be anycast prefixes > too. Well, that's the trouble. fe80::/64 refers to a single interface if there is only one, but if there's more than one, does it refer to a default choice of interface, or to all interfaces simultaneously? I don't think that is discussed anywhere. > The forwarding system sends to the closest instance of an anycast > prefix, which in the case of fe80::/64 is always on-link, for other > anycast prefixes it may not and usually won't be. The only thinh > special about fe80::/64 in this context is that is automatically > configured on all links, so it is never an off-link anycast fe80::/64 > prefix. So the address fe80:: might, or might not, be reached on all the interfaces. > I think this text would have to specifically exclude fe80::/64 if > fe80::/128 is not a router-subnet anycast address. > > "Packets sent to the Subnet-Router anycast address will be delivered > to one router on the subnet. All routers are required to support the > Subnet-Router anycast addresses for the subnets to which they have > interfaces." My FritzBox at home certainly does not answer on fe80::%12, and as far as I can tell the Juniper switch at the uni does not answer on fe80::%11 Brian > > Regards, > Mark. > >> Brian >> >>> >>> Thanks - Fred >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >>>> Sent: Monday, July 03, 2017 10:36 AM >>>> To: IPv6 List >>>> Cc: Bob Hinden >>>> Subject: >>>> >>>> Hi, >>>> >>>> I published a new 6man w.g. version (-09) of the RFC4291bis draft. See links below. >>>> >>>> The summary of the changes are: >>>> >>>> o Added text to the last paragraph in Section 2.1 to clarify >>>> the differences on how subnets are hangled in IPv4 and IPv6, >>>> includes a reference to RFC5942 "The IPv6 Subnet Model: The >>>> Relationship between Links and Subnet Prefixes". >>>> >>>> o Removed short paragraph about manual configuration in >>>> Section 2.4.1 that was added in the -08 version. >>>> >>>> o Revised "Changes since RFC4291" Section to have a summary of >>>> changes since RFC4291 and a separate subsection with a change >>>> history of each Internet Draft. This subsection will be >>>> removed when the RFC is published. >>>> >>>> o Editorial changes. >>>> >>>> A diff from the previous version is available at: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >>>> >>>> This is part of the project to move the core IPv6 specifications to Internet Standard. >>>> >>>> Thanks, >>>> Bob >>>> >>>>> A new version of I-D, draft-ietf-6man-rfc4291bis-09.txt >>>>> has been successfully submitted by Robert M. Hinden and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-ietf-6man-rfc4291bis >>>>> Revision: 09 >>>>> Title: IP Version 6 Addressing Architecture >>>>> Document date: 2017-07-03 >>>>> Group: 6man >>>>> Pages: 35 >>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-09.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-09 >>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09 >>>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-09 >>>>> >>>>> Abstract: >>>>> This specification defines the addressing architecture of the IP >>>>> Version 6 (IPv6) protocol. The document includes the IPv6 addressing >>>>> model, text representations of IPv6 addresses, definition of IPv6 >>>>> unicast addresses, anycast addresses, and multicast addresses, and an >>>>> IPv6 node's required addresses. >>>>> >>>>> This document obsoletes RFC 4291, "IP Version 6 Addressing >>>>> Architecture". >>>>> >>> >>> -------------------------------------------------------------------- >>> 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 Mon Jul 10 20:50:21 2017 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 5EE841300BB for ; Mon, 10 Jul 2017 20:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 Kd8GqYOfxdPA for ; Mon, 10 Jul 2017 20:50:17 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 729DE12EC06 for ; Mon, 10 Jul 2017 20:50:17 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id y70so57909093vky.3 for ; Mon, 10 Jul 2017 20:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SxkhRxHBxDUvbchFxqVA6+88QAakjvCE9OtI4nuxNxQ=; b=S+N14OMCpfkcmhRl++j9UGRXk9lN6Q3pIGmKG2hIGEvX3gOiPFku9bqNAEhHDcwPUa VljQHEmQX4KjZJJ6AAk6hOdomzf1BlN1FyNiy6HVWgxELWTRkOAyuUtDQMm/2trMTq2J yklovO3J5QnlDVcvTD4XJrQ4JQot+HldMhzq6FWCWn0HC2mmH2254lgSF54rvDrrH2kS 4xHRjLWr07anCF9qduNnYYucWL2fFA9wyvHqM4ynKCPe5xg8dzVVHr33Q4t76kzk2OQ+ 6qtQW8NyV3KzVUQG/BKuj+YcMaI3UWjfk4y0yJxHCYOZwBLmT0UIH6vtfZHoB667jY7c gd7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SxkhRxHBxDUvbchFxqVA6+88QAakjvCE9OtI4nuxNxQ=; b=jw8kNRrQBKm6aeKas/GL5mT2mvSg770NF8w54I0SdKoWaBAWE6/nVrzu9+pDOtlUcn XYPArmxAlqVUg7tC9AWL4LsCIwzsyuZobAzaHbS82AhGFs3eKutDHvy38kThjO2pNANS r54LV68poNrpyz9+JvlNhdL1KjB439MSQcSJ17xlBqx7Owzsg8Vk2ubdIm4AKZllXmY3 69CzgSrwX8yJUdo1Nc2ouSWiewpJmg6wKjqghHEtiuB3566wQ6S9kMGbfwn9ZE+IXwr7 PTyit3qv/X4QkGqgyJQwMXCFN5AzV6zOyf55XxWzCwT3c5qfbBTcgvHYBupEOJGtt4EC vD7A== X-Gm-Message-State: AIVw112DeGPXdpUSjQdB0RKyN8kcVHZyvhoZh+Ftn4UqxgBI6T4jresR YW4Kf/ZTUXsHzPDUjBwk2EUBOagzOA== X-Received: by 10.31.180.80 with SMTP id d77mr8075114vkf.110.1499745016465; Mon, 10 Jul 2017 20:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Mon, 10 Jul 2017 20:49:46 -0700 (PDT) In-Reply-To: <88ca6eb2-cf01-357e-4cbd-c28b655ae851@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> <88ca6eb2-cf01-357e-4cbd-c28b655ae851@gmail.com> From: Mark Smith Date: Tue, 11 Jul 2017 13:49:46 +1000 Message-ID: Subject: Re: To: Brian E Carpenter Cc: "Templin, Fred L" , IPv6 List , Bob Hinden Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 03:50:19 -0000 On 11 July 2017 at 11:36, Brian E Carpenter wrote: > On 11/07/2017 11:32, Mark Smith wrote: >> On 11 July 2017 at 06:52, Brian E Carpenter wrote: >>> Fred, >>> >>> On 11/07/2017 03:52, Templin, Fred L wrote: >>>> Hi, something that I think is a bit under-specified is whether the address "fe80::" >>>> should be considered as an Anycast address. In particular, the leftmost 10 bits >>>> are "link-local" and the rightmost 118 bits are all-zero. >>>> >>>> Should fe80:: be considered as the subnet router Anycast address for "link-local"? >>>> If so, I think that it could be mentioned somewhere in Section 2.5 that even the >>>> link-local subnet has an Anycast address. >>> >>> I don't think so. The text in 4291 about the Subnet-Router anycast address says: >>> 'The "subnet prefix" in an anycast address is the prefix that identifies a specific link.' >>> fe80::/10 does not identify a specific link, since it applies to every link. >>> Therefore, fe80:: is logically not a subnet-router anycast address. >>> >> >> I would disagree. fe80::/64 identifies a specific link - it identifies >> the link the host is attached to - "this" link. > > fe80::%eth0 specifies an address on an interface. > fe80::%eth1 specifies an address on a different interface. > Which kind of shows that fe80::/64 in the abstract doesn't > specify much of anything. fe80::%eth0/64 is valid syntax > under RFC 4007, however. > I understood the question was whether there is a subnet-router anycast address within the link-local prefix, meaning that all routers on a link would also have a fe80::/128 subnet-router interface address. Your comments seem to be about selecting an outbound interface using fe80::/128, although I'm not sure if you're talking about using it is the source or destination address. fe80::/64 is of course ambiguous, so zone information needs to be provided in either case. >> fe80::/64 could also be described as an anycast prefix, because it is >> assigned to multiple links. Other prefixes can be anycast prefixes >> too. > > Well, that's the trouble. fe80::/64 refers to a single interface > if there is only one, but if there's more than one, does it > refer to a default choice of interface, or to all interfaces > simultaneously? I don't think that is discussed anywhere. > I seem to remember a few years ago somebody posted a draft related to that. I can't remember the approach they suggested, however I think there are two, although both have issues - ND for the address out of all of the host's interface, and use the first response to select the outgoing interface (multi-homed host), or use just assume the interface the default router appears on (single-homed host). I don't think it considered anycast link-local addresses. An alternative thought I"ve had is to create unique link-local addresses by using the same method as ULAs, utilising the bits between fe80::/10 and fe80::/64 for a random number. The first host or router on a link would pick the random number, announcing the ULL prefix in RAs that have a zero value router lifetime, so the host isn't used as a default router. The second host on the link would learn that ULA prefix and then start announcing it too in RAs (RLife = 0) as a backup if the first host goes away. I think that is all doable, from memory the issue I ran into was where to put the ULA in the address selection rules, before or after the current LL prefix. This is very similar to how Appletalk had seed routers that seeded other non-configured routers with the link's cable range information. >> The forwarding system sends to the closest instance of an anycast >> prefix, which in the case of fe80::/64 is always on-link, for other >> anycast prefixes it may not and usually won't be. The only thinh >> special about fe80::/64 in this context is that is automatically >> configured on all links, so it is never an off-link anycast fe80::/64 >> prefix. > > So the address fe80:: might, or might not, be reached on all the > interfaces. > >> I think this text would have to specifically exclude fe80::/64 if >> fe80::/128 is not a router-subnet anycast address. >> >> "Packets sent to the Subnet-Router anycast address will be delivered >> to one router on the subnet. All routers are required to support the >> Subnet-Router anycast addresses for the subnets to which they have >> interfaces." > > My FritzBox at home certainly does not answer on fe80::%12, and as far > as I can tell the Juniper switch at the uni does not answer on fe80::%11 > I've had some experiences with FritzBoxes back in 2010, they do some unusual IPv6 things e.g., they thought that ULA and GUA prefixes were to be swapped in RAs, rather than being advertised in parallel, following the state of the WAN link. My OpenWRT router is answering pings to fe80::. $ ping6 -c 3 -I wlp3s0 fe80:: PING fe80::(fe80::) from %wlp3s0 wlp3s0: 56 data bytes 64 bytes from fe80::%wlp3s0: icmp_seq=1 ttl=64 time=4.78 ms 64 bytes from fe80::%wlp3s0: icmp_seq=2 ttl=64 time=42.5 ms 64 bytes from fe80::%wlp3s0: icmp_seq=3 ttl=64 time=4.46 ms --- fe80:: ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 4.469/17.273/42.566/17.885 ms $ I'm also getting a neighbor table entry for it on the sending host. fe80:: dev wlp3s0 lladdr router STALE I also verified with tcpdump that it is using fe80:: as the ICMP echo request destination address. Regards, Mark. From nobody Mon Jul 10 21:59:40 2017 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 699FF1272E1 for ; Mon, 10 Jul 2017 21:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: 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_WmtH94ozmI for ; Mon, 10 Jul 2017 21:59:37 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 5489512706D for ; Mon, 10 Jul 2017 21:59:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id B8BCF9A8 for ; Tue, 11 Jul 2017 04:59:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uFo5zy7HMdV for ; Mon, 10 Jul 2017 23:59:36 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 7F57199D for ; Mon, 10 Jul 2017 23:59:36 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id i63so47182110vkh.0 for ; Mon, 10 Jul 2017 21:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x8fAlcnzRyfnUtalXiFmjeLz9Y5rawg2YwtdrCDR59I=; b=jm4kvrV8gcsMXfRkHOXpmj/IupNYJgXQwvLsFgrzW9Csxv1HBnj9MWqarr79G5v8Up jO/E64bPrX7dMGaq9F8CNnNcIJk+o2nmFrK2vBxD6LMx1Jy9fN8TYjgHoOdO9dw1ctJk 2KpviGt2VEyAbnjgNzvP76GZfnIcmUgdahTjzfdphiO5h7AMnvWyNEELgZdwQx87X0wf quRUIfY8pHtBhRkmPLAZVhEuXWlbhmHRbkM5vsmENAu9f4fGkL60ICIOKX8wM0AauFqa W6WwvugLwPo1Fnm12JO+voNgxX+qL8b860seLoTz22y4GI/28CeavatK7jkMH4pAWPpU PKew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x8fAlcnzRyfnUtalXiFmjeLz9Y5rawg2YwtdrCDR59I=; b=Woy/jBIZ17PSuKK5Gej2+sg296jgpQVH+OJ1ubiX4wKYGD3Ubdl4TYlCR5vYvujDTp f7wDD5AtbCmOokqZtoZaXlGXRshs43F3qfWNnAV8Zei9XWv5qr6snQ1Xtwuqmmk+1eW/ s24WumaNT23oMvfoA//MZBcMZUBgpV2bF0j3UO4EJLqGFlDDFxiAtJyVVrIo7XUyjLi7 OXJJfiIO5hO8KJSz0AaBThRJfWNFoB4aSZ33cZJcYURLyEuwnnEI2nmCiGdYe9yWlJr3 Oc0F8hypUmTnxuCF8tP2ZWbBapzPVQYmNtDIp3D/hykG8GP1hnOo1NQ/UhGClOkWWRrq 0vaA== X-Gm-Message-State: AIVw11285CRs9h3wRrcpHAUB2CEwp1jbQtqD1392eF9N9+725U2Eii8a sZaQSd+615LeETL/pKMlRs1Jk/yk3/pUhp9Nu0Poj7K1O1hHqMx718yA7JPgZfJztl58DzByLkX mGf2UTBCxF/JPnZE= X-Received: by 10.159.37.100 with SMTP id 91mr10715499uaz.147.1499749175311; Mon, 10 Jul 2017 21:59:35 -0700 (PDT) X-Received: by 10.159.37.100 with SMTP id 91mr10715487uaz.147.1499749175131; Mon, 10 Jul 2017 21:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 10 Jul 2017 21:59:34 -0700 (PDT) In-Reply-To: <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Mon, 10 Jul 2017 23:59:34 -0500 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="94eb2c122da4d61c49055403905d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 04:59:39 -0000 --94eb2c122da4d61c49055403905d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > > > Agreed. On the other hand, maybe rough consensus could be > > achieved with s/required/recommended/, even if some objections > > remain. > > The problem I have is mainly that in the ebb and flow of these continuing > discussions, one sees the "IIDs must be 64 bits wide" creeping back in, > again and again. Where instead, the rough consensus seems to have become, > must be 64-bits wide unless the addresses are statically configured or are > provided by DHCPv6. In the latter cases, 64-bit IIDs might still be > "recommended," but in fact, the on-link prefix length can be from zero to > 128 bits, and the IID must therefore be 128 - prefix length. > > Why not just state those two exceptions outright? Citing RFCs that > mandated 64-bit IIDs doesn't hold much weight, if the rationale for doing > so has been deprecated. Or they may be cited, but with that proviso. Yes, > LLAs and ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a > "race to the bottom"). > > I too was impressed with the thoroughness of David Farmer's thesis, but as > far as I can tell, it doesn't change the above. > IPv6 as currently defined does actually require IIDs to be 64 bits, if this wasn't the case then you could use subnets of any length without any special requirements or considerations. RFC6164 is quite clear that there are /127 prefixes that should not be used and there are other requirements like disabling Subnet-Router anycast. However, as IPv6 unicast routing is based on on-link prefixes of any length, up to 128 bits, limited IPv6 functionality can be provided using any length IID. In the case of point-to-point links, the limitations are not a big deal, however it would be a stretch to that the limitations are not an issue is all cases. So, how about something like this; For the full functioning of all IPv6 capabilities, when assigning unicast addresses, except those that start with the binary value 000, Interface Identifiers are required to be 64 bits long. However, as IPv6 unicast routing and on-link determination are separate from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limitations, to use Interface Identifiers of other lengths in limited scenarios, these include; 128 bit prefixes, such as for router loopback addresses, point-to-point router-links [RFC6164], and links where all node are manually configured. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c122da4d61c49055403905d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E &= lt;albert= .e.manfredi@boeing.com> wrote:
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter

> Agreed. On the other hand, maybe rough consensus could be
> achieved with s/required/recommended/, even if some objections
> remain.

The problem I have is mainly that in the ebb and flow of these continuing d= iscussions, one sees the "IIDs must be 64 bits wide" creeping bac= k in, again and again. Where instead, the rough consensus seems to have bec= ome, must be 64-bits wide unless the addresses are statically configured or= are provided by DHCPv6. In the latter cases, 64-bit IIDs might still be &q= uot;recommended," but in fact, the on-link prefix length can be from z= ero to 128 bits, and the IID must therefore be 128 - prefix length.

Why not just state those two exceptions outright? Citing RFCs that mandated= 64-bit IIDs doesn't hold much weight, if the rationale for doing so ha= s been deprecated. Or they may be cited, but with that proviso. Yes, LLAs a= nd ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a "= race to the bottom").

I too was impressed with the thoroughness of David Farmer's thesis, but= as far as I can tell, it doesn't change the above.

IPv6 as currently defined does actually require IIDs to be= 64 bits, if this wasn't the case then you could use subnets of any len= gth without any special requirements or considerations.=C2=A0=C2=A0RFC6164 is quite clear that there are /127 = prefixes that should not be used and there are other requirements like=C2= =A0disabling Subnet-Ro= uter anycast.=C2=A0However, as IPv6= unicast routing is based on on-link prefixes of any length, up to 128 bits= , limited IPv6 functionality can be provided using any length IID. =C2=A0In the case of po= int-to-point links, the limitations are not a big deal, however it would be= a stretch to that the=C2=A0limitations are not an issue is all cases.

So, how about something = like this;

For the full fu= nctioning of all IPv6 capabilities, when=C2=A0assigning unicast addresses, except those that start with the bi= nary value 000,=C2=A0Interface Iden= tifiers=C2=A0are required to be 64 = bits long.=C2=A0However, as IPv6 unicast routing and on-link determination = are separate=C2=A0from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limit= ations, to use Interface Identifiers of other lengths in limited scenarios,= these include; 128 bit prefixes, such as for router loopback addresses, po= int-to-point router-links [RFC6164], and links where all node are manually = configured.

--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Far= mer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Netw= orking & Telecommunication Services
Office of Information Technology=
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c122da4d61c49055403905d-- From nobody Mon Jul 10 22:11:12 2017 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 8BA4A12ECEF for ; Mon, 10 Jul 2017 22:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEj-F2PpC1_M for ; Mon, 10 Jul 2017 22:11:08 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D939F12EC34 for ; Mon, 10 Jul 2017 22:11:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6A431B11 for ; Tue, 11 Jul 2017 05:11:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj-2g6eUSPua for ; Tue, 11 Jul 2017 00:11:08 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 26308B4D for ; Tue, 11 Jul 2017 00:11:07 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id 40so47946593uav.14 for ; Mon, 10 Jul 2017 22:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxtWmEDUXXeh4CIZjswmdn7wwu7a5Rn5dOvvdaXuN8I=; b=pGK+f2rfM9jmYkC/WFIoBCEEC5hm6hwx4mXJ2Yb0vbw9WJKM35W8NuuwWtSPNQJmN1 s6eAZNbuReW66Z23NjzEGR0z/6F3JQIP6dMCz9/kD1LO0Eakyit4Aw1jViwviJ6+Cjw0 vK8AOno71scK0RuurInoz2Rsta/ekRcGRMuYGoOGYJWgY/w2Gniq2ARPW5wseKQvRMtj cW5apTYA89j1hPNmqCOH13yC4J1wu74zTPiRTV+2ADX4A8lQhx9o2wpEnupT6GMHQfk8 baWvNILO2jQSxk8K0VzFSxsXbxIXFUhaBTYUzy6x8m3auzoDiNBhxNS55UxzfiOiyIjw zHCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxtWmEDUXXeh4CIZjswmdn7wwu7a5Rn5dOvvdaXuN8I=; b=muI5ltRBumEy4JXq0FKyJVfx5ANMe54WxWEZvv7bTo5J+o6o2UOLJV6SWmQBRdeB32 VkBCeAYaUJWG7S3z9tNagG+Ji60fMZs5Jppm9Ma0SusY+E5cSeF/ihZ2dUOD8DC+ReTd uv7wLU/ph0GOmSNeq+5jMQrbhwrDCwbglwX2JO4xQJV44uKX25zFhM4UDOVL77jnju4d t7kLPrVN6DHTaZ5zY8uMW4QlpPrcqDgj3AXQhdYUiyAnhY4nnqg7B560Vhrj4OvSYVdw 8kJUjJBLBmrhsJvt1Nfa+Wl4OJ9P4+R1P0YsOH+ZtEwggL4D+Iz/zvzpmUPZ+zLwDGWv Ht5w== X-Gm-Message-State: AIVw113RLmcXHcLQMvuWbENKNLYYvrT9WUbOnL/hpPUgxGOm8V4zo65E loHgTM0j11M0EsDAz+YErO3eRBhvau6B5stwhmF/gBKePXFNiJ2SKucbSYtX1cOGDYdtnwbuHAF aoR9EBSvrKrlxs0E= X-Received: by 10.159.48.214 with SMTP id k22mr10928882uab.31.1499749866985; Mon, 10 Jul 2017 22:11:06 -0700 (PDT) X-Received: by 10.159.48.214 with SMTP id k22mr10928873uab.31.1499749866804; Mon, 10 Jul 2017 22:11:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 10 Jul 2017 22:11:06 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Tue, 11 Jul 2017 00:11:06 -0500 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="f403045dada210318b055403ba81" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 05:11:10 -0000 --f403045dada210318b055403ba81 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 11:59 PM, David Farmer wrote: > > > On Mon, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E < > albert.e.manfredi@boeing.com> wrote: > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> >> > Agreed. On the other hand, maybe rough consensus could be >> > achieved with s/required/recommended/, even if some objections >> > remain. >> >> The problem I have is mainly that in the ebb and flow of these continuing >> discussions, one sees the "IIDs must be 64 bits wide" creeping back in, >> again and again. Where instead, the rough consensus seems to have become, >> must be 64-bits wide unless the addresses are statically configured or are >> provided by DHCPv6. In the latter cases, 64-bit IIDs might still be >> "recommended," but in fact, the on-link prefix length can be from zero to >> 128 bits, and the IID must therefore be 128 - prefix length. >> >> Why not just state those two exceptions outright? Citing RFCs that >> mandated 64-bit IIDs doesn't hold much weight, if the rationale for doing >> so has been deprecated. Or they may be cited, but with that proviso. Yes, >> LLAs and ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a >> "race to the bottom"). >> >> I too was impressed with the thoroughness of David Farmer's thesis, but >> as far as I can tell, it doesn't change the above. >> > > IPv6 as currently defined does actually require IIDs to be 64 bits, if > this wasn't the case then you could use subnets of any length without any > special requirements or considerations. RFC6164 is quite clear that > there are /127 prefixes that should not be used and there are other > requirements like disabling Subnet-Router anycast. However, as IPv6 > unicast routing is based on on-link prefixes of any length, up to 128 bits, > limited IPv6 functionality can be provided using any length IID. In the > case of point-to-point links, the limitations are not a big deal, however > it would be a stretch to that the limitations are not an issue is all > cases. > > So, how about something like this; > > For the full functioning of all IPv6 capabilities, when assigning unicast > addresses, except those that start with the binary value 000, Interface > Identifiers are required to be 64 bits long. However, as IPv6 unicast > routing and on-link determination are separate from address assignment and > will operate with Interface Identifiers of any length. It is therefore > possible, with several limitations, to use Interface Identifiers of other > lengths in limited scenarios, these include; 128 bit prefixes, such as for > router loopback addresses, point-to-point router-links [RFC6164], and links > where all node are manually configured. > Oops, forgot something; For the full functioning of all IPv6 capabilities, when assigning unicast addresses, except those that start with the binary value 000, Interface Identifiers are required to be 64 bits long. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. However, as IPv6 unicast routing and on-link determination are separate from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limitations, to use Interface Identifiers of other lengths in limited scenarios, these include; 128 bit prefixes, such as for router loopback addresses, point-to-point router-links [RFC6164], and links where all node are manually configured. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045dada210318b055403ba81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 11:59 PM, David Farmer <farmer@umn.edu> wrote:


On M= on, Jul 10, 2017 at 7:21 PM, Manfredi, Albert E <albert.e.manfr= edi@boeing.com> wrote:
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter

> Agreed. On the other hand, maybe rough consensus could be
> achieved with s/required/recommended/, even if some objections
> remain.

The problem I have is mainly that in the ebb and flow of these continuing d= iscussions, one sees the "IIDs must be 64 bits wide" creeping bac= k in, again and again. Where instead, the rough consensus seems to have bec= ome, must be 64-bits wide unless the addresses are statically configured or= are provided by DHCPv6. In the latter cases, 64-bit IIDs might still be &q= uot;recommended," but in fact, the on-link prefix length can be from z= ero to 128 bits, and the IID must therefore be 128 - prefix length.

Why not just state those two exceptions outright? Citing RFCs that mandated= 64-bit IIDs doesn't hold much weight, if the rationale for doing so ha= s been deprecated. Or they may be cited, but with that proviso. Yes, LLAs a= nd ULAs still require 64-bit IIDs, as does SLAAC (to try to thwart a "= race to the bottom").

I too was impressed with the thoroughness of David Farmer's thesis, but= as far as I can tell, it doesn't change the above.

IPv6 as currently defined does actually require IIDs to be= 64 bits, if this wasn't the case then you could use subnets of any len= gth without any special requirements or considerations.=C2=A0=C2=A0RFC6164 is quite clear that there are /127 = prefixes that should not be used and there are other requirements like=C2= =A0disabling Subnet-Ro= uter anycast.=C2=A0However, as IPv6= unicast routing is based on on-link prefixes of any length, up to 128 bits= , limited IPv6 functionality can be provided using any length IID. =C2=A0In the case of po= int-to-point links, the limitations are not a big deal, however it would be= a stretch to that the=C2=A0limitations are not an issue is all cases.

So, how about something = like this;

For the full fu= nctioning of all IPv6 capabilities, when=C2=A0assigning unicast addresses, except those that start with the bi= nary value 000,=C2=A0Interface Iden= tifiers=C2=A0are required to be 64 = bits long.=C2=A0However, as IPv6 unicast routing and on-link determination = are separate=C2=A0from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limit= ations, to use Interface Identifiers of other lengths in limited scenarios,= these include; 128 bit prefixes, such as for router loopback addresses, po= int-to-point router-links [RFC6164], and links where all node are manually = configured.

Oops, forgot something;

<= div>For the full functioning of all IPv6 capabilities, when=C2=A0assigning unicast addresses, except those that start= with the binary value 000,=C2=A0In= terface Identifiers=C2=A0are requir= ed to be 64 bits long.=C2=A0The rat= ionale for using 64 bit Interface Identifiers can be found in=C2=A0[RFC7421].=C2=A0However, as IPv6 unicast routing and on-link determination are= separate=C2=A0from address assignment and will operate with=C2=A0Interface Identifiers of any length. It is t= herefore possible, with several lim= itations, to use Interface Identifiers of other lengths in limited scenario= s, these include; 128 bit prefixes, such as for router loopback addresses, = point-to-point router-links [RFC6164], and links where all node are manuall= y configured.

=

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045dada210318b055403ba81-- From nobody Tue Jul 11 03:19:14 2017 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 D197C128BC8 for ; Tue, 11 Jul 2017 03:19:13 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 Lyq1t0zeoYLZ for ; Tue, 11 Jul 2017 03:19:11 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDA2128DE5 for ; Tue, 11 Jul 2017 03:19:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id E5AE91BC37 for ; Tue, 11 Jul 2017 10:19:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Simon Hobson In-Reply-To: <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> Date: Tue, 11 Jul 2017 11:19:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E06F041-CBAC-4D63-96CF-1E54FA63C009@thehobsons.co.uk> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:19:14 -0000 "Manfredi, Albert E" wrote: > The problem I have is mainly that in the ebb and flow of these = continuing discussions, one sees the "IIDs must be 64 bits wide" = creeping back in, again and again. Where instead, the rough consensus = seems to have become, must be 64-bits wide unless the addresses are = statically configured or are provided by DHCPv6. In the latter cases, = 64-bit IIDs might still be "recommended," but in fact, the on-link = prefix length can be from zero to 128 bits, and the IID must therefore = be 128 - prefix length. I'd go further ... While I've not been following the detail too closely, I get the feeling = that SLAAC for global addressing BASED ON HARDWARE ADDRESS, and link = local addresses, need 64 bits, nothing else actually does. On that = basis, surely the better way to express it would be to say that in = general there is no restriction as to where the prefix/id split falls - = but some addressing methods have specific requirements. And in reality, = link local addresses are pretty irrelevant in terms of how you manage = other addresses as they have their own prefix and semantics. If you say "it must be 64 bits except for X and Y" then if someone comes = along in the future with a spiffing idea for method Z - then the whole = merry go round of discussion starts up again getting "that changed to = "... except for X and Y and Z". Ie, unless there is some fundamental reason why the split MUST be at 64 = bits, then simply say there isn't a requirements except where noted in = the RFCs for the addressing methods that DO have a requirements for a = specific length. IMO that's the cleaner way of expressing it. If there are reasons why it's a good idea to use 64 bits - such as = because there are implementations out there that make that assumption - = then point them out (with a "for reasons of A, B, C is is recommended = that ..." paragraph) rather than using them as a reason to maintain = something that doesn't seem to make much sense now. David Farmer wrote: > IPv6 as currently defined does actually require IIDs to be 64 bits, if = this wasn't the case then you could use subnets of any length without = any special requirements or considerations.=20 And so we come back to (what appears to me to be) the fundamental = problem. At some point, for whatever reason, it was written that the = split must be at 64 bits. Now it seems that in the general case there is = no such requirement - but that CERTAIN ADDRESSING MODES/PROTOCOLS or = IMPLEMENTATIONS require it to be at 64 bits. So if the argument is that "we can't change 'something' because it = clashes with 'something else'" - then isn't that an argument for = 'correcting' the something else ? > So, how about something like this; > ... > Oops, forgot something; >=20 > For the full functioning of all IPv6 capabilities, when assigning = unicast addresses, except those that start with the binary value 000, = Interface Identifiers are required to be 64 bits long. The rationale for = using 64 bit Interface Identifiers can be found in [RFC7421]. However, = as IPv6 unicast routing and on-link determination are separate from = address assignment and will operate with Interface Identifiers of any = length. It is therefore possible, with several limitations, to use = Interface Identifiers of other lengths in limited scenarios, these = include; 128 bit prefixes, such as for router loopback addresses, = point-to-point router-links [RFC6164], and links where all node are = manually configured. As it read the discussions, it's not so much a case of "in limited = scenarios", but a case of "where an addressing mode requiring a specific = IID length is not in use". Al Albert writes, it seems that there's a desperation to hang on to 64 = bits but allow some exceptions (and somehow imply that even when these = exceptions apply, then it's a really really bad idea to depart from 64 = bits - rather than simply drop the requirement and move it to where it = actually applies (in the definition of those features/protocols that = require it). Just for completeness I'll add that my experience with IPv4 started more = or less after classless addresses was the norm. In a parallel to the bit = above about implementations having hardcoded assumptions, it came as "a = surprise" to me when I came across a piece of equipment (an oldish = serial terminal server) that refused to allow a /23 in the 192.168 = RFC1918 range as it had hard-coded assumptions about address classes. = That was the only time I came across such an issue - other than Cisco = course content still stuck in classful mode even after the whole world = set their routers to allow classless (and IP subnet zero) as the first = step in configuring a router. From nobody Tue Jul 11 08:22:11 2017 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 ADD1613146D for ; Tue, 11 Jul 2017 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5rcTv130l1uD for ; Tue, 11 Jul 2017 08:22:08 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5881316E4 for ; Tue, 11 Jul 2017 08:22:08 -0700 (PDT) Received: from [10.179.10.44] (77.16.42.44.tmi.telenormobil.no [77.16.42.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 05A842D4FF7; Tue, 11 Jul 2017 15:22:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: Date: Tue, 11 Jul 2017 17:22:02 +0200 Cc: Nick Hilliard , David Farmer , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <8BB052D8-221B-4BEC-B556-A06A63454807@employees.org> References: <5963BF27.1050300@foobar.org> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 15:22:10 -0000 Brian, > On 11 Jul 2017, at 01:10, Brian E Carpenter w= rote: >=20 > Neither of our WG Chairs is neutral on this issue; one is the > document editor, the other has a clear opinion, to which he is > completely entitled. Personally, I think the AD could step > in to judge consensus. What is my opinion? Could you please summarize? It might be clearer to you than me. :-) Ole= From nobody Tue Jul 11 09:10:10 2017 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 D47D4124D85 for ; Tue, 11 Jul 2017 09:10:08 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 8UALqXFDGgHZ for ; Tue, 11 Jul 2017 09:10:06 -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 5254C12ECC7 for ; Tue, 11 Jul 2017 09:10:05 -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 v6BGA4KF060087; Tue, 11 Jul 2017 09:10:05 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6BGA1Gk060057 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Jul 2017 09:10:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 09:10:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 11 Jul 2017 09:10:00 -0700 From: "Templin, Fred L" To: Mark Smith , Brian E Carpenter CC: IPv6 List , Bob Hinden Subject: RE: Thread-Topic: Thread-Index: AQHS9CLq2poJvbmwO0u0K0qIX4MZRqJNP64AgACB7p6AAJfNgIAAJSMAgABCYAA= Date: Tue, 11 Jul 2017 16:10:00 +0000 Message-ID: <2b1020b9fb1c46e2a801cffd1fcd0c06@XCH15-06-08.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> <88ca6eb2-cf01-357e-4cbd-c28b655ae851@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 16:10:09 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBTbWl0aCBb bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAxMCwg MjAxNyA4OjUwIFBNDQo+IFRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPg0KPiBDYzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPjsgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBn bWFpbC5jb20+DQo+IFN1YmplY3Q6IFJlOiA8ZHJhZnQtaWV0Zi02bWFuLXJmYzQyOTFiaXMtMDku dHh0Pg0KPiANCj4gT24gMTEgSnVseSAyMDE3IGF0IDExOjM2LCBCcmlhbiBFIENhcnBlbnRlciA8 YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gPiBPbiAxMS8wNy8yMDE3IDEx OjMyLCBNYXJrIFNtaXRoIHdyb3RlOg0KPiA+PiBPbiAxMSBKdWx5IDIwMTcgYXQgMDY6NTIsIEJy aWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ Pj4gRnJlZCwNCj4gPj4+DQo+ID4+PiBPbiAxMS8wNy8yMDE3IDAzOjUyLCBUZW1wbGluLCBGcmVk IEwgd3JvdGU6DQo+ID4+Pj4gSGksIHNvbWV0aGluZyB0aGF0IEkgdGhpbmsgaXMgYSBiaXQgdW5k ZXItc3BlY2lmaWVkIGlzIHdoZXRoZXIgdGhlIGFkZHJlc3MgImZlODA6OiINCj4gPj4+PiBzaG91 bGQgYmUgY29uc2lkZXJlZCBhcyBhbiBBbnljYXN0IGFkZHJlc3MuIEluIHBhcnRpY3VsYXIsIHRo ZSBsZWZ0bW9zdCAxMCBiaXRzDQo+ID4+Pj4gYXJlICJsaW5rLWxvY2FsIiBhbmQgdGhlIHJpZ2h0 bW9zdCAxMTggYml0cyBhcmUgYWxsLXplcm8uDQo+ID4+Pj4NCj4gPj4+PiBTaG91bGQgZmU4MDo6 IGJlIGNvbnNpZGVyZWQgYXMgdGhlIHN1Ym5ldCByb3V0ZXIgQW55Y2FzdCBhZGRyZXNzIGZvciAi bGluay1sb2NhbCI/DQo+ID4+Pj4gSWYgc28sIEkgdGhpbmsgdGhhdCBpdCBjb3VsZCBiZSBtZW50 aW9uZWQgc29tZXdoZXJlIGluIFNlY3Rpb24gMi41IHRoYXQgZXZlbiB0aGUNCj4gPj4+PiBsaW5r LWxvY2FsIHN1Ym5ldCBoYXMgYW4gQW55Y2FzdCBhZGRyZXNzLg0KPiA+Pj4NCj4gPj4+IEkgZG9u J3QgdGhpbmsgc28uIFRoZSB0ZXh0IGluIDQyOTEgYWJvdXQgdGhlIFN1Ym5ldC1Sb3V0ZXIgYW55 Y2FzdCBhZGRyZXNzIHNheXM6DQo+ID4+PiAnVGhlICJzdWJuZXQgcHJlZml4IiBpbiBhbiBhbnlj YXN0IGFkZHJlc3MgaXMgdGhlIHByZWZpeCB0aGF0IGlkZW50aWZpZXMgYSBzcGVjaWZpYyBsaW5r LicNCj4gPj4+IGZlODA6Oi8xMCBkb2VzIG5vdCBpZGVudGlmeSBhIHNwZWNpZmljIGxpbmssIHNp bmNlIGl0IGFwcGxpZXMgdG8gZXZlcnkgbGluay4NCj4gPj4+IFRoZXJlZm9yZSwgZmU4MDo6IGlz IGxvZ2ljYWxseSBub3QgYSBzdWJuZXQtcm91dGVyIGFueWNhc3QgYWRkcmVzcy4NCj4gPj4+DQo+ ID4+DQo+ID4+IEkgd291bGQgZGlzYWdyZWUuIGZlODA6Oi82NCBpZGVudGlmaWVzIGEgc3BlY2lm aWMgbGluayAtIGl0IGlkZW50aWZpZXMNCj4gPj4gdGhlIGxpbmsgdGhlIGhvc3QgaXMgYXR0YWNo ZWQgdG8gLSAidGhpcyIgbGluay4NCj4gPg0KPiA+IGZlODA6OiVldGgwIHNwZWNpZmllcyBhbiBh ZGRyZXNzIG9uIGFuIGludGVyZmFjZS4NCj4gPiBmZTgwOjolZXRoMSBzcGVjaWZpZXMgYW4gYWRk cmVzcyBvbiBhIGRpZmZlcmVudCBpbnRlcmZhY2UuDQo+ID4gV2hpY2gga2luZCBvZiBzaG93cyB0 aGF0IGZlODA6Oi82NCBpbiB0aGUgYWJzdHJhY3QgZG9lc24ndA0KPiA+IHNwZWNpZnkgbXVjaCBv ZiBhbnl0aGluZy4gZmU4MDo6JWV0aDAvNjQgaXMgdmFsaWQgc3ludGF4DQo+ID4gdW5kZXIgUkZD IDQwMDcsIGhvd2V2ZXIuDQo+ID4NCj4gDQo+IEkgdW5kZXJzdG9vZCB0aGUgcXVlc3Rpb24gd2Fz IHdoZXRoZXIgdGhlcmUgaXMgYSBzdWJuZXQtcm91dGVyIGFueWNhc3QNCj4gYWRkcmVzcyB3aXRo aW4gdGhlIGxpbmstbG9jYWwgcHJlZml4LCBtZWFuaW5nIHRoYXQgYWxsIHJvdXRlcnMgb24gYQ0K PiBsaW5rIHdvdWxkIGFsc28gaGF2ZSBhIGZlODA6Oi8xMjggc3VibmV0LXJvdXRlciBpbnRlcmZh Y2UgYWRkcmVzcy4NCj4gDQo+IFlvdXIgY29tbWVudHMgc2VlbSB0byBiZSBhYm91dCBzZWxlY3Rp bmcgYW4gb3V0Ym91bmQgaW50ZXJmYWNlIHVzaW5nDQo+IGZlODA6Oi8xMjgsIGFsdGhvdWdoIEkn bSBub3Qgc3VyZSBpZiB5b3UncmUgdGFsa2luZyBhYm91dCB1c2luZyBpdCBpcw0KPiB0aGUgc291 cmNlIG9yIGRlc3RpbmF0aW9uIGFkZHJlc3MuIGZlODA6Oi82NCBpcyBvZiBjb3Vyc2UgYW1iaWd1 b3VzLA0KPiBzbyB6b25lIGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIHByb3ZpZGVkIGluIGVpdGhl ciBjYXNlLg0KPiANCj4gPj4gZmU4MDo6LzY0IGNvdWxkIGFsc28gYmUgZGVzY3JpYmVkIGFzIGFu IGFueWNhc3QgcHJlZml4LCBiZWNhdXNlIGl0IGlzDQo+ID4+IGFzc2lnbmVkIHRvIG11bHRpcGxl IGxpbmtzLiBPdGhlciBwcmVmaXhlcyBjYW4gYmUgYW55Y2FzdCBwcmVmaXhlcw0KPiA+PiB0b28u DQo+ID4NCj4gPiBXZWxsLCB0aGF0J3MgdGhlIHRyb3VibGUuIGZlODA6Oi82NCByZWZlcnMgdG8g YSBzaW5nbGUgaW50ZXJmYWNlDQo+ID4gaWYgdGhlcmUgaXMgb25seSBvbmUsIGJ1dCBpZiB0aGVy ZSdzIG1vcmUgdGhhbiBvbmUsIGRvZXMgaXQNCj4gPiByZWZlciB0byBhIGRlZmF1bHQgY2hvaWNl IG9mIGludGVyZmFjZSwgb3IgdG8gYWxsIGludGVyZmFjZXMNCj4gPiBzaW11bHRhbmVvdXNseT8g SSBkb24ndCB0aGluayB0aGF0IGlzIGRpc2N1c3NlZCBhbnl3aGVyZS4NCj4gPg0KPiANCj4gSSBz ZWVtIHRvIHJlbWVtYmVyIGEgZmV3IHllYXJzIGFnbyBzb21lYm9keSBwb3N0ZWQgYSBkcmFmdCBy ZWxhdGVkIHRvDQo+IHRoYXQuIEkgY2FuJ3QgcmVtZW1iZXIgdGhlIGFwcHJvYWNoIHRoZXkgc3Vn Z2VzdGVkLCBob3dldmVyIEkgdGhpbmsNCj4gdGhlcmUgYXJlIHR3bywgYWx0aG91Z2ggYm90aCBo YXZlIGlzc3VlcyAtIE5EIGZvciB0aGUgYWRkcmVzcyBvdXQgb2YNCj4gYWxsIG9mIHRoZSBob3N0 J3MgaW50ZXJmYWNlLCBhbmQgdXNlIHRoZSBmaXJzdCByZXNwb25zZSB0byBzZWxlY3QgdGhlDQo+ IG91dGdvaW5nIGludGVyZmFjZSAobXVsdGktaG9tZWQgaG9zdCksIG9yIHVzZSBqdXN0IGFzc3Vt ZSB0aGUNCj4gaW50ZXJmYWNlIHRoZSBkZWZhdWx0IHJvdXRlciBhcHBlYXJzIG9uIChzaW5nbGUt aG9tZWQgaG9zdCkuIEkgZG9uJ3QNCj4gdGhpbmsgaXQgY29uc2lkZXJlZCBhbnljYXN0IGxpbmst bG9jYWwgYWRkcmVzc2VzLg0KPiANCj4gQW4gYWx0ZXJuYXRpdmUgdGhvdWdodCBJInZlIGhhZCBp cyB0byBjcmVhdGUgdW5pcXVlIGxpbmstbG9jYWwNCj4gYWRkcmVzc2VzIGJ5IHVzaW5nIHRoZSBz YW1lIG1ldGhvZCBhcyBVTEFzLCB1dGlsaXNpbmcgdGhlIGJpdHMgYmV0d2Vlbg0KPiBmZTgwOjov MTAgYW5kIGZlODA6Oi82NCBmb3IgYSByYW5kb20gbnVtYmVyLiBUaGUgZmlyc3QgaG9zdCBvciBy b3V0ZXINCj4gb24gYSBsaW5rIHdvdWxkIHBpY2sgdGhlIHJhbmRvbSBudW1iZXIsIGFubm91bmNp bmcgdGhlIFVMTCBwcmVmaXggaW4NCj4gUkFzIHRoYXQgaGF2ZSBhIHplcm8gdmFsdWUgcm91dGVy IGxpZmV0aW1lLCBzbyB0aGUgaG9zdCBpc24ndCB1c2VkIGFzDQo+IGEgZGVmYXVsdCByb3V0ZXIu IFRoZSBzZWNvbmQgaG9zdCBvbiB0aGUgbGluayB3b3VsZCBsZWFybiB0aGF0IFVMQQ0KPiBwcmVm aXggYW5kIHRoZW4gc3RhcnQgYW5ub3VuY2luZyBpdCB0b28gaW4gUkFzIChSTGlmZSA9IDApIGFz IGEgYmFja3VwDQo+IGlmIHRoZSBmaXJzdCBob3N0IGdvZXMgYXdheS4gSSB0aGluayB0aGF0IGlz IGFsbCBkb2FibGUsIGZyb20gbWVtb3J5DQo+IHRoZSBpc3N1ZSBJIHJhbiBpbnRvIHdhcyB3aGVy ZSB0byBwdXQgdGhlIFVMQSBpbiB0aGUgYWRkcmVzcyBzZWxlY3Rpb24NCj4gcnVsZXMsIGJlZm9y ZSBvciBhZnRlciB0aGUgY3VycmVudCBMTCBwcmVmaXguIFRoaXMgaXMgdmVyeSBzaW1pbGFyIHRv DQo+IGhvdyBBcHBsZXRhbGsgaGFkIHNlZWQgcm91dGVycyB0aGF0IHNlZWRlZCBvdGhlciBub24t Y29uZmlndXJlZA0KPiByb3V0ZXJzIHdpdGggdGhlIGxpbmsncyBjYWJsZSByYW5nZSBpbmZvcm1h dGlvbi4NCj4gDQo+IA0KPiA+PiBUaGUgZm9yd2FyZGluZyBzeXN0ZW0gc2VuZHMgdG8gdGhlIGNs b3Nlc3QgaW5zdGFuY2Ugb2YgYW4gYW55Y2FzdA0KPiA+PiBwcmVmaXgsIHdoaWNoIGluIHRoZSBj YXNlIG9mIGZlODA6Oi82NCBpcyBhbHdheXMgb24tbGluaywgZm9yIG90aGVyDQo+ID4+IGFueWNh c3QgcHJlZml4ZXMgaXQgbWF5IG5vdCBhbmQgdXN1YWxseSB3b24ndCBiZS4gVGhlIG9ubHkgdGhp bmgNCj4gPj4gc3BlY2lhbCBhYm91dCBmZTgwOjovNjQgaW4gdGhpcyBjb250ZXh0IGlzIHRoYXQg aXMgYXV0b21hdGljYWxseQ0KPiA+PiBjb25maWd1cmVkIG9uIGFsbCBsaW5rcywgc28gaXQgaXMg bmV2ZXIgYW4gb2ZmLWxpbmsgYW55Y2FzdCBmZTgwOjovNjQNCj4gPj4gcHJlZml4Lg0KPiA+DQo+ ID4gU28gdGhlIGFkZHJlc3MgZmU4MDo6IG1pZ2h0LCBvciBtaWdodCBub3QsIGJlIHJlYWNoZWQg b24gYWxsIHRoZQ0KPiA+IGludGVyZmFjZXMuDQo+ID4NCj4gPj4gSSB0aGluayB0aGlzIHRleHQg d291bGQgaGF2ZSB0byBzcGVjaWZpY2FsbHkgZXhjbHVkZSBmZTgwOjovNjQgaWYNCj4gPj4gZmU4 MDo6LzEyOCBpcyBub3QgYSByb3V0ZXItc3VibmV0IGFueWNhc3QgYWRkcmVzcy4NCj4gPj4NCj4g Pj4gIlBhY2tldHMgc2VudCB0byB0aGUgU3VibmV0LVJvdXRlciBhbnljYXN0IGFkZHJlc3Mgd2ls bCBiZSBkZWxpdmVyZWQNCj4gPj4gICAgdG8gb25lIHJvdXRlciBvbiB0aGUgc3VibmV0LiAgQWxs IHJvdXRlcnMgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlDQo+ID4+ICAgIFN1Ym5ldC1Sb3V0 ZXIgYW55Y2FzdCBhZGRyZXNzZXMgZm9yIHRoZSBzdWJuZXRzIHRvIHdoaWNoIHRoZXkgaGF2ZQ0K PiA+PiAgICBpbnRlcmZhY2VzLiINCj4gPg0KPiA+IE15IEZyaXR6Qm94IGF0IGhvbWUgY2VydGFp bmx5IGRvZXMgbm90IGFuc3dlciBvbiBmZTgwOjolMTIsIGFuZCBhcyBmYXINCj4gPiBhcyBJIGNh biB0ZWxsIHRoZSBKdW5pcGVyIHN3aXRjaCBhdCB0aGUgdW5pIGRvZXMgbm90IGFuc3dlciBvbiBm ZTgwOjolMTENCj4gPg0KPiANCj4gSSd2ZSBoYWQgc29tZSBleHBlcmllbmNlcyB3aXRoIEZyaXR6 Qm94ZXMgYmFjayBpbiAyMDEwLCB0aGV5IGRvIHNvbWUNCj4gdW51c3VhbCBJUHY2IHRoaW5ncyBl LmcuLCB0aGV5IHRob3VnaHQgdGhhdCBVTEEgYW5kIEdVQSBwcmVmaXhlcyB3ZXJlDQo+IHRvIGJl IHN3YXBwZWQgaW4gUkFzLCByYXRoZXIgdGhhbiBiZWluZyBhZHZlcnRpc2VkIGluIHBhcmFsbGVs LA0KPiBmb2xsb3dpbmcgdGhlIHN0YXRlIG9mIHRoZSBXQU4gbGluay4NCj4gDQo+IE15IE9wZW5X UlQgcm91dGVyIGlzIGFuc3dlcmluZyBwaW5ncyB0byBmZTgwOjouDQo+IA0KPiAkIHBpbmc2IC1j IDMgLUkgd2xwM3MwIGZlODA6Og0KPiBQSU5HIGZlODA6OihmZTgwOjopIGZyb20gPGRlbGV0ZWQ+ JXdscDNzMCB3bHAzczA6IDU2IGRhdGEgYnl0ZXMNCj4gNjQgYnl0ZXMgZnJvbSBmZTgwOjo8ZGVs ZXRlZD4ld2xwM3MwOiBpY21wX3NlcT0xIHR0bD02NCB0aW1lPTQuNzggbXMNCj4gNjQgYnl0ZXMg ZnJvbSBmZTgwOjo8ZGVsZXRlZD4ld2xwM3MwOiBpY21wX3NlcT0yIHR0bD02NCB0aW1lPTQyLjUg bXMNCj4gNjQgYnl0ZXMgZnJvbSBmZTgwOjo8ZGVsZXRlZD4ld2xwM3MwOiBpY21wX3NlcT0zIHR0 bD02NCB0aW1lPTQuNDYgbXMNCj4gDQo+IC0tLSBmZTgwOjogcGluZyBzdGF0aXN0aWNzIC0tLQ0K PiAzIHBhY2tldHMgdHJhbnNtaXR0ZWQsIDMgcmVjZWl2ZWQsIDAlIHBhY2tldCBsb3NzLCB0aW1l IDIwMDJtcw0KPiBydHQgbWluL2F2Zy9tYXgvbWRldiA9IDQuNDY5LzE3LjI3My80Mi41NjYvMTcu ODg1IG1zDQo+ICQNCj4gDQo+IA0KPiBJJ20gYWxzbyBnZXR0aW5nIGEgbmVpZ2hib3IgdGFibGUg ZW50cnkgZm9yIGl0IG9uIHRoZSBzZW5kaW5nIGhvc3QuDQo+IA0KPiBmZTgwOjogZGV2IHdscDNz MCBsbGFkZHIgPGRlbGV0ZWQ+IHJvdXRlciBTVEFMRQ0KPiANCj4gSSBhbHNvIHZlcmlmaWVkIHdp dGggdGNwZHVtcCB0aGF0IGl0IGlzIHVzaW5nIGZlODA6OiBhcyB0aGUgSUNNUCBlY2hvDQo+IHJl cXVlc3QgZGVzdGluYXRpb24gYWRkcmVzcy4NCg0KSW50ZXJlc3RpbmcgdG8gaGVhciB0aGF0IHRo YXQgd29ya3MuIEkgcmFuIGludG8gYSBzbmFnIHdpdGggdGhlIEtFQSBESENQdjYNCnNlcnZlciBv biBVYnVudHUgMTQuMDQgd2hlbiBJIGhhZCB0aGUgY2xpZW50IHVzZSBmZTgwOjogYXMgdGhlIElQ djYgc291cmNlDQphZGRyZXNzIG9mIGl0cyBESENQdjYgbWVzc2FnZXMuIEkgY2FuJ3QgcmVtZW1i ZXIgaWYgaXQgd2FzIEtFQSBvciBsaW51eA0KdGhhdCBkaWRuJ3QgbGlrZSBpdCwgYnV0IGl0IGRp ZCBub3Qgd29yay4gU29tZSBzb3J0IG9mIGJvZ29uIGZpbHRlciBtdXN0IGhhdmUNCnJlamVjdGVk IGl0Lg0KDQpJdCB0aGVyZWZvcmUgc2VlbXMgbGlrZSB0aGVyZSBpcyBzb21ldGhpbmcgc3BlY2lh bCBhYm91dCBmZTgwOjogYW5kIHRoYXQNCmRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgaGFuZGxl IGl0IGluIGRpZmZlcmVudCB3YXlzLiBXaGV0aGVyIGZlODA6Og0KaXMgYSBzdWJuZXQgcm91dGVy IGFueWNhc3QgYWRkcmVzcywgYW4gb3JkaW5hcnkgdW5pY2FzdCBhZGRyZXNzIG9yIGENCmJvZ3Vz IGFkZHJlc3MgaXQgc2VlbXMgbGlrZSB0aGUgc3BlYyBzaG91bGQgc2F5IHNvbWV0aGluZyBhYm91 dCBpdC4NCg0KVGhhbmtzIC0gRnJlZCANCg0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KDQo= From nobody Tue Jul 11 09:49:49 2017 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 278C613175A for ; Tue, 11 Jul 2017 09:49:46 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 7UIJZxif8ytB for ; Tue, 11 Jul 2017 09:49:44 -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 3E3861201F2 for ; Tue, 11 Jul 2017 09:49:44 -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 v6BGnhDc060157; Tue, 11 Jul 2017 09:49:43 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6BGnavc059657 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Jul 2017 09:49:36 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 09:49:36 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 11 Jul 2017 09:49:35 -0700 From: "Templin, Fred L" To: Mark Smith , Brian E Carpenter CC: Bob Hinden , IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS9CLq2poJvbmwO0u0K0qIX4MZRqJNP64AgACB7p6AAJfNgIAAJSMAgABCYACAACEm0A== Date: Tue, 11 Jul 2017 16:49:35 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <98f52609-f4c5-1975-8237-6f849479c6de@gmail.com> <88ca6eb2-cf01-357e-4cbd-c28b655ae851@gmail.com> <2b1020b9fb1c46e2a801cffd1fcd0c06@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <2b1020b9fb1c46e2a801cffd1fcd0c06@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 16:49:46 -0000 Hi again, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, July 11, 2017 9:10 AM > To: Mark Smith ; Brian E Carpenter > Cc: Bob Hinden ; IPv6 List > Subject: RE: >=20 > Hi, >=20 > > -----Original Message----- > > From: Mark Smith [mailto:markzzzsmith@gmail.com] > > Sent: Monday, July 10, 2017 8:50 PM > > To: Brian E Carpenter > > Cc: Templin, Fred L ; IPv6 List ; Bob Hinden > > Subject: Re: > > > > On 11 July 2017 at 11:36, Brian E Carpenter wrote: > > > On 11/07/2017 11:32, Mark Smith wrote: > > >> On 11 July 2017 at 06:52, Brian E Carpenter wrote: > > >>> Fred, > > >>> > > >>> On 11/07/2017 03:52, Templin, Fred L wrote: > > >>>> Hi, something that I think is a bit under-specified is whether the= address "fe80::" > > >>>> should be considered as an Anycast address. In particular, the lef= tmost 10 bits > > >>>> are "link-local" and the rightmost 118 bits are all-zero. > > >>>> > > >>>> Should fe80:: be considered as the subnet router Anycast address f= or "link-local"? > > >>>> If so, I think that it could be mentioned somewhere in Section 2.5= that even the > > >>>> link-local subnet has an Anycast address. > > >>> > > >>> I don't think so. The text in 4291 about the Subnet-Router anycast = address says: > > >>> 'The "subnet prefix" in an anycast address is the prefix that ident= ifies a specific link.' > > >>> fe80::/10 does not identify a specific link, since it applies to ev= ery link. > > >>> Therefore, fe80:: is logically not a subnet-router anycast address. > > >>> > > >> > > >> I would disagree. fe80::/64 identifies a specific link - it identifi= es > > >> the link the host is attached to - "this" link. > > > > > > fe80::%eth0 specifies an address on an interface. > > > fe80::%eth1 specifies an address on a different interface. > > > Which kind of shows that fe80::/64 in the abstract doesn't > > > specify much of anything. fe80::%eth0/64 is valid syntax > > > under RFC 4007, however. > > > > > > > I understood the question was whether there is a subnet-router anycast > > address within the link-local prefix, meaning that all routers on a > > link would also have a fe80::/128 subnet-router interface address. > > > > Your comments seem to be about selecting an outbound interface using > > fe80::/128, although I'm not sure if you're talking about using it is > > the source or destination address. fe80::/64 is of course ambiguous, > > so zone information needs to be provided in either case. > > > > >> fe80::/64 could also be described as an anycast prefix, because it i= s > > >> assigned to multiple links. Other prefixes can be anycast prefixes > > >> too. > > > > > > Well, that's the trouble. fe80::/64 refers to a single interface > > > if there is only one, but if there's more than one, does it > > > refer to a default choice of interface, or to all interfaces > > > simultaneously? I don't think that is discussed anywhere. > > > > > > > I seem to remember a few years ago somebody posted a draft related to > > that. I can't remember the approach they suggested, however I think > > there are two, although both have issues - ND for the address out of > > all of the host's interface, and use the first response to select the > > outgoing interface (multi-homed host), or use just assume the > > interface the default router appears on (single-homed host). I don't > > think it considered anycast link-local addresses. > > > > An alternative thought I"ve had is to create unique link-local > > addresses by using the same method as ULAs, utilising the bits between > > fe80::/10 and fe80::/64 for a random number. The first host or router > > on a link would pick the random number, announcing the ULL prefix in > > RAs that have a zero value router lifetime, so the host isn't used as > > a default router. The second host on the link would learn that ULA > > prefix and then start announcing it too in RAs (RLife =3D 0) as a backu= p > > if the first host goes away. I think that is all doable, from memory > > the issue I ran into was where to put the ULA in the address selection > > rules, before or after the current LL prefix. This is very similar to > > how Appletalk had seed routers that seeded other non-configured > > routers with the link's cable range information. > > > > > > >> The forwarding system sends to the closest instance of an anycast > > >> prefix, which in the case of fe80::/64 is always on-link, for other > > >> anycast prefixes it may not and usually won't be. The only thinh > > >> special about fe80::/64 in this context is that is automatically > > >> configured on all links, so it is never an off-link anycast fe80::/6= 4 > > >> prefix. > > > > > > So the address fe80:: might, or might not, be reached on all the > > > interfaces. > > > > > >> I think this text would have to specifically exclude fe80::/64 if > > >> fe80::/128 is not a router-subnet anycast address. > > >> > > >> "Packets sent to the Subnet-Router anycast address will be delivered > > >> to one router on the subnet. All routers are required to support= the > > >> Subnet-Router anycast addresses for the subnets to which they hav= e > > >> interfaces." > > > > > > My FritzBox at home certainly does not answer on fe80::%12, and as fa= r > > > as I can tell the Juniper switch at the uni does not answer on fe80::= %11 > > > > > > > I've had some experiences with FritzBoxes back in 2010, they do some > > unusual IPv6 things e.g., they thought that ULA and GUA prefixes were > > to be swapped in RAs, rather than being advertised in parallel, > > following the state of the WAN link. > > > > My OpenWRT router is answering pings to fe80::. > > > > $ ping6 -c 3 -I wlp3s0 fe80:: > > PING fe80::(fe80::) from %wlp3s0 wlp3s0: 56 data bytes > > 64 bytes from fe80::%wlp3s0: icmp_seq=3D1 ttl=3D64 time=3D4.78= ms > > 64 bytes from fe80::%wlp3s0: icmp_seq=3D2 ttl=3D64 time=3D42.5= ms > > 64 bytes from fe80::%wlp3s0: icmp_seq=3D3 ttl=3D64 time=3D4.46= ms > > > > --- fe80:: ping statistics --- > > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > > rtt min/avg/max/mdev =3D 4.469/17.273/42.566/17.885 ms > > $ > > > > > > I'm also getting a neighbor table entry for it on the sending host. > > > > fe80:: dev wlp3s0 lladdr router STALE > > > > I also verified with tcpdump that it is using fe80:: as the ICMP echo > > request destination address. >=20 > Interesting to hear that that works. I ran into a snag with the KEA DHCPv= 6 > server on Ubuntu 14.04 when I had the client use fe80:: as the IPv6 sourc= e > address of its DHCPv6 messages. I can't remember if it was KEA or linux > that didn't like it, but it did not work. Some sort of bogon filter must = have > rejected it. >=20 > It therefore seems like there is something special about fe80:: and that > different implementations handle it in different ways. Whether fe80:: > is a subnet router anycast address, an ordinary unicast address or a > bogus address it seems like the spec should say something about it. I just tried assigning the address fe80::/128 to the eth0 interface of a first linux host then tried ping6 from a second linux host and the ping6's succeeded. So, whether it is a plain unicast address or a subnet router anycast address it looks like linux is not rejecting it as a bogon. So, it must be KEA that didn't like it. Thanks - Fred > Thanks - Fred >=20 > > Regards, > > Mark. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jul 11 10:06:59 2017 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 7BEDA13176E for ; Tue, 11 Jul 2017 10:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 kv5EvfKED1dG for ; Tue, 11 Jul 2017 10:06:55 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35EC12EAB0 for ; Tue, 11 Jul 2017 10:06:55 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id d78so9232446qkb.1 for ; Tue, 11 Jul 2017 10:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JK8Lxt6iEwlXsQSEMte3bJVo7eruGcNyscXhQyN/ces=; b=GPL+D3VhjImg6CbtWdUVqwTbeqLh8DQg8CAIhR8jBB/1CagAf4GSy+4QJ3suhc6wR0 WpDLRyjv88Jo6srsQkF2OKue6jjHYmdiE33ip4fBELuF54+54NGBb9vEPisQoVw+Os0F 2Z1/IyxoaXRwByOKeyBSBGD874qXWBPs5lQcFnVa3IZTKkrmkTYs5JNNZpcTD0gqEBtj HGqFS3d+2T4/BvOQ6CGrlnCbup7pvflqRmMdKRmskPOXVVfXpPahVumG69zRfDr+ZDkw Kn9VVhxugqh0dfo62rw2VsKsQnceKeKjqg8MgH6akxEed7XupY7dxDIrTHzAsJywzHy3 rt7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JK8Lxt6iEwlXsQSEMte3bJVo7eruGcNyscXhQyN/ces=; b=Ve3egvItT7ARSz6xuI/bYzjVxOyqvqsBYV+Vp69zzsuChoWLY4qCEZLFsJd1l2GuDQ tk3b+oMTXIISgqs+1Nuc7tyb2CQoj1hb2T5McFrkpv+k+05j+PTniKdkDufFMUssVDqI M6mU1u/GsBQhmq6PEm/hfZd17xdMV+8qe87AHgLlmsHc28fZhQM6R2HcTq/1fOfxe/bR riCSIeqZyvvIzT/2XuqPnBTAqIS8gfmy6IS9tRBy2vZHg0Y2E1f9mxbm77rPQQG/orxL 9LZLbW5gRV3jS7Q1oenna++qT4t+ZlAkWzs/AhCZGpevV1+2diXIlgKnyKjYcs1EiHy1 gycA== X-Gm-Message-State: AIVw111cAJmZortjp3xGbzDxHwkfROg3x3C6aL2JfY8IQLyn0WkEOcVg W8GXKzEOk3IajryRtFeN8ZY6CDl5ACRCR6Q= X-Received: by 10.200.46.100 with SMTP id s33mr1354434qta.48.1499792814705; Tue, 11 Jul 2017 10:06:54 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Tue, 11 Jul 2017 10:06:54 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 11 Jul 2017 10:06:54 -0700 X-Google-Sender-Auth: DjibuEw2VEKoG3CCq6WjQWlrqg8 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: David Farmer Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 17:06:57 -0000 At Mon, 10 Jul 2017 15:16:46 -0500, David Farmer wrote: > While that doesn't explicitly say "A prefix length associated with a > manually configured address determines the on-link prefix associated with > the manually configured address." in my opinion it strongly implies it. > How else would you provide an on-link prefix for a manually configures > address otherwise? Also, I think this need to be said explicitly some > place. But if you have suggestion to clarify, I'd be interested to here > them. Regardless of how strongly (if at all) RFC5942 implies that, I agree it's good to note it explicitly in some place. As for suggested text, I'll hold off for now - at this moment it's not even clear we (wg) agree on the need for further wordsmith. -- From nobody Tue Jul 11 10:21:03 2017 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 9F68C129B07 for ; Tue, 11 Jul 2017 10:21:01 -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 dUj89_CM0MgM for ; Tue, 11 Jul 2017 10:21:00 -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 10AD0124234 for ; Tue, 11 Jul 2017 10:21:00 -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 v6BHKwYh050851; Tue, 11 Jul 2017 10:20:59 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6BHKmsH050287 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Jul 2017 10:20:48 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 10:20:47 -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.1263.000; Tue, 11 Jul 2017 10:20:47 -0700 From: "Manfredi, Albert E" To: David Farmer CC: 6man WG Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BAgADKDwCAAFSoEA== Date: Tue, 11 Jul 2017 17:20:47 +0000 Message-ID: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 17:21:02 -0000 RnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdIA0KDQo+IElQdjYgYXMg Y3VycmVudGx5IGRlZmluZWQgZG9lcyBhY3R1YWxseSByZXF1aXJlIElJRHMgdG8gYmUgNjQgYml0 cywNCj4gaWYgdGhpcyB3YXNuJ3QgdGhlIGNhc2UgdGhlbiB5b3UgY291bGQgdXNlIHN1Ym5ldHMg b2YgYW55IGxlbmd0aA0KPiB3aXRob3V0IGFueSBzcGVjaWFsIHJlcXVpcmVtZW50cyBvciBjb25z aWRlcmF0aW9ucy4NCg0KQW5kIGluIGdlbmVyYWwsIHlvdSBjYW4uIEkgdGhpbmsgdGhpcyBpcyBh IHN0dW1ibGluZyBibG9jay4gVGhlcmUgYXJlIGV4YW1wbGVzIHdoZXJlIDY0LWJpdCBJSURzIGFy ZSBzdGlsbCByZXF1aXJlZCwgYW5kIHRoZXJlIGFyZSBleGFtcGxlcyB3aGVyZSB0aGV5IHdlcmUg cmVxdWlyZWQgZm9yIHJlYXNvbnMgdGhhdCBubyBsb25nZXIgYXBwbHkuIEJ1dCBhcyBvZiBub3cs IGlmIHlvdSB1c2Ugc3RhdGljIGFkZHJlc3Nlcywgb3Igc2ltaWxhcmx5IERIQ1B2NiwgeW91J3Jl IG5vdCBsaW1pdGVkLiBFdmVyeXRoaW5nIHdvcmtzIGZpbmUgd2l0aCBzaG9ydGVyIElJRHMuIElm IHlvdSB1c2UgU0xBQUMsIHlvdSBhcmUgbGltaXRlZCB0byA2NC1iaXQgSUlEcywgYnV0IHRoYXQg bGltaXRhdGlvbiBpcyBzZWxmLWltcG9zZWQsIHRvIHRyeSB0byBrZWVwIG90aGVyLXRoYW4tNjQt Yml0LUlJRHMgZnJvbSBiZWNvbWluZyB0b28gZWFzeSB0byBjb25maWd1cmUuIEluIHByaW5jaXBs ZSwgaXQgd291bGQgYmUgZWFzeSBlbm91Z2ggdG8gcmVtb3ZlIHRoYXQgNjQtYml0IGxpbWl0YXRp b24gZnJvbSBTTEFBQy4NCg0KSSdtIG9wcG9zZWQgdG8gY29udGludWUgdG8gaW1wbHkgdGhhdCA2 NC1iaXQgSUlEcyBhcmUgInJlcXVpcmVkLCIgb3RoZXIgdGhhbiBpbiBjYXNlcyBsaWtlIFNMQUFD LCBVTEFzLCBMTEFzLiBUaGF0IHdvcmQgInJlcXVpcmVkIiBpcyB3aGF0IGNhdXNlcyB0aGUgcHVz aGJhY2suDQoNCkJlcnQNCg0K From nobody Tue Jul 11 16:54:43 2017 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 E49FC12F287 for ; Tue, 11 Jul 2017 16:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 j-XTm6Z_k3OE for ; Tue, 11 Jul 2017 16:54:40 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 D5FC812EC10 for ; Tue, 11 Jul 2017 16:54:39 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w19so4891645uac.0 for ; Tue, 11 Jul 2017 16:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=liiJ81L0Blta3Ox8RD5slMiMxkT4Cvv7s/l+cEbS1bs=; b=FBCN1TK3om6mcgG3U0+mrKiDfKyMSWZdI46bWtE7lGUH1RsIWUZU74QoTwU6yb82My N/egjFXvgB8F8VCvCEXZsocRd/4QUF9523tTR7WVsP02BAfOKkAQReIhl3kt/xmypA39 QEFCxUnnokk+hBC01v7VKnkJ3VXvlgIZ1eOvOSh0S2flLZUMMqjDzwUx1p/YNbcJtdvL DxKbPIgLwzCKnOZp7KUbzC/VNV5Hu6WUen2CuMwins0UTH10qyM5ZjflsuaTGTDf3V/1 wS88El1mOO62Z2BC6CLYO+3rB9HGP55SHvMykS0pxX5Y00wgsfMfaMZAZkZGaIQ5bmMD yvHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=liiJ81L0Blta3Ox8RD5slMiMxkT4Cvv7s/l+cEbS1bs=; b=latpV14mb5dMEJJF3OYZz73qln9nNC4Mg8qCZgL5A1JU1Z/r8FASeL1j/8ZkuR6ycX Cg93vZWL3w1bLickJlY3ADXO745P7J6SoKd24aKWLw5SEbO+vN1T6XtB7c6lZyR78cjR I8aKcgBRl89J+o7sASyBILxLKH6hT14v3J2TrC1k0JqngKbGolMaMeoIilBdrCaB+mi2 nvvCUCmNlrcaJYJFFSf5hcpDul1QJyd/GoidWNEdKlcIWFrNnWzehrJQXgXU6kepA7Bh mpXvkbD9pRvEP84SyMLbnW947pymgOP9On/pJB3AK3GshMA1QiFVS74py5RRcjfQX/K1 5ajQ== X-Gm-Message-State: AIVw111AGeEukwrh3HustECzk0jO8Ovpgx1ZTWoyCZcGjFH70QiviOQK WUmXscsvt7HuurZ8A2n+GX+9+wBjlA== X-Received: by 10.159.41.163 with SMTP id s32mr1370364uas.90.1499817278935; Tue, 11 Jul 2017 16:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Tue, 11 Jul 2017 16:54:38 -0700 (PDT) Received: by 10.176.81.100 with HTTP; Tue, 11 Jul 2017 16:54:38 -0700 (PDT) In-Reply-To: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Wed, 12 Jul 2017 09:54:38 +1000 Message-ID: Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" Cc: 6man WG , David Farmer Content-Type: multipart/alternative; boundary="001a114bd63e2398c00554136c6e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 23:54:42 -0000 --001a114bd63e2398c00554136c6e Content-Type: text/plain; charset="UTF-8" On 12 Jul. 2017 03:21, "Manfredi, Albert E" wrote: From: David Farmer [mailto:farmer@umn.edu] > IPv6 as currently defined does actually require IIDs to be 64 bits, > if this wasn't the case then you could use subnets of any length > without any special requirements or considerations. And in general, you can. I think this is a stumbling block. There are examples where 64-bit IIDs are still required, and there are examples where they were required for reasons that no longer apply. But as of now, if you use static addresses, or similarly DHCPv6, you're not limited. Everything works fine with shorter IIDs. This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too. As an example, the stateful DHCPv6 server in OpenWRT currently compromises those security and privacy properties as it is enabled by default, as the range of IIDs it uses is the same size as the DHCPv4 server's address range e.g. 100 addresses. (OpenWRT supports both SLAAC and Stateful DHCPv6 by default, my hosts that support both had great private/secure addresses through SLAAC and terrible ones through DHCPv6) In IPv4, this is less of a concern, because NAT provided a layer of security and privacy to individual hosts' addresses, in particular to residential users. If we advocate for removing NAT from IPv6, or more accurately advocate end-to-end addressing, we need to provide alternate methods to restore the privacy and security provided by NAT. Those methods should also not be reliant on devices or functions in the network, because the hosts that need them the most are also very portable (i.e., smartphones and laptops), and are easily and commonly attached to untrustable public networks. If you use SLAAC, you are limited to 64-bit IIDs, but that limitation is self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy to configure. In principle, it would be easy enough to remove that 64-bit limitation from SLAAC. I'm opposed to continue to imply that 64-bit IIDs are "required," other than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes the pushback. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a114bd63e2398c00554136c6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 Jul. 2017 03:21, "Manfredi, Albert E" <albert.e.manfredi@boeing.com&g= t; wrote:
From: David Farm= er [mailto:farmer@umn.edu]

> IPv6 as currently defined does actually require IIDs to be 64 bits, > if this wasn't the case then you could use subnets of any length > without any special requirements or considerations.

And in general, you can. I think this is a stumbling block. There are= examples where 64-bit IIDs are still required, and there are examples wher= e they were required for reasons that no longer apply. But as of now, if yo= u use static addresses, or similarly DHCPv6, you're not limited. Everyt= hing works fine with shorter IIDs.

This is not recognising that there ar= e more than operational or functional properties of addresses. They have pr= ivacy and security properties too.

As an example, the stateful DHCPv6 server in OpenWRT currently c= ompromises those security and privacy properties as it is enabled by defaul= t, as the range of IIDs it uses is the same size as the DHCPv4 server's= address range e.g. 100 addresses. (OpenWRT supports both SLAAC and Statefu= l DHCPv6 by default, my hosts that support both had great private/secure ad= dresses through SLAAC and terrible ones through DHCPv6)

In IPv4, this is less of a concern, because= NAT provided a layer of security and privacy to individual hosts' addr= esses, in particular to residential users. If we advocate for removing NAT = from IPv6, or more accurately advocate end-to-end addressing, we need to pr= ovide alternate methods to restore the privacy and security provided by NAT= .

Those methods should a= lso not be reliant on devices or functions in the network, because the host= s that need them the most are also very portable (i.e., smartphones and lap= tops), and are easily and commonly attached to untrustable public networks.=


If
you use SLAAC, you are limited to 64-bi= t IIDs, but that limitation is self-imposed, to try to keep other-than-64-b= it-IIDs from becoming too easy to configure. In principle, it would be easy= enough to remove that 64-bit limitation from SLAAC.

I'm opposed to continue to imply that 64-bit IIDs are "required,&q= uot; other than in cases like SLAAC, ULAs, LLAs. That word "required&q= uot; is what causes the pushback.

Bert

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

--001a114bd63e2398c00554136c6e-- From nobody Tue Jul 11 19:32:53 2017 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 7737C12EB4A for ; Tue, 11 Jul 2017 19:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 W2syYTMdsAI0 for ; Tue, 11 Jul 2017 19:32:51 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 2EF30120725 for ; Tue, 11 Jul 2017 19:32:51 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k14so5319467pgr.0 for ; Tue, 11 Jul 2017 19:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5fc86EdUzmug6TvTzx5YFivsLaswOSJLv1LQXbU22wE=; b=dXCP21zN3yRhft+BlsiOM6PbRXd26JV/AptIuQTLGvrvDWNYjudJRItjbLFIRb9+4w gZB6xidPDRKydPT4W/E8euZfHvHqU4OF9PuSrsDr2/FntgTnB7tgJqgurB09uGhcmZAu VP6NYWPLukAysUhxXb30mHPX/3m/JpM+/fqr4bUxhMY5dmGecOQJsOzBN/Th0MgXJlVF wlEKoux8cQOuiYTIve+geGH6Z4VJjLArH2bt/Jr2wnM4uSwMRm1+JQUjKWLyP/KFHIjM itrXDl6/+s1vtO0J4rGYWqt6gkaI2ypPlGO+0Ldv//plyOyxFuUcdxmhaR9VLO98eCas YOnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5fc86EdUzmug6TvTzx5YFivsLaswOSJLv1LQXbU22wE=; b=Ya7ifvAfReQoCuUOUMurunCQl8E0/3Xjx6anENgvBjfP+TkmTezdIPVAVrsMX5snIc tqTppdqrZog0tFSsbpu21ZRbhPVtCWlX2vUy0PXrQLn+cdFIysi7uV7oWdbyA/krY8AW 5KZNESppAOsaCMZHDSKJ1FPBuroAcZonEkqdffpGH8FqDE7zgjUq9pf6mzBfRi3Wxyfi SgksoLcMskKOMHbK7kNMFYjBZt2Phi5Cm/0BNXvqQIJ4fe4DJYgAI1QJiLPqINAORapq zbC1gBOKzLB7sssih2V92RDMf5rV3KaxJAQapzHGDvcxhT9WzjUc6dQPOB74/HA4OUtr jRQw== X-Gm-Message-State: AIVw110pkQ/6F9Nrj4OHvzfqnZrKh5p5ixtQIdFySrBZYz6WqugMbJCC nLKABfhdOLOcoL9i X-Received: by 10.84.229.5 with SMTP id b5mr1611593plk.164.1499826770497; Tue, 11 Jul 2017 19:32:50 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id 10sm1163538pfo.134.2017.07.11.19.32.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 19:32:49 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Ole Troan Cc: Nick Hilliard , David Farmer , 6man WG References: <5963BF27.1050300@foobar.org> <8BB052D8-221B-4BEC-B556-A06A63454807@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <71ee0acd-9f4b-c5ea-baf8-4861e882df9e@gmail.com> Date: Wed, 12 Jul 2017 14:32:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8BB052D8-221B-4BEC-B556-A06A63454807@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 02:32:52 -0000 Ole, It seems to me that you have always been indicating that you think the text should say, effectively, that the IID length MUST be 64 (except for the well know exceptions). I apologise if that is incorrect. Regards Brian On 12/07/2017 03:22, Ole Troan wrote: > Brian, > >> On 11 Jul 2017, at 01:10, Brian E Carpenter wrote: >> >> Neither of our WG Chairs is neutral on this issue; one is the >> document editor, the other has a clear opinion, to which he is >> completely entitled. Personally, I think the AD could step >> in to judge consensus. > > What is my opinion? Could you please summarize? > It might be clearer to you than me. :-) > > Ole > . > From nobody Tue Jul 11 19:39:21 2017 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 33F1212EB4A for ; Tue, 11 Jul 2017 19:39:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q9HPxJ4lKJbC for ; Tue, 11 Jul 2017 19:39:17 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 2ABE512762F for ; Tue, 11 Jul 2017 19:39:17 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q86so5303462pfl.3 for ; Tue, 11 Jul 2017 19:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0J6BYe9qu/8DE+owSbQklULvkSsnaKCdkTyAydnyb2U=; b=u3Jbdikhf9bXIFyKN2pUWkvElLFyMNkmiZL0zb/WDk7pbPJYffeeZgl/Rp/n3Hizua M7ZB9uehsXgTQ7n5JAOV6tf7G14OJKuTSiFEDQSAgD6hZRNj13R7Dz0q/ugDHZo32Xev Rmbxw4AVXW6DTfHSfFbhikjEFvFr1IGRoLZ5otRvuL5+RYPBVBvnLqE47ydS0Pp3nYKZ wKGv8lsteyCXSU42OwNSY0YsLMCCRgdZl0EGazN9VoJz3dMC69SYhFpTzt1v6zduoYIQ tzjLUQNL7+BoALfuT7rmNVTx2ohfBs9eisR+Fs5Y2OPYrf4IhN+WghenMZ0dN6jIaTAc rCPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0J6BYe9qu/8DE+owSbQklULvkSsnaKCdkTyAydnyb2U=; b=KTnOPnJ6FPZj5qswCYSeB+IE80Z5chzF87QqJJblAOc37UeHEDab2nQAmf3DVe7on7 pVAoRAzP5a2TxIVeu7a7ArH1xM/tDUOVV5ywBgFTRBtyyTxWM0sPAoV5R3QAIF0lxWZm FvHeZiosMijkQQowXzHoLJ3j5dQ2pObhpEf6M3kOkv2FAy+O86RCQMAT361dSm+A9Txw NLzTb+v+yA6QekKKuTQNyPRXTn+kRzWE3aEl45QgqqzkSajzzuP9yJxhee15fqAlixm3 /Rpb7WLhSKD2+kb5Jn9sh2WEsv1YfrCwBHxg7JIzLlAMkrf53EBWRsIp3YkWixGHEXI8 e74w== X-Gm-Message-State: AIVw110rqmIr/Ljrnd+UXxIoFXxBUekUmdNCkxVhjAZofQ2M0L9iocNp NMiIpFz7WYHy8rtJ X-Received: by 10.98.223.141 with SMTP id d13mr53555862pfl.179.1499827156545; Tue, 11 Jul 2017 19:39:16 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id a71sm1175119pfl.129.2017.07.11.19.39.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 19:39:15 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Mark Smith , "Manfredi, Albert E" Cc: 6man WG References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> Date: Wed, 12 Jul 2017 14:39:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 02:39:19 -0000 On 12/07/2017 11:54, Mark Smith wrote: >> On 12 Jul. 2017 03:21, "Manfredi, Albert E" >> wrote: >> >> From: David Farmer [mailto:farmer@umn.edu] >> >>> IPv6 as currently defined does actually require IIDs to be 64 bits, >>> if this wasn't the case then you could use subnets of any length >>> without any special requirements or considerations. >> >> And in general, you can. I think this is a stumbling block. There are >> examples where 64-bit IIDs are still required, and there are examples where >> they were required for reasons that no longer apply. But as of now, if you >> use static addresses, or similarly DHCPv6, you're not limited. Everything >> works fine with shorter IIDs. >> > > This is not recognising that there are more than operational or functional > properties of addresses. They have privacy and security properties too. Very specifically, it would be irresponsible not to require pseudo-random IIDs of at least N bits for automatically assigned addresses. RFC7217 doesn't define N, but I assume it would be at least 40 and probably more. The advantage of requiring or recommending 64 bits is that it avoids the debate about N. I prefer 'recommend' because it avoids enumerating all possible exceptions. We've seen how hard it is to wordsmith the exceptions. Brian > As an example, the stateful DHCPv6 server in OpenWRT currently compromises > those security and privacy properties as it is enabled by default, as the > range of IIDs it uses is the same size as the DHCPv4 server's address range > e.g. 100 addresses. (OpenWRT supports both SLAAC and Stateful DHCPv6 by > default, my hosts that support both had great private/secure addresses > through SLAAC and terrible ones through DHCPv6) > > In IPv4, this is less of a concern, because NAT provided a layer of > security and privacy to individual hosts' addresses, in particular to > residential users. If we advocate for removing NAT from IPv6, or more > accurately advocate end-to-end addressing, we need to provide alternate > methods to restore the privacy and security provided by NAT. > > Those methods should also not be reliant on devices or functions in the > network, because the hosts that need them the most are also very portable > (i.e., smartphones and laptops), and are easily and commonly attached to > untrustable public networks. > > > If > > you use SLAAC, you are limited to 64-bit IIDs, but that limitation is > self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy > to configure. In principle, it would be easy enough to remove that 64-bit > limitation from SLAAC. > > I'm opposed to continue to imply that 64-bit IIDs are "required," other > than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes > the pushback. > > Bert > > -------------------------------------------------------------------- > 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 11 20:18:41 2017 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 B43DA126CC7 for ; Tue, 11 Jul 2017 20:18:40 -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 wVGIDtrGhBdb for ; Tue, 11 Jul 2017 20:18:39 -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 6B5D8126D05 for ; Tue, 11 Jul 2017 20:18:39 -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 v6C3Ic7A044222; Tue, 11 Jul 2017 20:18:38 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6C3IWUn044212 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Jul 2017 20:18:32 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 20:18:31 -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.1263.000; Tue, 11 Jul 2017 20:18:31 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , Mark Smith CC: 6man WG Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BAgADKDwCAAFSoEIAA6HsAgAAt/wD//43p8A== Date: Wed, 12 Jul 2017 03:18:31 +0000 Message-ID: <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> In-Reply-To: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 03:18:41 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPiBWZXJ5IHNwZWNpZmljYWxseSwg aXQgd291bGQgYmUgaXJyZXNwb25zaWJsZSBub3QgdG8gcmVxdWlyZQ0KPiBwc2V1ZG8tcmFuZG9t IElJRHMgb2YgYXQgbGVhc3QgTiBiaXRzIGZvciBhdXRvbWF0aWNhbGx5IGFzc2lnbmVkDQo+IGFk ZHJlc3Nlcy4gUkZDNzIxNyBkb2Vzbid0IGRlZmluZSBOLCBidXQgSSBhc3N1bWUgaXQgd291bGQg YmUgYXQNCj4gbGVhc3QgNDAgYW5kIHByb2JhYmx5IG1vcmUuDQoNCkV4YWN0bHkuIFRoaXMgaXMg b25lIGV4YW1wbGUgdGhhdCBzaG91bGQgbm90IG1hbmRhdGUgNjQsIGJ1dCByYXRoZXIgd2hhdGV2 ZXIgaXMgZW5vdWdoIGZvciBhbGwgdGhlIGNvbnNpZGVyYXRpb25zIHRoYXQgaGF2ZSB0byBiZSBt YWRlLiBGb3IgY29sbGlzaW9ucyBvciBzZWN1cml0eSwgNDggb3IgNDAgYml0cyBpcyBwcm9iYWJs eSBwbGVudHksIGRlcGVuZGluZyBhbHNvIG9uIHRoZSBudW1iZXIgb2YgaG9zdHMgZXhwZWN0ZWQg aW4gYSBzdWJuZXQgcHJlZml4LiBXaXRoaW4gYSBob21lbmV0LCBJJ2QgbXVjaCByYXRoZXIgZGVw ZW5kIG9uIGEgZmlyZXdhbGwgdGhhbiBhbiBvdmVyYWJ1bmRhbmNlIG9mIElJRCBiaXRzLCBmb3Ig aW5zdGFuY2UuDQoNCj4gVGhlIGFkdmFudGFnZSBvZiByZXF1aXJpbmcgb3IgcmVjb21tZW5kaW5n IDY0IGJpdHMgaXMgdGhhdCBpdA0KPiBhdm9pZHMgdGhlIGRlYmF0ZSBhYm91dCBOLg0KDQpCdXQg aXQgcGVuYWxpemVzIGFwcGxpY2F0aW9ucyB0aGF0IHdvdWxkIGJlbmVmaXQgZnJvbSBtb3JlIGZs ZXhpYmlsaXR5LiBNdWNoIG9mIHRoZSBwcm9ibGVtIGNvbWVzIGZyb20gb3VyIGluYWJpbGl0eSB0 byBldmVuIGRlZmluZSB3aGF0IGEgInNpdGUiIG1pZ2h0IGJlLCB0byB3aGljaCBhIC80OCBtaWdo dCB0aGVvcmV0aWNhbGx5IGJlIGFzc2lnbmVkIChpZiB3ZSBldmVuIGJlbGlldmUgdGhhdCdzIGEg cmVhbGlzdGljIGV4cGVjdGF0aW9uIGFueW1vcmU/KS4gU28sIG5vdCBrbm93aW5nIHdoYXQgY29u c3RpdHV0ZXMgInNpdGUsIiBhbmQgbm90IGJlbGlldmluZyB0aGF0IGFsbCBzaXRlcyB3aWxsIGdl dCBhbnl0aGluZyBiZXR0ZXIgdGhhbiBhIC82NCwgSSB0aGluayB3ZSBuZWVkIHRvIGF2b2lkIGhh dmluZyBkZXZpY2UgbWFrZXJzIGNyZWF0ZSBoYXJkIDY0LWJpdCBJSUQgYm91bmRhcmllcy4gSXQg d291bGQgYmUgdW5mb3J0dW5hdGUgaWYgZXZlcnkgdGhlcm1vbWV0ZXIgYW5kIHRoZXJtb3N0YXQg d2VyZSByZXF1aXJlZCB0byBoYXZlIGEgNjQtYml0IElJRC4gKk9yKiB3ZXJlIGJ1aWx0IHRoYXQg d2F5LCBiZWNhdXNlIHNvbWVvbmUgcmVhZCB0aGF0IDY0LWJpdCBJSURzIGFyZSAicmVxdWlyZWQu Ig0KDQpCZXJ0DQoNCg== From nobody Tue Jul 11 21:53:05 2017 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 E63F9129AAD for ; Tue, 11 Jul 2017 21:53:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xZhCsbP9ntd6 for ; Tue, 11 Jul 2017 21:53:01 -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 85D04120227 for ; Tue, 11 Jul 2017 21:53:01 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c73so6782720pfk.2 for ; Tue, 11 Jul 2017 21:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=egAOkkqOJBGqAeNSyPbK7xkB2iqt6DChU0e7ToF5Pes=; b=YFz5/sOltn/UwllMka2/k5RsIbQTb1ObuQvbgUMtdLOLv45XtiyeDMJArCt4wzz9ri CtGNl5sxr1Xm6W5eA69EmKBR3TVpXeKXb2U565E8EFZwFW6w9JClsJXHEdX9Cb4ezbSH UH6LnJg+KSkCoU6+i8oZgQFaK3glqeWuYc7k7ujarN7xbpywjF5QVFL2E/CQPjreWhQb bAuZ7XYUsZGg8cbF/ZsbcDY3F6Dc5qHKvFOiBNQOEYQlat/Ykyb5fhlaRRnU+ixgMvtj 8SBTstF117pGe/fNDU4Tnbu37BDWxu/Vr77EpUbrH3nhY1KvPzjHV1ykjNBvC7z9zJ1/ zmAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=egAOkkqOJBGqAeNSyPbK7xkB2iqt6DChU0e7ToF5Pes=; b=KrRBfexZBkoi/gIyFjYjwFno5bhd1eUV15OgfB7q4/1fh8NyrWSjMLIOLTCHwxOWEW zsqw7jxrXYKiIJ25GTc1Iu/MVF58HjI6mD/Uz9DUmI6GO5r2Y6LHaT7j9wCZlj1nwaWZ cKJJh37Me6f0zPXPPv2V6qGoEq7GMt9ZdOPEztrNNmCXFY9K4ceSPiPxTAiF/jwddRZt R8jTq9skKkNtKNBtVB8MqdiX/p95kJNyH1nWCqIP47O+NB2SmEjOgcQzJUYfozxu0ZQw NwyKLbFFyshe74T9HspH6JH5ad2tj4WaGvIQKLtGP9ChsJhm2PcH4SyxmcAABpQ5ofp7 EpPg== X-Gm-Message-State: AIVw110YdZPoqsFXNro/8izZaYVDt2oJjtaNq7zulkXEiFMj4nj/Khb5 BORv7T8Y0o/gb2g/ X-Received: by 10.84.194.163 with SMTP id h32mr2068178pld.79.1499835180944; Tue, 11 Jul 2017 21:53:00 -0700 (PDT) Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id k127sm1733146pfc.75.2017.07.11.21.52.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 21:53:00 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" , Mark Smith Cc: 6man WG References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <268238ef-79ae-3ae2-45ab-7dadb04501b7@gmail.com> Date: Wed, 12 Jul 2017 16:53:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 04:53:03 -0000 On 12/07/2017 15:18, Manfredi, Albert E wrote: > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Very specifically, it would be irresponsible not to require >> pseudo-random IIDs of at least N bits for automatically assigned >> addresses. RFC7217 doesn't define N, but I assume it would be at >> least 40 and probably more. > > Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance. > >> The advantage of requiring or recommending 64 bits is that it >> avoids the debate about N. > > But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?). So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64, I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID. *Or* were built that way, because someone read that 64-bit IIDs are "required." I'm not convinced. I'm arguing for flexibility so that we don't look stupid in 50 years time, but 15 trillion /48s is an awful lot of /48s, even for the Internet of Things. I don't really have a problem with 64 bit IIDs in light switches. Brian From nobody Tue Jul 11 22:38:58 2017 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 60B04129B29 for ; Tue, 11 Jul 2017 22:38:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 LMIT6tx7EoWL for ; Tue, 11 Jul 2017 22:38:56 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 13F5812706D for ; Tue, 11 Jul 2017 22:38:56 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 84so3789895ybe.0 for ; Tue, 11 Jul 2017 22:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D2q291yP9sDvi6RJlFENIC6RB0addEZRicaj1RF8So0=; b=Mk3LZdO9mS07Njl73zohGKnHORKo9veq91I2pE+E5GQ4MMDlcRl///pvy1blROfUCG GLBzsUQfpprtmfL+SphJ/u4vMyj5/QIFBlNRdG5AMNrtSZ7rrHDnKXqsZIGwGWzaAskO +uqgcrMfJLyvBVbWo1LmQGgJxnasb8MVyGG9Vjf+9CdoWJ3Yr0ICEpTns47vrJr3GPYN /2JfWiYZ0iy8snCYrSDBBAODU1Iyzv26e2jjdbZrBM9DAcVr1VmvNCTJuMmczlBmLFH1 ai0KRECnhZudRYXnzw82hyfmyFS9Yue0sZXbgC1Fic9Su3yWxPHx975LVg/evRulY54g dA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D2q291yP9sDvi6RJlFENIC6RB0addEZRicaj1RF8So0=; b=jNQpvC4qoDDPtaoKHyHb3zcK7y4CTJwEUYhf3fmGBoqJNLdRJE7E6bXwazdgW2V2w5 n1+MXJa4old2YLhsKYjrKEIAFP+BwfxmGk9G+FvHZB88nSUxNsBC9FuzQu44fgOGaF/h Gdr/+Gc8T/SuNQI7y0HjsL/uJMFhF/0pvABxxqs5WRJKiJwtsso85MvwyVmv9cd+FJSS 0MWwvOwEISqbc7rPKrCi9BYwEnH5GszVV0zOaun3WxDMiB+URcKydQc3zIhq8GnsgxhX gHMgfqXvDPgaXKMnQKPkMpiR3t/ONQSKye3exv0nTQkdkXNZdVWTrdvTJsNWELAkbR9c i+ZQ== X-Gm-Message-State: AIVw110TRdTReaLC42wjSg+D+/ofgAAQjQt62C3/ZeIGHDHhkQ1KaY4Y +P138lquCPk3CA== X-Received: by 10.37.48.139 with SMTP id w133mr116516ybw.84.1499837935303; Tue, 11 Jul 2017 22:38:55 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id s29sm558366ywa.45.2017.07.11.22.38.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 22:38:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Suresh Krishnan In-Reply-To: Date: Wed, 12 Jul 2017 01:38:54 -0400 Cc: Nick Hilliard , David Farmer , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <1DAEB80F-A139-4839-BA4B-78AE2F479595@gmail.com> References: <5963BF27.1050300@foobar.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 05:38:57 -0000 Hi Brian, > On Jul 10, 2017, at 7:10 PM, Brian E Carpenter = wrote: > ... > Personally, I think the AD could step > in to judge consensus. Yes. I have refrained from actively discussing this topic in order to = leave this option open for me if it is required. I sincerely hope that = the WG can come to consensus on this issue, though. Thanks Suresh From nobody Wed Jul 12 00:48:08 2017 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 8AB21131467 for ; Wed, 12 Jul 2017 00:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zG3Rt-SX3rXz for ; Wed, 12 Jul 2017 00:48:05 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 2B7E5131447 for ; Wed, 12 Jul 2017 00:48:05 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id g40so9312148uaa.3 for ; Wed, 12 Jul 2017 00:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=m7pX7LSITvnmDpGlRn144CEOKN+AekyZtpopmMO5cDE=; b=MaFPlruo57pHTCq+3YumnvaclSXwGYE7bVWZTMPolP1qHW5cNQ7rHlYXjQfzfiQQKp hmedQodORYAbc/RGAsfZfwuo16x+o2KZBbEe0wrtz5ZksQ+Pa5UvBMUQY4vkDY9txTc0 S6xmb02FdarUbCsx/dwZrcX3kY1ilPCb+CogJ4E9qcbtfqsmw91DUibVWASizeWcpB9A o1ILcv/KnPeA/2fqUjWPJWKQDyijcBW5tvI6zLhkG6piHmMC2dzSITLFzGdxHZ4Z+ut1 sAdYRTQk/JMfBrs5rHte+zhJshMITOvErvt+xSvF8UncW9VkgbnJ7kflOCDMZAvZILgJ z7OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=m7pX7LSITvnmDpGlRn144CEOKN+AekyZtpopmMO5cDE=; b=Y0V3jdlbJWm0yEljWVeb+IMoo+2p1iB/LZhlCK8xuQNpD1LSvHI9tJMbtMJ5CjRKnI RfqxyECZpQzpcWbg1pfkKW3w25Qjp/Xrkk1WLGA6+JXbiOHrEf2qfA7rBjDktSNetB5U sMGdU22pDS3/z8i1zMN1aCIaNXAr4bDUwiDg2XUt2mKDqQQUCeLK/gLEobvaUe0M5HLz uOvD51m/e5kevRP7qtUbFGU2cbVU6yvKieWv4n1fkAoA6tUfu0AIMX2JEHjQSRm1xtSO YTQI7Wg0fvrch13DxLNCSiJrlqIfQGEhVbi86OlEDH3BcQSJSN6HjKTY8aFwdE3+b7ih b0+Q== X-Gm-Message-State: AIVw113Xlv7Nvf0XIVBMI9HMfpTMzORLN4u5eyihuLlcZ31g7Vx+BUfl m7TKfrOC9u1bnlg44nA0YKQNAoG5+g== X-Received: by 10.159.61.110 with SMTP id m46mr2556552uai.64.1499845684213; Wed, 12 Jul 2017 00:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Wed, 12 Jul 2017 00:47:33 -0700 (PDT) In-Reply-To: <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Wed, 12 Jul 2017 17:47:33 +1000 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 07:48:07 -0000 On 12 July 2017 at 13:18, Manfredi, Albert E wrote: > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Very specifically, it would be irresponsible not to require >> pseudo-random IIDs of at least N bits for automatically assigned >> addresses. RFC7217 doesn't define N, but I assume it would be at >> least 40 and probably more. > > Exactly. This is one example that should not mandate 64, but rather whate= ver is enough for all the considerations that have to be made. For collisio= ns or security, 48 or 40 bits is probably plenty, depending also on the num= ber of hosts expected in a subnet prefix. Within a homenet, I'd much rather= depend on a firewall than an overabundance of IID bits, for instance. > How many are enough, and do you expect non-technical end-users to make good decisions about how many bits they need for their privacy and security? RFC5505, "Principles of Internet Host Configuration" "2.1. Minimize Configuration Anything that can be configured can be misconfigured." >> The advantage of requiring or recommending 64 bits is that it >> avoids the debate about N. > > But it penalizes applications that would benefit from more flexibility. M= uch of the problem comes from our inability to even define what a "site" mi= ght be, to which a /48 might theoretically be assigned (if we even believe = that's a realistic expectation anymore?). >So, not knowing what constitutes "site," and not believing that all sites = will get anything better than a /64, /64 per-site looks to be proving to be the exception rather than the rule. I've been casually observing what ISPs give out, because having worked at residential ISPs (and one who provided the first production IPv6 on residential broadband in Australia back in 2011), they've tended to make static IPv4 addresses and routed subnets a premium or business only product option with a corresponding price premium. I expected that becoming a standard IPv6 feature may be resisted significantly. Most are giving out /56s. I know of one that is now giving out /60s, and they originally gave out a single /64. I know of one that is giving out a single /64 on their residential plans, and in the forum that is being complained about, people are pointing out that other ISPs are giving out /56s. Here in Australia it is usual for our incumbent Telco to charge the most, sometimes for the least, yet they too are giving out /56s standard on residential plans. In a market where there is choice, being miserly with assigned IPv6 address space won't persist for long if it causes trouble for customers - the time and staff cost of dealing with their complaint will outweigh any costs of giving them plenty of address space in the first place. > I think we need to avoid having device makers create hard 64-bit IID boun= daries. It would be unfortunate if every thermometer and thermostat were re= quired to have a 64-bit IID. What are the specific drawbacks or advantages of thermometer and thermostats not having 64 bit IIDs? I can't think of any. It doesn't reduce the code in them, nor can I see how it somehow reduces the number of packets they need to send, and I don't see how if they were battery operated it would make a beneficial difference to their battery life. Being hidden in a 64 bit IID address space does make them a less likely target for a DoS attack, assuming they've somehow been made reachable by somebody who would benefit from them being DoS'd. What are some applications that would benefit from more flexibility? Are you talking about applications where the flexibility would be an additional benefit to the application, or ones where the flexibility would be required to work around not having a 64 bit IID available? >*Or* were built that way, because someone read that 64-bit IIDs are "requi= red." > 64 bit IIDs have been written as required since July 1998 in RFC2373. In some countries this requirement can drive, vote in elections and drink alcohol. "In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]." ... " The details of forming interface identifiers are defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc." Regards, Mark. From nobody Wed Jul 12 06:06:01 2017 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 169F6131689 for ; Wed, 12 Jul 2017 06:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PFQ2ZDtjWgC for ; Wed, 12 Jul 2017 06:05:56 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 C4E0D130154 for ; Wed, 12 Jul 2017 06:05:56 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 50D2AA1F for ; Wed, 12 Jul 2017 13:05:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGdUuEnOGDyd for ; Wed, 12 Jul 2017 08:05:56 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 1E9606CA for ; Wed, 12 Jul 2017 08:05:56 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id i63so8138464vkh.4 for ; Wed, 12 Jul 2017 06:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PJzU0ZZmT6d37gV5y/718fOnTUD99WAM5SA5Hln/8q0=; b=C0vWECKgj8EPYAA0vygJ1//TjaT/OOnWYddc6vVPBJ+FmGWGWpLyiAmDim+eztuJIh ukm1Ef4h203DY+uCrcY0NwUwedt0w+0QOyd8amoqGNUXaZ5KcRoYcEC7dMQMUcMjiWV9 lS0K6qKz6BLtwUvNY9iEHzqnTXRi1NZ5H7Of+slWMy5JcjMj3uYN2l1VXR7c+6jif3Me lijKRc+nYWTvEC/Lu9u5312uI8jW/bmE4TP9DUZNjZ1gFa8eQH0HS98eKcsbv2XFD/I/ EYjeHEmRRKDn5mqJpIR7LeoOxKdk2K8cE9dD2hnb2bqKX0rktXGCkn16shL/MJLthgGd W+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PJzU0ZZmT6d37gV5y/718fOnTUD99WAM5SA5Hln/8q0=; b=ERYRHVtYE7mNzZDRm1SsXIpeSEb3Ha3Ygpx/+kMA67Rne1tmpaJoUjhQWlzxzScAnU GOCfp68jqCtvpORyY9Kb7N3wWz2gEtdL8ruXHsHftFQ5ezI3fYUTDh7BL85a8qVr6bMg HtwD+szL+DbMDQJ+EhhdDGghk+I/vfss/SSP4Qy2BlQ6E3y5kYjT6XhWPx+NbpLSj6BC voC47u4vcZgs7O02M/9ZPpmO8a7CW3jVOm9kD0PsQE2xgaOiuwpq2S1NeqWrkCfZKmkG YHlS20tb1a4nL2AJPms0YV1oz3UJ11xojGIkYNWSFMNjdn0O2LK+MqzXkWzdMQvybERb Dizg== X-Gm-Message-State: AIVw113hQW8l6QosOmzcyoA5rUttG2bTeoXkQtm493b+gaDgHH/9rehe tDlheOcayhT55ADkiKdS9zBTwBk7JNtKPzhhHRKXF6ISLqhaZJPZXlu6EyWTQ4vNGjxusOJN0yq CSuOWq7Co+2zckPU= X-Received: by 10.31.166.11 with SMTP id p11mr1188297vke.134.1499864755022; Wed, 12 Jul 2017 06:05:55 -0700 (PDT) X-Received: by 10.31.166.11 with SMTP id p11mr1188280vke.134.1499864754754; Wed, 12 Jul 2017 06:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Wed, 12 Jul 2017 06:05:53 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Wed, 12 Jul 2017 08:05:53 -0500 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Mark Smith Cc: "Manfredi, Albert E" , 6man WG Content-Type: multipart/alternative; boundary="001a1142cdbceb2c2305541e7953" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 13:06:00 -0000 --001a1142cdbceb2c2305541e7953 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 2:47 AM, Mark Smith wrote: > > /64 per-site looks to be proving to be the exception rather than the > rule. I've been casually observing what ISPs give out, because having > worked at residential ISPs (and one who provided the first production > IPv6 on residential broadband in Australia back in 2011), they've > tended to make static IPv4 addresses and routed subnets a premium or > business only product option with a corresponding price premium. I > expected that becoming a standard IPv6 feature may be resisted > significantly. > > Most are giving out /56s. I know of one that is now giving out /60s, > and they originally gave out a single /64. I know of one that is > giving out a single /64 on their residential plans, and in the forum > that is being complained about, people are pointing out that other > ISPs are giving out /56s. > > Here in Australia it is usual for our incumbent Telco to charge the > most, sometimes for the least, yet they too are giving out /56s > standard on residential plans. > > In a market where there is choice, being miserly with assigned IPv6 > address space won't persist for long if it causes trouble for > customers - the time and staff cost of dealing with their complaint > will outweigh any costs of giving them plenty of address space in the > first place. > All I can say is hope so, but from my perspective I'm not seeing it, I'm seeing /64s per customer. Related to this I've said several times that section 2.4.4 of RFC4291bis needs work. If we are going to keep a clear 64 bit IID requirement, we need to be equally resolute that ISPs assigning only a /64 is wrong. I'd like to see some of you that are resolute that we keep the 64 bit IID requirement commenting about section 2.4.4's issues. Minimally, for section 2.4.4, I'd like to see a statement that m>1 and a more direct pointer to RFC6177. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1142cdbceb2c2305541e7953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 12, 2017 at 2:47 AM, Mark Smith <markzzzsmith@gmail.c= om> wrote:

/64 per-site looks to be proving to be the exception rather than the
rule. I've been casually observing what ISPs give out, because having worked at residential ISPs (and one who provided the first production
IPv6 on residential broadband in Australia back in 2011), they've
tended to make static IPv4 addresses and routed subnets a premium or
business only product option with a corresponding price premium. I
expected that becoming a standard IPv6 feature may be resisted
significantly.

Most are giving out /56s. I know of one that is now giving out /60s,
and they originally gave out a single /64. I know of one that is
giving out a single /64 on their residential plans, and in the forum
that is being complained about, people are pointing out that other
ISPs are giving out /56s.

Here in Australia it is usual for our incumbent Telco to charge the
most, sometimes for the least, yet they too are giving out /56s
standard on residential plans.

In a market where there is choice, being miserly with assigned IPv6
address space won't persist for long if it causes trouble for
customers - the time and staff cost of dealing with their complaint
will outweigh any costs of giving them plenty of address space in the
first place.

All I can say is hope so, = but from my perspective I'm not seeing it, I'm seeing /64s per cust= omer.

Related to this I've said several times = that section 2.4.4 of RFC4291bis needs work.=C2=A0 If we are going to keep = a clear 64 bit IID requirement, we need to be equally resolute that ISPs as= signing only a /64 is wrong. I'd like to see some of you that are resol= ute that we keep the 64 bit IID requirement commenting about section 2.4.4&= #39;s issues.

Minimally, for section 2.4.4, I'= d like to see a statement that m>1 and a more direct pointer to RFC6177.=

Thanks.=C2=A0

--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--001a1142cdbceb2c2305541e7953-- From nobody Wed Jul 12 06:48:07 2017 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 C034912FEEB for ; Wed, 12 Jul 2017 06:48:05 -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, RP_MATCHES_RCVD=-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 sAMNR7IPQvyb for ; Wed, 12 Jul 2017 06:48:04 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BB51200B9 for ; Wed, 12 Jul 2017 06:48:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 8121F1A071 for ; Wed, 12 Jul 2017 13:47:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Simon Hobson In-Reply-To: Date: Wed, 12 Jul 2017 14:47:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 13:48:06 -0000 Mark Smith wrote: > This is not recognising that there are more than operational or = functional properties of addresses. They have privacy and security = properties too. Shouldn't this requirement be separate from the underlying protocol = requirements ? Ignoring LL addresses, it seems that only self assigned addresses using = deprecated methods (ie based on hardware address) actually *require* a = 64 bit split. So on that basis, the standard defining how the protocols = work should require implementations to support an arbitrary split. Separate to that (in a separate section), make recommendations (as in = "should") to support security and privacy. From nobody Wed Jul 12 06:54:14 2017 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 2B541131919 for ; Wed, 12 Jul 2017 06:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 TougsLIoiNYi for ; Wed, 12 Jul 2017 06:54:10 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08E0131907 for ; Wed, 12 Jul 2017 06:54:10 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id r125so13175816vkf.1 for ; Wed, 12 Jul 2017 06:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xswzVrBmnFvFZTdu9PmbJlcRf+irbMjqeirSdQtuFns=; b=HFuNnEoU3DjkD0Hvyt5IJZJLyfhdU1eZUnzPRq1effrQMSGaq3Uey1DRwlAyeprpiC v+gJjRW37rBVpZ6T9yyWEmYNdCz8c9a1BBMcSUFbhCFvGFdwP5VqEh2BUyj3T1pDmEVA gwIIz+8CigZFwc2GLlgk4ZsCmj32d5H/ElEbX2RxkzptXpTZySYQjr7arqa6UnADMm91 Z17BBgUdC1npdU4tXN++yKfh/50ZVyAo5H/htzhyXqngtrLLgMlpmEJCKeQKvOw9AKTj K+43MAc4x6/I3cAtJ8qcEA8XcATKUOAEJe0bA+MP/s64zBRCMyzOuVn0FfDKZ53R2yKX IeKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xswzVrBmnFvFZTdu9PmbJlcRf+irbMjqeirSdQtuFns=; b=kRMCYzvLlSTExJKs0JUxuobmYzxMsrUWJGjrXdzgxKFMbEJSbddGbPts/JmloQWFVf zamQm+V0i2RLXApySoQjnwareVrIvh+h89NExS+gYB0zZ2z5tjKb7zHho3VTRdWLO5jL 0Kj7t7QHQNrUPkPq8OOqIW9ebmEJ6MEaP0+SkSHLIx0rJ61iFG5mvhEmBBcHo6j10azk MGe9JGKuaaELBUbA4xjTndWMyfBmFM8dgtEv0VonQ9QYpFb4A0PokXNzx5xm0qMPHXGT GC2ToqwHk/X4f1RU/UnFglWI0+5pjMlbmRvKeqrKTq1p16p1kEDTEnTe0cEO4Dev2lj5 EL9g== X-Gm-Message-State: AIVw110ElbBBOx/qO/g7cFj6KI8upCs1HOv3xm8mgaVGdNpC+OY4hFYL +4I3ALFDQvBer2iD6iZRtj9ZgXx9xFST X-Received: by 10.31.209.199 with SMTP id i190mr1330661vkg.125.1499867649446; Wed, 12 Jul 2017 06:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Wed, 12 Jul 2017 06:53:48 -0700 (PDT) In-Reply-To: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> From: Lorenzo Colitti Date: Wed, 12 Jul 2017 22:53:48 +0900 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Brian E Carpenter Cc: Mark Smith , "Manfredi, Albert E" , 6man WG Content-Type: multipart/alternative; boundary="001a114e6e1875190d05541f267d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 13:54:12 -0000 --001a114e6e1875190d05541f267d Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The advantage of requiring or recommending 64 bits is that it avoids the > debate about N. I prefer 'recommend' because it avoids enumerating all > possible exceptions. We've seen how hard it is to wordsmith the exceptions. > What's hard is not wordsmithing the exceptions. What's hard is claiming that there's consensus (even rough consensus). The fact of the matter is that we have opposing camps with equally strong opinions on the matter, and neither camp is willing to accept the position of the other. Based on past experience, it seems pretty clear to me that this situation will not change until we get a problem statement that we agree on. Care to write one up? --001a114e6e1875190d05541f267d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
The ad= vantage of requiring or recommending 64 bits is that it avoids the
debate about N. I prefer 'recommend' because it avoids enumerating = all
possible exceptions. We've seen how hard it is to wordsmith the excepti= ons.

What's hard is not wordsmithin= g the exceptions.

What's hard is claiming that= there's consensus (even rough consensus). The fact of the matter is th= at we have opposing camps with equally strong opinions on the matter, and n= either camp is willing to accept the position of the other.

<= /div>
Based on past experience, it seems pretty clear to me that this s= ituation will not change until we get a problem statement that we agree on.= Care to write one up?
--001a114e6e1875190d05541f267d-- From nobody Wed Jul 12 06:59:41 2017 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 75B6312ECB7 for ; Wed, 12 Jul 2017 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 xYmuDk5Hg5jd for ; Wed, 12 Jul 2017 06:59:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 244DD128961 for ; Wed, 12 Jul 2017 06:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0CE997222C3; Wed, 12 Jul 2017 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1499867978; bh=Oyqxd2AmDp6jXVlZm+v9syBuuiUMnIezkcuIdSduy8A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=U5SzDAueeZtUH9yYKzc/qZ0f0W9x+RyslN9P7c96RJXBYKTnWJDIPocCWijSLBas9 sZyPMnGMoIgb6RPbhujiyRZIxLZOXOjGIG7hv5BgN9ftOKEIKBHqswABjKOB1S+Vdm qUPyuJbwI8jJ6ew33QENXoJrn9ekja5HDi1FF+HE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A30471C02FB; Wed, 12 Jul 2017 06:59:35 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Simon Hobson , 6man WG References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> From: "Joel M. Halpern" Message-ID: Date: Wed, 12 Jul 2017 09:59:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 13:59:39 -0000 If we keep the self-genereated IID length at 64 bits, then folks can work otu different methods for making use of it, and see what the value is. if we say taht the length is defined by something the network, then we need to work out what we have to tell people to make that safe to do. We also restrict people's ability to innovate in the host stack (which is where, as I understand it, we want to see innovation.) If we were short of bits, sure, freeing up bits might make sense. But why do so in the absence of such a shortage? Yours, Joel On 7/12/17 9:47 AM, Simon Hobson wrote: > Mark Smith wrote: > >> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too. > > Shouldn't this requirement be separate from the underlying protocol requirements ? > > Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split. > > Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jul 12 10:10:41 2017 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 D44A31300CF for ; Wed, 12 Jul 2017 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 K-9uPI9ltiGt for ; Wed, 12 Jul 2017 10:10:38 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF49126B7E for ; Wed, 12 Jul 2017 10:10:38 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6CHAV5I083765 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2017 18:10:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <59665806.4060500@foobar.org> Date: Wed, 12 Jul 2017 18:10:30 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Brian E Carpenter CC: 6man WG Subject: IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing) X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 17:10:41 -0000 Brian E Carpenter wrote: > We've seen how hard it is to wordsmith the exceptions. Brian, the whole idea of exceptions may have hit the nail on the head. We've spent weeks discussing hard-coding or not hardcoding /64 to no avail, but the issue may not be as important to 4291bis as it may seem. The reason why is that in practice, the interface ID length depends on how the interface is configured: no-one is disputing that you can configure a static IP address with a non-/64 prefix length. This implies by necessity that the number 64 as an IID length is not an intrinsic part of ipv6 addressing per-se, but a statement of defaults. If you split interface addressing down into the different protocols used, they are: 1. link-local: IID length defined as /64 in rfc4291, section 2.5.6 2. SLAAC: IID length defined in rfc4862 3. DHCP: dependent on SLAAC 4. static addressing: consensus this is variable 5. others (e.g. PPP defines its interface mask length in rfc5072; does AERO define interface adddressing? Any others?) 6. future protocols There's consensus on IID length for #1 and #4. #3 depends on #2 (dhcpv6 pulls the netmask from slaac, but if addressing is not handled in slaac, it uses /128). Other cases (#5) seem to be defined in the individual rfcs which describe them. This means that the only substantive issues are SLAAC and whether future protocols should be /64 by default or whether the prefix length needs to be explicitly defined in the document which defines it. All the other cases state the IID length explicitly in the documents which describe them, with the exception of static addressing, about which there isn't really any argument to start with. I would suggest that future protocols need to define what makes sense for them, and mandating a constant in advance isn't necessary or even appropriate. Regarding SLAAC, if there needs to be a definition that its IID size is hard-coded at /64, then this is a discussion for 4862bis, not 4291bis. So outside SLAAC, we're left in a situation where either there is consensus or explicit definition in the individual protocol definitions. Given this, I'd like to suggest that we drop the sentence from 4291bis completely and devolve the specification for IID length down to the individual protocols where it belongs. This may mean updating rfc4862. Nick From nobody Wed Jul 12 10:24:29 2017 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 79A301296C6 for ; Wed, 12 Jul 2017 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PS8SUFvOqAHW for ; Wed, 12 Jul 2017 10:24:26 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 0C783126B7E for ; Wed, 12 Jul 2017 10:24:26 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id r30so18285473qtc.0 for ; Wed, 12 Jul 2017 10:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VmI8hE8uG0iZPBAW2wJMvsSmdNR6v9uZHeVPpIiCK94=; b=AiZ5WKncXxj6AtR91RTU/UMpAFvidw4q3DMg2wFScUkRJbzVFp536KTaM2WSgKBarV UqamtcT015zLL4Kb+wHXQTZZUtUwV9DqWbFCEmNTpTww22CW/26Oysinlhm7S29FH4vs dpmvWnNko828h2MgwdGFkmoTrKYiGz1quKMZ08CX3IvHT6j9gH+KtMEMbSbYYGw4+6kI /6y7Iy/7ABs4Ft4ZXfz1n/tHfJh7d/jqvp6vu6fPHoVjDb+9FteuCAOTqyVYZnfWYY9x XR10T7CqjgIPREI8vyMy0TvFxSotmGsr18acdQSU0GjTuSAGEkJiPwH2zog05Gdj9M81 JMyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VmI8hE8uG0iZPBAW2wJMvsSmdNR6v9uZHeVPpIiCK94=; b=iSig+WDlW99awBItIZuyoBu1MmHMqC2jYp1EFKpS86/p9F2rXBpxFF1CLUqdMBawAW hKpkVG4C/v6CdkYh+RtLb9xnI25UVolrpKNIAU1XuXbID32q3Ke4PmcSCRxj+6xov5nu 2ukr4Fibr0iQS41JzGXX9kwWXPIRCghiz5SrhNlNRoErcQuXyTcGIF+83yHs8THacmZt iiEvTSXc4pE2s9QrRtd6zWx4fgJ2x/Wp5WRCn7lFxbF98QDVExJsOf+7AcVRsI/nHxZx 3dr6hBLD5uKqJyf6EPEEMHcYc+91FzwB8k/TyEB0+2tkRJwdimyNF8/8LL1Eu0Bgdcw2 DGIA== X-Gm-Message-State: AIVw1111AOSK2KUMAixhK0piSs7YdvoamT26/Z/6UrrIecJeOLBLoOFn pOvaJXto1DNzY6wT8z06j8n0S+pH/uv05D4= X-Received: by 10.200.41.238 with SMTP id 43mr8133428qtt.168.1499880264915; Wed, 12 Jul 2017 10:24:24 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Wed, 12 Jul 2017 10:24:24 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 12 Jul 2017 10:24:24 -0700 X-Google-Sender-Auth: ElMDtOgJa9zxXeIZEPyuCK6tBQ8 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Lorenzo Colitti Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 17:24:27 -0000 At Wed, 12 Jul 2017 22:53:48 +0900, Lorenzo Colitti wrote: > > The advantage of requiring or recommending 64 bits is that it avoids the > > debate about N. I prefer 'recommend' because it avoids enumerating all > > possible exceptions. We've seen how hard it is to wordsmith the exceptions. > > What's hard is not wordsmithing the exceptions. > > What's hard is claiming that there's consensus (even rough consensus). The > fact of the matter is that we have opposing camps with equally strong > opinions on the matter, and neither camp is willing to accept the position > of the other. Right, but in terms of advancing rfc4291bis as an Internet Standard, I still have a feeling that the wg has been distracted with out-of-scope matters too heavily. In my understanding the primary reason why rfc4291bis was sent back to the wg after passing WGLC is that conflicts between - an "opposing camp" who wants to justify their practice of using non-64 prefix in their operation (and most likely for manually configured addresses) - another "opposing camp" who wants to keep the IID length to be 64 bits as much as possible And, my high-level understanding is that both camps seem to accept a compromise to make the manual-configuration case an exception. In that sense I still see a possibility of consensus and moving forward. And, in that case it's generally a matter of wordsmithing. But since the original pushback there have been other arguments of whether the length of IIDs should be even more flexible. If this had to be resolved for rfc4291bis to move forward, I agree we can't reach a consensus at least without stepping back very far (and, in that case, IMO it's even better to declare the failure of rfc4291bis instead of wasting more time in this context). But, IMO, this discussion should have been out of scope of rfc4291bis - after all there's virtually no implementation that has this flexibility in SLAAC (where IID matters most), let alone multiple independent such implementations that are interoperable. So, due to the conservative nature of rfc4291bis any such discussions should have been a post-rfc4291bis fodder. Unfortunately, most of the recent discussions in this thread seem to be spent on this topic. So I hope we can now focus on the matter of the very original clash and see if we can reach consensus through some wordsmithing. If we can't even do that I think it's better to drop rfc4291bis at this point. If people still have energy on this topic after that we can try to write up a problem statement or whatever for a fresh restart. Meanwhile some others in the wg can use their time for some other, possibly more practically important things such as header insertion matters. > Based on past experience, it seems pretty clear to me that this situation > will not change until we get a problem statement that we agree on. Care to > write one up? -- JINMEI, Tatuya From nobody Wed Jul 12 11:00:59 2017 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 2C35A13173B for ; Wed, 12 Jul 2017 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 6gJ5clVQpz4L for ; Wed, 12 Jul 2017 11:00:57 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 CA4F2129B4C for ; Wed, 12 Jul 2017 11:00:56 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 16so31246106qkg.2 for ; Wed, 12 Jul 2017 11:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pSYoDa8B/+n+axkIcc+8ZLqgNVXBRm1LBeu8yCr1b1w=; b=GQlz7dK96CM3D5AaituKe9//btMrsVMIxascJJjix/RkaYqGCXQ1w6PRqiSgjTMYs9 5P5FAaZLqcSWMCIGetCsYgzx2l4Zuou+MTomTlSmWsawyd/1Gs/PbcJGQ/g2UvqfC+29 aBwJq42/y5uhRnN9UQ6r0nOfEhagWP3j8FiqCz2c2R/jXn/zTV42sVIh96fr8YhVZ1Lb ujUqAiavgM22y/AQYDUNqzsmJtlxoDjaWUpEWmzj66QpL2zXuebECWpLQIet0pAFYh0s GoWMj94rEcKY8emtQ4rDAWGYJ4nPFIrWbu+137GJgoDnlaQFEz78qRku3VLS9lqxLN+A Y99A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pSYoDa8B/+n+axkIcc+8ZLqgNVXBRm1LBeu8yCr1b1w=; b=YrN1dCKUnMh0nS/oK1gXfe48Lr6/MUjeSXGuEGxoQBdFwAkG3n51XJhjDXHKbONdr9 rL8mqq4vC4hdfR/gs+obmDdJPUGEh+h53F+iV9bj197dKxezG0z4Dnxw7TDA0KCiGnLx 4M6MTdGHKASVL/5WObsiCbD9OJKd0UapiWmVgQrTgbAx/uP7m0JsFu48tCZNTbav2JJU v19KZfBYrKNcLN5MAWID2YdREbIWW6X2aclpBllZnm9U5zPXz5SOTqVTfAR7TQxWktOS gr1sYI2gY/H+ppFvU3y8lBaxUQlbmnK831UcXvOlt7ZdXFQ0J+TjsDNgB+qAQ+qj74NB atrA== X-Gm-Message-State: AIVw111CM0Lj4tPNP6A78kQ5CRKlMDEPZjLuJTZ7dz+AXognRt5LfwJe YWz6WlW8wqqQ95jW/en+mcDTbKoSrWreNNs= X-Received: by 10.55.185.6 with SMTP id j6mr7400788qkf.14.1499882455775; Wed, 12 Jul 2017 11:00:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Wed, 12 Jul 2017 11:00:55 -0700 (PDT) In-Reply-To: <59665806.4060500@foobar.org> References: <59665806.4060500@foobar.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 12 Jul 2017 11:00:55 -0700 X-Google-Sender-Auth: akFSOF8C1oNcPMlF4B4PGc09vok Message-ID: Subject: Re: IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing) To: Nick Hilliard Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 18:00:58 -0000 At Wed, 12 Jul 2017 18:10:30 +0100, Nick Hilliard wrote: > If you split interface addressing down into the different protocols > used, they are: > > 1. link-local: IID length defined as /64 in rfc4291, section 2.5.6 > 2. SLAAC: IID length defined in rfc4862 No, RFC4862 doesn't define IID length. It intentionally leaves the definition to link-specific specifications with the assumption that those specifications are consistent with the addressing architecture. RFC4862 intentionally and very carefully avoids being involved in the business of defining the size of IIDs. > 3. DHCP: dependent on SLAAC I don't know what you mean here, but at least the IID length for a DHCP-configured address has nothing to do with SLAAC. Maybe you mean an on-link prefix that might cover the address is provided via an RA's prefix information option. If so, it's correct (although, in theory, this on-link prefix could also be manually configured), but that's irrelevant to SLAAC. And, if this meant on-link prefix configuration there's commonly seen confusion between on-link prefix and address assignment prefix (IID length is a matter of the latter, not the former). Maybe you want to read David Farmer's summary posted a few days ago. > Regarding SLAAC, if there needs to be a definition that its IID size is > hard-coded at /64, then this is a discussion for 4862bis, not 4291bis. Whether or not it should be in 4291bis, it's at least not a matter of 4862bis (see above). Due to these confusions I'm not sure how to respond to the actual suggestion below... > So outside SLAAC, we're left in a situation where either there is > consensus or explicit definition in the individual protocol definitions. ...but I tend to agree that the main conflict essentially only exists in the context of SLAAC in practice. That said... > Given this, I'd like to suggest that we drop the sentence from 4291bis > completely and devolve the specification for IID length down to the > individual protocols where it belongs. This may mean updating rfc4862. ...(first off, again, it's at least not a matter of rfc4862bis) I doubt this suggestion forms a consensus given how badly one "opposing camp" wants to keep the hardcoded 64 number in 4291bis. Obviously people in the other "opposing camp" aren't happy about this position, but in terms of reaching any rough consensus with any possible concessions, I suspect it's just not realistic to try to remove it. Personally, I hope the other camp can accept this reality and allow the 64 to remain in 4291bis as long as any exceptions in the current (rather than future possibilities) actual practices are clearly admitted (like in the case of manual address configuration). -- JINMEI, Tatuya From nobody Wed Jul 12 11:32:54 2017 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 636A9131780 for ; Wed, 12 Jul 2017 11:32: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, 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 w3rXNlMPQS6u for ; Wed, 12 Jul 2017 11:32:52 -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 1793C13177E for ; Wed, 12 Jul 2017 11:32:51 -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 v6CIWojq046330; Wed, 12 Jul 2017 11:32:50 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6CIWnk1046325 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 12 Jul 2017 11:32:49 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 11:32:48 -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.1263.000; Wed, 12 Jul 2017 11:32:48 -0700 From: "Manfredi, Albert E" To: Mark Smith CC: 6man WG Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BAgADKDwCAAFSoEIAA6HsAgAAt/wD//43p8IAAyDmAgAAyBvA= Date: Wed, 12 Jul 2017 18:32:48 +0000 Message-ID: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 18:32:53 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJr enp6c21pdGhAZ21haWwuY29tXSANCg0KPiBXaGF0IGFyZSB0aGUgc3BlY2lmaWMgZHJhd2JhY2tz IG9yIGFkdmFudGFnZXMgb2YgdGhlcm1vbWV0ZXINCj4gYW5kIHRoZXJtb3N0YXRzIG5vdCBoYXZp bmcgNjQgYml0IElJRHM/DQoNCkknbSBmYWlybHkgY2VydGFpbiB0aGF0IGlmIHRoZSBJRVRGIGNv dWxkIHNvbWVob3cgZ3VhcmFudGVlIHRoYXQgZXZlcnkgInNpdGUiIChob3dldmVyIHRoYXQncyBk ZWZpbmVkKSB3ZXJlIGFsbG9jYXRlZCBhIC80OCwgdGhlcmUgd291bGRuJ3QgYmUgc28gbXVjaCBv ZiBhbiBpc3N1ZS4gVGhpcyBpcyBhbm90aGVyIG9uZSBvZiB0aG9zZSBhcmd1bWVudHMgdGhhdCBr ZWVwcyBjeWNsaW5nLCB0aG91Z2guIFRoZSBwcm8tNjQtYml0IGJvdW5kYXJ5IGNhbXAgc2F5cyB0 aGF0IHRoZXJlIGFyZSBwbGVudHkgb2YgLzQ4cyB0byBnbyBhcm91bmQuIEZpbmUgYW5kIGdvb2Qs IGJ1dCB0aGUgb3RoZXIgY2FtcCBzYXlzLCBob3cgY29tZSAvNDhzIGFyZSBub3QgYmVpbmcgaGFu ZGVkIG91dCwgdGhlbj8gU28gaXQncyBhIHF1ZXN0aW9uIG9mIHRoZW9yeSB2cyByZWFsaXR5Lg0K DQpUaGUgZHJhd2JhY2tzIGFyZSBnZW5lcmljLCBidXQgbGV0J3MgdGFrZSBIVkFDLiBUaGUgc3lz dGVtIGdldHMgdXBncmFkZWQsIGZyb20gYSByZWxhdGl2ZWx5IG9sZCBzY2hvb2wgZGVzaWduLCB3 aXRoIGEgZmV3IGludGVyZmFjZXMgdG8gdGhlIHBsYXRmb3JtIG5ldHdvcmssIGFuZCBtdWNoIGhh cmQgd2lyaW5nIGJlaGluZCB0aGVzZSwgdG8gc2V2ZXJhbCBodW5kcmVkIG5ldHdvcmtlZCBpbnRl cmZhY2VzIHdpdGhpbiB0aGUgSFZBQyBzdWJzeXN0ZW0uDQoNCldpdGggYSBoYXJkIDY0LWJpdCBi b3VuZGFyeSwgSSdtIGNvbnN0cmFpbmVkIHRvIGNyZWF0aW5nIGEgZmxhdCBhZGRyZXNzIHNwYWNl IGZvciB0aGUgdXBncmFkZWQgSFZBQyBzeXN0ZW0sIHdpdGggYWxsIHRoZXNlIGxpdHRsZSBnaXpt b3MgaGFuZ2luZyBvZmYgdGhlIHBsYXRmb3JtIG5ldHdvcmsuIFRoYXQgY2FuIHdvcmssIGJlY2F1 c2UgNjQtYml0IElJRHMgYWxsb3cgZm9yIGxvdHMgb2YgZGV2aWNlcy4gQWx0ZXJuYXRpdmVseSwg SSBjYW4gY3JlYXRlIG5ldyAvNjBzIG9yIC82MnMsIGZvciB0aGlzIHVwZ3JhZGVkIEhWQUMgc3lz dGVtLCBhc3N1bWluZyBJIGhhdmUgZW5vdWdoIHByZWZpeCBzcGFjZSB0byB3b3JrIHdpdGghDQoN CkJ1dCB3aXRoIElJRCBmbGV4aWJpbGl0eSwgSSBjYW4gcGFydGl0aW9uIHRoZSB1cGdyYWRlZCBI VkFDIHN5c3RlbSBpbnRvIGl0cyBvd24gc3VibmV0cywgYmVoaW5kIHRoZSBwcmV2aW91cyBwbGF0 Zm9ybSBuZXR3b3JrIGludGVyZmFjZXMgdG8gSFZBQywgd2l0aCBubyB0cm91YmxlIGF0IGFsbCwg ZXZlbiBpZiB0aGUgZW50aXJlIHBsYXRmb3JtIHdhcyBvbmx5IGFsbG9jYXRlZCwgc2F5LCBhIC81 Niwgb3IgZm9yIHRoYXQgbWF0dGVyLCBldmVuIGEgLzY0Lg0KDQpPZiBjb3Vyc2UsIHRoZSBvdGhl ciBvcHRpb24gaXMgdG8gZXhwYW5kIHVzaW5nIFVMQXMsIGJ1dCB0aGVuLCB0aGF0J3MgInNvIElQ djQuIg0KDQpCZXJ0DQoNCg== From nobody Wed Jul 12 14:37:27 2017 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 08345131795 for ; Wed, 12 Jul 2017 14:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 m1OS_E18rq7x for ; Wed, 12 Jul 2017 14:37:22 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D685E131925 for ; Wed, 12 Jul 2017 14:37:19 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6CLbFVq022515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2017 22:37:16 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5966968A.7000904@foobar.org> Date: Wed, 12 Jul 2017 22:37:14 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= CC: Brian E Carpenter , 6man WG Subject: Re: IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing) References: <59665806.4060500@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 21:37:25 -0000 神明é”哉 wrote: > At Wed, 12 Jul 2017 18:10:30 +0100, Nick Hilliard wrote: >> If you split interface addressing down into the different protocols >> used, they are: >> >> 1. link-local: IID length defined as /64 in rfc4291, section 2.5.6 >> 2. SLAAC: IID length defined in rfc4862 > > No, RFC4862 doesn't define IID length. apologies, my mistake; I wrote this in error and had intended to remove it before sending the email. The fact that it doesn't define IID length was the reason I suggested later on in the email that discussion about IID length for SLAAC should be handled in the context of a 4862bis document. > It intentionally leaves the > definition to link-specific specifications with the assumption that > those specifications are consistent with the addressing architecture. > RFC4862 intentionally and very carefully avoids being involved in the > business of defining the size of IIDs. It certainly does that, but one way or another, interface mask lengths need to be configured on network devices which use SLAAC and the mechanism for deciding how this should handled needs to be referenced in rfc4862 either directly or indirectly. The current mechanism is an indirect reference to rfc4291. My suggestion is that IID length is not particularly an intrinsic property of ipv6 addressing, but in practice is the specification of a default which can be overridden on a per protocol basis, and in the case of static addressing, actually is overridden. It's not an intrinsic property of ipv6 because there is no specific reason why /64 had to be chosen over, say /63 or /60. 64 was chosen because more it related to EUI64, 8+8 and the fact that we like byte-aligned constants. It could have been plenty of other values. Because of this, it's not an intrinsic property of the protocol, but a statement of policy about what this specific value should be. > ...(first off, again, it's at least not a matter of rfc4862bis) I > doubt this suggestion forms a consensus given how badly one "opposing > camp" wants to keep the hardcoded 64 number in 4291bis. Obviously > people in the other "opposing camp" aren't happy about this position, > but in terms of reaching any rough consensus with any possible > concessions, I suspect it's just not realistic to try to remove it. > Personally, I hope the other camp can accept this reality and allow the > 64 to remain in 4291bis as long as any exceptions in the current > (rather than future possibilities) actual practices are clearly > admitted (like in the case of manual address configuration). If the statement is dropped in 4291bis and instead an explicit statement of the mask length is added to a new revision of rfc4862, then from a practical point of view, we will be in the same position as before which is, I believe, what most people are concerned about: that we don't end up breaking SLAAC or any other existing protocol. Nick From nobody Wed Jul 12 17:23:26 2017 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 3D61D129482 for ; Wed, 12 Jul 2017 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, 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 lozGuXfX3mvn for ; Wed, 12 Jul 2017 17:23:23 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 4EE06126CC4 for ; Wed, 12 Jul 2017 17:23:23 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id k14so20753021pgr.0 for ; Wed, 12 Jul 2017 17:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=nIgNW3O9cv1NC7i1k4kxya3BIOseRUYyswH2AlRHKkU=; b=ESdYaZXun5XTUlc2Rxt8FXZ+dy7hsYKNNVkP6ChGx8Mcbq6j5S6c80BInvKocooq1r nJlZgdYzRqL/C3dfCiJI55GV8G9WjxGpUHIkNk5MvPFHShJ3+nXVd+Ts4FH1QXu47hBi yNvmKwlTyXVMfABx0j+gwpixB8e6vYHxWfVxqCJGjYVXH9BE8PoWymaFxtPnR1rJUI/X 7VXZl76w3FTYggaPxV87mcj/oMHcy49MYQ53Gd7lobpRClT9CXWa1EuZwmameElIu2aM h9e7+29fBMGeP5JUpMQ95INPJEMz/6QhY9m5JxX99D+SJjBHc/6mPv25VqtHMdRhKIk3 fl/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=nIgNW3O9cv1NC7i1k4kxya3BIOseRUYyswH2AlRHKkU=; b=uWHcyiacotRDCwFv/fnV9zF5rc8Ebv8V8YrOROJBwDFukg/OGlAePzG83OkBA3J4Eu aB+ULhs1WY+WEUTqlgY5MG0C3ge8HpawJgf3G41u/eskooBpvKobTSz4FApTc/sf5dAr ZNhBJVBmHdck2M2ttrVAmHtf6Culd6ImD6jZrHNSo3LPNbPT50fJ159IH4zrvHOVn7Rw L57Lay8ablS2SL/ZmEZkHz1SLkQK3Vm57vm12+eTaHUI34YeCWi/hj4xuISAcZBGCvrB 8cfR+UWXLcDx2QYfv2fbxrWfLKZogmkmHdtE87ImmdsoYkOamSGgcla9K/QAWoLsRA9u 6zvg== X-Gm-Message-State: AIVw110TgmtkdpacttxJwsprewBvL2lgDr+9Ac/Z3YheR/nh4kVuxOq1 Tm1OTa1DyRJsyVzvMNc= X-Received: by 10.98.98.199 with SMTP id w190mr52666284pfb.44.1499905402630; Wed, 12 Jul 2017 17:23:22 -0700 (PDT) Received: from [59.29.43.118] ([59.29.43.118]) by smtp.gmail.com with ESMTPSA id y2sm5960123pgy.60.2017.07.12.17.23.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 17:23:21 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Date: Thu, 13 Jul 2017 09:23:18 +0900 References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> To: 6man WG In-Reply-To: Message-Id: <9427A0FF-E957-431A-B381-E2CCE7B07D67@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 00:23:24 -0000 It seems to me that people have to beat rfc7421 first before stopping = rfc4291bis from going forwards: rfc4291bis: "The rationale for using 64 bit Interface Identifiers can be = found in [RFC7421].=E2=80=9D =E2=80=94- DY From nobody Wed Jul 12 18:19:14 2017 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 4EC121317C2 for ; Wed, 12 Jul 2017 18:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 F8TZ4p5CQ3BW for ; Wed, 12 Jul 2017 18:19:11 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 75D03120726 for ; Wed, 12 Jul 2017 18:19:11 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id g40so25015872uaa.3 for ; Wed, 12 Jul 2017 18:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jMev1rzwq1HUG+zAiAJ9SSzQbqMEAsHEm4pyEwMa7lE=; b=tubFExfUVlyCMd6Ldqm9Cfbie91GnWb6eZUGXY+bQr4htBUa8oty8joXbtDwxe4aBU 3GrSebAKsWVcMgLxVxblchPLfjQ5thuxqwh4GJCJpr1XD9WoC2jGxEYBN0VGiMSWm7rU jd7kUBHuWmIUt1Zhtl1IAtWsgi56QGVZ4uvvfrcEqYLaI0SdOXEkF8+OdrnzPIISOH9j WQIBoXpPEQxYj81B7ooS8AatJyJ/2NLG0jACC3+a3+fqp5cyMvF86JxmFo4QcbLKUACF /u8rTtdW0R4btLvI9fr3DxkRzhiCN+xqXuOUZTtFDx85IrHo2o9fABArTnAifR+AxlWP IC6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jMev1rzwq1HUG+zAiAJ9SSzQbqMEAsHEm4pyEwMa7lE=; b=ZaHybFSM8QPUACOzdYMXKXN151cY8dKwUHlcNtOdCKt2EDc4JdDsbI7xPhnIExn52P U2e6PPVFyPXs0WFpQuKaDw50qHikKc5M/ddEZT2j8sJSRle09vwj3N4VP/I1jrdrjlQY F4PX0hn9V0GSMaJCENVO8kUapnOpkXGES5hgeufI24EIVlj5xofQ2AHaYbqFt+m1BpIC 1lA3vZjH3z/eX4aqnFbNQUapqAcaDADDSg1OxNgLXQBBudyLp0nC5FQ9lmClBAXQwzyd CY+vZyvBbKFk2i2pkuVKjpFd/DPslhW8n/E/5qfawH8BxD447rJRjBnHy9Hj9lT1OuyO izCQ== X-Gm-Message-State: AIVw113/vfyujx0bqdxX7VD9/wOERrF18FEnCzMNVUFUhOEcBrKLEZgR 8c6yXMOReE2ERDjoCrKgJy7jlOmT/MsY X-Received: by 10.159.53.45 with SMTP id o42mr911066uao.84.1499908750270; Wed, 12 Jul 2017 18:19:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.94.135 with HTTP; Wed, 12 Jul 2017 18:18:39 -0700 (PDT) In-Reply-To: <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> From: Mark Smith Date: Thu, 13 Jul 2017 11:18:39 +1000 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Simon Hobson Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:19:13 -0000 On 12 July 2017 at 23:47, Simon Hobson wrote: > Mark Smith wrote: > >> This is not recognising that there are more than operational or function= al properties of addresses. They have privacy and security properties too. > > Shouldn't this requirement be separate from the underlying protocol requi= rements ? > No, I don't think so. These protocols fundamentally exist to serve end-user needs. If they don't, then they're no more than an academic experiment, and we'll have wasted an awful lot of human capital on them. These are primary protocol requirements, necessary to meet to justify the protocol's existence. > Ignoring LL addresses, it seems that only self assigned addresses using d= eprecated methods (ie based on hardware address) actually *require* a 64 bi= t split. So on that basis, the standard defining how the protocols work sho= uld require implementations to support an arbitrary split. > I think the final arbiter in any of these situations is "what is best for the end-users?" What is the simplest, that will result in lower network capex and opex costs to the end-users who directly or indirectly pay those costs? What is the most reliable and robust, so that when an end user connects to and uses the network, they're least likely to encounter issues for which they do not have the technical skillsets to resolve? > Separate to that (in a separate section), make recommendations (as in "sh= ould") to support security and privacy. > We've tried that before, making security and privacy optional to implement makes it easy to justify not implementing it. We need to have the Internet secure and private by default. If we make them options, we should make them options that have to be turned off rather than on, because that causes the person to make an active and conscious decision to give them up (whether it is the right decision for their context is separate, and not one we can control or forecast. If they're unsure, we are providing the safest default.) BCP188/RFC7258 is stating that we take this secure and private by default approach: "The IETF will strive to produce specifications that mitigate pervasive monitoring attacks." Although RFC1726, "Technical Criteria for Choosing IP The Next Generation (IPng)", doesn't specifically call out privacy, privacy is a component of security, and it stated that: "Security should be an integral component of any IPng from the beginning." It is evident from the Snowden revelations that we dropped the ball on that (e.g., IPsec was dropped as an implementation requirement per RFC6434 and became an option), we now need correct that mistake and take a security and privacy first and by default approach. Regards, Mark. From nobody Wed Jul 12 18:42:40 2017 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 398711252BA for ; Wed, 12 Jul 2017 18:42:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QIzwGVMInI64 for ; Wed, 12 Jul 2017 18:42:37 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A56212EC12 for ; Wed, 12 Jul 2017 18:42:37 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c73so21348626pfk.2 for ; Wed, 12 Jul 2017 18:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XlqlRFIT1hwWpUgoy4M651/mJNIqSW68QGzhsUqKm9I=; b=hwGIwhKQ2XGNXl39TBP9empQyKdJ5xc3Pk33oG+xWaOKKi/abLtbI1Siip/NGsjids RJy41eQbbwsU/hgqmd2si64qv3C5lbT3wCDf90eSzOlScb6RqwfvcM7KdU1c9uzyeBhN CCvbKOmXBFt2G0RxOgJzc2ozvguRd7as3Sxy7Vfz6VO975iX1PQUJxtJKVCyrIAvB25V 2eoirgZdYLORwwFfZXnMrJsc1DrYcPETVOFNPd/XLN+X/G/ea8BFXrJSrMLuaBMduHJv UaTDV6/YMGR9cYj+ha1f+ZxMUNyKQacFY32iAK2ML9WQhcc0PjIPnmFpdRl+af1Lq146 iPgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XlqlRFIT1hwWpUgoy4M651/mJNIqSW68QGzhsUqKm9I=; b=LELlMCRou9dCZcms3kVmXEZ2utu3APSRN/kjE8cT+Z3a8mWaoATGGJ1H9yoN48B1kt k09jNcNh0KcyZ8U0OtTjtdLpWUoAi+WDicbds4juwglTqatItkrBlK19Xa5u4wklzGAy 3u/y1Zfd4WL2oA61mDmZA+w7LtBlMDG+4VEiMbBLYi0iHW/4yZ1WPo2suLzapg9DlfrF s1SpWnFATObOZcd68cRiGXwRpA8mVwpPGoWdCY9wbKWH7hZZOiXQfyAItEnHPWy6+Ny5 QecJEzcwlnm/l41C65fi2o6oddUxZweKrxKY+RWLjAP1GFbxTI6TGGfe86wSamofNgPP QVCQ== X-Gm-Message-State: AIVw111DqNFRwE6BMBjMvH2EFYMacutKSpsgu3F8LnjTgT1GgvT2hQlW htEfKlQMhMnJv40P X-Received: by 10.98.155.4 with SMTP id r4mr59075612pfd.186.1499910156435; Wed, 12 Jul 2017 18:42:36 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id d74sm8454535pfb.31.2017.07.12.18.42.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 18:42:35 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: ipv6@ietf.org References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> Date: Thu, 13 Jul 2017 13:42:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:42:39 -0000 On 13/07/2017 06:32, Manfredi, Albert E wrote: ... > Of course, the other option is to expand using ULAs, but then, that's "so IPv4." Not. ULA doesn't imply NAT. It just implies private addresses. I think keeping the addresses of my light switches private and not globally reachable is a wonderful idea. My lighting controller might be accessible via a global address, and would hopefully have much better security than the individual lightswitches. Brian From nobody Wed Jul 12 18:46:37 2017 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 030651317E0 for ; Wed, 12 Jul 2017 18:46:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RDIqkX-3P8KV for ; Wed, 12 Jul 2017 18:46:34 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 833231317DF for ; Wed, 12 Jul 2017 18:46:34 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id g13so6436207uaj.0 for ; Wed, 12 Jul 2017 18:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DiUasQhhLPfk//D+4FbVGfeyj+Ga8FyLtdNo5Fscki8=; b=DHrz9z8o/VoyoPFr4WtJBpfnSzUl5qY/KGsqO36kVaBumcrq9d6E38UiUaN+xIQOhc n3vViZexX04DzBHhS0Km6c+La0fazQK/GzZsh/qZWxudAS6wBhsn1jeGhi95U4xktm0n LIAJ9Y7NSd84IwV7vxoUpPmYvrIl3AEFayX4WEzBnDHOyvJVPPyIGyeoDUcwtK98EVrb ORUx8z+2RR3JANGWa4wY+Sy8e51JUxp3nplv+6FiAKBpUQGfkok57esfHdadJbzF/dqI KYS8bg7RylCLG5lqzXrXnaLVYkCEOzqc9CFqQ4U0oHAbhZjLejIF/MzmBErRtaVuAgib Cd7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DiUasQhhLPfk//D+4FbVGfeyj+Ga8FyLtdNo5Fscki8=; b=FdmVkL+ZTnDhKultNQ1AHOXkzGtEfNXAPTogERiwB6EI8r6Hz3hOp4DPNcmbqyYMvM m+btt4Rcpm/bLWu/xp91cDcyEAe8Fh1qe0aB4pk4fV5BmTLxwGV4UMjDRNOakenXyYSC 7JhADfNaYqGcLt3LrTNqgmusEt4FXHyN5CfpMfMk684k8Qxqk0PfBTxHYflvchVE6P1j mS8PQmrnwdKTbcC+ckIVgGh2XgDgNfuhopPQq8OXlauAP08m4TMH3+PAh7J9Meffd3Oc 1AEEZL5FVqvREMdImtGqW4SILEUPMtQcX7jzotAQJ5NSGuevQVAEqKiSZNKYvuztrUEF d1bw== X-Gm-Message-State: AIVw111uAt3XznYyaLbwO3GTSv5nAXsHm34VuQTNaRtw32vdEkvJYm+l DqwJPlHFDqZ9i0RcBzaWxRhItoIZJmXz X-Received: by 10.176.93.2 with SMTP id u2mr938535uaf.109.1499910393364; Wed, 12 Jul 2017 18:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Wed, 12 Jul 2017 18:46:12 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> From: Lorenzo Colitti Date: Thu, 13 Jul 2017 10:46:12 +0900 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="f403043621883185b10554291a3e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:46:36 -0000 --f403043621883185b10554291a3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 13, 2017 at 2:24 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > So I hope we can now focus on the matter of the very original clash > and see if we can reach consensus through some wordsmithing. If we > can't even do that I think it's better to drop rfc4291bis at this > point. Agreed on both counts. --f403043621883185b10554291a3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 13, 2017 at 2:24 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
So I hop= e we can now focus on the matter of the very original clash
and see if we can reach consensus through some wordsmithing.=C2=A0 If we can't even do that I think it's better to drop rfc4291bis at this point.

Agreed on both counts.
--f403043621883185b10554291a3e-- From nobody Wed Jul 12 18:48:47 2017 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 7CE281317E4 for ; Wed, 12 Jul 2017 18:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CFO30uxbWok5 for ; Wed, 12 Jul 2017 18:48:44 -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 7656F1317E3 for ; Wed, 12 Jul 2017 18:48:44 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y70so22277141vky.3 for ; Wed, 12 Jul 2017 18:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kvPPTlsN2MqeQGQMjIRsGtHsF+d3pukVsEvifvuqpOo=; b=DOB7mqdFD9d4lKaXc+C0FvSFTy6GNPxiWf2GvKIG0pNgSxLr7Nr146X9BIpnRTW3F2 VQGsP73GDfJ8mdi1iFU5KZufL4qTpx01e3Cmb43n8zJzw9yd/44c5hWXbMRiAihpYz/U c6dwAWfdfgyT2mZIgBOtRGVIUtW3roxyMvttRSBmCzNu574KoxKgAcPqpuJL3iA5NA7Y Qnu1f2kCnHHJt4Yta9jxnWxq9KsIBeuurBYn0+UjPfcYv/zOl24zToPM44cR26LSLBSp HSi9OFcdSwGBBQN+1anlUNP1pZw3l/DyBvA6pUfrGfTI1uc5K41ievLjhNiyRUFFfOQb sdfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kvPPTlsN2MqeQGQMjIRsGtHsF+d3pukVsEvifvuqpOo=; b=kJc2V77oZlBbyJTq+mJYpPHXOfu29U3UbatmntTk+160e2sY2pQ1Zs6MlC5ITwmINN xELven4II3cSLA+/9p+nUN5GJV274nMneXlJQ7E3jpU6a8krklSgjpX5LT+zEHj2oqc1 fEaMmpyicGd6HF+gVEVVoB5mJ1dDfLdpvdOywk+A6e3dbSBrOUgPYxEZrwYQiMitTFu3 vrg+1GPcX8cS+LiMTNbwkqOlXaPlBZYwcZZuZ/GNVuHVUnVkjpL2TQ4FXXrfljpiCEUA 91EOIf7VqyEpDl6UiAhunAeY33W7DUKYhIYGuaLEWKSjAq+V2G3XGVEE1PqrHbxeFB08 zpTQ== X-Gm-Message-State: AIVw110yM+hOUIRKcEt94BG4GCSzLoXCUv+GQ4RZcsSUTCVhihapKAsL MJfNoGN0Kh+BPT8AlRqc2y8dSXYMug== X-Received: by 10.31.238.196 with SMTP id m187mr862326vkh.96.1499910523560; Wed, 12 Jul 2017 18:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.88 with HTTP; Wed, 12 Jul 2017 18:48:13 -0700 (PDT) In-Reply-To: <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> From: Mark Smith Date: Thu, 13 Jul 2017 11:48:13 +1000 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Brian E Carpenter Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:48:45 -0000 On 13 July 2017 at 11:42, Brian E Carpenter wrote: > On 13/07/2017 06:32, Manfredi, Albert E wrote: > ... >> Of course, the other option is to expand using ULAs, but then, that's "so IPv4." > > Not. ULA doesn't imply NAT. It just implies private addresses. > I think keeping the addresses of my light switches private and not > globally reachable is a wonderful idea. My lighting controller > might be accessible via a global address, and would hopefully have > much better security than the individual lightswitches. > Agree. ULAs is not "so IPv4". I know of at least two AMI Smartmeter networks with well over 300K meters attached that are using IPv6 and ULAs. They don't need global reachability to or from the Internet, so they don't need GUA addresses (and they're certainly not getting Internet reachability via NAT66 either). Regards, Mark. From nobody Wed Jul 12 18:52:06 2017 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 8004E13180C for ; Wed, 12 Jul 2017 18:52:05 -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 1FER0k8-WeTb for ; Wed, 12 Jul 2017 18:52:04 -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 9F8AF13180F for ; Wed, 12 Jul 2017 18:52:03 -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 v6D1q3aa048853; Wed, 12 Jul 2017 18:52:03 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6D1psEd048355 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 12 Jul 2017 18:51:54 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 18:51:53 -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.1263.000; Wed, 12 Jul 2017 18:51:53 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+SDP3OTJu1pEb0ubfyaiRp6wkqJNwW2AgAAMmoCAAFh6gP//l4BAgADKDwCAAFSoEIAA6HsAgAAt/wD//43p8IAAyDmAgAAyBvCAAPpaAP//i2Cg Date: Thu, 13 Jul 2017 01:51:53 +0000 Message-ID: <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> In-Reply-To: <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 01:52:05 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Of course, the other option is to expand using ULAs, but then, that's >> "so IPv4." > > Not. ULA doesn't imply NAT. I never mentioned NAT, Brian. "So IPv4" was meant to imply use of RFC 1918.= In fact, I can expand a public IPv4 or IPv6 address space, using private I= P addresses or ULAs, with the same advantages and limitations. I can route = these inside my network, overcoming the limitations that have a way of cree= ping up over time. The problem is that over time, way more IP addresses become necessary, not = just a few more. It's because so many more systems adopt IP, and become so = much smarter than they used to be. So you need flexibility to expand, not j= ust in number of connected devices, but also in the architecture of the net= work. Bert From nobody Wed Jul 12 19:05:18 2017 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 35412131803 for ; Wed, 12 Jul 2017 19:05: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 CWXrfTrgq6VZ for ; Wed, 12 Jul 2017 19:05:15 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 88BF3131805 for ; Wed, 12 Jul 2017 19:05:15 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id c73so21581943pfk.2 for ; Wed, 12 Jul 2017 19:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Js465JSS43JIGapupJ9uKPhVKWHhjc6Qs6h4q/X5mEs=; b=b/svA3dFlp4bqFog3cK/46YOXqV7iuZ62sHso6MerLXYMdGeinM8XszjqPlqVVle1R yjHzNgJbBWntA2RbboCBtHBZYSkkQP6yPbpB03qp/Snbhj4RVymi2UM0LWSvlDpKM4yG 8sh00lgrRuliNVr4HkJzXsY5GYNCd5G0GH5s0GKPqfV2aRhXLuPJg2zqMVE4OZgtKXks YYukC47vroIGR0MPRcd8o6A2dJksU05qc97oDcJWtXN9fcQu5QjdRZi0O9CtJ7Ch9fY+ YjqOArkDnRDGCpPyC1vyvAihDbr0/luaHMk53XJgWM4iOcGLRykHL8gujIJwSxoQ5U9J kXBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Js465JSS43JIGapupJ9uKPhVKWHhjc6Qs6h4q/X5mEs=; b=ecUX29avlcqzN4P0tB+u2iFxulrzyBHVNzbYxndrwBaWNFJc2060/fniino+vvSCGH B7KjTURboIsfw/2d193QF7/8bTq5Jrr/a0Lkv775U3fUtU2871ccpMF5ZaXFYkDV6bwH 4j02XiQAB3EdRYPVMwrwb14Lufippv6PbD6ar5hJw+6yEffJgM+0g9gM4U9yKmCjz2io 9gF8TBs1Co7Qc1OqzjXLXlo2Wb9icgd2QyQHqomJ85yDbcms3O0Svn1KmJqyVaQMtStK 8KGEAEwcnZgPBM5iJ/uo17t2SyUWQaiSn3JMNcD3t1KmriL+3HZUuyiaZG+w9B3KRvKz 5bfA== X-Gm-Message-State: AIVw113tK7iAqRphWqyso4sOx4EVWH/6HzCRGnUzUN3m7nqF8FAskG1J rDg8Sn3StwoOk4iR X-Received: by 10.84.174.3 with SMTP id q3mr7335543plb.289.1499911514890; Wed, 12 Jul 2017 19:05:14 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id v70sm8281913pfi.110.2017.07.12.19.05.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 19:05:14 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Lorenzo Colitti Cc: Mark Smith , "Manfredi, Albert E" , 6man WG References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <81b2c3d8-f646-f376-2243-270b2e9e3f3d@gmail.com> Date: Thu, 13 Jul 2017 14:05:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 02:05:17 -0000 On 13/07/2017 01:53, Lorenzo Colitti wrote: > On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> The advantage of requiring or recommending 64 bits is that it avoids the >> debate about N. I prefer 'recommend' because it avoids enumerating all >> possible exceptions. We've seen how hard it is to wordsmith the exceptions. >> > > What's hard is not wordsmithing the exceptions. > > What's hard is claiming that there's consensus (even rough consensus). The > fact of the matter is that we have opposing camps with equally strong > opinions on the matter, and neither camp is willing to accept the position > of the other. > > Based on past experience, it seems pretty clear to me that this situation > will not change until we get a problem statement that we agree on. Care to > write one up? > Nick Hilliard just did: >> I would suggest that future protocols need to define what makes sense >> for them, and mandating a constant in advance isn't necessary or even >> appropriate. Which is why I personally would be happy with the addressing architecture either not mentioning 64 at all, or *recommending* 64, or requiring 64 "except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents." IMHO any of those three formulations would resolve Nick's problem statement (given that there is also a citation of BCP198 in the latest draft to clarify how routing works). Brian From nobody Wed Jul 12 19:09:23 2017 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 3499B126B7F for ; Wed, 12 Jul 2017 19:09:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 m5DLSZMbRubw for ; Wed, 12 Jul 2017 19:09:19 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18D312EC37 for ; Wed, 12 Jul 2017 19:09:19 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c73so21624499pfk.2 for ; Wed, 12 Jul 2017 19:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nHAUCvrqO24V8jSXpeeJKr+HKq5UDvHIfCfWaI+1TJc=; b=EQY8LnKuWSba73FaDaZ+orfQobUqdJ/1wUpIEEk/er0W0BXCJNOy3/T6BHxD79NCBf KU1HLxjMf9iuo59XXwtWPem8jtN8BsE+aUJZe7+97gvHG8AP4xm5gFoBEBRfjGMGIktm 8bterhX2+/V75pAnMKrWbFXSPrimEv+KQl8attmjrm9rUQDfTVOGo/6O9PdE2pjodp2O uO1QD21Ewn4/4GzI3qtQqfcuRJ+pzkDTMEKZ5sqmBqqdNZ6yuvY3WH9pmYXN8pqC+Iwf xORGbe/YxXKyUxpiER5aK2uAuAEMFWhifEZGKRVGl5Sy1JgdaVpY+Wy93b2RLxc7AMX5 Bwag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nHAUCvrqO24V8jSXpeeJKr+HKq5UDvHIfCfWaI+1TJc=; b=r3vmEQIbWoCB3Gh78MPjg2PQ5aLvYaUJ2swM42mf4gKHyQNV/15Zt2GUVJAVvhsb0X tmIEbU3tb1vOEdRLUn7xih6aof/sTLFpdAKunaehHfgVzAJUayMW98LJ/Zxeiqml8La5 criyN0FgcmV60p7gaXCOa+HR8IK/cpCPFadXTih2Mjee23kpkWZs6XAwqqTHS7pKfPts QaBWs5YV/GWDj9PEZBZzBuviwAzIm9FeHAS3eJJVgBA9G8ITHWwEU16SustwTIIJ4JRH Ktiz4ckSx+/dneIxgJWKCmocWYpVg4Tbs8E1vXVQPDe9N8rZLM+fOyZs7hzYf+kOKmAi jCEQ== X-Gm-Message-State: AIVw1137y2o6ujsvqLQ72Wc7nK4MHx+hjiXzzpUePn4/iW7n1yXHHS3l UWSGxaGPYHGEZzFS X-Received: by 10.99.107.135 with SMTP id g129mr6915211pgc.179.1499911759230; Wed, 12 Jul 2017 19:09:19 -0700 (PDT) Received: from [192.168.178.21] ([118.148.68.108]) by smtp.gmail.com with ESMTPSA id t78sm8885062pfa.48.2017.07.12.19.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 19:09:18 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Manfredi, Albert E" , "ipv6@ietf.org" References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 13 Jul 2017 14:09:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 02:09:21 -0000 On 13/07/2017 13:51, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >>> Of course, the other option is to expand using ULAs, but then, that's >>> "so IPv4." >> >> Not. ULA doesn't imply NAT. > > I never mentioned NAT, Brian. "So IPv4" was meant to imply use of RFC 1918. In fact, I can expand a public IPv4 or IPv6 address space, using private IP addresses or ULAs, with the same advantages and limitations. I can route these inside my network, overcoming the limitations that have a way of creeping up over time. > > The problem is that over time, way more IP addresses become necessary, not just a few more. It's because so many more systems adopt IP, and become so much smarter than they used to be. So you need flexibility to expand, not just in number of connected devices, but also in the architecture of the network. Sure. Which is why we have always advocated /48 to end users. Truth be told, I liked RFC3177 a lot more than RFC6177. But 6177 is more realistic. Brian From nobody Wed Jul 12 20:14:22 2017 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 CD006129AEB for ; Wed, 12 Jul 2017 20:14:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YhSocwbLnUla for ; Wed, 12 Jul 2017 20:14:19 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::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 6ABAB12700F for ; Wed, 12 Jul 2017 20:14:19 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y129so5232862pgy.3 for ; Wed, 12 Jul 2017 20:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eC4cuvBERO5dJdAIUACsTJamRCyCRyCMp9BVhBvJaK8=; b=KUUJriZI5UVH/hrQ4Y/P0BhQtYpV9ngydFtytX/pqQCaTceJKPYzbCdel1tOlRZ3Hx ZJJ/xH6cOeOTkPWXZHPG710Qzsq9RWzNrOrsWIjxyUlBqogUBEQ+GFWpwaAW9LSFUj11 8Nsw922cvy4MmXKuTuBRMI4gz+wyft14HcrEM2AKYjkE/RBdRrM+xS47RNcwKZOts5yy 9mYIh+/FkdkoHo6Mufj7FpTE1FZ1YfZ5IyufApSWHuTWAj4YhTSzkSj9A0ZrgpAwXOPU sDShpPzkZkTNtqp0LiaHERY4kyJLg4Bk7CM3meUjBEWRH4zJlxWD1DqsXnXtV5a0V1ag rxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eC4cuvBERO5dJdAIUACsTJamRCyCRyCMp9BVhBvJaK8=; b=f6Thwc3XaRXZyGWVoVgGmNvIZpH6/hsfUyWacDPDjUP1LgmSS70Zgn1oLLGgIDzfG6 WrnK0xpk8THRDEkQKG3Qp3ty9A9peRmExzBEQ3KBs1eGxyJk3CEx4B+U2JlKwKzZljL8 IYDVHVFj943eZOFfn0QVqMDjraOssgDgQAQLnhsgUbn5iVfp6DTQoF1yRdi/m6E75KBD nxKRLR22LvsUnxAu0+sGzCqhaubUH2vvDqpwlLkK66+wvIF0+cLY6NOjWeL5v+yERqlL KMYIS+iXJ+0GsY/VZP6ok9SR0aqT2zrg1CfZDqFi6EiOboj7Xb05zQZJFHNWQ6tM+ggn mbmA== X-Gm-Message-State: AIVw112Y0Rije+COaFwFHa06roTduuczsrxAVBl6lYDGmmWNrS2ja1gQ VB7tDsiPWrXXAYtu8Sg= X-Received: by 10.99.127.11 with SMTP id a11mr7045775pgd.213.1499915658545; Wed, 12 Jul 2017 20:14:18 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:fdbd:7c9a:e072:f676? ([2601:646:c005:a10:fdbd:7c9a:e072:f676]) by smtp.gmail.com with ESMTPSA id 124sm5875551pgi.62.2017.07.12.20.14.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 20:14:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Fred Baker X-Mailer: iPhone Mail (14G57) In-Reply-To: <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> Date: Wed, 12 Jul 2017 20:14:15 -0700 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 03:14:21 -0000 Sent using a machine that autocorrects in interesting ways... > On Jul 12, 2017, at 6:42 PM, Brian E Carpenter wrote: >=20 >> On 13/07/2017 06:32, Manfredi, Albert E wrote: >> ... >> Of course, the other option is to expand using ULAs, but then, that's "so= IPv4." >=20 > Not. ULA doesn't imply NAT. It just implies private addresses. I would go a step further. A ULA is a global-scope address that is not adver= tised in BGP, and if advertised is refused, barring private arrangements. I c= arry a T-Mobile telephone, and the address of the DNS server is a ULA addres= s. The point, I have no doubt, is to prevent attacks on the server by having= it untraceable absent a legitimate reason to have the address. It's a firewall rule that is programmed in routing instead of a firewall. No= thing more, and nothing less.= From nobody Wed Jul 12 22:18:51 2017 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 B1A4F12EB4A for ; Wed, 12 Jul 2017 22:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 uZ3xCmA9VF4x for ; Wed, 12 Jul 2017 22:18:48 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 06391129B33 for ; Wed, 12 Jul 2017 22:18:48 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id y70so23850493vky.3 for ; Wed, 12 Jul 2017 22:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=hTHRWd6BcyMNeGfHspj2M7r949NBG0cHflLEJ55Nhec=; b=sElubCE2UY6rcR81pdsO7ojnN0vMdv19CGW8fvIXhJAPeSy5Yv9ZdtgCr7rxZF7dsz dT/qgHWKGLIaWoyT4XnxzmiI96R9T/SHj/Vcwy7/4nWUNJpXtsN212WOEhVHFSndB5Qg 3Y5C+jFKUsH2LX5UPSAl64DvS/f81rzyn5jMOJPTPi1Q8FS8dzmMN+1ni0Qaxc2pDxqE ilu5IypvLEM6MQQ6txnshvr7OApDgt7ZIO3j71xoRtzYEe2G9P8hy+pYnMSWGh6bbCy5 V+/sb7EOFoEgSB4c2X5hrXyj3Cl99WakGr6aURfmJ7NL4bxXXDtl+HgyaiBmCRCJdtDL UcYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=hTHRWd6BcyMNeGfHspj2M7r949NBG0cHflLEJ55Nhec=; b=iHJre/CoUvN7yZoV1Lj1ysjDCNj9UgSR7aptWLCU3XPNoSvu9CoEVPpCEnOznY+3dQ Zpb2n6nkMX09r65mSGfLMd8vQZBB6mIhDkK9knmr8PE8Jdkcr4fI3ND3H1d+cyUm6Kjc yQVQNDA0sZ36jisQiGfbcjxatYzYXL8ZYkHrKW621BAyHuQgJhBRlWtGnbbuxt/YC2No JKWC/KK2iQ5mat7AG9/lyYpes9vBj9mtfTBDyGcSEVBGmon993Xb0+7LC4UWO7nCsTa4 dMftaiWhbGpO0k3VJ/NnZauJlgNBT8y4LQSm4mFDg2FlGVibZplc9XOCIKyTtzMFdbV/ m1cg== X-Gm-Message-State: AIVw113QuEiFRJygftpjwHR4px2QwhYIJXQr5TZFASn0OieuwGG1IVor RWDpwLm5jtVJMB++ZbTuL+knHqJU0A== X-Received: by 10.31.173.214 with SMTP id w205mr1027513vke.8.1499923126923; Wed, 12 Jul 2017 22:18:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.88 with HTTP; Wed, 12 Jul 2017 22:18:16 -0700 (PDT) From: Mark Smith Date: Thu, 13 Jul 2017 15:18:16 +1000 Message-ID: Subject: Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing, ) To: Brian E Carpenter Cc: Lorenzo Colitti , "Manfredi, Albert E" , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 05:18:49 -0000 On 13 July 2017 at 12:05, Brian E Carpenter wrote: > On 13/07/2017 01:53, Lorenzo Colitti wrote: >> On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> > Nick Hilliard just did: > >>> I would suggest that future protocols need to define what makes sense >>> for them, and mandating a constant in advance isn't necessary or even >>> appropriate. > > Which is why I personally would be happy with the addressing > architecture either not mentioning 64 at all, or *recommending* 64, > or requiring 64 "except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents." > > IMHO any of those three formulations would resolve Nick's problem > statement (given that there is also a citation of BCP198 in the > latest draft to clarify how routing works). I think what Nick suggested is the total opposite of what should be done and I think opposite to one of IPv6's major themes. Forming IIDs should not be left to link-layer specific protocol specs. I think one of the significant differences between IPv4 and IPv6 is that a number of mechanisms have been made more generic and less link-layer specific, or have been shifted from out of the link layer. Specifically, - ND is part of ICMP, rather than being a link-layer specific protocol a ARP was. - ND itself also tries to be as generic as possible, so that it can operate over all link-types. Link unicast is a given, it expects a link to emulate multicast if it isn't natively supported. - IP and higher layer parameter configuration has been moved out of PPP to upper layer and generic, non-link-layer specific protocols such as RAs and DHCPv6. We did have link-layer specific methods to generate IPv6 IIDs for SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID generation could be made link-layer agnostic because it was for convenience rather than necessity. Stateful DHCPv6 doesn't do link-layer specific or dependent addressing either. Another way to consider what the IPv6 layer/protocol does is that it abstracts away link-layer differences. As RFC6272 says in its overview of the Internet Protocol Suite, "The Internet layer provides a uniform network abstraction network that hides the differences between various network technologies. This is the layer that allows diverse networks such as Ethernet, 802.15.4, etc. to be combined into a uniform IP network. New network technologies can be introduced into the IP Protocol Suite by defining how IP is carried over those technologies, leaving the other layers of the IPS and applications that use those protocol unchanged." So, with IPv6 abstracting away the link-layer differences, for consistency, IPv6 addresses are better to be abstract and decoupled from underlying link-layer characteristics such as the link-layer address characteristics and values. Regards, Mark. From nobody Thu Jul 13 01:41:36 2017 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 4B13E131447 for ; Thu, 13 Jul 2017 01:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wxciSIyA3O9a for ; Thu, 13 Jul 2017 01:41:33 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 67DF2129B2C for ; Thu, 13 Jul 2017 01:41:33 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g40so29487143uaa.3 for ; Thu, 13 Jul 2017 01:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c0w94hueICnmLRlplRy36e4vVIxy23PponBO7H5VqpE=; b=bXJ+EuiFJkSgcdyFxN8Ep/KCazycuk3ceav0RZ3a9HpzvNyccEjbYeViN1aBjPahUC 508apw4cn8iuq6ogMJLqnCZjty8Ad9kYeZKRSbunGSG+fbzVXWbByiA4/icGL1pvDxds +ihFdnFziOv1tUQqH865LLzv/BbuA6uYDF0+Jp8U3NENXsd60zL4AbC6oqEO2mWhwkD+ 3AEKsOCxOrU4lF2mgKDL1sikM9jhpnfPwx/U+nnaEhIq5l2RoWXBdqZHhiHjb+XOjHkd EjMepCZe0wHDC173wW4geavZK5OqudsvKOfflHZVx3b1ZqgBcQHwchPcV06vzrJHxreq nwKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c0w94hueICnmLRlplRy36e4vVIxy23PponBO7H5VqpE=; b=aT+6SKmMUUpYDHTZfVyhGzXoSz2uJayYB74uUrUcQOCrirDFW2C/LOklxv/BDfzhrv 9pdcL/e4j4IuUGuFgigaYdFDQMMy70/JaKj5DxnmyNrRY30q3tMci0Jcz7Wr/nJrSNXG 4zwqSZaRo5uMsNvWdxpKkG98W+NtXUy0nPOFkXQz+X2K81g5e0gprS7eDIx7wtX51uBN ikwX5P1ktFrY+rHjQRsy373Vh5lG/Hn8frEargx0nkLRjOBRfa1wZ0T5dbL+pwHBvjHH jx/eenS2asYf5ZQO61pRSX9iZ0WJIB7572+uLk27IMXKfc+nDB4cNCeUWiKJ+TSg6cyi t+Wg== X-Gm-Message-State: AIVw111XEVjGknypfRIkENLx/SjIlNOx8g4NF7SdZ6aQ9b+hLjYKkMlM 5/uVCjffPXATfeO10fUm5r1WqkaiGs6I X-Received: by 10.159.61.110 with SMTP id m46mr1777607uai.64.1499935292253; Thu, 13 Jul 2017 01:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.88 with HTTP; Thu, 13 Jul 2017 01:41:01 -0700 (PDT) From: Mark Smith Date: Thu, 13 Jul 2017 18:41:01 +1000 Message-ID: Subject: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 08:41:35 -0000 Hi, I've been thinking about this for a while and finally put together a draft. It's partly the next step on from a draft I wrote a few years ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in response to the recent inserting EH's proposals. As mentioned, not expecting any discussion at IETF99. Skinny IPv6 in IPv6 Tunnelling draft-smith-skinny-ipv6-in-ipv6-tunnelling-02 Abstract This memo proposes a method of tunnelling IPv6 packets inside IPv6 packets with a reduced tunnelling overhead. http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt Comments and suggestions most welcome. Thanks, Mark. From nobody Thu Jul 13 02:29:55 2017 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 71B6A128768 for ; Thu, 13 Jul 2017 02:29:53 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3XWHou3pTUb for ; Thu, 13 Jul 2017 02:29:51 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF7712708C for ; Thu, 13 Jul 2017 02:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499938188; x=1500542988; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=/Xu20cgNUDeMh6HPtCHmahSMD 8AZIoRFasM60X/IuOo=; b=MZ8jZ17fFNachfoe+gmzIrcwjS1ENjlblNKiwHlK2 AtXoRtmLoCf4wJNzBRDEHcXb9/inqZK0xK/QteOy/wTxZWc8ishjLpZ9VqjT9425 Rrd8A4139BK+ZxXNriZowH9R+b7yC2FmmQ/GMhf8bAXBz7MdKkAlKNgXFfo8mlu0 Is= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=J+FZojgB+JbEdv1BV7zuQOp6wMBqLatnTCOklV1i7lxSIgOrCENelLRDVKef dsPBZn8bxqd/3f8aOdsCCUgCJufA5y5gHxymIEfEYw6Raa9T0A+92D+ck r2jj/HBV5cbRKn0A+9jAAt6Uo1xLso3OCcG5xtFwsi9G6U0kUCqO1s=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Jul 2017 11:29:48 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Jul 2017 11:29:47 +0200 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005474353.msg for ; Thu, 13 Jul 2017 11:29:46 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170713:md50005474353::IJae9mWzenQuvLsZ:00000Rhe X-Return-Path: prvs=136700ef73=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 13 Jul 2017 11:29:45 +0200 Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" From: JORDI PALET MARTINEZ To: 6man WG Message-ID: Thread-Topic: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 09:29:53 -0000 The link doesn=E2=80=99t work for me, even can=E2=80=99t traceroute to the = server =E2=80=A6 Isn=E2=80=99t in the IETF repository? Regards, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Mark Smith Responder a: Fecha: jueves, 13 de julio de 2017, 10:41 Para: 6man WG Asunto: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelli= ng" Hi, =20 I've been thinking about this for a while and finally put together a draft. It's partly the next step on from a draft I wrote a few years ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in response to the recent inserting EH's proposals. =20 As mentioned, not expecting any discussion at IETF99. =20 =20 Skinny IPv6 in IPv6 Tunnelling draft-smith-skinny-ipv6-in-ipv6-tunnelling-02 =20 Abstract =20 This memo proposes a method of tunnelling IPv6 packets inside IPv6 packets with a reduced tunnelling overhead. =20 =20 http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunne= lling.txt =20 =20 Comments and suggestions most welcome. =20 Thanks, Mark. =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Jul 13 02:45:36 2017 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 2C13B1318A5 for ; Thu, 13 Jul 2017 02:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BRck07nJdWWA for ; Thu, 13 Jul 2017 02:45:33 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 AA737131895 for ; Thu, 13 Jul 2017 02:45:33 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id g13so11518426uaj.0 for ; Thu, 13 Jul 2017 02:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7AaC7xDACmBGlBm/ceNeIUQ9PwmRPAOs/5DO2Z4/Kto=; b=BCBrcmTCnXKQqF2W47Uo4XbJknzovijJg1zD+8u8/vW9Z125XQtH9fW6VhWWAUYhB8 lhps9xlyRMFBqb90FGaMB2PF18p1baAFlQhLX8Xg8kPLfez1PQOl8A2oBXbrg3wpsDQZ I8xUNAR9KAlVprro23lE1FCV/V2OZpt5HbP7XP9W1Lldsap7y+fuQwCkp/RfseTOXuwe yTvDZ+xzbUs59APv4qYLXuLu6k4IgWQ5S2/pugexrfcAatBAzvGlK+nAvI1artsoYp0I f46+uUeGb8SV+MZg0pa+8Qxu51O7pWM5IwWw9Qfc+teMvoB8KboP/CW/rDw9oKN77QIT lpbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7AaC7xDACmBGlBm/ceNeIUQ9PwmRPAOs/5DO2Z4/Kto=; b=TCby1ajR1KnDTXWoHwJA6bhWSwT8yuwc9iQaG4B3OOQOS4xkb01vLojOGQMrTcJ26u QMEwYGQQWLXXrdrhoJHrAeFdfEdJpZyTR132zldON31lorPS6/s2IPjnAM7shNlh+6jt Ya1EWbcc++tppAlSkBL2Cz6zr/O8ax45FoIZlRcTIhJAg5tQj2JBolppOSEkCkj4wUvT TSmmDdrn03eBFU1t4fNGUDqZR5VK87xRboZIObC/0pYz6CLfDgOufWdgWLwa8FP+1d/T iYdIh5nnRe7tBSgd5zVpTGHWYayYTJ6jTU/NwHekwIIGdDDWJrnb294zZbfJu+/Vk1yj nIZw== X-Gm-Message-State: AIVw111XbLGzDr8pd2qp1EvFB/fSMvFKclnkWMTqxxQyj8L/Au/CgSt+ ue/bD6VywV3nBMyHouyI0n8DDF2TDJQR X-Received: by 10.159.53.45 with SMTP id o42mr1902445uao.84.1499939132604; Thu, 13 Jul 2017 02:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.17.88 with HTTP; Thu, 13 Jul 2017 02:45:02 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Thu, 13 Jul 2017 19:45:02 +1000 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: jordi.palet@consulintel.es Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 09:45:35 -0000 On 13 July 2017 at 19:29, JORDI PALET MARTINEZ wrote: > The link doesn=E2=80=99t work for me, even can=E2=80=99t traceroute to th= e server =E2=80=A6 > Strange. I can access it, however I'm downstream of it. A few of those "is it up" websites are showing it is reachable. I'll email you a copy off list. > Isn=E2=80=99t in the IETF repository? > Repository closed for submissions leading up to IETF99, opens again on the 16th and I got a little impatient because I finished it :-) Regards, Mark. > Regards, > Jordi > > > -----Mensaje original----- > De: ipv6 en nombre de Mark Smith > Responder a: > Fecha: jueves, 13 de julio de 2017, 10:41 > Para: 6man WG > Asunto: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnel= ling" > > Hi, > > I've been thinking about this for a while and finally put together a > draft. It's partly the next step on from a draft I wrote a few years > ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in > response to the recent inserting EH's proposals. > > As mentioned, not expecting any discussion at IETF99. > > > Skinny IPv6 in IPv6 Tunnelling > draft-smith-skinny-ipv6-in-ipv6-tunnelling-02 > > Abstract > > This memo proposes a method of tunnelling IPv6 packets inside IPv6 > packets with a reduced tunnelling overhead. > > > http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tun= nelling.txt > > > Comments and suggestions most welcome. > > Thanks, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the use of the individua= l(s) named above. If you are not the intended recipient be aware that any d= isclosure, copying, distribution or use of the contents of this information= , including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jul 13 03:34:12 2017 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 85D1912EA7C for ; Thu, 13 Jul 2017 03:34:11 -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] 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 gIxdftDnghea for ; Thu, 13 Jul 2017 03:34:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 19F56129A9F for ; Thu, 13 Jul 2017 03:34:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dVbRc-0000GQC; Thu, 13 Jul 2017 12:34:04 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 13 Jul 2017 01:51:53 +0000 ." <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 13 Jul 2017 12:33:59 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 10:34:11 -0000 >The problem is that over time, way more IP addresses become necessary, not just a > few more. It's because so many more systems adopt IP, and become so much smarter > than they used to be. So you need flexibility to expand, not just in number of c >onnected devices, but also in the architecture of the network. Using pseudo-random IIDs comes with the risk of collisions. So you have to waste lots of bits to get that risk down to an acceptable level. It is a really bad trade-off if your ability to expand the network comes at the price of increased risk of collision. However, since the mid 90s we have a protocol for dense allocation of addresses. Where in the 64-bit IID space you can fit an entire universe. So maybe stop trying to shoehorn the wrong protocol to your application and make the right one work for you. From nobody Thu Jul 13 07:46:07 2017 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 DDAA9131919 for ; Thu, 13 Jul 2017 07:46:05 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 IipmdYmh0Mmq for ; Thu, 13 Jul 2017 07:46:04 -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 07E9A1318DB for ; Thu, 13 Jul 2017 07:46:03 -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 v6DEk36Q025544; Thu, 13 Jul 2017 07:46:03 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6DEjtn9025461 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 13 Jul 2017 07:45:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 07:45:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 13 Jul 2017 07:45:54 -0700 From: "Templin, Fred L" To: Mark Smith , "jordi.palet@consulintel.es" CC: 6man WG Subject: RE: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" Thread-Topic: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" Thread-Index: AQHS+7PhYhMm1RODQkqiZ54dbSiZoqJR8xGAgAAERQD//95CAA== Date: Thu, 13 Jul 2017 14:45:54 +0000 Message-ID: <6ce5f2f53de54260ae4836b5fe33c9ed@XCH15-06-08.nw.nos.boeing.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 x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 14:46:06 -0000 SSB3YXMgYWJsZSB0byBhY2Nlc3MgaXQuIEl0IGlzIGFuIGludGVyZXN0aW5nIGRyYWZ0IC0gaGF2 ZSB5b3UgdGhvdWdodCBhYm91dCBob3cNCml0IHdvdWxkIGludGVyYWN0IHdpdGggaGVhZGVyIGNv bXByZXNzaW9uIGFuZCB3aG9sZSBtZXNzYWdlIGNvbXByZXNzaW9uPw0KDQpUaGFua3MgLSBGcmVk DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlw djYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNCj4gU2VudDogVGh1 cnNkYXksIEp1bHkgMTMsIDIwMTcgMjo0NSBBTQ0KPiBUbzogam9yZGkucGFsZXRAY29uc3VsaW50 ZWwuZXMNCj4gQ2M6IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBOb3Qg Zm9yIGZvcm1hbCBkaXNjdXNzaW9uIGF0IElFVEY5OSAtICJTa2lubnkgSVB2NiBpbiBJUHY2IFR1 bm5lbGxpbmciDQo+IA0KPiBPbiAxMyBKdWx5IDIwMTcgYXQgMTk6MjksIEpPUkRJIFBBTEVUIE1B UlRJTkVaDQo+IDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4gd3JvdGU6DQo+ID4gVGhlIGxp bmsgZG9lc27igJl0IHdvcmsgZm9yIG1lLCBldmVuIGNhbuKAmXQgdHJhY2Vyb3V0ZSB0byB0aGUg c2VydmVyIOKApg0KPiA+DQo+IA0KPiBTdHJhbmdlLiBJIGNhbiBhY2Nlc3MgaXQsIGhvd2V2ZXIg SSdtIGRvd25zdHJlYW0gb2YgaXQuIEEgZmV3IG9mIHRob3NlDQo+ICJpcyBpdCB1cCIgd2Vic2l0 ZXMgYXJlIHNob3dpbmcgaXQgaXMgcmVhY2hhYmxlLg0KPiANCj4gSSdsbCBlbWFpbCB5b3UgYSBj b3B5IG9mZiBsaXN0Lg0KPiANCj4gPiBJc27igJl0IGluIHRoZSBJRVRGIHJlcG9zaXRvcnk/DQo+ ID4NCj4gDQo+IFJlcG9zaXRvcnkgY2xvc2VkIGZvciBzdWJtaXNzaW9ucyBsZWFkaW5nIHVwIHRv IElFVEY5OSwgb3BlbnMgYWdhaW4gb24NCj4gdGhlIDE2dGggYW5kIEkgZ290IGEgbGl0dGxlIGlt cGF0aWVudCBiZWNhdXNlIEkgZmluaXNoZWQgaXQgOi0pDQo+IA0KPiBSZWdhcmRzLA0KPiBNYXJr Lg0KPiANCj4gDQo+ID4gUmVnYXJkcywNCj4gPiBKb3JkaQ0KPiA+DQo+ID4NCj4gPiAtLS0tLU1l bnNhamUgb3JpZ2luYWwtLS0tLQ0KPiA+IERlOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc+ IGVuIG5vbWJyZSBkZSBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KPiA+IFJl c3BvbmRlciBhOiA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4NCj4gPiBGZWNoYToganVldmVzLCAx MyBkZSBqdWxpbyBkZSAyMDE3LCAxMDo0MQ0KPiA+IFBhcmE6IDZtYW4gV0cgPGlwdjZAaWV0Zi5v cmc+DQo+ID4gQXN1bnRvOiBOb3QgZm9yIGZvcm1hbCBkaXNjdXNzaW9uIGF0IElFVEY5OSAtICJT a2lubnkgSVB2NiBpbiBJUHY2IFR1bm5lbGxpbmciDQo+ID4NCj4gPiAgICAgSGksDQo+ID4NCj4g PiAgICAgSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMgZm9yIGEgd2hpbGUgYW5kIGZpbmFs bHkgcHV0IHRvZ2V0aGVyIGENCj4gPiAgICAgZHJhZnQuIEl0J3MgcGFydGx5IHRoZSBuZXh0IHN0 ZXAgb24gZnJvbSBhIGRyYWZ0IEkgd3JvdGUgYSBmZXcgeWVhcnMNCj4gPiAgICAgYWdvICgiRW5o YW5jaW5nIFZpcnR1YWwgTmV0d29yayBFbmNhcHN1bGF0aW9uIHdpdGggSVB2NiIpIGFuZCBhbHNv IGluDQo+ID4gICAgIHJlc3BvbnNlIHRvIHRoZSByZWNlbnQgaW5zZXJ0aW5nIEVIJ3MgcHJvcG9z YWxzLg0KPiA+DQo+ID4gICAgIEFzIG1lbnRpb25lZCwgbm90IGV4cGVjdGluZyBhbnkgZGlzY3Vz c2lvbiBhdCBJRVRGOTkuDQo+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBT a2lubnkgSVB2NiBpbiBJUHY2IFR1bm5lbGxpbmcNCj4gPiAgICAgICAgICAgICAgICAgIGRyYWZ0 LXNtaXRoLXNraW5ueS1pcHY2LWluLWlwdjYtdHVubmVsbGluZy0wMg0KPiA+DQo+ID4gICAgIEFi c3RyYWN0DQo+ID4NCj4gPiAgICAgICAgVGhpcyBtZW1vIHByb3Bvc2VzIGEgbWV0aG9kIG9mIHR1 bm5lbGxpbmcgSVB2NiBwYWNrZXRzIGluc2lkZSBJUHY2DQo+ID4gICAgICAgIHBhY2tldHMgd2l0 aCBhIHJlZHVjZWQgdHVubmVsbGluZyBvdmVyaGVhZC4NCj4gPg0KPiA+DQo+ID4gICAgIGh0dHA6 Ly93d3cudXNlcnMub24ubmV0L35tYXJrYWNoeS9kcmFmdC1zbWl0aC1za2lubnktaXB2Ni1pbi1p cHY2LXR1bm5lbGxpbmcudHh0DQo+ID4NCj4gPg0KPiA+ICAgICBDb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgbW9zdCB3ZWxjb21lLg0KPiA+DQo+ID4gICAgIFRoYW5rcywNCj4gPiAgICAgTWFyay4N Cj4gPg0KPiA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICAgICBJRVRGIElQdjYgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3QNCj4gPiAgICAgaXB2NkBpZXRmLm9yZw0KPiA+ICAgICBBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 DQo+ID4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4gSVB2NCBpcyBvdmVyDQo+ ID4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+ID4gaHR0cDovL3d3dy5j b25zdWxpbnRlbC5lcw0KPiA+IFRoZSBJUHY2IENvbXBhbnkNCj4gPg0KPiA+IFRoaXMgZWxlY3Ry b25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0 aGUgdXNlDQo+IG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YNCj4gdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5m b3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gPg0K PiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdA0KPiA+IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Thu Jul 13 08:02:28 2017 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 F11C31316D9 for ; Thu, 13 Jul 2017 08:02:24 -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, RP_MATCHES_RCVD=-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 aw2q78mzcciO for ; Thu, 13 Jul 2017 08:02:23 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6176D13192B for ; Thu, 13 Jul 2017 08:02:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 7DB781BC37 for ; Thu, 13 Jul 2017 15:02:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Simon Hobson In-Reply-To: Date: Thu, 13 Jul 2017 16:02:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <374AC757-B69A-426C-8C28-E84132E6C7C4@thehobsons.co.uk> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <8392C5AA-0E37-4A09-AFEB-13A61D11E783@thehobsons.co.uk> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:02:25 -0000 Re-ordering the comments slightly ... Mark Smith wrote: >> Ignoring LL addresses, it seems that only self assigned addresses = using deprecated methods (ie based on hardware address) actually = *require* a 64 bit split. So on that basis, the standard defining how = the protocols work should require implementations to support an = arbitrary split. >>=20 >=20 > I think the final arbiter in any of these situations is "what is best > for the end-users?" >=20 > What is the simplest, that will result in lower network capex and opex > costs to the end-users who directly or indirectly pay those costs? >=20 > What is the most reliable and robust, so that when an end user > connects to and uses the network, they're least likely to encounter > issues for which they do not have the technical skillsets to resolve? The obvious answer to that is "all implementations MUST handle any IID = length". That way, when a device does get connected to a network where = the IID length isn't 64 bits - it'll still work. If you leave in any suggestion that an implementation can assume a split = 64/64 then some implementations are going to have that embedded in them. = If you allow that, and the device gets connected to a network where that = isn't the case (for whatever reason*) then it's going to "not work" = (either at all or properly). * We've already seen some suggestions of why that might be - for example = where an ISP only provides a single /64 and the user wants more than one = network. >>> This is not recognising that there are more than operational or = functional properties of addresses. They have privacy and security = properties too. >>=20 >> Shouldn't this requirement be separate from the underlying protocol = requirements ? >=20 > No, I don't think so. These protocols fundamentally exist to serve > end-user needs. If they don't, then they're no more than an academic > experiment, and we'll have wasted an awful lot of human capital on > them. These are primary protocol requirements, necessary to meet to > justify the protocol's existence. But that's the point I was making - having the IID length at (say) 64 = bits is NOT a fundamental requirement. Things would still work just fine = even if it was (say) 32 bits, or 16 bits, or ... With shorter lengths = (smaller address space) the problem of creating addresses autonomously = without clashes becomes harder - but other than that, as long as there = is "enough" space then devices will still work. Where the large address space requirement comes from is a secondary = function - privacy. It is not in any way a fundamental limitation in = shifting packets about. > Separate to that (in a separate section), make recommendations (as in = "should") to support security and privacy. >>=20 >=20 > We've tried that before, making security and privacy optional to > implement makes it easy to justify not implementing it. I think there's something of a difference between an optional feature - = ie something that needs to be added - and something where it's not a = feature that's turned on or off. And the IID length would need to be a = lot shorter than 64 bits before the address space becomes trivially = smaller. You can't really say the privacy feature is "off" if the IID is = only 63 bits, or even down to (say) 32 bits which still gives 4 billion = addresses to play with. If the recommendation is for 64 bits, then it's going to be hard to = justify such a small address space that privacy is nullified. And the = sort of outfit that does, will be quite happy to do other crap that's = harmful to their users - regardless of what any RFC says. So if you're going to set some arbitrary sizes for IID lengths - then = give the real reason which is security/privacy. Because AIUI there is no = other fundamental reason to set any restrictions. From nobody Thu Jul 13 08:13:41 2017 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 1C6DC12741D for ; Thu, 13 Jul 2017 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.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 j_11bZHbvfeL for ; Thu, 13 Jul 2017 08:13:38 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 91FF3124C27 for ; Thu, 13 Jul 2017 08:13:38 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 77so54880997wrb.1 for ; Thu, 13 Jul 2017 08:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7NvblCEyvKfDNaS0m8pTANlP6cQ+KpoUXBeMBYQFCkI=; b=YNFLiCJxBngw5jjOTkqpBrUPwYG1CIYxOQYFgXGu5Sg2snAZys56aI2xElzi+oH6nQ 9P/oTfKbShON3OJhRUFSD4reZblam1uWcIBlOTJjdf2YxOqfPRGB/YfsqBOTsRD0HrL9 ohxHWKU/kjq9Wc6jHb+YfgA7vpJIJ2PJnTc2o1ex0WE7v4Q9iiLc9mUCs1VNSPshc3zq C1EQcBa9WCiTgWGE87NYjcmdrYbA48uujwWL5RZnvfiek6UgaNoRYS2Zf1l6X1EfRy59 S1b1dDy/e2SFxCbSvw3vJrVQ3R25DwAkmr8wXlqIAsWYyKb/ysr3eVZgqXfGBpzKgu6t 7LZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7NvblCEyvKfDNaS0m8pTANlP6cQ+KpoUXBeMBYQFCkI=; b=txGjACJQ/ZflZf3VJqqVjzR6Y2U3ZaanV8CqHGWPENla8PDuc/uo404JXeN+celk3z IrRS0mFmDu3zJIMgDXUmFZuTcH2HVgvAm1tI/069oo2eIVCZy0yB1nWgl2FvUqSVzXKH YUiZEISyC5PK6Y97fLJsqbdGkBHHOU+07mF0RuQs0yhDidhH531HJj5YhX7t9W6x5toE kgl6aTl7nvWSK7wb4wowuDgn5ilq115yXO323D03qFJ5ZNke1TJli8hQ+0x8rLPqzuvr zzeAs50XmxOzvN/nhAJsL1DMA8ud3G5twkuilGSZleK88OGjXz2AMpUfqe5BYSERsG+N qm/w== X-Gm-Message-State: AIVw111guFokXRbYngdw/UN/SgNtZP7CceW8ZAq8xFfsMENL5U/hAM4f A90mXGX55vHeSPrFzk3NFCqqCRXHHqm9 X-Received: by 10.223.139.21 with SMTP id n21mr1911433wra.42.1499958816929; Thu, 13 Jul 2017 08:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.161.27 with HTTP; Thu, 13 Jul 2017 08:13:36 -0700 (PDT) X-Originating-IP: [192.147.168.22] In-Reply-To: References: From: Job Snijders Date: Thu, 13 Jul 2017 17:13:36 +0200 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: jordi.palet@consulintel.es Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:13:40 -0000 On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ wrote: > The link doesn=E2=80=99t work for me, even can=E2=80=99t traceroute to th= e server =E2=80=A6 The problem might be that the server is not reachable over IPv6 Kind regards, Job From nobody Thu Jul 13 08:20:26 2017 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 3EA0C1316F9 for ; Thu, 13 Jul 2017 08:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 0kYrKWypyKeE for ; Thu, 13 Jul 2017 08:20:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646561316F6 for ; Thu, 13 Jul 2017 08:20:23 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6DFKFZB055186 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2017 16:20:15 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <59678FAE.5070903@foobar.org> Date: Thu, 13 Jul 2017 16:20:14 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Job Snijders CC: jordi.palet@consulintel.es, 6man WG Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:20:25 -0000 Job Snijders wrote: > On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ > wrote: >> The link doesn’t work for me, even can’t traceroute to the server … > > The problem might be that the server is not reachable over IPv6 to clarify, the web server host is only available on ipv4. No doubt this is a dns oversight which will be rectified asap. Nick From nobody Thu Jul 13 08:48:15 2017 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 DA9241316D7 for ; Thu, 13 Jul 2017 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 c0XrQIZt5WvT for ; Thu, 13 Jul 2017 08:48:04 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B72124BE8 for ; Thu, 13 Jul 2017 08:48:04 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6DFm0g4058452 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2017 16:48:00 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5967962E.506@foobar.org> Date: Thu, 13 Jul 2017 16:47:58 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Mark Smith CC: Brian E Carpenter , 6man WG Subject: Re: Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing, ) References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:48:07 -0000 Mark, I don't particularly want to get dragged down a rathole on ipv6 architecture philosophy, but regarding what you have written below, IPv6 was a product of its time and its design philosophy suffered from a substantial degree of second system syndrome. A disconcertingly large number of the core design principals have in retrospect proven to be of high cost and of marginal practical value. In some cases, core features have been problematic enough to recommend deprecation; in others, many people are left wanting to deprecate design points but are unable to do so. We are going to need to disagree on a wide range of issues, including most of the things you mention below, none of which is particularly relevant to this discussion except for the issue of generating IIDs, about which: 1. /64 is a statement of policy rather than a constant intrinsic to the protocol. 2. hard-coding semi-arbitrary constants in design specifications is a poor idea at the best of times. 3. even then, IID generation in the cases you are talking about is relevant for host-side address auto-selection protocols, not externally assigned addressing. 4. even then, a hardcoded mask length is objectively unnecessary, as implicitly acknowledged by the existence of the Prefix Length field in the prefix information option in RA. This entire discussion could be concluded with no practical fallout of any form if /64 were specified for SLAAC and the constant were omitted from the addressing architecture specification. Nick Mark Smith wrote: > On 13 July 2017 at 12:05, Brian E Carpenter wrote: >> On 13/07/2017 01:53, Lorenzo Colitti wrote: >>> On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> > > > >> Nick Hilliard just did: >> >>>> I would suggest that future protocols need to define what makes sense >>>> for them, and mandating a constant in advance isn't necessary or even >>>> appropriate. >> Which is why I personally would be happy with the addressing >> architecture either not mentioning 64 at all, or *recommending* 64, >> or requiring 64 "except if the first three bits >> of the address are 000, or when the addresses are manually >> configured, or by exceptions defined in standards track documents." >> >> IMHO any of those three formulations would resolve Nick's problem >> statement (given that there is also a citation of BCP198 in the >> latest draft to clarify how routing works). > > > I think what Nick suggested is the total opposite of what should be > done and I think opposite to one of IPv6's major themes. Forming IIDs > should not be left to link-layer specific protocol specs. > > I think one of the significant differences between IPv4 and IPv6 is > that a number of mechanisms have been made more generic and less > link-layer specific, or have been shifted from out of the link layer. > > Specifically, > > - ND is part of ICMP, rather than being a link-layer specific protocol > a ARP was. > > - ND itself also tries to be as generic as possible, so that it can > operate over all link-types. Link unicast is a given, it expects a > link to emulate multicast if it isn't natively supported. > > - IP and higher layer parameter configuration has been moved out of > PPP to upper layer and generic, non-link-layer specific protocols such > as RAs and DHCPv6. > > > We did have link-layer specific methods to generate IPv6 IIDs for > SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID > generation could be made link-layer agnostic because it was for > convenience rather than necessity. > > Stateful DHCPv6 doesn't do link-layer specific or dependent addressing either. > > Another way to consider what the IPv6 layer/protocol does is that it > abstracts away link-layer differences. As RFC6272 says in its overview > of the Internet Protocol Suite, > > "The Internet layer provides a uniform network abstraction network > that hides the differences between various network technologies. > This is the layer that allows diverse networks such as Ethernet, > 802.15.4, etc. to be combined into a uniform IP network. New network > technologies can be introduced into the IP Protocol Suite by defining > how IP is carried over those technologies, leaving the other layers > of the IPS and applications that use those protocol unchanged." > > > So, with IPv6 abstracting away the link-layer differences, for > consistency, IPv6 addresses are better to be abstract and decoupled > from underlying link-layer characteristics such as the link-layer > address characteristics and values. From nobody Thu Jul 13 08:50:21 2017 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 79CF5129B53 for ; Thu, 13 Jul 2017 08:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 I0h8gaT3Q6RM for ; Thu, 13 Jul 2017 08:50:16 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 3B2B9131453 for ; Thu, 13 Jul 2017 08:50:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6DFoE0O037043 for ; Thu, 13 Jul 2017 17:50:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93ACD2057A6 for ; Thu, 13 Jul 2017 17:50: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 7E03420542D for ; Thu, 13 Jul 2017 17:50:14 +0200 (CEST) Received: from [132.166.84.92] ([132.166.84.92]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6DFoEg9003235 for ; Thu, 13 Jul 2017 17:50:14 +0200 Subject: Re: Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing, ) To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <3efd38bf-33e1-bc56-aa2c-20b9c016f2a2@gmail.com> Date: Thu, 13 Jul 2017 17:50:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:50:20 -0000 A divergence, but just to mention it... Le 13/07/2017 à 07:18, Mark Smith a écrit : [...] > We did have link-layer specific methods to generate IPv6 IIDs for > SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID > generation could be made link-layer agnostic because it was for > convenience rather than necessity. Well, that RFC pair is very ambitious. But it's hard to imagine statements like "this RFC updates RFC1, 2... n" is very easy to do. For example RFC8064 says: > In particular, this document RECOMMENDS that nodes do not generate > stable IIDs with the schemes specified in ... RFC5072 ... However: RFC5072 "ppp IPv6" is still in wide use, and the way it generates a stable IID is by a ConfigReq/Ack negotiation, not by extracting numbers from a local built-in hardcoded address. Depending on how that PPP negotiation happens, on a case-by-case basis, the IID offers some privacy when it is proposed by the terminal and accepted by the network, or no privacy at all when it is proposed by the network and accepted by the terminal. So, it is not obvious how RFC8064 deprecates RFC5072. Alex From nobody Thu Jul 13 09:02:47 2017 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 54C401316E5 for ; Thu, 13 Jul 2017 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 xzygAtPCK7yr for ; Thu, 13 Jul 2017 09:02:44 -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 0172F124BE8 for ; Thu, 13 Jul 2017 09:02:43 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id r125so32637945vkf.1 for ; Thu, 13 Jul 2017 09:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nNpq+2wR9l/iyzmtxLA3w893T/wlf4cbOa5OBMPuEi4=; b=askzp5yhxlnsuYwsqG7869C4M2xiqFOGy2WoooEhxMZtR6gCRAJMmVpzEhKGn2k2s4 tWR/0b8dlBJxS/gsKh+etHAb25qwy4ECz68nft2fgE5xyFZ3pcSVXZtDeRlCNH7m/ahv IOQ2sQdHALRfU+nYYsJuPE+cDvJnhwiMn0/0WoCGTGBqv4pg20K4AFdLjf1oiaaV0zpG bIde18jEIIuo06ADJ7lp5JBPHod6e9a1esyL8q08qVb3Di2VU3fyPp/vpV4lcf4Idyep fv2brLtY2Kz8MYvlrbTdxl0l7t0F27+9+DUAcxJakwgdnoDY7VDWerjj0t+2IF3/E3Zc HU/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nNpq+2wR9l/iyzmtxLA3w893T/wlf4cbOa5OBMPuEi4=; b=OLk23gzFK3W8UJxcLeRk5W96NWP6T+wE4IBgATELfHqpfGr3nmAut5MkJQ/GfhTqUO rsPAD8B9AIvMzNzX1f0D4EHzTuqlPKg9qDUbLPinnGwOTaLSiWoHpOMCFu2P69ip4s31 aotQewTlXkkTULfUM93jd9rck0+q/ItcpLPkB1W1WPoqOkCrhkSPzdgb8xdy7dzUdOuX M0VOjS+mD6Y5tgttBjpMD5i/5a9ow4TNyOlilivDZ7liR309X6nJ7nakPrPsetvLxvMe z/SW4O4tCBFc2jawp3u26hcMiPpTte2eBECS/taPdpme3tYhjjqx4D2BKovUO3inIMfC p9Xw== X-Gm-Message-State: AIVw110VvaKablF0jLS+nWrqImZLzv/B6PHcJA0N2Vs3OWMTzHVGDp3O U5dMBfiLhjO5S6ebI2d4H88fdA4J8TzG X-Received: by 10.31.181.1 with SMTP id e1mr2647934vkf.69.1499961762695; Thu, 13 Jul 2017 09:02:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Thu, 13 Jul 2017 09:02:21 -0700 (PDT) In-Reply-To: <81b2c3d8-f646-f376-2243-270b2e9e3f3d@gmail.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <81b2c3d8-f646-f376-2243-270b2e9e3f3d@gmail.com> From: Lorenzo Colitti Date: Fri, 14 Jul 2017 01:02:21 +0900 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Brian E Carpenter Cc: Mark Smith , "Manfredi, Albert E" , 6man WG Content-Type: multipart/alternative; boundary="001a1143a5700b5baa05543510c1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 16:02:45 -0000 --001a1143a5700b5baa05543510c1 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 13, 2017 at 11:05 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Based on past experience, it seems pretty clear to me that this situation > > will not change until we get a problem statement that we agree on. Care > to > > write one up? > > Nick Hilliard just did: > > >> I would suggest that future protocols need to define what makes sense > >> for them, and mandating a constant in advance isn't necessary or even > >> appropriate. > I said "a problem statement we're likely to agree on". "X isn't necessary or even appropriate" is a heavily subjective statement. The other camp in this discussion finds X very much necessary and appropriate, and the conversation never goes anywhere. You could substitute "X" with "a fixed boundary" or "a variable boundary" and both sentences read perfectly well. An example of a problem statement that is be easier to agree on is "X causes problems A, B, and C, which we would like to solve". --001a1143a5700b5baa05543510c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 13, 2017 at 11:05 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
> Based= on past experience, it seems pretty clear to me that this situation
> will not change until we get a problem statement that we agree on. Car= e to
> write one up?

Nick Hilliard just did:

>> I would suggest that future protocols need to define what makes se= nse
>> for them, and mandating a constant in advance isn't necessary = or even
>> appropriate.

I said "a pr= oblem statement we're likely to agree on".

"X isn't necessary or even appropriate" is a heavily subjec= tive statement. The other camp in this discussion finds X very much necessa= ry and appropriate, and the conversation never goes anywhere. You could sub= stitute "X" with "a fixed boundary" or "a variable= boundary" and both sentences read perfectly well.

An example of a problem statement that is be easier to agree on is &q= uot;X causes problems A, B, and C, which we would like to solve".
--001a1143a5700b5baa05543510c1-- From nobody Thu Jul 13 09:15:23 2017 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 A144612EE8D for ; Thu, 13 Jul 2017 09:15:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Wk_nSyW9LsYU for ; Thu, 13 Jul 2017 09:15:20 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE69124BE8 for ; Thu, 13 Jul 2017 09:15:20 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id r126so32838555vkg.0 for ; Thu, 13 Jul 2017 09:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tT0IRJET1pYcYstYmoVE93HumDiOfoevZbbUUKf7nhw=; b=QMbsLJ4dr5HmZNVAE09Cxz0e6yS3BNPc5KZH9v9wfegHBT3gDT8ixLv4nK152mBBTJ QYFnZ+DxgedgBulHhNRMqLKsRJ1/BTp+Z3jZ0an+fAtDRtKe4lobPaO0qPkMSvStpfo5 8M99zWrY8So0bwUfKFhwGlnHkYYEgBCSrG8KKITClwUMCz4lJHAWyJyzfbPWlm+JWXK/ C3pvz6G+A50+z33QTEsVUpbsxivehIC8dOAx3ikOC6KQ5spMHhi3Lo6D7ApibjPYDRwD 7wPUfh/JY26bn5QncbRjMuQQSthwfWB6YpZqRCibndMgYhoVn7bKAd42hPGVBPAhN5ot UDOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tT0IRJET1pYcYstYmoVE93HumDiOfoevZbbUUKf7nhw=; b=hd0AjMfrLKRjhpshioQnVYJr0Gz46ZDgvZVyz18Oo7KvbtNjeNE5fkv/MFcC5wIJTc OiWbOU0WkjXn2Jp7wfPhzRHkF6YeGMJlieR94Pm06tD2a0q15A06vccLklxqLoDIuH77 WIr9xUzVtolq3h5JQvNjjfd236souwLCoXHbCJ9AtMgMjTnG42DQmrOniiHJwO0fxOsh XuKKYPLJ6/m7gOAz0zm6+xMEfalEOTxL+tp7KgTtsVwwPQ0byXGyLjhEggQao5oJNl2M Ll+ek6zOyzdySjSqIGckBrNDVWSVcxoOk38MN5pNZXCrvqNmwJi7WYDbNte80QAM8Fms v0OA== X-Gm-Message-State: AIVw113xz9YzXGLg38Rytnu/bI5f9TvlZw7/FqjXNGnPtGhsKnE2+Sj1 RUw6ReUXM8GvDPP/stxDqYwhcVokbxtIQEeLuA== X-Received: by 10.31.209.199 with SMTP id i190mr2662499vkg.125.1499962519021; Thu, 13 Jul 2017 09:15:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Thu, 13 Jul 2017 09:14:58 -0700 (PDT) In-Reply-To: <5966968A.7000904@foobar.org> References: <59665806.4060500@foobar.org> <5966968A.7000904@foobar.org> From: Lorenzo Colitti Date: Fri, 14 Jul 2017 01:14:58 +0900 Message-ID: Subject: Re: IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing) To: Nick Hilliard Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Type: multipart/alternative; boundary="001a114e6e18202c730554353d4b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 16:15:22 -0000 --001a114e6e18202c730554353d4b Content-Type: text/plain; charset="UTF-8" On Thu, Jul 13, 2017 at 6:37 AM, Nick Hilliard wrote: > My suggestion is that IID length is not particularly an intrinsic > property of ipv6 addressing, but in practice is the specification of a > default which can be overridden on a per protocol basis, and in the case > of static addressing, actually is overridden. > Did you mean "should" instead of "is"? Because the IID length has been clearly defined as being 64 bits for two decades now. > If the statement is dropped in 4291bis and instead an explicit statement > of the mask length is added to a new revision of rfc4862, then from a > practical point of view, we will be in the same position as before which > is, I believe, what most people are concerned about: that we don't end > up breaking SLAAC or any other existing protocol. > Actually, I think you'll find that the other side of this discussion is mostly concerned about *new* protocols and network types, not existing ones. In practice, we can't really break existing protocols anyway; even if we were to try, implementers would just ignore us. --001a114e6e18202c730554353d4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 13, 2017 at 6:37 AM, Nick Hilliard <nick@foobar.org> w= rote:
My suggestion is= that IID length is not particularly an intrinsic
property of ipv6 addressing, but in practice is the specification of a
default which can be overridden on a per protocol basis, and in the case of static addressing, actually is overridden.

Did you mean "should" instead of "is"? Because t= he IID length has been clearly defined as being 64 bits for two decades now= .
=C2=A0
I= f the statement is dropped in 4291bis and instead an explicit statement
=
of the mask length is added to a new revision of rfc4862, then from a
practical point of view, we will be in the same position as before which is, I believe, what most people are concerned about: that we don't end<= br> up breaking SLAAC or any other existing protocol.

=
Actually, I think you'll find that the other side of this di= scussion is mostly concerned about *new* protocols and network types, not e= xisting ones.

In practice, we can't really= break existing protocols anyway; even if we were to try, implementers woul= d just ignore us.
--001a114e6e18202c730554353d4b-- From nobody Thu Jul 13 09:32:08 2017 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 73AB6131670 for ; Thu, 13 Jul 2017 09:32:06 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0QHQZm5f5vY for ; Thu, 13 Jul 2017 09:32:05 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A499E12FB9C for ; Thu, 13 Jul 2017 09:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1499963521; x=1500568321; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=0OTV/ndiOgEVRY3fIm+L6nEUv GaD622UTzsHYb6c1lI=; b=HHjnsA1nMTs1er3v5f2ffmrKpmo8PBIxLgiPkrfD8 z98qC/xNlPdtaZke46YWV9/Ex6lSDNZvykSS/WjCzUAXn+0L1PvKgf3WgclLmOVF oUZ+b2yFqgfU1w1lahqTV7Q5QNuYO7u57lzJOzzkQJ66wwKyGRFSDr8KeqBBVcsw Ck= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cfOVwx1JcMzfmbr8fT7vA2lCSWcNrjrqS3bGUz4FOMUy3J9TV1LY2Va7TRIN nlxOG8FdauQ8WRK2tHsdKUW7PnOWOqRrrO3qITx6KfnFxO0Com3TB/KXf 0gkTeM5LnNXOqNOBkRfYS1GUy6nvPfWQE1XE9Ns99VcU2wCm0QdylY=; X-MDAV-Processed: mail.consulintel.es, Thu, 13 Jul 2017 18:32:01 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 13 Jul 2017 18:32:01 +0200 Received: from [172.20.10.2] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005474769.msg for ; Thu, 13 Jul 2017 18:32:00 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170713:md50005474769::4OrNC9hLCNE/sIdh:00003WGg X-Return-Path: prvs=136700ef73=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.24.0.170702 Date: Thu, 13 Jul 2017 18:31:52 +0200 Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" From: JORDI PALET MARTINEZ To: 6man WG Message-ID: <3FC5108D-C979-46F2-B27F-EC55034739AC@consulintel.es> Thread-Topic: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 16:32:06 -0000 Not really, it is some IPv4 routing problema. Saludos, Jordi =20 -----Mensaje original----- De: Job Snijders Responder a: Fecha: jueves, 13 de julio de 2017, 17:13 Para: CC: 6man WG Asunto: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunn= elling" On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ wrote: > The link doesn=E2=80=99t work for me, even can=E2=80=99t traceroute t= o the server =E2=80=A6 =20 The problem might be that the server is not reachable over IPv6 =20 Kind regards, =20 Job =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Jul 13 10:36:16 2017 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 0D2C6131732 for ; Thu, 13 Jul 2017 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 zN3ugO19mOqU for ; Thu, 13 Jul 2017 10:36:13 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 6422D13170F for ; Thu, 13 Jul 2017 10:36:13 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 16so56597884qkg.2 for ; Thu, 13 Jul 2017 10:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=44bQS/C+/IoMWEZigrC5p28N6ekoUlKj8kZGNntzL9M=; b=sVS7nQatt1sq1a5RpKCz2esp0r/H7d6EIdvGAe9JyEuiIKvdWt2tALsYqLdGPhtmAG z7KOZ7QtaynM090as8c6x0OJ23s4DpBpbxB8ys9lXo3DquFhEKpkagcJIkhTg+Apge6M vfgm6NkTUUXMoPLqoSwB5NDTiLMlYI/DC/WKFavFznD4QVhsb0A1Q7tCQKYJjyhlDl6O vn5Gxr4Y3W/T/AjKCVZvHDoFJhtYldWBE/yZc2nDA4D9jdwy/RJyPt12OSa/5LwZyhYo LM6FRvBu5WlnwBT5tZId+PmoR/nhpfAmkO/a+X6kRjH5mJ1K3H+m0kk+OIZgiDNVuhWH qCMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=44bQS/C+/IoMWEZigrC5p28N6ekoUlKj8kZGNntzL9M=; b=UTh6X5uOKPYZh5YaEf0p5Vl6hnDXId0A55wYZNsnDDTo4bWHjmIEICkuqnNkHJBpkK /nxo0LtNhZ0ldoPVusdBQ30rGUDA4tc37vqyyMz1mSEHLiIvD6LYyyFzGF39LoJC//Gd ShuQm5VkgeivYL/sGrpNr0/+Gl46Ldoa5e6TmIVHAOIT9GNuDo/q1AeTAvasQyFavQCd +JadLX6vUfbfR7L6hjAt9kGyi+q73tltEPRE9uc3OgRnmAvKGkrIss3cJMAiPx37zfYC Mwa4ppxFfZNrAIHdAUfHPq7l3O4VsKpR93SaYyogmJQAvFc15aHCYL1g67GZEvGcoR7y ZIzg== X-Gm-Message-State: AIVw112kaqhk5nxdnlBleE5zpbrrjhG4ryaQN27QQcWqjTfowJRyiYwj ahaQL4Bp/xx4tIN+Iu6Hq+Nk4SV1Ki8knzw= X-Received: by 10.55.72.81 with SMTP id v78mr6010422qka.133.1499967372413; Thu, 13 Jul 2017 10:36:12 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Thu, 13 Jul 2017 10:36:11 -0700 (PDT) In-Reply-To: <5966968A.7000904@foobar.org> References: <59665806.4060500@foobar.org> <5966968A.7000904@foobar.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 13 Jul 2017 10:36:11 -0700 X-Google-Sender-Auth: zcieCIHozmKLByYUdo2Aw93tAEM Message-ID: Subject: Re: IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing) To: Nick Hilliard Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 17:36:15 -0000 At Wed, 12 Jul 2017 22:37:14 +0100, Nick Hilliard wrote: > > ...(first off, again, it's at least not a matter of rfc4862bis) I > > doubt this suggestion forms a consensus given how badly one "opposing > > camp" wants to keep the hardcoded 64 number in 4291bis. Obviously > > people in the other "opposing camp" aren't happy about this position, > > but in terms of reaching any rough consensus with any possible > > concessions, I suspect it's just not realistic to try to remove it. > > Personally, I hope the other camp can accept this reality and allow the > > 64 to remain in 4291bis as long as any exceptions in the current > > (rather than future possibilities) actual practices are clearly > > admitted (like in the case of manual address configuration). > > If the statement is dropped in 4291bis and instead an explicit statement > of the mask length is added to a new revision of rfc4862, then from a > practical point of view, we will be in the same position as before which > is, I believe, what most people are concerned about: that we don't end > up breaking SLAAC or any other existing protocol. I don't disagree on this observation. But I don't think it a realistic way forward for 4291bis. Unless this update to rfc4862 happens at the same time as 4291bis (which I suspect is quite unlikely), the immediate result is just the complete drop of the magic number from 4291bis. I can't imagine one "camp" will accept it. As someone who is more interested in completing the task of 4291bis so the wg can work on other important matters, it's quite clear that the phase of suggesting something that should be right, clean, modern, ideal, or whatever good in one camp's opinion is now over. The history of this discussion proves it won't lead to any consensus and we'll just waste our time, having each camp repeat their opinions again and again with no indication of listening to the other. In my view the only realistic next step is to figure out what they can at least live with while giving them what they definitely can't live without (as I said in an earlier message I still think this is possible). If those camps are not willing to make this kind of compromise, it's even better to stop the 4219bis work than further time wasting. But I suspect it would hurt more the camp that doesn't like the current 4291 text, since in that case RFC4291 will remain as the status quo. -- JINMEI, Tatuya From nobody Thu Jul 13 11:16:11 2017 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 3D6DD131734 for ; Thu, 13 Jul 2017 11:16:10 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 B3GQPfUItw7M for ; Thu, 13 Jul 2017 11:16:08 -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 B3AE9129B05 for ; Thu, 13 Jul 2017 11:16:08 -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 v6DIG8ih002928; Thu, 13 Jul 2017 11:16:08 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6DIG3NP002884 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 13 Jul 2017 11:16:04 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Jul 2017 11:16:03 -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.1263.000; Thu, 13 Jul 2017 11:16:03 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS+8OVa2oiBiwIAEuVrerXjOp/r6JSC+xg Date: Thu, 13 Jul 2017 18:16:03 +0000 Message-ID: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 18:16:10 -0000 -----Original Message----- From: pch-b7900FA3D@u-1.phicoh.com [mailto:pch-b7900FA3D@u-1.phicoh.com] On= Behalf Of Philip Homburg >> The problem is that over time, way more IP addresses become necessary, >> not just a few more. It's because so many more systems adopt IP, and >> become so much smarter than they used to be. So you need flexibility >> to expand, not just in number of connected devices, but also in the >> architecture of the network. > > Using pseudo-random IIDs comes with the risk of collisions. So you have > to waste lots of bits to get that risk down to an acceptable level. With DHCP, or with static configuration of hosts, you don't have any risk o= f collisions. And the risk of collisions with fewer than 64 bits is not nec= essarily a problem. The risk of collisions with 48 bits should be acceptabl= e too. However, if we continue the self-imposed limit of 64 bit IIDs for SL= AAC, that becomes a non-problem. I'm belaboring here, but if, at the same time, "sites" (again, however that= is defined) are assigned /64s, or /56s, and we continue to insist that IID= s must be 64 bits, then the plain result is that we're back to where we wer= e with IPv4. Expansion becomes a problem. Either you go back and get more a= ddress space, or you use IPv4-like techniques. And to avoid the conclusions= people arrived at last time, I'm talking about using ULAs. Just like it wa= s with private addresses in IPv4. The rationale people give that /48s should be plentiful may be fine. Proble= m is, it becomes irrelevant, if /48s are not handed out. The IETF has no po= lice powers here, so that rationale is not reflecting reality. > However, since the mid 90s we have a protocol for dense allocation of > addresses. Where in the 64-bit IID space you can fit an entire universe. In a flat universe, maybe. No one is disputing that 64 bit IIDs allow for m= any hosts in a single subnet prefix. But we also discovered in the 1980s an= d 1990s how bad it is to create gymongous IP subnets. Bert From nobody Thu Jul 13 14:19:59 2017 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 0F4EE131774 for ; Thu, 13 Jul 2017 14:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 jMdxJZK2Uq7v for ; Thu, 13 Jul 2017 14:19:55 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 08BE8131775 for ; Thu, 13 Jul 2017 14:19:25 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id t70so6223894wmt.0 for ; Thu, 13 Jul 2017 14:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uAqqZr/baLgrrCE5A1Su4B2POL0yDpELneJz13MJt4s=; b=O35xuT1/6j6P44kujNpgFPdKlD24602HIG0ZJEjXnAnacGbadOnG1+lygY7kOLKKHA xFs6ocAtcYxlAm2Vh/5nMmYPA7+HoIjjXQ3kxs9i3zhcmkNWM6xZfRgE6Sjr5t5sBK1b LFHrfiQvGUSLvyBPVeoh2yC+GtIisQ+ItSgvCHsXcDLc3uP8na+/AIGpZ9BmMa2OeMKR dP8bKy5STzUdwAZKFP/GA+vKDjpXCOQVx7x9AMr1vxrIIbcH0ObmeqrMCz56SevvJF1m vYZ/g4q2tsxdwAHEkrkxvajLHXc9ceEx4+Sys0zBb5/c+JC5JvHNXUA5FxiRUZ3ELYWP Achw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uAqqZr/baLgrrCE5A1Su4B2POL0yDpELneJz13MJt4s=; b=ApL0PPitIoBJP1jUT5lEDIWj+YDeGN2nLfUpLDpANeQUfxddonTFtQ1EgmPbr329+h hbWdFu9hgWRuzv6SZ0XNNpLwMnyuPKqxL1epF1od+/ZHI0bw4+tBD4/iQorC+G2v6BmS XE+phFsjAghy/Ds+5cYyMNX7qevVUHkGKuzhnnKmhM7CF2syrBtnSqtkpa4UGERTtZwn gQalubN/i8vosbG9M2B1iUKJmWw6ABaDjkzgVkJ0r1NPSZ9+2GlvjHVRNWPzTEcDCU0J /zOvg1WDAOyCQ61CvcGy24rifZm7Jw1kxkDljIyvFQ7RDTFggpItOz5vYYEF0ETYTyn7 iZKQ== X-Gm-Message-State: AIVw112S4Ty2qa9VcOKgs/maKwaAVaLlGyMhQqKlgMbAF6LRmawMZEwW YXMpERPt+8JIQzabUzWXV97T1I5TX0Z9 X-Received: by 10.28.11.21 with SMTP id 21mr398448wml.105.1499980763470; Thu, 13 Jul 2017 14:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Thu, 13 Jul 2017 14:19:22 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 13 Jul 2017 14:19:22 -0700 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: Mark Smith Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 21:19:58 -0000 On Thu, Jul 13, 2017 at 1:41 AM, Mark Smith wrote: > Hi, > > I've been thinking about this for a while and finally put together a > draft. It's partly the next step on from a draft I wrote a few years > ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in > response to the recent inserting EH's proposals. > Mark, In section "9.1. Skinny IPv6-in-IPv6 EH Construction" I think you need to consider the checksum for protocols that include a pseudo header. Since the IP addresses are being changed in the packet the TCP or UDP checksum should be updated to reflect that in the encap/decap procedures. However, I think the the bigger problem is that when the original addresses are moved to an extension header they would no longer be included in any checksum and so corruption of the EH could ultimately lead to misdelivery. Maybe the EH should include a checksum? Tom > As mentioned, not expecting any discussion at IETF99. > > > Skinny IPv6 in IPv6 Tunnelling > draft-smith-skinny-ipv6-in-ipv6-tunnelling-02 > > Abstract > > This memo proposes a method of tunnelling IPv6 packets inside IPv6 > packets with a reduced tunnelling overhead. > > > http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt > > > Comments and suggestions most welcome. > > Thanks, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jul 13 15:20:16 2017 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 0CF3112F26C for ; Thu, 13 Jul 2017 15:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gs-cOz9NUhK2 for ; Thu, 13 Jul 2017 15:20:14 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 CD9C812F253 for ; Thu, 13 Jul 2017 15:20:13 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id z22so42358730uah.1 for ; Thu, 13 Jul 2017 15:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j27QfNzo57nKzd4S8Q3XZwYqv2wpSTHS18yRNvkovaM=; b=d5h/cIv90UijRJo2KTt0VJ4hMPJEtPUGt9zGJKkskjCRWBKqnPCnQW4gN2kKLBup4O HaPcT+a6hUGUZxeh3LQcNjaNBDwp68OldpbGgpbpex8BTE/WUY5VxT6vSGh6w70nKi+H IYJi8OOJkK7aeyVK5iD7s4ybSDTXwWi8gsAMEwrFyxtzTRLIzN2hAnrHRALU00fIQ8EF sOpaUfBweURmhygJ1VmgbkktCRxAj53AyyioYmOIXF5OrKgHY5raDcKTvMKaxz0L5b1z pPGUIdxMo8+lHgE1Iz2VBg05fEIaqRIpz9PaIyIvjohR4GRAWLAYGF0ozb9tr/pUzmhs 9LJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=j27QfNzo57nKzd4S8Q3XZwYqv2wpSTHS18yRNvkovaM=; b=tU7U0Q/chgjqVE6ciufOR/YeQDcrGSBtOnK6B9C5ED8pgIHuYZ3Ee+O9yzR1JMTLrL 7Clzvj+Ki8BlitkMQyfm+izG9zCtWwTsh5sPyoh2PWsN6mbF32e33654QcL5RMob2ORI vrhVUV6sy2KdGmHdB0EbOTN+dUeAx4sOpmUR9PtYzrNBoMTr7fwnt3eyCrpS/TAuASEo u94SoPGRNrmpTHoltush454bCwdzrOtx+FmcPrsl8qvsiz+l2sDf6JUnIrAovh4Sn9Wi y5IkZzBjXEOdXJ2Ez0mBIfl6rLbG/3xa2BSXY0wAaOZ2i/HVp279xV1TRS67h9YeGcQq 8aWw== X-Gm-Message-State: AIVw112ViCvjin9rb6yTvIk3zy7EUKcAXTj7FlNLQ/L8h9b2GIgy3p5/ Eu8kCQCsKVD8XChLb8VeLTrIn8ZT5Q== X-Received: by 10.176.81.52 with SMTP id e49mr3793732uaa.33.1499984412858; Thu, 13 Jul 2017 15:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 13 Jul 2017 15:19:42 -0700 (PDT) In-Reply-To: <3efd38bf-33e1-bc56-aa2c-20b9c016f2a2@gmail.com> References: <3efd38bf-33e1-bc56-aa2c-20b9c016f2a2@gmail.com> From: Mark Smith Date: Fri, 14 Jul 2017 08:19:42 +1000 Message-ID: Subject: Re: Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing, ) To: Alexandre Petrescu Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 22:20:15 -0000 On 14 July 2017 at 01:50, Alexandre Petrescu wrote: > A divergence, but just to mention it... > > Le 13/07/2017 =C3=A0 07:18, Mark Smith a =C3=A9crit : > [...] >> >> We did have link-layer specific methods to generate IPv6 IIDs for SLAAC, >> however RFC8064/RFC7217 has just deprecated all of them. IID generation >> could be made link-layer agnostic because it was for convenience rather = than >> necessity. > > > Well, that RFC pair is very ambitious. But it's hard to imagine > statements like "this RFC updates RFC1, 2... n" is very easy to do. > > For example RFC8064 says: >> >> In particular, this document RECOMMENDS that nodes do not generate >> stable IIDs with the schemes specified in ... RFC5072 ... > > > However: RFC5072 "ppp IPv6" is still in wide use, and the way it generate= s a > stable IID is by a ConfigReq/Ack negotiation, not by extracting numbers f= rom > a local built-in hardcoded address. > That's because PPP doesn't have a link layer addresses useful for IID formation, so RFC5072 invents a method of generating them. On a (true) point-to-point link there is no functional need for link layer addresses as the only place anything can be sent to is to the other end of the link. PPP itself in RFC1661 doesn't specify link-layer addressing, and PPP in HDLC-like Framing (which from memory is the framing we actually use/used) sets the HDLC destination address to the "All-Stations address" and says that individual addresses aren't assigned. On PPP with HDLC-link framing, there is no frame source address and the destination address is a link-layer broadcast address. It's easy to think that Ethernet links directly between two devices are "point-to-point" links. Physically they may be, however, the ethernet protocol operating over the link is still a multi-access protocol because it supports, assigns and uses individual link-layer addresses. If somebody wanted to squeeze 12 more payload octets out of an ethernet frame on a point-to-point physical link, they could switch the interfaces on both ends into promiscuous mode and use the addressing bytes for what ever they liked (a long time ago I thought this could be where MPLS labels could be put, similar to how in Frame Relay and ATM they reused the DLCI and PVC fields for MPLS label information). > Depending on how that PPP negotiation happens, on a case-by-case basis, t= he > IID offers some privacy when it is proposed by the terminal and accepted = by > the network, or no privacy at all when it is proposed by the network and > accepted by the terminal. > Yes. I've seen your concerns about the 3GPP spec and network forced IIDs, and agree with them. Reflecting on it, it is a perfect example of the security and privacy risks of tightly coupling a link-layer addressing and IPv6 layer IID generation. Functionally there is no issue. Reusing identifiers from different layers can cause security and privacy problems because the security and privacy scope at one layer (e.g., within a single link-layer) can be different to the security and privacy scope at the different layer where the identifier is reused (e.g., across the Internet). Even within a link there can be concerns, because an a multi-access link there can be untrusted parties collecting security and privacy sensitive identifier information. Identifiers really should change across different links, so that the same untrusted party attached to multiple links can't correlate the link-limited identifiers across the links. Changing MAC addresses between different Wifi SSIDs is an example of a mitigation of that risk. > So, it is not obvious how RFC8064 deprecates RFC5072. RFC7217 will work on a link without link-layer addresses. It can use link-layer addresses as one of the value types for the Net_Iface parameter as an interface identifier, however there are 3 other types suggested (Interface Index, Interface Name, Logical Network Service Identity). Link-layer addresses is subtly recommended against, because there is the risk that if the interface module is swapped, the link-layer address can change, and that would stop the address being stable across hardware replacement, one of the goals of RFC7217. Regards, Mark. From nobody Thu Jul 13 16:08:35 2017 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 E820712F092 for ; Thu, 13 Jul 2017 16:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 NeP_aU7QzN46 for ; Thu, 13 Jul 2017 16:08:32 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D2C12ECF0 for ; Thu, 13 Jul 2017 16:08:32 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y70so37963449vky.3 for ; Thu, 13 Jul 2017 16:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oZzPvHQGrT6L0dBxk9QTtDgdEx3EwJs4zGkKmo21OPg=; b=FtvDAeJUsg+Qk41i4ZD1DZc9RhoSS5/kWL9uLgMZuP3PKYipGQFv7nBHqLz5r28Wtm qMXZCvoMbFo7+pnYxTgSQirJEo1uhRgDWzRDDIxwkbTLB8SM2TkZIR+shIL+W0Y4Fh36 DiLYuw1+X22b4Jn0z6TTPWL2kvg2AAm+DUxPRy+x2nNy6WVLMnfB7ctrj2W5GDf/DosE mCVmVK4zppx1Z8xLN8Urb6Al3oySEF81Kg+PgFF9Dae82faeZAJzl80511nV2L/WsEXc O4+LcTh/xyRoYtkbdiDUIVcHSWpNuklglauRQNtXAvvL+MmfY/vCr38P8Krm8gODR8Cx OyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oZzPvHQGrT6L0dBxk9QTtDgdEx3EwJs4zGkKmo21OPg=; b=jAxgRuE0A2hDp8znPK99Tc2hNzv5ob/RIJiILhNHm1wiJ5CmUbxBanZIdHnMPJ3/+e HRvEQZdqKPQurlCpGm+T+Bh7oHorMRVbXpCVE6JKj3ZCAAQ/r6NPyfBUijVZ/I+Vorud JQ0kqJExI3U24FOlx2UMs2eu1fV7NpSl1P5Xov8l0at282lHl85Q+iR4d+bk9on6KSM2 xk7D4IdusyAFY8QFMuAxjMPvu1O3VrIPwtOsNtaQ+2HvkXUHUrWytqc2h/1vwPBQL+Go wB5+Zz4PU1lZVS62/iBYoJHfhZWseGL7VW/LwFyypCxCNjvfYalP3zS0TtAb8jonNTvi Aiiw== X-Gm-Message-State: AIVw110e0ACA9lkk4mxRUmENs+YI4URGrG//IUkvuNuSA/SBcY4PMwj2 ujPrP/nHFJjKAD7FrfmMhr2S9egiNosT X-Received: by 10.31.173.214 with SMTP id w205mr3218458vke.8.1499987310283; Thu, 13 Jul 2017 16:08:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 13 Jul 2017 16:07:59 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Fri, 14 Jul 2017 09:07:59 +1000 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: Tom Herbert Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 23:08:34 -0000 Hi Tom, Thanks very much for having a look and providing feedback. On 14 July 2017 at 07:19, Tom Herbert wrote: > On Thu, Jul 13, 2017 at 1:41 AM, Mark Smith wrote: >> Hi, >> >> I've been thinking about this for a while and finally put together a >> draft. It's partly the next step on from a draft I wrote a few years >> ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in >> response to the recent inserting EH's proposals. >> > Mark, > > In section "9.1. Skinny IPv6-in-IPv6 EH Construction" I think you need > to consider the checksum for protocols that include a pseudo header. > Since the IP addresses are being changed in the packet the TCP or UDP > checksum should be updated to reflect that in the encap/decap > procedures. I don't think they need to be, as the TCP or UDP checksum isn't evaluated by any device while the inner packet is being carried over the Skinny IPv6-in-IPv6 tunnel. When the reconstructed inner packet arrives at the final destination where the TCP or UDP checksum is evaluated, it will be post Skinny IPv6-in-IPv6 decapsulation, and therefore any Skinny IPv6-in-IPv6 related addressing changes that would have caused the TCP or UDP checksum to be invalid should have been completely reversed. >However, I think the the bigger problem is that when the > original addresses are moved to an extension header they would no > longer be included in any checksum and so corruption of the EH could > ultimately lead to misdelivery. Maybe the EH should include a > checksum? I think that same risk exists with vanilla IPv6 packets, since there is no IPv6 Header Checksum, as there was in IPv4. >From memory, I understand from Christian's "IPv6 - The New Internet Protocol" book (really good for lots of the reasons why IPv6 is the way it is), that it was decided the risks of delivery to the wrong node were worth it compared to the performance gains of not evaluating a per-hop IPv6 header checksum. Protection against corruption over a link is provided by a link-layer checksum, and as this was the reason why the UDP checksum became mandatory, end-to-end TCP, UDP etc. checksums protect against corruption inside devices like routers. So delivery to the wrong node is possible, however that node will ignore it because TCP, UDP etc. checksum will fail. Skinny IPv6-in-IPv6 is using IPv6 as a virtual link-layer, so it could be argued this should have a link-layer checksum, however there will be real link-layers underneath with checksums, so a checksum in Skinny IPv6-in-IPv6 is probably not necessary. I'm not against including a checksum if useful and know that GRE does have that option. I'm not sure how often the GRE checksum option is used, although I haven't heard of it being used and I'm around people who might. A search for "GRE checksum" only finds one link on the first page of the search results that is related to operationally enabling it, and the person answering the question also says in their experience it isn't commonly used. I'll look to include some of the above comments in the draft as they sound like they could be common queries. Thanks again for having a look. Regards, Mark. From nobody Thu Jul 13 16:31:51 2017 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 AEBBF13173D for ; Thu, 13 Jul 2017 16:31:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 x_i4YtIzhJZC for ; Thu, 13 Jul 2017 16:31:49 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 3B227129A97 for ; Thu, 13 Jul 2017 16:31:49 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id u62so36595602pgb.3 for ; Thu, 13 Jul 2017 16:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RPaprlcXNdPw4HbVJTYgXtU9tE3MhBXyN1SsTYaCtI0=; b=T7Noeoh1P9o9dkvHkYCNb6nI/IgK/pvH12KcDgE1aNKkugxm59rtf7Jih7lW2zI8Id YH9b/bGiZBgTGZJudbphGOEKwDHN40mMGglFJvssOcC2ho61AvUKDfO1YDS+E0fzS2IA tOpNtYSWWszJ80T4PUHoQwa3uRpxb21IPaRiMbFS5cMndkLFUDbAIwyYmXYDX8/mFSWV RQTslpn9jlKEZDBSrSQkCMcxHZT4CByU2eUANidX45edHiTl/uM/xo+9bt+8CRbxap9v XZljRh3297XDA+AV+sldm411ezLLWXVLjtTLVS5Ktn00WaSai+NER/2ksna27NpceV+9 KvjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RPaprlcXNdPw4HbVJTYgXtU9tE3MhBXyN1SsTYaCtI0=; b=idefNVatQgmiaYCMyo/N6DDm7L7Hi2I3nuq7AJdnwbikUPphLnXhshoNgvI0luZ26f 5fKGCOP/sfsows0YcnFogxlYLtBqy6tp3CaX5ZuIHrpwMmnEtSStC7PHZ7h3BowTMNn3 +TK2K6/sRwAfpZ5SwNoODWiRvP2x5+GRiGo4RximcZTRShUujCeFEq1hIJwyc0mXMYQd t4XHMkvs+5ZMGUiyoahheMOyxT1IrWCO6YqZojmZgmdUhN5oZoFqL3ruVD5p1Jefepme 9hS22nn2UvVBP7C9SGyD6G21IoJCYtjIVhAhbvd59lrJEvkONP2DQn0xT7Ck+EDgOjBQ P+2w== X-Gm-Message-State: AIVw112fHGNIfvscsYGvdkQFQpiE54e+2w39txifPI3bZCvzB7lnH6Aw lV84LQ1E3J15BY5hPjA= X-Received: by 10.98.133.16 with SMTP id u16mr2097617pfd.140.1499988708420; Thu, 13 Jul 2017 16:31:48 -0700 (PDT) Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w87sm13765665pfk.100.2017.07.13.16.31.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 16:31:47 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Philip Homburg , ipv6@ietf.org References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Jul 2017 11:31:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 23:31:51 -0000 On 13/07/2017 22:33, Philip Homburg wrote: >> The problem is that over time, way more IP addresses become necessary, not just a >> few more. It's because so many more systems adopt IP, and become so much smarter >> than they used to be. So you need flexibility to expand, not just in number of c >> onnected devices, but also in the architecture of the network. > > Using pseudo-random IIDs comes with the risk of collisions. So you have to waste > lots of bits to get that risk down to an acceptable level. This is backwards. The goals of pseudo-random IIDs are to reduce the probability that scanning attacks find hosts, and to reduce the risk of IIDs being used to breach privacy. If these goals are met, the collision probability will in any case be low, so DAD failure will be exceedingly rare. > It is a really bad > trade-off if your ability to expand the network comes at the price of increased > risk of collision. That seems completely theoretical for any IID length that would be acceptable under the above goals. If there's a significant risk of collision, the IID is too short to protect against scanning attacks or address-based surveillance, so is unacceptable anyway. Brian From nobody Thu Jul 13 16:48:53 2017 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 6E17712EC0C for ; Thu, 13 Jul 2017 16:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1h_LBatnanAD for ; Thu, 13 Jul 2017 16:48:50 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB5312EC05 for ; Thu, 13 Jul 2017 16:48:50 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q86so36586999pfl.3 for ; Thu, 13 Jul 2017 16:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NqmXzCd7NUcCnSFzr+X9uNu0YXQgu1i9bzBxIbNxIbE=; b=Lf4A8+a1X31HWxIWUZChWuIxRBUen7605j7xOdHDHbCMCXHBZb6iYEb+q/hIk3cC13 95CX50MLBNWMRRzccJnmaEATgrsQU9IDLLiKTGtkqsWRySp3N78cyJ1SyxY87kbIu9g3 r6UCR7WRhsDbAC4Lv+mbTDmQRVZCNfEpNFonjO5mHqn6rS6q8hSgVr7hpBqJUpnoqwlN A47IMLwofM/oSILtHqWwKIzPTzoaAjHBDQKi1+GqGHAhEa32CHtcwasv6zuYlH4MdaIX HJWVNO22R+gB0urlYqsPP08QpnULiTn+6UdF0hqWHs/Ndf9hGMjcSUWHioHGTGnKByDL GKcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NqmXzCd7NUcCnSFzr+X9uNu0YXQgu1i9bzBxIbNxIbE=; b=BQFQPHaGgITGpOLjvKvCtSwtqGR2dh+YK130X3m/jmFZOEFTTUu5gp8/QFJoxXay6V kGltqmcXvi+KvhxK6x+Y+7DARmf2tn9VkadVM4OJ76sonB7rhKTeYaZyfT4mnkFbvH8j zJU2iT7wUvLhWbr0tXDxEhjnTdGTvVml6Pa8bwbo+lrWsCDFNfNr/QmnX6kV8agI9PAj JWOrgpAToPpX2bLKzVTF6mjZg2OnhLXTOnL+w0ua91115FrzjeFioBnKrMRPnbOxryWy eO/TP6XOy+I9DX3P9LnSrZw3WuWBVEjgVg5YPkTMjUcj+codYccOKV7M6T2DZXM+/FSD N1gw== X-Gm-Message-State: AIVw111tZNiif4fbFC6c5QnK2qp7rzj4V9zmulo+skwOwtaOZg5vdBZW ABTRrQc8gL4Ndu8qj5c= X-Received: by 10.98.199.26 with SMTP id w26mr2133149pfg.233.1499989730012; Thu, 13 Jul 2017 16:48:50 -0700 (PDT) Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o84sm17775908pfj.109.2017.07.13.16.48.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 16:48:49 -0700 (PDT) Subject: Re: Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing,) To: Mark Smith Cc: Lorenzo Colitti , "Manfredi, Albert E" , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Jul 2017 11:48:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 23:48:52 -0000 Mark, On 13/07/2017 17:18, Mark Smith wrote: > On 13 July 2017 at 12:05, Brian E Carpenter wrote: >> On 13/07/2017 01:53, Lorenzo Colitti wrote: >>> On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> > > > >> Nick Hilliard just did: >> >>>> I would suggest that future protocols need to define what makes sense >>>> for them, and mandating a constant in advance isn't necessary or even >>>> appropriate. >> >> Which is why I personally would be happy with the addressing >> architecture either not mentioning 64 at all, or *recommending* 64, >> or requiring 64 "except if the first three bits >> of the address are 000, or when the addresses are manually >> configured, or by exceptions defined in standards track documents." >> >> IMHO any of those three formulations would resolve Nick's problem >> statement (given that there is also a citation of BCP198 in the >> latest draft to clarify how routing works). > > > I think what Nick suggested is the total opposite of what should be > done and I think opposite to one of IPv6's major themes. Forming IIDs > should not be left to link-layer specific protocol specs. Unfortunately it always has been that way. True, you can argue that it's a mistaken holdover from Xerox PUP via Novell IPX. You can argue that we wouldn't design it that way today. However, it's hard to squeeze the toothpaste back in the tube. RFC7217, which is applicable to all link types, is not bound exclusively to 64. Neither is RFC8064, nor SLAAC. They all treat 64 as an externally defined parameter. Brian From nobody Thu Jul 13 17:46:38 2017 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 43791126B72 for ; Thu, 13 Jul 2017 17:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FFh9bor5qo82 for ; Thu, 13 Jul 2017 17:46:36 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 04454131788 for ; Thu, 13 Jul 2017 17:46:35 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id z22so43740356uah.1 for ; Thu, 13 Jul 2017 17:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6yeryq85Bm2/bQ1gNHgGl0vuuSeXM9WXK47N7pWSWzo=; b=a5RAe/mOKJafVdCSdtx6ZIvN9gQwCjGC3twnqg/ytmHxvveKTHTtwG+BRiFCX5lo+w EIDj5BTsMIg0v76JZyCRKMVZbSPQE2PqNWe/Qo5AR88wAWHAHqZP6pIBF3IRT5vxRTCq SsPJx8w69kaxQFMYB7ugIBkv/ao4Z65kPbHYtYqe9Ld1Sg4zfPOMm+uBPpCgkrNoRa9+ I3HXCrf2d0Wp+86QVByFJ/vKh6YsGaS47GhBra9erR+xaDvb801pa2rTVdM/8B/tNAYP GXvqs+CyDh6NYOx7Qokz85AJJ8w7oIpsqnV511+eOb68qzkulwr0YhocyYO8sx/uXDCy BBqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6yeryq85Bm2/bQ1gNHgGl0vuuSeXM9WXK47N7pWSWzo=; b=tVKy1CN0hUHxQWPDQweK2IaIvslB8Z8SAf0i8s1tV3ys0/DoLM1z8Mgo/HNTloEzT/ VjmKKbNIxpyhL8OCYAjfW61nnB46Fmr9l0y1SD0MwuM0UZBdTiMRqfkBDew0FSVSiFQ4 FN7kcfr6An89puUC4zag75hPcmlrCH0LDp7VpLGm8vxM7ZUkUkRYwcMdeiN/I7C/Hyqd anX2oNz8zkiGx77DP/OTvjDLDVi2eCGDcIrGvKUdydDZBWijSHEpXqqoUlMWqwf5i5gy elpwqiUFls7bFNBQrCXNzIc2SeJX5b3WhMNsTYxAQg7CN+TdDMa/QHi8dXNcCdijriwy 9V0w== X-Gm-Message-State: AIVw11152IA47mIlKLAxbCFK6tOy1+lMhGQj5CmM6YFcA0yhf4vV3xAC tKHvmLaN0JBcbREe8GEAabdPfaWJXA== X-Received: by 10.176.65.130 with SMTP id 2mr3713682uap.83.1499993194113; Thu, 13 Jul 2017 17:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 13 Jul 2017 17:46:03 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Fri, 14 Jul 2017 10:46:03 +1000 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: Tom Herbert Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 00:46:37 -0000 Hi Tom, On 14 July 2017 at 07:19, Tom Herbert wrote: > On Thu, Jul 13, 2017 at 1:41 AM, Mark Smith wrote: >> Hi, >> >> I've been thinking about this for a while and finally put together a >> draft. It's partly the next step on from a draft I wrote a few years >> ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in >> response to the recent inserting EH's proposals. >> > Mark, > > In section "9.1. Skinny IPv6-in-IPv6 EH Construction" I think you need > to consider the checksum for protocols that include a pseudo header. > Since the IP addresses are being changed in the packet the TCP or UDP > checksum should be updated to reflect that in the encap/decap > procedures. I've just realised that you might have been talking about middleboxes validating the TCP or UDP checksum while the inner packet is Skinny IPv6-in-IPv6 encapsulated. Yes, that would fail. My expectation of the common use case for Skinny IPv6-in-IPv6 is limited to within middle box free closed networks e.g., the SPRING situation rather than over the Internet where middle boxes might be encountered. EHs seem to be being commonly dropped on the Internet anyway, so a new one like a Skinny IPv6-in-IPv6 EH is unlikely to be very usable over the Internet. I'll put some text in about that limitation and propose the use of am optional UDP header in front of the Skinny IPv6-in-IPv6 EH to trick middle boxes into letting it through. Shame to do that because of the additional UDP overhead. At least the inner packet IID entropy in the outer packet SA and DA would still be a benefit in that case where existing IPv6 routers don't use Flow Labels for load balancing. Thanks, Mark. From nobody Fri Jul 14 09:01:29 2017 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 9DAF6128961 for ; Fri, 14 Jul 2017 09:01:27 -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=herbertland-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 H8-SRL2nCCxW for ; Fri, 14 Jul 2017 09:01:26 -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 123C9127ABE for ; Fri, 14 Jul 2017 09:01:25 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f67so26955673wmh.1 for ; Fri, 14 Jul 2017 09:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mN8bhz9py9+QEdpidNuLAtEqM2TkkEe0BgnswW4rdTo=; b=x8V5+WxG+0S6SFu+KFTHrB+1XaWvW7UA7QzpU/z1QnpvcdCj10L43vFaesWg1vmzC6 QGtsBPBwGyy3JxvespwvRFnAd51DNeT95+w/5FF6/hVFUX34pFZ790BsTLv+9e8XwC0r Dikia7utpaJgMjKAHGbWetIq1yh6dkYCgolFVwknEjY97FaKIrDSSIdbNl6D0CgJwAx8 r4MkgLMd18Zdq4MU8gstammKdewyWf/ACIjPV/nhvEV6OhWta9EAQETle7+BPxH+9/gA IeRmzhHB+MisjfEvN3GL5A0LxSOremLcWmgZcmTXHL3rHKRB4MVpjTDkzjc7L9Uc96t3 IpEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mN8bhz9py9+QEdpidNuLAtEqM2TkkEe0BgnswW4rdTo=; b=f/EEGhbmB8+ASAZzrVcyj/CFT1WwxnJ8Y+t566kHe4m0/O9O7jzoIEdkNhdYW/pmGn 79X0kV+GuCl4JLhgxgKf7QDOloN3sr9LkSVnqQJnnO00mO+HL5CL/caiMZwd5U/Y8ZLI 1EKbNMqjN9A+9W07L9hvLjYOr7MKcHyx0U6IWQ4gXSNvL80kD8rv9L+824qWxYystb8U sQ7dAnwAiSiOkh2J082XcOs/D5Jc+YmocQ+1TpaTbvZQrd6t0UrBF/poVGb/2R2WtX67 nw0Ge/Sq8O7P31W2mFvdDecRcUpr4Mnx8g/M6SlOMcru0vFf8edgBxR7ZmQMxTKQQ7Je B5mA== X-Gm-Message-State: AIVw113yK0tIAlcaDPKAQgpNY6wkYXcYaArPo2fDgBBH9Pua9t7JeY6W Vm7j0tYC0Bz3cLY+gcWJNGBzTbz+168o X-Received: by 10.28.149.209 with SMTP id x200mr3136665wmd.91.1500048084235; Fri, 14 Jul 2017 09:01:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Fri, 14 Jul 2017 09:01:22 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Fri, 14 Jul 2017 09:01:22 -0700 Message-ID: Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling" To: Mark Smith Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 16:01:28 -0000 On Thu, Jul 13, 2017 at 5:46 PM, Mark Smith wrote: > Hi Tom, > > On 14 July 2017 at 07:19, Tom Herbert wrote: >> On Thu, Jul 13, 2017 at 1:41 AM, Mark Smith wrote: >>> Hi, >>> >>> I've been thinking about this for a while and finally put together a >>> draft. It's partly the next step on from a draft I wrote a few years >>> ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in >>> response to the recent inserting EH's proposals. >>> >> Mark, >> >> In section "9.1. Skinny IPv6-in-IPv6 EH Construction" I think you need >> to consider the checksum for protocols that include a pseudo header. >> Since the IP addresses are being changed in the packet the TCP or UDP >> checksum should be updated to reflect that in the encap/decap >> procedures. > > I've just realised that you might have been talking about middleboxes > validating the TCP or UDP checksum while the inner packet is Skinny > IPv6-in-IPv6 encapsulated. Yes, that would fail. > > My expectation of the common use case for Skinny IPv6-in-IPv6 is > limited to within middle box free closed networks e.g., the SPRING > situation rather than over the Internet where middle boxes might be > encountered. > Every NIC performs checksum offload, if a host is both an outer and inner destination then there's a pretty good chance we lose that and so the cost is much greater compared to processing an eight byte UDP header. Also, there's a good chance we lose GSO. This is why UDP encapsulation is so popular, it can be used to make an encapsulation work transparently with any encapsulation format. That being said, defining Skinny as an extension header should work out fine in this respect. This would be amenable for use with GUE which gives the UDP encapsulation, a checksum that could cover the Skinny IP addresses, remote checksum offload, etc. With regards to SPRING, it would be good to have a better description of the problem their facing. AFAICT, the SPRING EH use could be quite large anyway so the need to jump through these hoops to just save a few bytes of an additional IP header isn't obvious to me. Tom From nobody Fri Jul 14 10:37:49 2017 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 280C513147F; Fri, 14 Jul 2017 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 KtzN6pOLOdAV; Fri, 14 Jul 2017 10:37:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D830613146D; Fri, 14 Jul 2017 10:37:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 59DAAB80D35; Fri, 14 Jul 2017 10:37:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: STD 86, RFC 8200 on Internet Protocol, Version 6 (IPv6) Specification X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipv6@ietf.org Message-Id: <20170714173743.59DAAB80D35@rfc-editor.org> Date: Fri, 14 Jul 2017 10:37:43 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 17:37:48 -0000 A new Request for Comments is now available in online RFC libraries. STD 86 RFC 8200 Title: Internet Protocol, Version 6 (IPv6) Specification Author: S. Deering, R. Hinden Status: Standards Track Stream: IETF Date: July 2017 Mailbox: bob.hinden@gmail.com Pages: 42 Characters: 93658 Obsoletes: RFC 2460 See Also: STD 86 I-D Tag: draft-ietf-6man-rfc2460bis-13.txt URL: https://www.rfc-editor.org/info/rfc8200 DOI: 10.17487/RFC8200 This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jul 14 10:38:17 2017 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 2532213146D; Fri, 14 Jul 2017 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 UXKZro3wTMy2; Fri, 14 Jul 2017 10:38:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE98131600; Fri, 14 Jul 2017 10:38:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0702BB80D46; Fri, 14 Jul 2017 10:37:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: STD 87, RFC 8201 on Path MTU Discovery for IP version 6 X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipv6@ietf.org Message-Id: <20170714173757.0702BB80D46@rfc-editor.org> Date: Fri, 14 Jul 2017 10:37:57 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 17:38:04 -0000 A new Request for Comments is now available in online RFC libraries. STD 87 RFC 8201 Title: Path MTU Discovery for IP version 6 Author: J. McCann, S. Deering, J. Mogul, R. Hinden, Ed. Status: Standards Track Stream: IETF Date: July 2017 Mailbox: bob.hinden@gmail.com Pages: 19 Characters: 42751 Obsoletes: RFC 1981 See Also: STD 87 I-D Tag: draft-ietf-6man-rfc1981bis-08.txt URL: https://www.rfc-editor.org/info/rfc8201 DOI: 10.17487/RFC8201 This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jul 14 12:23:25 2017 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 37922131457 for ; Fri, 14 Jul 2017 12:23:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fWKGMIKK4tPi for ; Fri, 14 Jul 2017 12:23:21 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 9E1B113173F for ; Fri, 14 Jul 2017 12:23:20 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id u110so7101531wrb.0 for ; Fri, 14 Jul 2017 12:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=FH7YjC1P19jd6kjdthtBj2YdUwMrFfQhljIoHIy5SC8=; b=XDRhPLWvCRct4wHSF7uRpFFRqTnA4dIUSTLNPUtepAwpyatGcG8zFNm8wir6WP+el3 wdWhI4u36FfGWAYUeUwToq9AGyO0oBWSIXKPPv07MK0qDAr7iechLzAxWrOkezlRUl2s DuuZIZeqKBKEIxZ8OZOaEaF50cM3duZVlX0wF6yccuaBr6zc/KMFfWFmAnCQ6zlUw8zA ouUyNWOVNv4hE7iSAhyRLIRRCo5wNnEhszhAMgHeaTNxEiLlY1DaapnoYVF/6vNVsXkH 0MnbZfQ8iZiYZ3oNPjmnBrGDM69ahcBNM+N0a7RZpHGhYz6kkRX9SKH/j7S4IL7sb24t seFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=FH7YjC1P19jd6kjdthtBj2YdUwMrFfQhljIoHIy5SC8=; b=ILgiDdeMR2LrYGGJCuv4VsogUnzYUNggzCiZUgxqSTgJQ3qBZVu/v97KkPySimsYT3 tZEunZm6xtTLtIwn6WSQViqduyu7Iv8SYtQh069bjKBIYL/l6N0sb5OGkEGN8igJyGrA 5yG31XKgwXDfnXX69yKphxSJ1iRX4VLE4LuvS8gyuSwNXsLIJIJhDV4C9FswLvV0Ulyw qKP/zI46UOGwWtzHCEybookfCzNqQqT+SSAguWXTzprKvfU5rVw+X6cSIVLNcqunatza lk9ap7tyB5RHLe2xQ7ESE3aMbd0qqjZGJsnyB3h7o8P3BkZ/1j6/xWh5zf7EAALlSNhx osDA== X-Gm-Message-State: AIVw1131/6xi0XnCWx7QPqfz18IduzkjgffTZ0gpXcFZoE7iqvT6GjUI ywB1Iz3S60sJLS/qWeg= X-Received: by 10.223.150.27 with SMTP id b27mr6362694wra.67.1500060198799; Fri, 14 Jul 2017 12:23:18 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:ac27:fffb:924e:60be? ([2001:67c:1232:144:ac27:fffb:924e:60be]) by smtp.gmail.com with ESMTPSA id n189sm3483008wmd.0.2017.07.14.12.23.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 12:23:17 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_478F1D6D-6CF4-421D-A232-9BC84CF61245"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: STD 88, RFC 3596 on DNS Extensions to Support IP Version 6 Message-Id: References: <20170714174124.BA5F6B80D56@rfc-editor.org> To: IPv6 List Date: Fri, 14 Jul 2017 21:23:16 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:23:23 -0000 --Apple-Mail=_478F1D6D-6CF4-421D-A232-9BC84CF61245 Content-Type: multipart/alternative; boundary="Apple-Mail=_2FA1F0A8-51C8-42AF-843A-E26F27BF9AAC" --Apple-Mail=_2FA1F0A8-51C8-42AF-843A-E26F27BF9AAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: >=20 > From: rfc-editor@rfc-editor.org > Subject: STD 88, RFC 3596 on DNS Extensions to Support IP Version 6 > Date: July 14, 2017 at 7:41:24 PM GMT+2 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, dnsext@ietf.org, = rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org >=20 > RFC 3596 has been elevated to Internet Standard. >=20 > STD 88 > RFC 3596 >=20 > Title: DNS Extensions to Support IP Version 6 > Author: S. Thomson, > C. Huitema, > V. Ksinant, > M. Souissi > Status: Standards Track > Stream: IETF > Date: October 2003 > Pages: 8 > Characters: 14093 > Obsoletes: RFC 3152, RFC 1886 > See Also: STD 88 >=20 > I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt >=20 > URL: https://www.rfc-editor.org/info/rfc3596 >=20 > DOI: 10.17487/RFC3596 >=20 > This document defines the changes that need to be made to the Domain = Name System (DNS) to support hosts running IP version 6 (IPv6). The = changes include a resource record type to store an IPv6 address, a = domain to support lookups based on an IPv6 address, and updated = definitions of existing query types that return Internet addresses as = part of additional section processing. The extensions are designed to = be compatible with existing applications and, in particular, DNS = implementations themselves. >=20 > This document is a product of the DNS Extensions Working Group of the = IETF. >=20 > This is now an Internet Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the > standardization state and status of this protocol. Distribution of = this > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 --Apple-Mail=_2FA1F0A8-51C8-42AF-843A-E26F27BF9AAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

Begin forwarded message:

From: = rfc-editor@rfc-editor.org
Subject: = STD 88, RFC 3596 = on DNS Extensions to Support IP Version 6
Date: = July 14, 2017 at 7:41:24 PM = GMT+2
To: = ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, dnsext@ietf.org, rfc-editor@rfc-editor.org
Reply-To: = ietf@ietf.org

RFC 3596 has been elevated to = Internet Standard.

=        STD 88 =        
=        RFC 3596

       Title: =      DNS Extensions to Support IP Version 6
       Author: =     S. Thomson,
=             &n= bsp;      C. Huitema,
=             &n= bsp;      V. Ksinant,
=             &n= bsp;      M. Souissi
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       October 2003
=        Pages: =      8
=        Characters: 14093
=        Obsoletes:  RFC 3152, = RFC 1886
       See = Also:   STD 88

=        I-D Tag: =    draft-ietf-dnsext-rfc1886bis-03.txt

       URL: =        https://www.rfc-editor.org/info/rfc3596

       DOI: =        10.17487/RFC3596

This document defines the changes that need to = be made to the Domain Name System (DNS) to support hosts running IP = version 6 (IPv6).  The changes include a resource record type to = store an IPv6 address, a domain to support lookups based on an IPv6 = address, and updated definitions of existing query types that return = Internet addresses as part of additional section processing.  The = extensions are designed to be compatible with existing applications and, = in particular, DNS implementations themselves.

This document is a product of the DNS Extensions Working = Group of the IETF.

This is now an Internet = Standard.

STANDARDS TRACK: This document = specifies an Internet Standards Track
protocol for the = Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition = of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. =  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce = and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC


= --Apple-Mail=_2FA1F0A8-51C8-42AF-843A-E26F27BF9AAC-- --Apple-Mail=_478F1D6D-6CF4-421D-A232-9BC84CF61245 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZaRokAAoJEK7rdBF357uomeUIAIomK1hixzdRZxqs4kEc9XPw Zs6XuezFB0eYvSbqZRezpbIxTel9BZ6oOydo6DxhGWbRG0jBXkFf4APCcqxUxmiD f9xpFASVThxb7IquhUm0rn5CCOQzszhef9A53sIFR9HK3ePWjKvDaCke0AS+4037 GLCG5alFbnTmeOut/pbp80QAl8h53ocwZENZUd3tjWYjmetiAFEZHHcobTmMH7An hrEFRG6hr9KE7PEQ7lNZ62JveFnAPuqKSkN7l6JBdwL1lZwi5idBGtbRmBftTVmf mabXCQh6TMwuc8w/l5SCZlJlcxhS1HktgGzselCRabwBCxv7pfgAgZWs/Srh0qY= =m4J5 -----END PGP SIGNATURE----- --Apple-Mail=_478F1D6D-6CF4-421D-A232-9BC84CF61245-- From nobody Fri Jul 14 12:24:21 2017 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 CC75A13175F for ; Fri, 14 Jul 2017 12:24:19 -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 z6PjNkHXarUw for ; Fri, 14 Jul 2017 12:24:18 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 D1003131822 for ; Fri, 14 Jul 2017 12:24:17 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i127so31604167wma.0 for ; Fri, 14 Jul 2017 12:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=m5YmMTdrHqMe8GaWh+SL/hH0CaOq98jsVAejLFmLNko=; b=Y5tlT9Ix4qQDITgOKhAFUWNU10PoQqnYeZNxggyGy5QarcqthgX4bPA92VjBXmBlI2 T+SfufWqRfteFqn9pO0duzQ7puhuHu3B20G+RYNX32wOjWZV6o/RqDQv5KCQQiOBoL5R Ggugu60uHHlZT8zxM+PxCOqYTQnLRarNQK1mnSrO5ZJqny09f0NcFEYXdzJ9PhltakL9 eafvhhpHT9rTCUVmVQsVOPKNd99snuKzyeZMAEGFAqE81eI7Ac5S2mX2MSw8mNmZ+RfE eCI+TJq13z8neCZ3vyrZ1X2dQr5KPLVoEIiz1LZQegB7d81Af5qRzcGXlu32AO4GxhQ7 QUiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=m5YmMTdrHqMe8GaWh+SL/hH0CaOq98jsVAejLFmLNko=; b=taEglKihkzE/zC+N+oJuP3cK4qICz08pnuU5m0jbY17X4r1ZpGwQ6weJj1KegzNsm3 mXm40Ly2FQjXWwZJsKZlY9nGq+g6uPDld80ddElH5zKix2GTMa/q8yp/Mkw1d+hIyeUw iuD09uV4nPLpmlJnRrSyHQQubi4u2NX5ot7vttXrSZazYXSWzQEiH1HZjbS+/6piDBMU LluRsFPXREjgBreV6PwEZ6Sd5D1wzdqoocwh9E4DFkJFdvMc7uf08PJOqXEbJSeAMTgu TXfm0BxFUGwCrRqKoeF1lR3gKwrF6KcOhQKSArjlBujwy6tSXo853qLNtvFEcVrfVb5t 3RVg== X-Gm-Message-State: AIVw110+1uLsz3WcEDBDCjg0dL3mx3L0ngSIUC58HdJfeLF6jn6eqs/3 JNJ3fltS4qUH+nBPZ1M= X-Received: by 10.28.149.76 with SMTP id x73mr4174321wmd.119.1500060256139; Fri, 14 Jul 2017 12:24:16 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:ac27:fffb:924e:60be? ([2001:67c:1232:144:ac27:fffb:924e:60be]) by smtp.gmail.com with ESMTPSA id n189sm3483008wmd.0.2017.07.14.12.24.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 12:24:13 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_0B5902BE-D36F-4045-9D5F-07A2A710A046"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: STD 89, RFC 4443 on Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Date: Fri, 14 Jul 2017 21:24:12 +0200 References: <20170714174213.487B4B80D63@rfc-editor.org> Cc: Bob Hinden To: IPv6 List Message-Id: <224776D9-48A1-403D-9505-65EC86BE2E7E@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:24:20 -0000 --Apple-Mail=_0B5902BE-D36F-4045-9D5F-07A2A710A046 Content-Type: multipart/alternative; boundary="Apple-Mail=_23883023-BF40-48CA-8216-D481D6EBACED" --Apple-Mail=_23883023-BF40-48CA-8216-D481D6EBACED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: >=20 > From: rfc-editor@rfc-editor.org > Subject: STD 89, RFC 4443 on Internet Control Message Protocol = (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification > Date: July 14, 2017 at 7:42:13 PM GMT+2 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org >=20 > RFC 4443 has been elevated to Internet Standard. >=20 > STD 89 > RFC 4443 >=20 > Title: Internet Control Message Protocol (ICMPv6) > for the Internet Protocol Version 6 (IPv6) > Specification > Author: A. Conta, > S. Deering, > M. Gupta, Ed. > Status: Standards Track > Stream: IETF > Date: March 2006 > Pages: 24 > Characters: 48969 > Obsoletes: RFC 2463 > Updates: RFC 2780 > See Also: STD 89 >=20 > I-D Tag: draft-ietf-ipngwg-icmp-v3-07.txt >=20 > URL: https://www.rfc-editor.org/info/rfc4443 >=20 > DOI: 10.17487/RFC4443 >=20 > This document describes the format of a set of control messages used > in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the > Internet Control Message Protocol for Internet Protocol version 6 > (IPv6). >=20 > This document is a product of the IP Version 6 Working Group of the = IETF. >=20 > This is now an Internet Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the > standardization state and status of this protocol. Distribution of = this > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 --Apple-Mail=_23883023-BF40-48CA-8216-D481D6EBACED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

Begin forwarded message:

From: = rfc-editor@rfc-editor.org
Subject: = STD 89, RFC 4443 = on Internet Control Message Protocol (ICMPv6) for the Internet Protocol = Version 6 (IPv6) Specification
Date: = July 14, 2017 at 7:42:13 PM = GMT+2
To: = ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org
Reply-To: = ietf@ietf.org

RFC 4443 has been elevated to = Internet Standard.

=        STD 89 =        
=        RFC 4443

       Title: =      Internet Control Message Protocol (ICMPv6) =
=             &n= bsp;      for the Internet Protocol = Version 6 (IPv6)
=             &n= bsp;      Specification
=        Author: =     A. Conta,
=             &n= bsp;      S. Deering,
=             &n= bsp;      M. Gupta, Ed.
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       March 2006
=        Pages: =      24
=        Characters: 48969
=        Obsoletes:  RFC 2463
       Updates: =    RFC 2780
=        See Also:   STD = 89

=        I-D Tag: =    draft-ietf-ipngwg-icmp-v3-07.txt

       URL: =        https://www.rfc-editor.org/info/rfc4443

       DOI: =        10.17487/RFC4443

This document describes the format of a set of = control messages used
in ICMPv6 (Internet Control Message = Protocol).  ICMPv6 is the
Internet Control Message = Protocol for Internet Protocol version 6
(IPv6).

This document is a product of the IP Version 6 = Working Group of the IETF.

This is now an = Internet Standard.

STANDARDS TRACK: This = document specifies an Internet Standards Track
protocol = for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition = of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. =  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce = and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC


= --Apple-Mail=_23883023-BF40-48CA-8216-D481D6EBACED-- --Apple-Mail=_0B5902BE-D36F-4045-9D5F-07A2A710A046 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZaRpcAAoJEK7rdBF357uoZuEIAJuzUOIpEMA4eYxS2tSbRM4R u9WFr5MJtcxu8GlKfEkjj3yQSYKx+RD3mL+etIuJ9HrD0qtwxe5PMvUDogxgSkHr K81MdZU9DloeL93tDBe0QL702ngC6EVSYHc32ULIc8g2HTk/J88GR90xH4pM8cqP KtXJi3mIGPyGxGFoO6ncylMLDTNO8yVl9YyNw782p6i0Q6idMTDjYUTedAalFwAw FEv28HypXYRnESGtEu00hSc5nkIHlb6ipOUh8vRNzcyCQmE4sWXd+Di7ukn4lpvS uENJj8X5OcYayucSHKyTLWfEmC9p9rBY781AbkKgQVwRimvf6WYVtSiETCZvqik= =utEt -----END PGP SIGNATURE----- --Apple-Mail=_0B5902BE-D36F-4045-9D5F-07A2A710A046-- From nobody Fri Jul 14 15:52:49 2017 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 49420126DEE for ; Fri, 14 Jul 2017 15:52:48 -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 8Xq3UHmQCtq2 for ; Fri, 14 Jul 2017 15:52:46 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCC6126C25 for ; Fri, 14 Jul 2017 15:52:46 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:0:53aa:64c:38f3:78e2:a18e:b3f3]) by relay.sandelman.ca (Postfix) with ESMTPS id 201641F8FB for ; Fri, 14 Jul 2017 22:52:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3443927F8; Sat, 15 Jul 2017 00:52:28 +0200 (CEST) From: Michael Richardson To: ipv6@ietf.org Subject: Re: STD 86, RFC 8200 on Internet Protocol, Version 6 (IPv6) Specification In-reply-to: <20170714173743.59DAAB80D35@rfc-editor.org> References: <20170714173743.59DAAB80D35@rfc-editor.org> Comments: In-reply-to rfc-editor@rfc-editor.org message dated "Fri, 14 Jul 2017 10:37:43 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 15 Jul 2017 00:52:28 +0200 Message-ID: <14843.1500072748@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 22:52:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > STD 86 RFC 8200 > Title: Internet Protocol, Version 6 (IPv6) Specification Wow. "8200" ... What a great number. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZaUssAAoJEJVM4Vb9/EKQj7UH/j6PVqhnXwauSoRT8lls/PnO ehDKEEkOMW1r4ZXM+RDz9WQnaGDcCnyBoGJpIe/l8exlO1REULrG53Ru/wTT6HGv adShSNVEHHAh0aNhWeHs0URapL/yRtZ2bipVLGa5WdV7HvSG8AyKeNqqDJxufpj6 VhdPGRDm44W4rk0lSuaRJJDnQYLi8fo/0B3QP/YJ0Hks47gBb6GWsMZQJAslqFU4 0O2ylHI0A1Z9EJMppGkbML9GUWOr/rOVo3ZPGNKiecFMIzbimV54ku6JmsydoD/r 2HW17xLWW9y/rHUOw4egOulSTKbotUZGWs8jdOB8r7Sr6jyTxi7+7IsFL4BIEj0= =A+ES -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 15 06:39:46 2017 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 132AB131BAF for ; Sat, 15 Jul 2017 06:39:46 -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] 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 TPZMTEfpHfJ2 for ; Sat, 15 Jul 2017 06:39:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9D131BAC for ; Sat, 15 Jul 2017 06:39:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dWNIL-0000FpC; Sat, 15 Jul 2017 15:39:41 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Fri, 14 Jul 2017 11:31:53 +1200 ." Date: Sat, 15 Jul 2017 15:39:39 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 13:39:46 -0000 >This is backwards. The goals of pseudo-random IIDs are to reduce the >probability that scanning attacks find hosts, and to reduce the risk >of IIDs being used to breach privacy. > >If these goals are met, the collision probability will in any case >be low, so DAD failure will be exceedingly rare. I completely disagree. A collision is fatal. We are nowhere near transparently handling all collisions. At best we can hope that DAD can make one node continue unaffected. In contrast, people have been scanning my IPv4 ranges for the past 20 years or so. That may be annoying. That may amplify attacks opportunities. But in it self it is not fatal. From nobody Sat Jul 15 06:51:14 2017 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 41BB4131BEB for ; Sat, 15 Jul 2017 06:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 QUhSkNO2MCdJ for ; Sat, 15 Jul 2017 06:51:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE0131BB2 for ; Sat, 15 Jul 2017 06:51:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dWNTQ-0000FNC; Sat, 15 Jul 2017 15:51:08 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 13 Jul 2017 18:16:03 +0000 ." Date: Sat, 15 Jul 2017 15:51:04 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 13:51:13 -0000 > > However, since the mid 90s we have a protocol for dense allocation of > > addresses. Where in the 64-bit IID space you can fit an entire universe. > > In a flat universe, maybe. No one is disputing that 64 bit IIDs > allow for many hosts in a single subnet prefix. But we also discovered > in the 1980s and 1990s how bad it is to create gymongous IP subnets. Just in case you missed it, I'm advocating that 64 bit IIDs only apply to SLAAC and not to DHCPv6 IA_NA. So using DHCP, a /64 prefix can be subdivided exactly as you want. You can for example hand out a /96 prefix using IA_PD to every link and then per link you still have more than enough addresses. Note that I believe Lorenzo's argument is valid. The reason we can expect a /64 to be there is that SLAAC requires a /64. If we relax that requirement then soon we will see longer prefixes pop up and are back to square one. For DHCP I don't care. For SLAAC I just don't want the collision risk. So keep SLAAC at 64 and use DHCP for anything else. From nobody Sat Jul 15 07:04:01 2017 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 01568131BF2 for ; Sat, 15 Jul 2017 07:03:59 -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 RDjLZ4FiN6l8 for ; Sat, 15 Jul 2017 07:03:56 -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 B1D1F129B26 for ; Sat, 15 Jul 2017 07:03:56 -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 v6FE3tVD008436; Sat, 15 Jul 2017 07:03:55 -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 v6FE3l25008323 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 15 Jul 2017 07:03:47 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 15 Jul 2017 07:03:46 -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.1263.000; Sat, 15 Jul 2017 07:03:46 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS/XFmwSXX/U8PI0SttVg+W0fk4KJU6M+Q Date: Sat, 15 Jul 2017 14:03:46 +0000 Message-ID: <5ac2b25b9f794362885ad7f5d1c0ca17@XCH15-06-11.nw.nos.boeing.com> References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 14:03:59 -0000 > Just in case you missed it, I'm advocating that 64 bit IIDs only > apply to SLAAC and not to DHCPv6 IA_NA. That's good. It's a good compromise. I'm all for it. > Note that I believe Lorenzo's argument is valid. The reason we can > expect a/64 to be there is that SLAAC requires a /64. If we relax > that requirement then soon we will see longer prefixes pop up and > are back to square one. SLAAC currently requires whatever IID length applies to the link, which sti= ll comes out to 64 bits for Ethernet (but for reasons that no longer apply)= . So, we have agreed, I think, to retain this 64-bit IID requirement for SL= AAC, as a self-imposed measure. Part of this compromise. We agreed that relaxing that requirement for SLAAC would make it too easy t= o "race to the bottom." This is all good, I think. Bert From nobody Sat Jul 15 10:54:26 2017 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 DED0E127369 for ; Sat, 15 Jul 2017 10:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XURiRiqHuWzz for ; Sat, 15 Jul 2017 10:54:23 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 578F71270A0 for ; Sat, 15 Jul 2017 10:54:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 93495B1C for ; Sat, 15 Jul 2017 17:54:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbTXWTWQlbsZ for ; Sat, 15 Jul 2017 12:54:22 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 5AA67B18 for ; Sat, 15 Jul 2017 12:54:22 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id o190so42377875vka.10 for ; Sat, 15 Jul 2017 10:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=5lYO7rEWXIcLwZZPHWnmBSSUbjnsnE/eYmx7cOQFnYo=; b=Y3iRmIb5w7R0Vsv7gBAEmEhZnoTSz0204QPEBsjH1tcy2Q23faktpHI+NEBhCKFuJ9 IVnmoQHkBG2tRImzG0HeNKHNdAtqhdN5Eu1YPclzKPQD+9tzu50C1pGJf45CbVuYD1Qg b2jtzw8u5rB06NEGBB2nBFCzl0tCcz1wMyO7zOwJGECIiQvv8u2N+Fv1AVarvcz1v+Ju Xnr9qFmLHJycPjOYD5y3k+COmWeD1ftuQoUa5xyuGIJ2Kmy96qZvngswJwQMHNfuoVb1 IDOgp7m7MR+tcZUY4Le8Y7wZn+0lTJrQ4PdnBD599cKWWZyYRIi1Op2mZQHpd0NkXEMd It7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5lYO7rEWXIcLwZZPHWnmBSSUbjnsnE/eYmx7cOQFnYo=; b=Kf2+WCYWuPs9eMafTvmZPjav5QmqnyT0jC0nHRdfXWeOsBgJDJaAKVeJK5ZDEyuJJ2 7eIV2bpH8mkPKlzbNwwpWDaG+qiDFCY5jbi9TIjsAG3imqOM+TDzvwEP3N3su4WqbvFp YUz9V1hQTMKF2skrORT0EKmVXiZ/K/Uvq0hEdJmnwqdqs1bI+bg+A+x1Z8F2aiMrrqM3 sNUC8cvj96d6z/plNuYXm5y0+wasAzAdwpju+MzOA8Y3AHGMoTv8GDssrdSDgJpa9J3K Aa35RyNkxuaiEcxwA4NCZ79KcKa2QM41MZxpyNkqMr3GjoW76wvviLHOezqJ8f2mp4D1 pD0A== X-Gm-Message-State: AIVw110PEc5Fdaue//+cvwYpKMlF1YTvCLikHTqiqH68ovPhTpY/7Bed 1zoo/4gWehOktWwZpif+U+wtDSAGBaawxRS7CDFEMbyyryLthZzraVE+Sp7+cM+Cxr3Ld0mD/LX w8wIOZqpixxwt+ug= X-Received: by 10.31.9.137 with SMTP id 131mr8320378vkj.142.1500141261569; Sat, 15 Jul 2017 10:54:21 -0700 (PDT) X-Received: by 10.31.9.137 with SMTP id 131mr8320365vkj.142.1500141261315; Sat, 15 Jul 2017 10:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sat, 15 Jul 2017 10:54:20 -0700 (PDT) From: David Farmer Date: Sat, 15 Jul 2017 12:54:20 -0500 Message-ID: Subject: 64bit IIDs are both recommended and required To: 6man WG Content-Type: multipart/alternative; boundary="001a11440eb8fe85fd05545edad0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 17:54:25 -0000 --001a11440eb8fe85fd05545edad0 Content-Type: text/plain; charset="UTF-8" Listening to the discussion for the last couple weeks, it seems apparent that a simple statement requiring or recommending 64 bit IIDs doesn't accurately reflect the true nature of the IPv6 architecture. Also a problem statement was asked for, and I think that is it, "a simple statement requiring or recommending 64 bit IIDs doesn't accurately reflect the true nature of the IPv6 architecture." A statement simply requiring 64 bit IIDs, as in RFC4291, ignores the following; - /128 prefixes are frequently assigned to loopback addresses for routing protocols. - /127 or /126 prefixes are frequently assigned to point-to-point router links. - Further it is common to assign these /128, /127, and /126 prefixes out of a common /64 prefix. - ND and unicast routing are explicitly designed to work with IIDs of any length - DHCPv6 IA_NA and IA_TA provide no routing information, the on-link prefix come from PIOs in RAs, and can be any length. - Most IPv6 implementations allow the manual configuration of prefixes of any length On the other hand, a statement simply recommending 64 bit IIDs doesn't accurately reflect the following either; - The Link-Local IID length has to be known, and there are no easy mechanisms to discover it, therefore it is defined to be 64 bits for all current link types. - SLAAC uses the Link-Local IID to create other Unicast Address types and requires 64 bit IIDs for Unicast Address assignment and on-link determination for proper operation. - As currently defined, many other parts of IPv6 assume Unicast Address assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc... I think the following more accurately conveys the true nature of the IPv6 architecture in regards to IIDs; Several components of IPv6 architecturally require Unicast Addresses with fixed length Interface Identifiers that are 64 bits long, except addresses that start with the binary value 000, primary of these is Stateless Address Autoconfiguration (SLAAC) [RFC4862], other examples are discussed in [RFC7421]. Whereas other components of IPv6 are explicitly designed operate with Interface Identifiers of any length, Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast routing [RFC7608] are examples of these. Therefore, the use of 64 bit Interface Identifiers are recommended to ensure all components of IPv6 operate as designed. However, there are several situations where Interface Identifiers of other lengths can safely be used, these include loopback interfaces, point-to-point router links [RFC6164], and links where all nodes are configured manually or with DHCPv6. Although, links with any nodes that are configured with SLAAC require 64 bit Interface Identifiers. What do others think? -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a11440eb8fe85fd05545edad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Listening to the discussion for the last couple weeks= , it seems apparent that a simple statement requiring or recommending 64 bi= t IIDs doesn't accurately reflect the true nature of the IPv6 architect= ure.=C2=A0 Also a problem statement was asked for, and I think that is it, = "a simple statement requiring or recommending 64 bit IIDs doesn't = accurately reflect the true nature of the IPv6 architecture."

A statement simply requiring=C2=A064 bit IIDs, as in RFC4291, i= gnores the following;

- /128 prefixes are frequently ass= igned to loopback addresses for routing protocols.
- /127 or /126= =C2=A0=C2=A0prefixes are frequently assigned=C2=A0to point-to-point router = links.=C2=A0
- Further it is common to assign these /128, /127, a= nd /126 prefixes out of a common /64 prefix.

- ND = and unicast routing are explicitly=C2=A0designed to work with IIDs of any l= ength
- DHCPv6 IA_NA and IA_TA provide no routing information, th= e on-link prefix come from PIOs in RAs, and can be any length.=C2=A0
- Most IPv6 implementations allow the manual configuration of = prefixes of any length

On the other hand, a = statement simply recommending=C2=A064 bit IIDs doesn't accurately refle= ct the following either;

- The Link-Local IID = length has to be known, and there are no easy mechanisms to discover it, th= erefore it is defined to be 64 bits for all current link types.
- SLAAC uses the Link-Local IID to create other Unicast Address types an= d requires 64 bit IIDs for Unicast Address assignment and on-link determina= tion for proper operation.
- As currently defined, many other par= ts of IPv6 assume Unicast Address assignments based on 64 bit IIDs, Embeded= RP Multicast, Mobile IP, etc...

I think the = following more accurately conveys the true nature of the IPv6 architecture = in regards to IIDs;

Several components of IPv6= architecturally=C2=A0require Unicast Addresses with fixed length Interface= Identifiers that are 64 bits long,=C2=A0except addresses that start with the binary value=C2=A0<= /span>000,=C2= =A0primary of these is Stateless Address Autoconfiguration (SLAAC) [RFC4862= ], other examples are discussed in [RFC7421]. Whereas other components of I= Pv6 are explicitly=C2=A0designed operate with Interface Identifiers=C2=A0of= any length, Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicas= t routing [RFC7608] are examples of these. Therefore, the use of 64 bit Int= erface Identifiers are recommended to ensure all components of IPv6 operate= as designed. However, there are several situations where Interface Identif= iers of other lengths can safely be used, these include loopback interfaces= , point-to-point router links [RFC6164], and links where all nodes are conf= igured manually or with DHCPv6. Although, links with any nodes that are con= figured with SLAAC require 64 bit Interface Identifiers.

What do others think?

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
Networking & Telecommunication Services
Office of Inform= ation Technology
University of Minnesota=C2=A0=C2=A0
2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 5= 5414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11440eb8fe85fd05545edad0-- From nobody Sat Jul 15 11:49:57 2017 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 E9E01129AFF for ; Sat, 15 Jul 2017 11:49:55 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 ksYtnLoQlZF3 for ; Sat, 15 Jul 2017 11:49:54 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425B51250B8 for ; Sat, 15 Jul 2017 11:49:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 75BE41BC37 for ; Sat, 15 Jul 2017 18:49:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: 64bit IIDs are both recommended and required From: Simon Hobson In-Reply-To: Date: Sat, 15 Jul 2017 19:49:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F3B6075-AE4E-46D2-970F-DFD4B6A66CB1@thehobsons.co.uk> References: To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 18:49:56 -0000 David Farmer wrote: > On the other hand, a statement simply recommending 64 bit IIDs doesn't = accurately reflect the following either; >=20 > - The Link-Local IID length has to be known, and there are no easy = mechanisms to discover it, therefore it is defined to be 64 bits for all = current link types. That's OK - but really LL addresses are a special case. > - SLAAC uses the Link-Local IID to create other Unicast Address types = and requires 64 bit IIDs for Unicast Address assignment and on-link = determination for proper operation. Is that correct ? I was under the impression that SLAAC can use any = prefix length advertised in an RA. The use of hardware address derived = addresses is deprecated - and therefore any fixed 64 bit requirement = should also be deprecated ? The only remaining argument I've seen for keeping the 64 bit split is = for privacy/security by making the available address space "very large" = - but that in itself doesn't need a "fixed" 64 bit. > - As currently defined, many other parts of IPv6 assume Unicast = Address assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile = IP, etc... "Assume" or "require" ? As I've said earlier, I think the safest option is the require (as in = *MUST*) implementations to work with arbitrary prefix lengths. If an = implementation can handle an arbitrary split, then it can handle a 64/64 = split - if you allow fixed assumptions then it's storing up *potential* = problems later on. Who knows what someone might come up with in the next = few decades ! From nobody Sat Jul 15 12:32:39 2017 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 26607128B8F for ; Sat, 15 Jul 2017 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBt6SHn5r07O for ; Sat, 15 Jul 2017 12:32:36 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 0AA0A126D46 for ; Sat, 15 Jul 2017 12:32:36 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 6F93AB58 for ; Sat, 15 Jul 2017 19:32:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXwQtZtGhjvp for ; Sat, 15 Jul 2017 14:32:35 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 30E8B9CA for ; Sat, 15 Jul 2017 14:32:35 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id f68so40725350vkg.1 for ; Sat, 15 Jul 2017 12:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BYh2b5CyeD7wgahIuaN8J0CU+QIkNvyo5wKDtADRMX0=; b=DAl9RN6GKnjZpTrRf5fkkR3byKun/RKX3QXO/COfwEzVF2A9RmR/PdOmv0WJ62dAul m7SMhU/sBwsFpPVCsZH8FUQdxYWxkxynx44rxIWZW3zDJY0ysDV94cDSTCyQPc5saVzr fe1CFwce668geo4Y4PpGn2Sfvrr8eGO62xnVOZ808csHntY6HmiyE3Zp2YnLmjz2emng zyAK5qPj79AQAzTnkqkOUX/HC7Ylsv9YmoGMlHz0JmkT6fuRxIxmcV1R4L6PWE9prsTX LlL69atW3uj/9TxKwk7FnxRdnvvNz6g6WopsTfyp1lA3DYHvQXiC6oe449RQdgIqxJmi U0Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BYh2b5CyeD7wgahIuaN8J0CU+QIkNvyo5wKDtADRMX0=; b=K6/Uvdyq/LCIv6bdkYPtnN4oqr60O80PectlNgEjXhha71mOGRi7m6LbCvp619shau YzOkFTCdeIwfdp2g7iRNd/1ezIfuLjXOVifFvqKi6r4Ex6XRXgIRxYdVk4O2v6sZzCLm kqXdfIJRLiTRef4X/QlJ8EVBuw4dHemrOGKhB+8MRNKeizd20w1t4SgHX4uu9nwPQr0h B6l6qITfKqr5LC94YKhAipvTOddPccdStXKrQJPjuozFe/wvUEmxW1CCScM82/eH+Slu l3mKvICzacp8ON9mrYOpeglhoZk7/fGs8thhtQ3zQ9PGQX+RdaESiZwDKcnUxsuXs2aG TzyA== X-Gm-Message-State: AIVw112IhqTUEgAvImvFB2+0f8lkP0VESB3qRWXkE6mLL8b0E0dXi/Bj Ujmx7BR0LSyM5s19/dortDHeRFVjJA4irdz3XVCBlClAIFutrzAlcS4QS3OmY8COOeYrUqcKuLf n1Myhdzr7tKuRIIU= X-Received: by 10.31.13.78 with SMTP id 75mr8482519vkn.121.1500147154544; Sat, 15 Jul 2017 12:32:34 -0700 (PDT) X-Received: by 10.31.13.78 with SMTP id 75mr8482509vkn.121.1500147154311; Sat, 15 Jul 2017 12:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sat, 15 Jul 2017 12:32:33 -0700 (PDT) In-Reply-To: <8F3B6075-AE4E-46D2-970F-DFD4B6A66CB1@thehobsons.co.uk> References: <8F3B6075-AE4E-46D2-970F-DFD4B6A66CB1@thehobsons.co.uk> From: David Farmer Date: Sat, 15 Jul 2017 14:32:33 -0500 Message-ID: Subject: Re: 64bit IIDs are both recommended and required To: Simon Hobson Cc: 6man WG Content-Type: multipart/alternative; boundary="001a11440f443e74330554603ac4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:32:38 -0000 --001a11440f443e74330554603ac4 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 1:49 PM, Simon Hobson wrote: > David Farmer wrote: > > > On the other hand, a statement simply recommending 64 bit IIDs doesn't > accurately reflect the following either; > > > > - The Link-Local IID length has to be known, and there are no easy > mechanisms to discover it, therefore it is defined to be 64 bits for all > current link types. > > That's OK - but really LL addresses are a special case. > > > - SLAAC uses the Link-Local IID to create other Unicast Address types > and requires 64 bit IIDs for Unicast Address assignment and on-link > determination for proper operation. > > Is that correct ? I was under the impression that SLAAC can use any prefix > length advertised in an RA. The use of hardware address derived addresses > is deprecated - and therefore any fixed 64 bit requirement should also be > deprecated ? > The only remaining argument I've seen for keeping the 64 bit split is for > privacy/security by making the available address space "very large" - but > that in itself doesn't need a "fixed" 64 bit. > RFC4862 says: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291]. And RFC4291 clearly says IIDs are 64 bits long, and I'm not aware of any link type document that specifies something different that 64 bits. > > - As currently defined, many other parts of IPv6 assume Unicast Address > assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc... > > "Assume" or "require" ? > Doesn't matter, things will break, can you redefine some of theses, sure, but not by simply changing a few paragraphs in RFC4291bis. > As I've said earlier, I think the safest option is the require (as in > *MUST*) implementations to work with arbitrary prefix lengths. If an > implementation can handle an arbitrary split, then it can handle a 64/64 > split - if you allow fixed assumptions then it's storing up *potential* > problems later on. Who knows what someone might come up with in the next > few decades ! > At one level, I agree with you. But that is not what was done, some parts of IPv6 require variable prefixes and IIDs, where other parts require fixed length 64 bit prefixes and IIDs, that is the facts on the ground, yes it's a little schizophrenic, but it is the way it is. You can't change that without changing all the parts of IPv6 that require fixed length 64 bit IIDs first, and changing a couple paragraphs in RFC4291bis can't do that. Further, I don't see consensus to go modify all of the other part of IPv6 first even if that is what I would prefer to do. However, accurately stating that some parts of IPv6 require variable length prefixes and IID and other parts require fixed length 64 bit prefixes and IIDs is something that can be done in RFC4291bis. In fact I think it has to be done to accurately describe IPv6 and move the IPv6 Address Architecture to Internet Standard. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a11440f443e74330554603ac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 15, 2017 at 1:49 PM, Simon Hobson <linux@thehobsons.c= o.uk> wrote:
David Farmer <f= armer@umn.edu> wrote:

> On the other hand, a statement simply recommending 64 bit IIDs doesn&#= 39;t accurately reflect the following either;
>
> - The Link-Local IID length has to be known, and there are no easy mec= hanisms to discover it, therefore it is defined to be 64 bits for all curre= nt link types.

That's OK - but really LL addresses are a special case.

> - SLAAC uses the Link-Local IID to create other Unicast Address types = and requires 64 bit IIDs for Unicast Address assignment and on-link determi= nation for proper operation.

Is that correct ? I was under the impression that SLAAC can use any prefix = length advertised in an RA. The use of hardware address derived addresses i= s deprecated - and therefore any fixed 64 bit requirement should also be de= precated ?
The only remaining argument I've seen for keeping the 64 bit split is f= or privacy/security by making the available address space "very large&= quot; - but that in itself doesn't need a "fixed" 64 bit.
=

RFC4862 says:
=C2=A0 =C2=A0 =C2=A0 If the sum of the prefix length and inte= rface identifier length
=C2=A0 =C2=A0 = =C2=A0 does not equal 128 bits, the Prefix Information option MUST be
=
=C2=A0 =C2=A0 =C2=A0 ignored.=C2=A0 An impl= ementation MAY wish to log a system management
=C2=A0 =C2=A0 =C2=A0 error in this case.=C2=A0 The length of the i= nterface identifier is
=C2=A0 =C2=A0 = =C2=A0 defined in a separate link-type specific document, which should
=C2=A0 =C2=A0 =C2=A0 also be consistent wi= th the address architecture [RFC4291].
=C2=A0
And RFC4291 clearly says= IIDs are 64 bits long, and I'm not aware of any link type document tha= t specifies something different that 64 bits.
=C2=A0
> - As currently defined, many other parts of IPv6 assume Unicast Addres= s assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc...=

"Assume" or "require" ?
=C2=A0
Doesn't matter, things will break, can you redefine some of thes= es, sure, but not by simply changing a few paragraphs in RFC4291bis.=C2=A0<= /div>
=C2=A0
As I've said earlier, I think the safest option is the require (as in *= MUST*) implementations to work with arbitrary prefix lengths. If an impleme= ntation can handle an arbitrary split, then it can handle a 64/64 split - i= f you allow fixed assumptions then it's storing up *potential* problems= later on. Who knows what someone might come up with in the next few decade= s !

At one level, I agree with you. But= that is not what was done, some parts of IPv6 require variable prefixes an= d IIDs, where other parts require fixed length 64 bit prefixes and IIDs, th= at is the facts on the ground, yes it's a little schizophrenic, but it = is the way it is. You can't change that without changing all the parts = of IPv6 that require fixed length 64 bit IIDs first, and changing a couple = paragraphs in RFC4291bis can't do that. Further, I don't see consen= sus to go modify all of the other part of IPv6 first even if that is what I= would prefer to do.

However, accurately stating t= hat some parts of IPv6 require variable length prefixes and IID and other p= arts require fixed length 64 bit prefixes and IIDs is something that can be= done in RFC4291bis. In fact I think it has to be done to accurately descri= be IPv6 and move the IPv6 Address Architecture to Internet Standard.
<= div>=C2=A0
Thanks.

--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--001a11440f443e74330554603ac4-- From nobody Sat Jul 15 12:51:16 2017 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 06736129ABE for ; Sat, 15 Jul 2017 12:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFhrJu_VW5tS for ; Sat, 15 Jul 2017 12:51:14 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 32B3F128BA2 for ; Sat, 15 Jul 2017 12:51:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id C2BB4BCB for ; Sat, 15 Jul 2017 19:51:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO6cXgp4WIRB for ; Sat, 15 Jul 2017 14:51:13 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 7F33EBB8 for ; Sat, 15 Jul 2017 14:51:13 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id 35so45065338uax.6 for ; Sat, 15 Jul 2017 12:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=neVYZCDRI1Vjn5DMDEo+9uH9aoFa7sEN7Hl+A0L17vw=; b=i70zvpLbj3D6DR8FYOyg/Ngbjgh/pLsFrGQfuynGJ6bBr6hp/sLKYtPmDoPA1CWqga yR0+7wSKiYdSWAnqccsYl7Cia0x8ZDZNwTivLoIr4m9Lu9Q1NxrzVMPVgFhuXTkFlpWe jRn+1wKymGS9YHdvsou8ysZtUluXHRw/kOBQhlvwd2ha1/M6iAk+KsIJncT0XGJT+hmU IYxY/acUlUZcS21lBqiM3ynczRxJHzf5YQ6i7jzILba7aIGLaY/E2pHDl+1aQKxkNRmR lgmTyEre7jYWIyBtuop/YTSQYZZZ3juzTtfaxEbeyjDKKLJwAKSSWeIL1GXFix+TqMz/ VYZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=neVYZCDRI1Vjn5DMDEo+9uH9aoFa7sEN7Hl+A0L17vw=; b=mvIganWLcj3E+6b2FFkjNxup0JTKxBt+t0p8Jz1yX61wcQ9Qtb8zyNjYdpjIbdWRLn MSuTKejFsiopUc2K6CZiUd/Qe8KMOSGK9Q6xuqxHR/FRs7iojnhEPpmcViqj972DAyFW 2usSqVeLiJBEOPz1rEJpEkwPaVfHrlXX6bKuomPdfR3+F5Hq/4+oeuyTrrNfKE4XEqhQ kVHYCojkAwzAipAf4NoOEZDTqd88CKxMWaX0GxookM4rqeZ+yZ7bKu6XQ9CCJF3EEDRl YtvGn8zb1U/icS4BOgNz/pBNRH22HKum7/vilw9azqHOLoBMFsf/azUAY/HVSpNa41qp BFQQ== X-Gm-Message-State: AIVw110c/eUEUhPe30rIeF/2EmO3D28KykDD6tYlb6o55ngR5MSFDRcr r6guJjlUcTUSVg3B4yqUHjttzKXAfpG4EOqNM7gJCqQrIGgXBfbZb8ORm9aEq3yIIs0wqAyb7ye yDShCf+4gtGUDMGM= X-Received: by 10.176.93.224 with SMTP id l32mr9049048uag.154.1500148272969; Sat, 15 Jul 2017 12:51:12 -0700 (PDT) X-Received: by 10.176.93.224 with SMTP id l32mr9049040uag.154.1500148272767; Sat, 15 Jul 2017 12:51:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sat, 15 Jul 2017 12:51:12 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Sat, 15 Jul 2017 14:51:12 -0500 Message-ID: Subject: Re: 64bit IIDs are both recommended and required To: 6man WG Content-Type: multipart/alternative; boundary="f403043ee0c4e916fa0554607cd0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 19:51:16 -0000 --f403043ee0c4e916fa0554607cd0 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 12:54 PM, David Farmer wrote: > Listening to the discussion for the last couple weeks, it seems apparent > that a simple statement requiring or recommending 64 bit IIDs doesn't > accurately reflect the true nature of the IPv6 architecture. Also a > problem statement was asked for, and I think that is it, "a simple > statement requiring or recommending 64 bit IIDs doesn't accurately reflect > the true nature of the IPv6 architecture." > > A statement simply requiring 64 bit IIDs, as in RFC4291, ignores the > following; > > - /128 prefixes are frequently assigned to loopback addresses for routing > protocols. > - /127 or /126 prefixes are frequently assigned to point-to-point router > links. > - Further it is common to assign these /128, /127, and /126 prefixes out > of a common /64 prefix. > > - ND and unicast routing are explicitly designed to work with IIDs of any > length > - DHCPv6 IA_NA and IA_TA provide no routing information, the on-link > prefix come from PIOs in RAs, and can be any length. > - Most IPv6 implementations allow the manual configuration of prefixes of > any length > > On the other hand, a statement simply recommending 64 bit IIDs doesn't > accurately reflect the following either; > > - The Link-Local IID length has to be known, and there are no easy > mechanisms to discover it, therefore it is defined to be 64 bits for all > current link types. > - SLAAC uses the Link-Local IID to create other Unicast Address types and > requires 64 bit IIDs for Unicast Address assignment and on-link > determination for proper operation. > - As currently defined, many other parts of IPv6 assume Unicast Address > assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc... > > I think the following more accurately conveys the true nature of the IPv6 > architecture in regards to IIDs; > > A minor tweak; Several components of IPv6 architecturally require Unicast Addresses with fixed length Interface Identifiers that are 64 bits long, except addresses that start with the binary value 000, primary of these is Stateless Address Autoconfiguration (SLAAC) [RFC4862], other examples are discussed in [RFC7421]. Whereas other components of IPv6 are explicitly designed operate with Interface Identifiers of any length, Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast routing [RFC7608] are examples of these. Therefore, the use of 64 bit Interface Identifiers are recommended to ensure all components of IPv6 operate as designed. However, there are several situations where Interface Identifiers of other lengths can safely be used, these include loopback interfaces, point-to-point router links [RFC6164], and links where all nodes are intended to be configured manually or with DHCPv6. Although, links with any nodes that are intended to be configured with SLAAC require 64 bit Interface Identifiers. What do others think? > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403043ee0c4e916fa0554607cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 15, 2017 at 12:54 PM, David Farmer <farmer@umn.edu> wrote:
Listening to the discussion for the last couple weeks, it see= ms apparent that a simple statement requiring or recommending 64 bit IIDs d= oesn't accurately reflect the true nature of the IPv6 architecture.=C2= =A0 Also a problem statement was asked for, and I think that is it, "a= simple statement requiring or recommending 64 bit IIDs doesn't accurat= ely reflect the true nature of the IPv6 architecture."

<= /div>A statement simply requiring=C2=A064 bit IIDs, as in RFC4291, ignores = the following;

- /128 prefixes are frequently assigned t= o loopback addresses for routing protocols.
- /127 or /126=C2=A0= =C2=A0prefixes are frequently assigned=C2=A0to point-to-point router links.= =C2=A0
- Further it is common to assign these /128, /127, and /12= 6 prefixes out of a common /64 prefix.

- ND and un= icast routing are explicitly=C2=A0designed to work with IIDs of any length<= /div>
- DHCPv6 IA_NA and IA_TA provide no routing information, the on-l= ink prefix come from PIOs in RAs, and can be any length.=C2=A0
- Most IPv6 implementations allow the manual configuration of prefix= es of any length

On the other hand, a statem= ent simply recommending=C2=A064 bit IIDs doesn't accurately reflect the= following either;

- The Link-Local IID length= has to be known, and there are no easy mechanisms to discover it, therefor= e it is defined to be 64 bits for all current link types.
- S= LAAC uses the Link-Local IID to create other Unicast Address types and requ= ires 64 bit IIDs for Unicast Address assignment and on-link determination f= or proper operation.
- As currently defined, many other parts of = IPv6 assume Unicast Address assignments based on 64 bit IIDs, Embeded RP Mu= lticast, Mobile IP, etc...

I think the follow= ing more accurately conveys the true nature of the IPv6 architecture in reg= ards to IIDs;


A minor tweak;

Several components of IPv6 architecturally=C2=A0require Unicast Addre= sses with fixed length Interface Identifiers that are 64 bits long,=C2=A0except addresses = that start with the binary value=C2=A0000,=C2=A0pr= imary of these is Stateless Address Autoconfiguration (SLAAC) [RFC4862], ot= her examples are discussed in [RFC7421]. Whereas other components of IPv6 a= re explicitly=C2=A0designed operate with Interface Identifiers=C2=A0of any = length, Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast rou= ting [RFC7608] are examples of these. Therefore, the use of 64 bit Interfac= e Identifiers are recommended to ensure all components of IPv6 operate as d= esigned. However, there are several situations where Interface Identifiers = of other lengths can safely be used, these include loopback interfaces, poi= nt-to-point router links [RFC6164], and links where all nodes are intended = to be configured manually or with DHCPv6. Although, links with any nodes th= at are=C2=A0intended to be=C2=A0configured with SLAAC require 64 bit I= nterface Identifiers.

What do other= s think?

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043ee0c4e916fa0554607cd0-- From nobody Sat Jul 15 14:01:46 2017 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 1C1D712F27C for ; Sat, 15 Jul 2017 14:01:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bPx1KfwCkUxe for ; Sat, 15 Jul 2017 14:01:43 -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 AD8FC12EC61 for ; Sat, 15 Jul 2017 14:01:43 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q85so60100454pfq.1 for ; Sat, 15 Jul 2017 14:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Rb7K63KiFQ/Oh737T9jtdV5dO1BEamOb35ovwH8qClw=; b=axThxe9c6HwAXPRei6obMjnLKgWO0DOVyocOz/x+HPH5kxM5tsNFF0htpTdPO0RLzc a6hn9GhpuF61L6BgM3/uBw4CQcB8tsVj6J/fp01a2pLSPXsv6FnhtpxMo68ibZlOAWiu OKY4R3wtxDohX6aiIjhwmaj6F9x1rCAcSXXrFBev27KEvmq7m9MlCdlaM+GkYjjSuCZK ItLKo+JiJ5QuQKVn0IuLlF4zSvhX912jQaWs1wAvSsfa1Qw6xM7Vb+x/q4qOSozOeJ/e 7eAhsBIlot5Kd7hrUKr15M1HFAHF7Szg0QPJJJ+czfXf4jKVIklNqLdHKlhUGMDyJTNb 9Ggg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Rb7K63KiFQ/Oh737T9jtdV5dO1BEamOb35ovwH8qClw=; b=Y/bsan2LB72kii1ERWtfBNjhCUvJA1pmS8sqz5PG8wFwscnHZExp5V66UGr9fLkm/P twZ/k/oYxrb67PlmUZfHiV/oC7QpuJyl+sV4VQXlJl4PiMbNswKo3HfIYnvgP8ZtyVZM MyOln6MEkppT+JXIy0LMi9VWllfEJ2tPJB3wJW4rvz6+6PsvdLiQTQH1ZQm8H+9aCqWn cU001zHoBAIlmVNNIoxg6ivDOeAV0M+NqWMUGi1xGKP9ZL39INstyEEKKsl7my4gSRqX S+1DYM3NRqsHdZS573cRLvldaeKyCV0wJtS0LmVwoTdCAQ+20W/9TjPgRrJ56me0xM1f TEAg== X-Gm-Message-State: AIVw111YuhpYuk5l9AOdSxzWXvLEjNPlca+beoBPbl8irv8yc6mUIFdU 5YJMYh4E0vTD1Uku X-Received: by 10.84.214.143 with SMTP id j15mr22450777pli.40.1500152502731; Sat, 15 Jul 2017 14:01:42 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id o62sm26679370pfg.120.2017.07.15.14.01.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 14:01:42 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Philip Homburg , ipv6@ietf.org References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> Date: Sun, 16 Jul 2017 09:01:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:01:45 -0000 On 16/07/2017 01:39, Philip Homburg wrote: >> This is backwards. The goals of pseudo-random IIDs are to reduce the >> probability that scanning attacks find hosts, and to reduce the risk >> of IIDs being used to breach privacy. >> >> If these goals are met, the collision probability will in any case >> be low, so DAD failure will be exceedingly rare. > > I completely disagree. A collision is fatal. We are nowhere near transparently > handling all collisions. At best we can hope that DAD can make one node > continue unaffected. I'm confused. Firstly, do we have any experimental evidence that collisions are a real operational problem? (Obviously, MAC address collisions are disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to detect them, they are irrelevant to the current discussion.) Secondly, if a collision does occur with IPv6+(pseudo-random IID), recovery is obvious: after DAD failure, generate a new pseudo-random IID and try again. This is perfectly compatible with RFC4862 section 5.5 and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy addresses. Brian > > In contrast, people have been scanning my IPv4 ranges for the past 20 years > or so. That may be annoying. That may amplify attacks opportunities. But > in it self it is not fatal. > > > . > From nobody Sat Jul 15 14:23:22 2017 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 7676F128C81 for ; Sat, 15 Jul 2017 14:23: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xRlqH2NG7J9f for ; Sat, 15 Jul 2017 14:23:19 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0594A124D85 for ; Sat, 15 Jul 2017 14:23:18 -0700 (PDT) Received: from [192.168.10.201] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 85BDC2D4F96; Sat, 15 Jul 2017 21:23:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> Date: Sat, 15 Jul 2017 23:23:09 +0200 Cc: Philip Homburg , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:23:20 -0000 Brian, DAD is not robust. Last time I tried on the IETF wireless network 1 time in 4= DAD failed to detect a duplicate.=20 Happy if anyone could do a more thorough experiment.=20 Cheers=20 Ole > On 15 Jul 2017, at 23:01, Brian E Carpenter w= rote: >=20 > On 16/07/2017 01:39, Philip Homburg wrote: >>> This is backwards. The goals of pseudo-random IIDs are to reduce the >>> probability that scanning attacks find hosts, and to reduce the risk >>> of IIDs being used to breach privacy. >>>=20 >>> If these goals are met, the collision probability will in any case >>> be low, so DAD failure will be exceedingly rare. >>=20 >> I completely disagree. A collision is fatal. We are nowhere near transpar= ently >> handling all collisions. At best we can hope that DAD can make one node >> continue unaffected. >=20 > I'm confused. >=20 > Firstly, do we have any experimental evidence that collisions > are a real operational problem? (Obviously, MAC address collisions are > disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to > detect them, they are irrelevant to the current discussion.) >=20 > Secondly, if a collision does occur with IPv6+(pseudo-random IID), > recovery is obvious: after DAD failure, generate a new pseudo-random > IID and try again. This is perfectly compatible with RFC4862 section 5.5 > and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy > addresses. >=20 > Brian >=20 >>=20 >> In contrast, people have been scanning my IPv4 ranges for the past 20 yea= rs >> or so. That may be annoying. That may amplify attacks opportunities. But >> in it self it is not fatal. >>=20 >>=20 >> . >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jul 15 14:34:33 2017 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 C6DFF131465 for ; Sat, 15 Jul 2017 14:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 kYeOl6CqOixU for ; Sat, 15 Jul 2017 14:34:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F022131483 for ; Sat, 15 Jul 2017 14:34:21 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6FLYBiv048382 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jul 2017 22:34:12 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596A8A52.9030108@foobar.org> Date: Sat, 15 Jul 2017 22:34:10 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ole Troan CC: Brian E Carpenter , ipv6@ietf.org Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) References: <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:34:32 -0000 Ole Troan wrote: > DAD is not robust. Last time I tried on the IETF wireless network 1 > time in 4 DAD failed to detect a duplicate. was this an implementation problem or a protocol problem? Nick From nobody Sat Jul 15 14:43:25 2017 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 C46CA12EA74 for ; Sat, 15 Jul 2017 14:43:22 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8lxiIzQmjTyK for ; Sat, 15 Jul 2017 14:43:21 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B557D12EA52 for ; Sat, 15 Jul 2017 14:43:21 -0700 (PDT) Received: from [192.168.10.201] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 52CF52D4FF9; Sat, 15 Jul 2017 21:43:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: <596A8A52.9030108@foobar.org> Date: Sat, 15 Jul 2017 23:43:15 +0200 Cc: Brian E Carpenter , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> To: Nick Hilliard Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:43:23 -0000 Nick, This a protocol problem. DAD is built with the assumption that physical link= s are reliable. 20% packet loss for multicast is common on wifi... Cheers=20 Ole > On 15 Jul 2017, at 23:34, Nick Hilliard wrote: >=20 > Ole Troan wrote: >> DAD is not robust. Last time I tried on the IETF wireless network 1 >> time in 4 DAD failed to detect a duplicate. >=20 > was this an implementation problem or a protocol problem? >=20 > Nick From nobody Sat Jul 15 15:22:57 2017 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 6CAA31205F0 for ; Sat, 15 Jul 2017 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 BQ8giD214jTf for ; Sat, 15 Jul 2017 15:22:55 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3EB1270AC for ; Sat, 15 Jul 2017 15:22:54 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6FMMmWG053999 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jul 2017 23:22:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596A95B7.6000408@foobar.org> Date: Sat, 15 Jul 2017 23:22:47 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ole Troan CC: Brian E Carpenter , ipv6@ietf.org Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 22:22:56 -0000 Ole Troan wrote: > This a protocol problem. DAD is built with the assumption that > physical links are reliable. 20% packet loss for multicast is common > on wifi... most protocols will croak at 20% packet loss. If wifi cannot support multicast properly, then this is an 802.11 problem rather than a problem with DAD or any of the many other bits of ipv6 that depend on moderately reliable multicast. Nick From nobody Sat Jul 15 15:42:00 2017 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 1B885129AA8 for ; Sat, 15 Jul 2017 15:41:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q5z1ZNtpjTYS for ; Sat, 15 Jul 2017 15:41:57 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 6BE1F1276AF for ; Sat, 15 Jul 2017 15:41:57 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id q86so60530754pfl.3 for ; Sat, 15 Jul 2017 15:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=K7WKbkGAmqORknM/4ndXL5T2hRZ7GkSpDgmF8/hmSSM=; b=EAFNgMCiT6+9G0MBgr2e3xeAwSaPKexlBjG45LEOaH50zJKPvc3YaubzL1y4RPRXPi 7MndD3mqX3RMWQ8WmlfpibTNMQvWeI008MA2I3Zzl0KcyWVL4VIb9d+SabgH0UFdw9J6 AsOTtzbrw1bgneWQ/e96aS3Mle7R7VP5OrrKUFTUZneESD5vPzAaI82gqHSFhngusg0F oERqkP8uQz3g4xdVl0hiaStveYmT2MxHoKe/4MvD8zfs+IAjSBSO1x3U3xPXy76oAQKh eVrV7nVKmLddshBwcmRHA+x1RT5epCyeP89WuOSYn62Fmwfvr5R6M94yEJ/7rBlT/U+t /m8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=K7WKbkGAmqORknM/4ndXL5T2hRZ7GkSpDgmF8/hmSSM=; b=YsypB9e7oCVWxa/uLAQo4ckoBI/nq1OSO9NDazLRG2Uybcw7jNuL+2oxIlBVu2i55Z pMdPVQjC9oBXguFY1Ze8bbFnufQAFLkBgnCnVLCjcxFdVSOSbGAAmCvh3dLS/75XDgUf Sg2RqtnkZL0ORsVE3gS79fb3V8sWiWEGNPPSPM+2aBdrsJ6unPLC068e8lZpLIly5f6O e6fdD5C3HSFWCAUaAUSqfO4t80Vkdo9/6aeIGn/ntQs524rJG6BZcRcDdu+zOHKQBkXV Pn2+exr92zDnVp8qWnsS+0syIlxt8baPkelGUNiEP4MDVmNbJVlDvfOY9kkbVF3bzxk7 kqwA== X-Gm-Message-State: AIVw110vYfFtj0D05VXKCJlkNpZOkoZahYS5UvjxO5lj5GhoT4ifBesY CQ16XqjDSG/fQUjC X-Received: by 10.84.132.44 with SMTP id 41mr23508211ple.204.1500158516865; Sat, 15 Jul 2017 15:41:56 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id q29sm33732032pfg.11.2017.07.15.15.41.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 15:41:56 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Nick Hilliard , Ole Troan Cc: ipv6@ietf.org References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> Date: Sun, 16 Jul 2017 10:41:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <596A95B7.6000408@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 22:41:59 -0000 On 16/07/2017 10:22, Nick Hilliard wrote: > Ole Troan wrote: >> This a protocol problem. DAD is built with the assumption that >> physical links are reliable. 20% packet loss for multicast is common >> on wifi... > > most protocols will croak at 20% packet loss. If wifi cannot support > multicast properly, then this is an 802.11 problem rather than a problem > with DAD or any of the many other bits of ipv6 that depend on moderately > reliable multicast. I'm curious. If DAD has that problem, why doesn't Neighbor Discovery have an equally bad problem? BTW, Ole is correct. While testing the GRASP prototype at the last IETF, we discovered a high loss rate for LL multicast on the network. However, it wasn't primarily due to WiFi. It was due to intentional multicast throttling in the switches: https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ Brian From nobody Sat Jul 15 16:37:50 2017 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 91AAD131566 for ; Sat, 15 Jul 2017 16:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUkQQSJAX4Ht for ; Sat, 15 Jul 2017 16:37:46 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 992001274D0 for ; Sat, 15 Jul 2017 16:37:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 0154CB72 for ; Sat, 15 Jul 2017 23:37:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5otjXLhotGcJ for ; Sat, 15 Jul 2017 18:37:45 -0500 (CDT) Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id C75FCB4D for ; Sat, 15 Jul 2017 18:37:45 -0500 (CDT) Received: by mail-it0-f71.google.com with SMTP id r4so142937055ith.7 for ; Sat, 15 Jul 2017 16:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oUaNGTyQOTftccZS1W3IAdGue2pqMZShqaEvEqMG71k=; b=YcTSQEfCQEnWw6BQxIJEnz257jXylaQNC55nWyUSnPedf6Ap0AxnhwGRVMKdkC6xIN bt9RJXzb/705ZdCxpa4mwEIbKEhBQxulmCcLHWN1KAQi6Fu2DZT3H+yBQo65C5Uh0Gj6 jfvKvxKkiQVwvXUH9IeNBe7tTWGWDGMNxQhG0ED+9GBvo9JfgioJ4X4mREP4pge8k5dG ED5x8VHiOJ5g0asKxc2FIpKIM95MVmHtn9GUz0WX/dEEkcTrFy6rjx/6METfjJc8TwCR jHE0NRYqGCduAwIHNWMEhzSqUWU4BdHoqNIaLAs4eQXSnj7FehnfcT5LhCrEegWXWwvn ubYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oUaNGTyQOTftccZS1W3IAdGue2pqMZShqaEvEqMG71k=; b=diq1kz+ERRlN5XlMUbc+mynnC6ec04DRPcjZqDzuoxqzaEMeZqumw2TkVlNPTT0z/c VTdUxNv5p7/2KhfEpEi7j71rHgU1AvIJp+8uEWIhSdHoST002cgJ3VlIL5bgkzlgjUPR NY3NqlIz2FsQFe1yhOqbi5Wpjgn/Q1O7opXB+t30fruUl/IkOhE6YXF4dV5ySJgbtJG4 pSj+dPbPGDAPFFfFGKOqnbM+AivgzY35Toy2wRmEWfm+iRcuT4jeeGXQH0r3X4EVzoY9 L54jXk+XJUi3QMI7c6roZ2KsRzbnj8+qQNfknZKa/VrSAeWFOQie7nqCJNfXMAc/sV/r /WuQ== X-Gm-Message-State: AIVw113aNZZhXmLZR+QTxxuPpfLwyo6mGwonlA6NYDCntiO6ChyiFh5n +g6dyM18kC+4oNcuX4R/Hnlkp5Wd/uGy8fUA3PpjE/XgdrTLpQMUeWT+9hvSbwKJDvQk0wrdq04 = X-Received: by 10.36.22.17 with SMTP id a17mr583986ita.40.1500161864946; Sat, 15 Jul 2017 16:37:44 -0700 (PDT) X-Received: by 10.36.22.17 with SMTP id a17mr583978ita.40.1500161864762; Sat, 15 Jul 2017 16:37:44 -0700 (PDT) Received: from [10.174.89.216] (mobile-166-175-56-16.mycingular.net. [166.175.56.16]) by smtp.gmail.com with ESMTPSA id g26sm2496364ioj.62.2017.07.15.16.37.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 16:37:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> Date: Sat, 15 Jul 2017 18:37:42 -0500 Cc: Nick Hilliard , Ole Troan , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 23:37:49 -0000 > On Jul 15, 2017, at 17:41, Brian E Carpenter = wrote: >=20 >> On 16/07/2017 10:22, Nick Hilliard wrote: >> Ole Troan wrote: >>> This a protocol problem. DAD is built with the assumption that >>> physical links are reliable. 20% packet loss for multicast is common >>> on wifi... >>=20 >> most protocols will croak at 20% packet loss. If wifi cannot support >> multicast properly, then this is an 802.11 problem rather than a problem >> with DAD or any of the many other bits of ipv6 that depend on moderately >> reliable multicast. =20 >=20 > I'm curious. If DAD has that problem, why doesn't Neighbor Discovery > have an equally bad problem? >=20 > BTW, Ole is correct. While testing the GRASP prototype at the last IETF, > we discovered a high loss rate for LL multicast on the network. > However, it wasn't primarily due to WiFi. It was due to intentional > multicast throttling in the switches: > https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND pro= xy, and they convert the responses from the proxy to unicast at the 802.11 l= ayer. Sometimes they even only do unicast at the 802.11 layer and replicate a= ll multicast into 802.11 unicasts. Frequently this is more efficient than mu= lticast because of the differences between the basic rate encoding used for m= ulticast packets vs the usually much higher density encoding used for unicas= t packets. That usually keeps things working well enough.= From nobody Sat Jul 15 16:59:57 2017 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 474BE129AE7 for ; Sat, 15 Jul 2017 16:59:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7uOWwKGbtxRO for ; Sat, 15 Jul 2017 16:59:54 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5465612778D for ; Sat, 15 Jul 2017 16:59:54 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q85so60921316pfq.1 for ; Sat, 15 Jul 2017 16:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZIhPOzRz2E5I96Vm+G0k9Dc3PzzDgP52FPQYM7Yr8ts=; b=LTZk6adWhlSoe3jcd6h8VtanOGDh5pxGM0Wm/xmL/Nl1sXyepnaEnj4dp8T5FKANeQ xNGRuyd81IfXbfCHtLmuwSL02B1l3Ix0Nv9a4Ftrgarsy6bZbiamjQA2sfLrNiEtGomn o0VQoykhyqkfzj/mfoLZsYtR7SR05UnFT1nc2qygMvFpF04kZ5bPVFRdeBBCbKrL9U4i 3Bo4B/EHAvQJ/6nuRmTAcSc1+e3ijuTIB8bMsZBEro1B6SBmU83d/OSow5rFMb76+3E/ 112PxfYHRqSMsnZpOv9rmfLax161ej5/swYGJ2VYBO2V7RMKn1v6jHS3bP+Vkue6rdI/ B3tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZIhPOzRz2E5I96Vm+G0k9Dc3PzzDgP52FPQYM7Yr8ts=; b=QRLXbyVgAuajN5iAjHg0W0pA7rhth2I/N13sw8yA+XbTG/3O1iZbIFUbR2yVKFiYXt hJK3WyIHVqlo8tAogfW8uPRovBlBxtkr8UnSXEz4C76zWJShmWdXrQYzuvnbnpsPMH7/ rIUTaWhm92RB5/Ivm+63/8pABrRAr/t+6YGB9eSOYIZP+cby7OhcXwDPWQMSwYUuDidW UUgcxpMi/P51zmk2UYeZhvGWwP+pU4PrSGDOKg9dztrn7+MzUaAjNi58Lry9W82BXBVX JoBOgXKMMDnoz3sNpbE7aX6GFdFdV7rZufXHG0hV1/Um+zy/6XcqpMNW2T4K7efKgkU/ MVRg== X-Gm-Message-State: AIVw111TbhlQUrnPEgrcPPhnmMZFpupW+vVQpFWm0gmiI/guRdXROo3i zEdHGI7TD6d9noz4 X-Received: by 10.84.134.34 with SMTP id 31mr23647986plg.57.1500163193703; Sat, 15 Jul 2017 16:59:53 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id u63sm10704110pgd.49.2017.07.15.16.59.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 16:59:52 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: David Farmer Cc: Nick Hilliard , Ole Troan , ipv6@ietf.org References: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 16 Jul 2017 11:59:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 23:59:56 -0000 On 16/07/2017 11:37, David Farmer wrote: > >> On Jul 15, 2017, at 17:41, Brian E Carpenter wrote: >> >>> On 16/07/2017 10:22, Nick Hilliard wrote: >>> Ole Troan wrote: >>>> This a protocol problem. DAD is built with the assumption that >>>> physical links are reliable. 20% packet loss for multicast is common >>>> on wifi... >>> >>> most protocols will croak at 20% packet loss. If wifi cannot support >>> multicast properly, then this is an 802.11 problem rather than a problem >>> with DAD or any of the many other bits of ipv6 that depend on moderately >>> reliable multicast. >> >> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery >> have an equally bad problem? >> >> BTW, Ole is correct. While testing the GRASP prototype at the last IETF, >> we discovered a high loss rate for LL multicast on the network. >> However, it wasn't primarily due to WiFi. It was due to intentional >> multicast throttling in the switches: >> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ > > Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND proxy, and they convert the responses from the proxy to unicast at the 802.11 layer. Sometimes they even only do unicast at the 802.11 layer and replicate all multicast into 802.11 unicasts. Frequently this is more efficient than multicast because of the differences between the basic rate encoding used for multicast packets vs the usually much higher density encoding used for unicast packets. > > That usually keeps things working well enough. ND proxy shouldn't break DAD, as I understand RFC4389. So logically, DAD is just as reliable as basic ND, right? Brian From nobody Sat Jul 15 17:32:54 2017 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 644FF12F253 for ; Sat, 15 Jul 2017 17:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC4U_y1be1mv for ; Sat, 15 Jul 2017 17:32:51 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 AB03C12F092 for ; Sat, 15 Jul 2017 17:32:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 04744D1E for ; Sun, 16 Jul 2017 00:32:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVwRqWeam93m for ; Sat, 15 Jul 2017 19:32:50 -0500 (CDT) Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id D5BBFCE4 for ; Sat, 15 Jul 2017 19:32:50 -0500 (CDT) Received: by mail-it0-f72.google.com with SMTP id v127so25764583itd.3 for ; Sat, 15 Jul 2017 17:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDs1pR/Py6Hku3ISPmrkq1v/ajtLBOYduOp/cdBbeXc=; b=qpkcvhcbmZ48YJsCAfhUUnsYDab84q4qsWRwUZn9EMl6D1LzkR3UEur8awokc/oK4m 3K9ofShTX1pg7F+maoLRa9vKj113Gcs3+DIGRZoXcYeHOqPda/Jaz4qInttuv2+xVa+F BqjBsRVFprIpIbVQ0jRn9QQLmp82SxGnO75TerVpkQbTbLfd9oAVDATFVMsxLOkkDtj/ puDajNvz33zmaTgNqzIvBiA9+3gQBYCXT3nzsoBRQOHu2OZT2cYquRY5eikwttya7d5h f0iuyGbvPQf8OYcl9bt2HCjvgIIqoJ/+jqJ+UwEgpYAVR6h/NPE5EdoKUemsvpUk0bmG UiHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDs1pR/Py6Hku3ISPmrkq1v/ajtLBOYduOp/cdBbeXc=; b=AGy3wEtSe0kpyDWqA+ksHMLb6IVohBw0gxK1p3IAjwu1+Ug8vyhKqzvgANoecbM2rZ PwsEIJHY3tRYZvT24P+rX7q7IslYCVByXZkGhL2jeiyy+ALg8GzPJNohtdHFzQ3+ZVlK RCDS8eonBSld/HKRiV5s2veDOJNdp1m6oJ47bS6JFqaQS+NsvUteU4sSrbhG6LHmXq/5 xEe51p0UNpQZVzauraZPj7e4vb8/ZgjM4Q6f1vvKq5O0j4h3GVSWzh5I2EuQy7LLCOeV A8/dLrj1RozuGWfAR6j/OV3VgOtzQK46BjLjCGGlvap1NHoqMVdexNTE/6Jjhk0IB9aJ Ke/A== X-Gm-Message-State: AIVw111KiApKmOOBZDa93/BTN3yhGMP3+FpNopzRfmHaWRCb6SU5LexQ FBXd8rtHWVLxtrUME3La4KHRSxz5qwSFAw5h3eszChBIFtIDfMPnsOK8ewfEmpGLzeSHUDuq+Lw = X-Received: by 10.107.11.87 with SMTP id v84mr14494067ioi.85.1500165169745; Sat, 15 Jul 2017 17:32:49 -0700 (PDT) X-Received: by 10.107.11.87 with SMTP id v84mr14494062ioi.85.1500165169539; Sat, 15 Jul 2017 17:32:49 -0700 (PDT) Received: from [10.174.89.216] (mobile-166-175-56-16.mycingular.net. [166.175.56.16]) by smtp.gmail.com with ESMTPSA id h196sm6854992ioe.41.2017.07.15.17.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 17:32:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sat, 15 Jul 2017 19:32:46 -0500 Cc: Nick Hilliard , Ole Troan , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23900F8F-CA9E-4087-A7C5-5ED5FB220F45@umn.edu> References: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 00:32:53 -0000 Sent from my iPhone > On Jul 15, 2017, at 18:59, Brian E Carpenter = wrote: >=20 >> On 16/07/2017 11:37, David Farmer wrote: >>=20 >>>> On Jul 15, 2017, at 17:41, Brian E Carpenter wrote: >>>>=20 >>>>> On 16/07/2017 10:22, Nick Hilliard wrote: >>>>> Ole Troan wrote: >>>>> This a protocol problem. DAD is built with the assumption that >>>>> physical links are reliable. 20% packet loss for multicast is common >>>>> on wifi... >>>>=20 >>>> most protocols will croak at 20% packet loss. If wifi cannot support >>>> multicast properly, then this is an 802.11 problem rather than a proble= m >>>> with DAD or any of the many other bits of ipv6 that depend on moderatel= y >>>> reliable multicast. =20 >>>=20 >>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery >>> have an equally bad problem? >>>=20 >>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,= >>> we discovered a high loss rate for LL multicast on the network. >>> However, it wasn't primarily due to WiFi. It was due to intentional >>> multicast throttling in the switches: >>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ >>=20 >> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND p= roxy, and they convert the responses from the proxy to unicast at the 802.11= layer. Sometimes they even only do unicast at the 802.11 layer and replicat= e all multicast into 802.11 unicasts. Frequently this is more efficient than= multicast because of the differences between the basic rate encoding used f= or multicast packets vs the usually much higher density encoding used for un= icast packets. >>=20 >> That usually keeps things working well enough. >=20 > ND proxy shouldn't break DAD, as I understand RFC4389. So logically, > DAD is just as reliable as basic ND, right? That is my understanding. =20 But I probably should have mentioned that older APs, especially older consum= er grade APs, might not have any IPv6 support. So it might only do arp prox= y, and ND and DAD could suck rocks, compared to arp. Also, another good rea= son to keep software updated. Also, obviously adhoc mode WiFi has none of that as there are no APs.=20= From nobody Sat Jul 15 21:06:16 2017 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 D167B127735 for ; Sat, 15 Jul 2017 21:06:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 avEV_5HP-89w for ; Sat, 15 Jul 2017 21:06:13 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796181252BA for ; Sat, 15 Jul 2017 21:06:13 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q86so62087253pfl.3 for ; Sat, 15 Jul 2017 21:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oHbsRZu4hxl6inY694yaPOPW7gGZMhpTcXnk+xSONs4=; b=Ze/orWdqiJXCIMXkSKs/nOew1xum4MmzGujbuiufWz06BmWx8/ryl37qNzRuO3oNaJ bpvrgbRCT6jBeFKUREMG7ycLVKSw7VZQNPYS16PaUngSkvY3L+SCbglxWR1RvF1BykTj p3PLs1QPYON7OdCjvN41dy5Ov8dOrSPBdFGtltvG2Q4GWFxnGHPt2uAhPgQjubYDYrpt BMsRl4bv/ERBcH65TRm/ePQuIi9uMn5RwBnTWB2HrUNUnDC0cpoCy7PRIbJQRxZK16JX VoaDHfC1iBfDdhA9X7V88YufXndXWwUM/wII/QhHs3/dpRCQlWBh4lYLDtYh7nsbyU0J Gxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oHbsRZu4hxl6inY694yaPOPW7gGZMhpTcXnk+xSONs4=; b=S9+xVMvcpcDm/d/ye/MnhnLexxnKKjS3FjsWqrVr9MJ3apcb1zPmCvqfikaMaOcYDl 5/VVXUs2k8vUy+x0icSv2KcsGsZEPeQugWjjjAwDehkhGyEunUAqYi597nfuqYmaICHf daeA4PrXe6OOjlwm/z9pipQ+jfIxpl6GIlfSlzIuHAfiRR0fwHJSRXRzohoBfv1H7lve GtNLFkY5rU5EkzHPpP7WjMW6/8Cm2YGEXWW96u39vBVBieSEVYhNn412sFszM0nMKaMc +mXjiltJPtecNMLHeM1aMMf/TxFGjkKFWUXyUqlMh1dV2pQiNlNkjVWDT4arKqyzWY0S j9EQ== X-Gm-Message-State: AIVw112SNoLb89r0QIQyX+NCVVKa4e4aDq1Sjzf+z3cdHh+3j36cIhJV GrRNsgbiwu9NXjiw X-Received: by 10.99.110.7 with SMTP id j7mr22567953pgc.169.1500177972800; Sat, 15 Jul 2017 21:06:12 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id m79sm27877175pfk.35.2017.07.15.21.06.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 21:06:11 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: 6man References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 16 Jul 2017 16:06:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149909644776.22718.16227939850699261560@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 04:06:15 -0000 Hi, Some comments, but not a full review: > - IPv6 over ATM Networks [RFC2492] Is this still worth mentioning? > - IP version 6 over PPP [RFC5072] > > In addition to traditional physical link-layers, it is also possible > to tunnel IPv6 over other protocols. Examples include: Shouldn't PPP be in this list, not the previous list? > - Teredo: Tunneling IPv6 over UDP through Network Address > Translations (NATs) [RFC4380] > > - Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and > Routers" [RFC4213] > > **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and > issues like RFC 6935, or 6936?** Maybe. But the field is evolving: Teredo is surely obsolescent, there's also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder what you can really say. > 5.1. Internet Protocol Version 6 - RFC 2460 > > The Internet Protocol Version 6 is specified in [RFC2460]. This > specification MUST be supported. > > **BIS Again, update for RFC 2460 -bis ** > > Any unrecognized extension headers or options MUST be processed as > described in RFC 2460. As well as s/2460/8200/, I suggest s/processed/treated/ to avoid another debate about the meaning of 'processed' ;-). (And don't forget s/1981/8201/.) > 5.7. IPv6 Jumbograms - RFC 2675 ... > and there is essentially no reported experience from usage. > Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. > > **BIS Are these used? Do we need to modify the text for that? ** I don't think so. They appear to be harmless and maybe somebody will need them one day, so there is no obvious argument for deprecation. > 5.10. First-Hop Router Selection - RFC 8028 ... > Hosts that may be deployed in such multihomed environments SHOULD > follow the guidance given in [RFC8028]. Which should therefore be listed as a Normative reference. > 6.1. IP Version 6 Addressing Architecture - RFC 4291 > > The IPv6 Addressing Architecture [RFC4291] MUST be supported. > > **BIS Update to 4291-bis ** Maybe not :-( > **BIS Add note on Why /64? RFC 7421, after the conclusion of the > RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic. But no > need for /127 p2p text RFC 6164. And no need for note on IID > significance, as per RFC 7136. ** I'm not sure we need to mention RFC 7421 here at all. If 4291bis gets published, it will be mentioned there. If it doesn't get published, 64 remains fixed anyway. > 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 > > Hosts MUST support IPv6 Stateless Address Autoconfiguration as > defined in either [RFC4862] or [RFC7217]. That's wrong, surely? SLAAC is defined in 4862, and 7217 doesn't even formally update it. I think you should simply delete 'or [RFC7217]'. > It is recommended that, > unless there is a specific requirement for MAC addresses to be > embedded in an IID, nodes follow the procedure in RFC7217 to generate > SLAAC-based addresses. That only applies if a stable IID is wanted. I would suggest: It is recommended that, unless there is a specific requirement for MAC addresses to be embedded in an IID, nodes follow the procedures in [RFC7217] or [RFC4941] (see below) to generate SLAAC-based addresses. (I think we've already established that it's possible to operate a node that has no stable global-scope address.) > 6.6. Default Address Selection for IPv6 - RFC 6724 > > IPv6 nodes will invariably have multiple addresses configured > simultaneously, and thus will need to choose which addresses to use > for which communications. The rules specified in the Default Address > Selection for IPv6 [RFC6724] document MUST be implemented. I am concerned about the famous rule 5.5 in RFC6724. It's optional there, but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn promotes rule 5.5 to a SHOULD. Could we add that promotion here too? Otherwise there is a complicated trail for implementers to follow. > 14. Router-Specific Functionality I think you should require BCP198 (RFC7068) support. Regards Brian From nobody Sat Jul 15 22:50:06 2017 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 C207012700F for ; Sat, 15 Jul 2017 22:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zcI1Z56Q4Hl9 for ; Sat, 15 Jul 2017 22:50:03 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F061120726 for ; Sat, 15 Jul 2017 22:50:03 -0700 (PDT) Received: from [192.168.10.201] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id AFE282D4F96; Sun, 16 Jul 2017 05:50:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: Date: Sun, 16 Jul 2017 07:49:55 +0200 Cc: David Farmer , Nick Hilliard , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <92A09555-5A34-406C-B5BB-D5C02D6AD431@employees.org> References: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <6a23ce43-89c3-0b37-a2da-70d40ba48b53@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 05:50:05 -0000 > On 16 Jul 2017, at 01:59, Brian E Carpenter w= rote: >=20 >> On 16/07/2017 11:37, David Farmer wrote: >>=20 >>>> On Jul 15, 2017, at 17:41, Brian E Carpenter wrote: >>>>=20 >>>>> On 16/07/2017 10:22, Nick Hilliard wrote: >>>>> Ole Troan wrote: >>>>> This a protocol problem. DAD is built with the assumption that >>>>> physical links are reliable. 20% packet loss for multicast is common >>>>> on wifi... >>>>=20 >>>> most protocols will croak at 20% packet loss. If wifi cannot support >>>> multicast properly, then this is an 802.11 problem rather than a proble= m >>>> with DAD or any of the many other bits of ipv6 that depend on moderatel= y >>>> reliable multicast. =20 >>>=20 >>> I'm curious. If DAD has that problem, why doesn't Neighbor Discovery >>> have an equally bad problem? >>>=20 >>> BTW, Ole is correct. While testing the GRASP prototype at the last IETF,= >>> we discovered a high loss rate for LL multicast on the network. >>> However, it wasn't primarily due to WiFi. It was due to intentional >>> multicast throttling in the switches: >>> https://mailarchive.ietf.org/arch/msg/anima/g4SUu-Bhkew-54hiJF1VPP8tfcQ >>=20 >> Wifi APs, especially enterprise grade Wifi APs, frequently do arp and ND p= roxy, and they convert the responses from the proxy to unicast at the 802.11= layer. Sometimes they even only do unicast at the 802.11 layer and replicat= e all multicast into 802.11 unicasts. Frequently this is more efficient than= multicast because of the differences between the basic rate encoding used f= or multicast packets vs the usually much higher density encoding used for un= icast packets. >>=20 >> That usually keeps things working well enough. >=20 > ND proxy shouldn't break DAD, as I understand RFC4389. So logically, > DAD is just as reliable as basic ND, right? Wrong.=20 DAD is by default a single fire and forget packet.=20 If you by basic ND mean address resolution, then that retries three times. A= nd the consequences of failure are quite different.=20 Ole= From nobody Sat Jul 15 23:31:18 2017 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 926FF1271DF for ; Sat, 15 Jul 2017 23:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 GpRpiuJlSbZ2 for ; Sat, 15 Jul 2017 23:31:14 -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 A8E57126B7F for ; Sat, 15 Jul 2017 23:31:14 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id r126so63689498vkg.0 for ; Sat, 15 Jul 2017 23:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YQ+CY/apj5t/YGl3GM7wW9trpjrBX0X9h6pBu0luaho=; b=ambunfGCCEv7t3mgqUozEELYZti75IqC1+aGSMzHHGJ1wPhFLi3yt08xQTAUcoUoBf /5TKJpnGzQTAUT+P4IgdzG0iNkgZooFvxbgEXkTsa/x3LDX2MeZps38+zoZQpG4idqxx UAKPEquQvw0PeF6petnaP8Jubv+7be5h08poBhT/JF2Pag0xWUBwJ5pI8NqW/a7Hqxbm hM7xg+0SaR8IpdjAmQBrY3jW3HHlNNbiGNCnckEaogMJWhytcgYiisTsNOe07Iq+5AJ2 YxMBRFUNcUC/WS7uniDXyUgiC9dwcgMHIRW1m2eL81MdxQ2Eub65VLb0wKDxYlBmoOYO aqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YQ+CY/apj5t/YGl3GM7wW9trpjrBX0X9h6pBu0luaho=; b=pJDqMo4MvbxrhCXRqAJpeOxHKfEbve7kLeKBmD5PEL5XcJLWByGAL2V4rqrO4f+aLs aIXbgcZAKTO/XZfz5ncMQHaf7R/sD2uRTzPwDFtq/E3n8lAX4oNfp7OX4xN9xaXosuP0 VDl0lBBtluNT5oorLJVggRurY1SsNZcMMYgQ3K26DUuLJRA8Jx82uYnIcOm+fUWet2Bz 3ibVd9GdS8fIPzZJN3sg80JFJ3ZIhw79nmmtGpRSWmbd2AYog2hf7speROfP6boNXVFW NnZxCrSP7ak6Z75Mu2qMHmKNbzMqGENHokOmN4TSmlbwGcf6FvzR44bRzXlK7FVe5bQr K0Lg== X-Gm-Message-State: AIVw113z4ZqYXq/47oZGCkbAGidC7pBiHV/7r8LQFX37caNK0CH0sRbT hJpUB7Une/rNy4UfxUBmPUoL/ks+reik X-Received: by 10.31.238.196 with SMTP id m187mr9649953vkh.96.1500186673649; Sat, 15 Jul 2017 23:31:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Sat, 15 Jul 2017 23:30:42 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Sun, 16 Jul 2017 16:30:42 +1000 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Philip Homburg Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 06:31:17 -0000 On 15 July 2017 at 23:51, Philip Homburg wrote: >> > However, since the mid 90s we have a protocol for dense allocation of >> > addresses. Where in the 64-bit IID space you can fit an entire universe. >> >> In a flat universe, maybe. No one is disputing that 64 bit IIDs >> allow for many hosts in a single subnet prefix. But we also discovered >> in the 1980s and 1990s how bad it is to create gymongous IP subnets. > > Just in case you missed it, I'm advocating that 64 bit IIDs only apply to > SLAAC and not to DHCPv6 IA_NA. > > So using DHCP, a /64 prefix can be subdivided exactly as you want. You can > for example hand out a /96 prefix using IA_PD to every link and then > per link you still have more than enough addresses. > More than enough addresses for what specifically? Privacy and security get lost with /96 prefixes. Trying to accommodate /64 per multi-subnet site is trying to accommodate irrationality. When a the smallest GUA allocation from an RIR provides 4 billion /64s and a ULA provides 65 536 /64s (and of course you can generate more of your own ULA /48s if that is not enough), being miserly with IPv6 /64s is irrational. We can go down that path, and we'll end up trying to engineer around greater and greater irrationality - "If you make something idiot proof, someone will just make a better idiot." We know the likely final end-result of accommodating >/64s would be a /128 per site and IPv6 NAPT, because irrational people will treat IPv6 addresses as though they're gold rather than lead, because they can. > Note that I believe Lorenzo's argument is valid. The reason we can expect a > /64 to be there is that SLAAC requires a /64. If we relax that requirement > then soon we will see longer prefixes pop up and are back to square one. > > For DHCP I don't care. For SLAAC I just don't want the collision risk. So > keep SLAAC at 64 and use DHCP for anything else. > Collision risk also exists in DHCPv6. There is no requirement that a single prefix is exclusively using stateful DHCPv6 or exclusively using SLAAC. OpenWRT by default provides addresses via SLAAC and stateful DHCPv6 from within the same prefix. rfc3315bis is adding an a MUST DAD check because of this. Worse, OpenWRT uses the same IPv4 address range size for IPv6 stateful DHCPv6. Your host can have SLAAC generated 64 bit privacy addresses and 64 bit RFC7217 stable addresses, and then if it too supports stateful DHCPv6, then it's stateful DHCPv6 addresses will be from an address space smaller than 8 bits, from within a GUA prefix. Regards, Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jul 15 23:41:52 2017 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 C75FE12785F for ; Sat, 15 Jul 2017 23:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, 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 XbU022Dz1W3b for ; Sat, 15 Jul 2017 23:41:48 -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 0C5951271DF for ; Sat, 15 Jul 2017 23:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1500187307; x=1501396907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wm77yizVSqyFcrpfGk6sBuiyKfZOvxbxOs95wmz+5vM=; b=mIhjdz6kk3qZPbQqwwOtGe3m1P+N5uqYqC28Ze+EF/9EjVnZFh7NSd+k TgkFEXXMvuR21f5n6VIDGLP0KFy0P2TNI6VGHn48EkHZp2Qaw1tSKePF5 lBUirdToA2lRYsjOHfq5KbUrqqdppJyUbuxztXEe+6qC+1XbKDblWoOHS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgBECmtZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRSfSCKILo1WghEhC4UbAoNxQBcBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQFsCwULAgEIGC4hBgslAgQOBYoXAw0IELA3hykNg10BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYMog02CDAuCboJXghODQ4IxBYlcBYc+jVo7Ao8khHAMkiO?= =?us-ascii?q?MColMASEBNYEKdRVJEgGFABwZgU52AYhVAQEB?= X-IronPort-AV: E=Sophos;i="5.40,367,1496102400"; d="scan'208";a="268417567" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 06:41:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6G6fkT3002960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 06:41:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 01:41:46 -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; Sun, 16 Jul 2017 01:41:46 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter CC: Philip Homburg , "ipv6@ietf.org" Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS/a2ZuieUK0MP90SlnyedjyZgWqJWAdXp Date: Sun, 16 Jul 2017 06:41:46 +0000 Message-ID: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> , <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> In-Reply-To: <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 06:41:50 -0000 Hello Brian: I'd say that DAD detecting a duplication is not a failure; just doing its j= ob right. The DAD failure that hurts is DAD false negative like can be easily obtaine= d on wireless because the reliability of the multicast is largely differen= t from that of wire. Are we ready to say that addresses that are generated with enough randomnes= s in them do not need DAD? Pascal > Le 15 juil. 2017 =E0 23:01, Brian E Carpenter a =E9crit : >=20 > On 16/07/2017 01:39, Philip Homburg wrote: >>> This is backwards. The goals of pseudo-random IIDs are to reduce the >>> probability that scanning attacks find hosts, and to reduce the risk >>> of IIDs being used to breach privacy. >>>=20 >>> If these goals are met, the collision probability will in any case >>> be low, so DAD failure will be exceedingly rare. >>=20 >> I completely disagree. A collision is fatal. We are nowhere near transpa= rently >> handling all collisions. At best we can hope that DAD can make one node >> continue unaffected. >=20 > I'm confused. >=20 > Firstly, do we have any experimental evidence that collisions > are a real operational problem? (Obviously, MAC address collisions are > disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to > detect them, they are irrelevant to the current discussion.) >=20 > Secondly, if a collision does occur with IPv6+(pseudo-random IID), > recovery is obvious: after DAD failure, generate a new pseudo-random > IID and try again. This is perfectly compatible with RFC4862 section 5.5 > and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy > addresses. >=20 > Brian >=20 >>=20 >> In contrast, people have been scanning my IPv4 ranges for the past 20 ye= ars >> or so. That may be annoying. That may amplify attacks opportunities. But >> in it self it is not fatal. >>=20 >>=20 >> . >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jul 15 23:59:01 2017 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 501161270A0 for ; Sat, 15 Jul 2017 23:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, 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 QsyVS1EeSL3J for ; Sat, 15 Jul 2017 23:58:58 -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 CAF8E120454 for ; Sat, 15 Jul 2017 23:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5840; q=dns/txt; s=iport; t=1500188337; x=1501397937; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=la1HiYnEF+/DppdknqlmXrpceW5HcKpEzeJfvCW1V3c=; b=BdYz5RNpZ+KgE3VTipKTonBXndlRl/54yHLUEC4rPu4GPB+rhOOXzBgE QYPSDFwtCe2IkSZ0xwiLOck4s2BDddK7/SDvVTEINUmzlrcyugjyRf2Hj g0fsMJscqyVyeZcsYVg8aWmA9LIgklqbrhwl1o9lM0bj5OIFFPaWYrfzZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQBADmtZ/49dJa1CGhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNaZIEUjguRPZB6hSyCESEBDoUXAoNxPxgBAgEBAQEBAQFrKIUZAgE?= =?us-ascii?q?DAQFsCxACAQg/BycLFBECBA4FG4kwZBAysAGLEwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgyiDTYIMC4JugyaFB4IxBYlcjWaHcgKHSIxMki+VVgEfOIEKdRUfKhI?= =?us-ascii?q?BhTWBTnYBAYhUAQEB?= X-IronPort-AV: E=Sophos;i="5.40,367,1496102400"; d="scan'208,217";a="454440557" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 06:58:48 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6G6wm1A011897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 06:58:48 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; Sun, 16 Jul 2017 01:58:47 -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; Sun, 16 Jul 2017 01:58:48 -0500 From: "Pascal Thubert (pthubert)" To: Nick Hilliard CC: Ole Troan , "ipv6@ietf.org" Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS/a2ZuieUK0MP90SlnyedjyZgWqJVuZOAgAADEwCAAAKKgIAACwyAgAA8W14= Date: Sun, 16 Jul 2017 06:58:48 +0000 Message-ID: <5C6E9C30-0217-4EEC-8A8D-F204002BE095@cisco.com> References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> , <596A95B7.6000408@foobar.org> In-Reply-To: <596A95B7.6000408@foobar.org> 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: multipart/alternative; boundary="_000_5C6E9C3002174EEC8A8DF204002BE095ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 06:58:59 -0000 --_000_5C6E9C3002174EEC8A8DF204002BE095ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I respectfully disagree. There are a number of cases where an SDO designs on false assumptions of wh= at the other is doing. IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which ena= bles DAD and discovery to be perfectly fine. ND also expects that the core = service that 802.1 provides on Ethernet (reliable broadcast) extends to the= whole ESS so we have our problems solved. Sadly, no such thing. The same exists in the other direction as well. IEEE expects that the AP wi= ll implement a magical ND proxy and that solves the problem. Again, the IET= F has no such thing, at least for ND. Some people at IEEE think that bridgi= ng 48bits address to 64bits addresses will enable bridging with all it's ni= ce properties on 802.15.4 links. Good thing this illusion is dissolving rap= idly. The solution is probably to stop throwing our problems over the fence (than= ks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,= _do_it_yourself The solution is probably to understand the IEEE design of an ESS for L2 ope= rations and emulate it at L3. A step towards reconciliation of the designs = may be to effectively provide the proxy that the IEEE expects to see at the= boundary of the mediums. All the best, Pascal Le 16 juil. 2017 ? 00:23, Nick Hilliard > a ?crit : Ole Troan wrote: This a protocol problem. DAD is built with the assumption that physical links are reliable. 20% packet loss for multicast is common on wifi... most protocols will croak at 20% packet loss. If wifi cannot support multicast properly, then this is an 802.11 problem rather than a problem with DAD or any of the many other bits of ipv6 that depend on moderately reliable multicast. Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_5C6E9C3002174EEC8A8DF204002BE095ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I respectfully disagree.

There are a number of cases where an SDO designs on false assumptions = of what the other is doing.

IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups whic= h enables DAD and discovery to be perfectly fine. ND also expects that the = core service that 802.1 provides on Ethernet (reliable broadcast) extends t= o the whole ESS so we have our problems solved. Sadly, no such thing.

The same exists in the other direction as well. IEEE expects that the = AP will implement a magical ND proxy and that solves the problem. Again, th= e IETF has no such thing, at least for ND. Some people at IEEE think that b= ridging 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 l= inks. Good thing this illusion is dissolving rapidly.

The solution is probably to stop throwing our problems over the fence = (thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,= _do_it_yourself

The solution is probably to understand the IEEE design of an ESS for L= 2 operations and emulate it at L3. A step towards reconciliation of the des= igns may be to effectively provide the proxy that the IEEE expects to see a= t the boundary of the mediums.

All the best,

Pascal

Le 16 juil. 2017 à 00:23, Nick Hilliard <nick@foobar.org> a écrit :

Ole Troan wrote:
This a protocol problem. DAD is built with = the assumption that
physical links are reliable. 20% packet los= s for multicast is common
on wifi...

most protocols will croak at 20% packet loss.  If wifi cannot su= pport
multicast properly, then this is an 802.11 problem rather than a prob= lem
with DAD or any of the many other bits of ipv6 that depend on moderat= ely
reliable multicast.    

Nick

--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
--_000_5C6E9C3002174EEC8A8DF204002BE095ciscocom_-- From nobody Sun Jul 16 00:59:19 2017 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 9307E1275AB for ; Sun, 16 Jul 2017 00:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.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 Yl9lKOSuvesz for ; Sun, 16 Jul 2017 00:59:15 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34F1127180 for ; Sun, 16 Jul 2017 00:59:14 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id f68so60301223vkg.2 for ; Sun, 16 Jul 2017 00:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ek7ogEO4E+gsDpM2jNG0EMOFY4Za7M0od99ZXp6iyKU=; b=ZOg1oHiQ/WsgHG8KZ/f/6dB4yDCdV/LYXGM2kxrKCPcOEtjJj43yehKKJ3uTUN5kYY ENp4I2pHY5lIXgAMKMmwN7RCbBPwyz+gmYl7USfm8N4hXvrgDetZ/yzlIlRRhX2s6RAZ usNdV8lQ8GoMswjtN4PQ50I6SIddyp4+qhLj2Fug1aA887PSrxeNWd/iIEXCQzvgUpQA P8puCmBpMz3DK5/DtsYpy34UBiKSVGN/79IIgrkiTpdfesqW7fmS95Kantyjcr/isTYi hcxr1Rjzm5o+4TDlyPbuHCP0YEMDw1b3bmP1j2CvoF/k+8W+OAJRzQvlHbc/I+LZ8fHB FwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ek7ogEO4E+gsDpM2jNG0EMOFY4Za7M0od99ZXp6iyKU=; b=o7LBzfV+8pt9/caHEO4IJVifbzxmQKs9WT8mrZEMim6SeDdADQwSR0acEhJ+3J28He dtivfv56spHoJ/tfDNu2qDhARJafX+eD5mcEu6HQNQ2zLSkdM3A81gMfApSiCylRWUnp p+CiEOfNGgOhxHqKCQOf+JuUXpx+A4IIKAzNlWg/11EcF7BaJkIsaa/nKcaBVPc5xIFc kZ0cVb7lOoeJqLpwKKgFTeXzK/3WAFAAc954rO0VQlnBjoYShCLVfqGqTyTvNBavu0vn KoyUU1oxONdzZuWbjzRY6raMcFAWTv+moZ9qQsGyl8w7vD4+9MU7dABv650oZr+IVd64 R4RA== X-Gm-Message-State: AIVw1123EBihyySHni1A1QnLCtZHpHljDL1vxH38tYrDlLbVZSpbGK0b X6DD9GFF+NnRa3W4SZ2EBRk7g+TcAA== X-Received: by 10.31.109.133 with SMTP id i127mr9703234vkc.0.1500191953982; Sun, 16 Jul 2017 00:59:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Sun, 16 Jul 2017 00:58:43 -0700 (PDT) In-Reply-To: References: <5963BF27.1050300@foobar.org> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> From: Mark Smith Date: Sun, 16 Jul 2017 17:58:43 +1000 Message-ID: Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: "Pascal Thubert (pthubert)" Cc: Brian E Carpenter , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 07:59:18 -0000 On 16 July 2017 at 16:41, Pascal Thubert (pthubert) wr= ote: > Hello Brian: > > I'd say that DAD detecting a duplication is not a failure; just doing its= job right. > > The DAD failure that hurts is DAD false negative like can be easily obtai= ned on wireless because the reliability of the multicast is largely differ= ent from that of wire. > > Are we ready to say that addresses that are generated with enough randomn= ess in them do not need DAD? > I looked up RFC4862 to find out how many DAD attempts there were, because I'd assumed 3 to 4, and if so, then if that many attempts failed, I'd say the link is well beyond its capacity. Something would need to be done to remedy a link capacity problem in that case. I was surprised to find, as Ole mentioned, the number of attempts was only 1 rather than 3 or 4. One thing it does say about that value is: Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). Although Wifi is emulating Ethernet at the IPv6 interface layer, it doesn't have the same multicast characteristics, so perhaps there should be an IPv6 over Wifi RFC that specifies IPv6's parameters to suit. > Pascal > >> Le 15 juil. 2017 =C3=A0 23:01, Brian E Carpenter a =C3=A9crit : >> >> On 16/07/2017 01:39, Philip Homburg wrote: >>>> This is backwards. The goals of pseudo-random IIDs are to reduce the >>>> probability that scanning attacks find hosts, and to reduce the risk >>>> of IIDs being used to breach privacy. >>>> >>>> If these goals are met, the collision probability will in any case >>>> be low, so DAD failure will be exceedingly rare. >>> >>> I completely disagree. A collision is fatal. We are nowhere near transp= arently >>> handling all collisions. At best we can hope that DAD can make one node >>> continue unaffected. >> >> I'm confused. >> >> Firstly, do we have any experimental evidence that collisions >> are a real operational problem? (Obviously, MAC address collisions are >> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs t= o >> detect them, they are irrelevant to the current discussion.) >> >> Secondly, if a collision does occur with IPv6+(pseudo-random IID), >> recovery is obvious: after DAD failure, generate a new pseudo-random >> IID and try again. This is perfectly compatible with RFC4862 section 5.5 >> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy >> addresses. >> >> Brian >> >>> >>> In contrast, people have been scanning my IPv4 ranges for the past 20 y= ears >>> or so. That may be annoying. That may amplify attacks opportunities. Bu= t >>> in it self it is not fatal. >>> >>> >>> . >>> >> >> -------------------------------------------------------------------- >> 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 16 01:25:26 2017 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 ABFAF12EC57 for ; Sun, 16 Jul 2017 01:25:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bx0MwIXd1lt for ; Sun, 16 Jul 2017 01:25:22 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 0CF36127180 for ; Sun, 16 Jul 2017 01:25:22 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id 32so88183563qtv.1 for ; Sun, 16 Jul 2017 01:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gXIsFvKqtBPgLqbrxuTxmSZsdK1WuhJf2b4xTb8DSBw=; b=cCdyI1W6HiwueTJaDdoG6MwfWLfqulUll6m7P4E6tP4ktEJ2QLGFI09TFVZ3SOJsOD CM/qQwOIHnGx8GHQIJ5zwh1VY0pkGpF80WFWQ1owAqZkQZ2sqdmyEmu9JN8xXkcS19Yl kfuSXiU0bVWxfx+6OPtIn8m7KXPZ2S+5ucXhw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gXIsFvKqtBPgLqbrxuTxmSZsdK1WuhJf2b4xTb8DSBw=; b=G5B1bIjNVOa3Q7lrGYEqxpndSkRJ60nwBGDtxmder+BeLqJgWKpjE/4Py2shvF2Ly3 ExDRyDpTtdix1pD3WDPn1lJ5B+2pFFO4+Az88pk9T5D2/YMnMqa8t0Fn3YDnaiPU0Rii mRYPALN1TtF1uhik5jXngQ/cj6rVz8xbMyyhJ6h59X34JsIWVFZjgmVINb2Q/fDc4SiT 5+us8a7bTbUYCOgEB55HO+kNWqauiROXlqsXG+13+XzBIaIZQdos4ukdRIdjRo+4wdKF wxh3le4Cmuc81vHIqLkwkAKDWUCT/Wc6AG8bXkCDHaKXTBUt0Kd3f+eT7IX0CIEVTpEG /O0Q== X-Gm-Message-State: AIVw110ZHNgP21BBfhuoppOso4Ys2x/+2jsQKlyLkZO6JI5cDkYn17hU SSw8i6afhqTlQn6DRsV1t9Vt2I29llY/ X-Received: by 10.237.34.109 with SMTP id o42mr22271155qtc.217.1500193521060; Sun, 16 Jul 2017 01:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.5.130 with HTTP; Sun, 16 Jul 2017 01:25:00 -0700 (PDT) In-Reply-To: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> From: Timothy Winters Date: Sun, 16 Jul 2017 04:25:00 -0400 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Brian E Carpenter Cc: 6man Content-Type: multipart/alternative; boundary="001a1140a004eae89005546b0545" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:25:25 -0000 --001a1140a004eae89005546b0545 Content-Type: text/plain; charset="UTF-8" Hi Brian, On Sun, Jul 16, 2017 at 12:06 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > Some comments, but not a full review: > > > - IPv6 over ATM Networks [RFC2492] > > Is this still worth mentioning? > Probably not, we'll remove this in the next draft. How do you feel about Frame Relay? > > - IP version 6 over PPP [RFC5072] > > > > In addition to traditional physical link-layers, it is also possible > > to tunnel IPv6 over other protocols. Examples include: > > Shouldn't PPP be in this list, not the previous list? > Yes. > > > - Teredo: Tunneling IPv6 over UDP through Network Address > > Translations (NATs) [RFC4380] > > > > - Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and > > Routers" [RFC4213] > > > > **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and > > issues like RFC 6935, or 6936?** > > Maybe. But the field is evolving: Teredo is surely obsolescent, there's > also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder > what you can really say. > > > 5.1. Internet Protocol Version 6 - RFC 2460 > > > > The Internet Protocol Version 6 is specified in [RFC2460]. This > > specification MUST be supported. > > > > **BIS Again, update for RFC 2460 -bis ** > > > > Any unrecognized extension headers or options MUST be processed as > > described in RFC 2460. > > As well as s/2460/8200/, I suggest s/processed/treated/ to avoid another > debate about the meaning of 'processed' ;-). > > (And don't forget s/1981/8201/.) > Thanks, we'll make all those updates. > > > 5.7. IPv6 Jumbograms - RFC 2675 > ... > > and there is essentially no reported experience from usage. > > Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. > > > > **BIS Are these used? Do we need to modify the text for that? ** > > I don't think so. They appear to be harmless and maybe somebody will > need them one day, so there is no obvious argument for deprecation. > K, we'll remove the note. > > > 5.10. First-Hop Router Selection - RFC 8028 > ... > > Hosts that may be deployed in such multihomed environments SHOULD > > follow the guidance given in [RFC8028]. > > Which should therefore be listed as a Normative reference. > Thanks, we'll update that to Normative. > > > 6.1. IP Version 6 Addressing Architecture - RFC 4291 > > > > The IPv6 Addressing Architecture [RFC4291] MUST be supported. > > > > **BIS Update to 4291-bis ** > > Maybe not :-( > I still have hope..... > > > **BIS Add note on Why /64? RFC 7421, after the conclusion of the > > RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic. But no > > need for /127 p2p text RFC 6164. And no need for note on IID > > significance, as per RFC 7136. ** > > I'm not sure we need to mention RFC 7421 here at all. If 4291bis gets > published, it will be mentioned there. If it doesn't get published, > 64 remains fixed anyway. > Thanks for the feedback. > > > 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 > > > > Hosts MUST support IPv6 Stateless Address Autoconfiguration as > > defined in either [RFC4862] or [RFC7217]. > > That's wrong, surely? SLAAC is defined in 4862, and 7217 doesn't even > formally update it. I think you should simply delete 'or [RFC7217]'. > > It is recommended that, > > unless there is a specific requirement for MAC addresses to be > > embedded in an IID, nodes follow the procedure in RFC7217 to generate > > SLAAC-based addresses. > > That only applies if a stable IID is wanted. I would suggest: > > It is recommended that, > unless there is a specific requirement for MAC addresses to be > embedded in an IID, nodes follow the procedures in [RFC7217] > or [RFC4941] (see below) to generate SLAAC-based addresses. > > (I think we've already established that it's possible to operate > a node that has no stable global-scope address.) > OK, this text looks fine to me. > > > 6.6. Default Address Selection for IPv6 - RFC 6724 > > > > IPv6 nodes will invariably have multiple addresses configured > > simultaneously, and thus will need to choose which addresses to use > > for which communications. The rules specified in the Default Address > > Selection for IPv6 [RFC6724] document MUST be implemented. > > I am concerned about the famous rule 5.5 in RFC6724. It's optional there, > but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn > promotes rule 5.5 to a SHOULD. Could we add that promotion here > too? Otherwise there is a complicated trail for implementers to follow. > I like this idea, how about. Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD implement this rule. > > > 14. Router-Specific Functionality > > I think you should require BCP198 (RFC7068) support. > Interesting thought (should be RFC7608). I don't have a problem adding this, I'll check with the co-authors. > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1140a004eae89005546b0545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Sun, Jul 16, 2017 at 12:06 AM, Brian E Carpenter <br= ian.e.carpenter@gmail.com> wrote:
Hi,

Some comments, but not a full review:

>=C2=A0 =C2=A0 -=C2=A0 IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?

Probabl= y not, we'll remove this in the next draft.=C2=A0 How do you feel about= Frame Relay?


>=C2=A0 =C2=A0 -=C2=A0 IP version 6 over PPP [RFC5072]
>
>=C2=A0 =C2=A0 In addition to traditional physical link-layers, it is al= so possible
>=C2=A0 =C2=A0 to tunnel IPv6 over other protocols.=C2=A0 Examples inclu= de:

Shouldn't PPP be in this list, not the previous list?
<= div>Yes.=C2=A0

>=C2=A0 =C2=A0 -=C2=A0 Teredo: Tunneling IPv6 over UDP through Network A= ddress
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Translations (NATs) [RFC4380]
>
>=C2=A0 =C2=A0 -=C2=A0 Section 3 of "Basic Transition Mechanisms fo= r IPv6 Hosts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Routers" [RFC4213]
>
>=C2=A0 =C2=A0 **BIS Do we want a small section somewhere on UDP IPv6 tu= nneling, and
>=C2=A0 =C2=A0 issues like RFC 6935, or 6936?**

Maybe. But the field is evolving: Teredo is surely obsolescent, there's=
also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder<= br> what you can really say.

> 5.1.=C2=A0 Internet Protocol Version 6 - RFC 2460
>
>=C2=A0 =C2=A0 The Internet Protocol Version 6 is specified in [RFC2460]= .=C2=A0 This
>=C2=A0 =C2=A0 specification MUST be supported.
>
>=C2=A0 =C2=A0 **BIS Again, update for RFC 2460 -bis **
>
>=C2=A0 =C2=A0 Any unrecognized extension headers or options MUST be pro= cessed as
>=C2=A0 =C2=A0 described in RFC 2460.

As well as s/2460/8200/, I suggest s/processed/treated/ to avoid another debate about the meaning of 'processed' ;-).

(And don't forget s/1981/8201/.)
Thanks, we'll= make all those updates.=C2=A0

> 5.7.=C2=A0 IPv6 Jumbograms - RFC 2675
...
>=C2=A0 =C2=A0 =C2=A0and there is essentially no reported experience fro= m usage.
>=C2=A0 =C2=A0 Consequently, IPv6 Jumbograms [RFC2675] remain optional a= t this time.
>
>=C2=A0 =C2=A0 **BIS Are these used?=C2=A0 Do we need to modify the text= for that? **

I don't think so. They appear to be harmless and maybe somebody will need them one day, so there is no obvious argument for deprecation.
K, we'll remove the note.=C2=A0

> 5.10.=C2=A0 First-Hop Router Selection - RFC 8028
...
>=C2=A0 =C2=A0 Hosts that may be deployed in such multihomed environment= s SHOULD
>=C2=A0 =C2=A0 follow the guidance given in [RFC8028].

Which should therefore be listed as a Normative reference.
=
Thanks, we'll update that to Normative.=C2=A0

> 6.1.=C2=A0 IP Version 6 Addressing Architecture - RFC 4291
>
>=C2=A0 =C2=A0 The IPv6 Addressing Architecture [RFC4291] MUST be suppor= ted.
>
>=C2=A0 =C2=A0 **BIS Update to 4291-bis **

Maybe not :-(
I still have hope.....=C2=A0

>=C2=A0 =C2=A0 **BIS Add note on Why /64?=C2=A0 RFC 7421, after the conc= lusion of the
>=C2=A0 =C2=A0 RFC4291-bis (lengthy!!!) discussions on the 64-bit IID to= pic.=C2=A0 But no
>=C2=A0 =C2=A0 need for /127 p2p text RFC 6164.=C2=A0 And no need for no= te on IID
>=C2=A0 =C2=A0 significance, as per RFC 7136. **

I'm not sure we need to mention RFC 7421 here at all. If 4291bis gets published, it will be mentioned there. If it doesn't get published,
64 remains fixed anyway.
Thanks for the feedback.=C2= =A0

> 6.3.=C2=A0 IPv6 Stateless Address Autoconfiguration - RFC 4862
>
>=C2=A0 =C2=A0 Hosts MUST support IPv6 Stateless Address Autoconfigurati= on as
>=C2=A0 =C2=A0 defined in either [RFC4862] or [RFC7217].

That's wrong, surely? SLAAC is defined in 4862, and 7217 doesn't ev= en
formally update it. I think you should simply delete 'or [RFC7217]'= .

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 It is recommended that,
>=C2=A0 =C2=A0 unless there is a specific requirement for MAC addresses = to be
>=C2=A0 =C2=A0 embedded in an IID, nodes follow the procedure in RFC7217= to generate
>=C2=A0 =C2=A0 SLAAC-based addresses.

That only applies if a stable IID is wanted.=C2=A0 I would suggest:

It is recommended that,
unless there is a specific requirement for MAC addresses to be
embedded in an IID, nodes follow the procedures in [RFC7217]
or [RFC4941] (see below) to generate SLAAC-based addresses.

(I think we've already established that it's possible to operate a node that has no stable global-scope address.)
OK, t= his text looks fine to me.=C2=A0

> 6.6.=C2=A0 Default Address Selection for IPv6 - RFC 6724
>
>=C2=A0 =C2=A0 IPv6 nodes will invariably have multiple addresses config= ured
>=C2=A0 =C2=A0 simultaneously, and thus will need to choose which addres= ses to use
>=C2=A0 =C2=A0 for which communications.=C2=A0 The rules specified in th= e Default Address
>=C2=A0 =C2=A0 Selection for IPv6 [RFC6724] document MUST be implemented= .

I am concerned about the famous rule 5.5 in RFC6724. It's optional ther= e,
but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn
promotes rule 5.5 to a SHOULD. Could we add that promotion here
too? Otherwise there is a complicated trail for implementers to follow.
=
I like this idea, how about.

Sin= ce RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD implement= this rule.=C2=A0

> 14.=C2=A0 Router-Specific Functionality

I think you should require BCP198 (RFC7068) support.
I= nteresting thought (should be RFC7608). =C2=A0 I don't have a problem a= dding this, I'll check with the co-authors.=C2=A0

Regards
=C2=A0 =C2=A0 =C2=A0Brian

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



--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a1140a004eae89005546b0545-- From nobody Sun Jul 16 01:48:38 2017 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 F07CB12EBFE for ; Sun, 16 Jul 2017 01:48:36 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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 KoSbDxPTlpRf for ; Sun, 16 Jul 2017 01:48:35 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872A5127180 for ; Sun, 16 Jul 2017 01:48:35 -0700 (PDT) Received: from [192.168.10.201] (77.16.64.96.tmi.telenormobil.no [77.16.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 1E46A2D4FF9; Sun, 16 Jul 2017 08:48:34 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-C69DB8C1-27AC-4271-BAC3-7AC6022E60C8 Mime-Version: 1.0 (1.0) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: <5C6E9C30-0217-4EEC-8A8D-F204002BE095@cisco.com> Date: Sun, 16 Jul 2017 10:48:29 +0200 Cc: Nick Hilliard , "ipv6@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <61C67E77-3A8A-4177-B492-988017E7BC80@employees.org> References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <5C6E9C3 0-0217-4EEC-8A8D-F204002BE095@cisco.com> To: "Pascal Thubert (pthubert)" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 08:48:37 -0000 --Apple-Mail-C69DB8C1-27AC-4271-BAC3-7AC6022E60C8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal, Agree with all you're saying.=20 The pragmatic solutions from our perspective is to treat the media as a set o= f point to point links with /64 to each host. Then all these problems of mul= ticast, DAD etc magically disappear.=20 Ole > On 16 Jul 2017, at 08:58, Pascal Thubert (pthubert) w= rote: >=20 > I respectfully disagree. >=20 > There are a number of cases where an SDO designs on false assumptions of w= hat the other is doing. >=20 > IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which en= ables DAD and discovery to be perfectly fine. ND also expects that the core s= ervice that 802.1 provides on Ethernet (reliable broadcast) extends to the w= hole ESS so we have our problems solved. Sadly, no such thing. >=20 > The same exists in the other direction as well. IEEE expects that the AP w= ill implement a magical ND proxy and that solves the problem. Again, the IET= F has no such thing, at least for ND. Some people at IEEE think that bridgin= g 48bits address to 64bits addresses will enable bridging with all it's nice= properties on 802.15.4 links. Good thing this illusion is dissolving rapidl= y. >=20 > The solution is probably to stop throwing our problems over the fence (tha= nks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,= _do_it_yourself >=20 > The solution is probably to understand the IEEE design of an ESS for L2 op= erations and emulate it at L3. A step towards reconciliation of the designs m= ay be to effectively provide the proxy that the IEEE expects to see at the b= oundary of the mediums. >=20 > All the best, >=20 > Pascal >=20 > Le 16 juil. 2017 =C3=A0 00:23, Nick Hilliard a =C3=A9cri= t : >=20 >> Ole Troan wrote: >>> This a protocol problem. DAD is built with the assumption that >>> physical links are reliable. 20% packet loss for multicast is common >>> on wifi... >>=20 >> most protocols will croak at 20% packet loss. If wifi cannot support >> multicast properly, then this is an 802.11 problem rather than a problem >> with DAD or any of the many other bits of ipv6 that depend on moderately >> reliable multicast. =20 >>=20 >> Nick >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- --Apple-Mail-C69DB8C1-27AC-4271-BAC3-7AC6022E60C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Pascal,

Agree with all you're saying. 
The pragmatic solutions f= rom our perspective is to treat the media as a set of point to point links w= ith /64 to each host. Then all these problems of multicast, DAD etc magicall= y disappear. 

Ole

On 16 Jul 2017= , at 08:58, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

=
I respectfully disagree.

There are a number of cases where an SDO designs on false assumptions o= f what the other is doing.

IPv6 ND expects that IEEE protocols can serve 2^24 Mulcair groups which= enables DAD and discovery to be perfectly fine. ND also expects that the co= re service that 802.1 provides on Ethernet (reliable broadcast) extends to t= he whole ESS so we have our problems solved. Sadly, no such thing.

The same exists in the other direction as well. IEEE expects that the A= P will implement a magical ND proxy and that solves the problem. Again, the I= ETF has no such thing, at least for ND. Some people at IEEE think that bridg= ing 48bits address to 64bits addresses will enable bridging with all it's nice properties on 802.15.4 li= nks. Good thing this illusion is dissolving rapidly.

The solution is probably to stop throwing our problems over the fence (= thanks to Norm Finn for the quote). As they say, if_you_want_a_thing_done_well,_do_= it_yourself

The solution is probably to understand the IEEE design of an ESS for L2= operations and emulate it at L3. A step towards reconciliation of the desig= ns may be to effectively provide the proxy that the IEEE expects to see at t= he boundary of the mediums.

All the best,

Pascal

Le 16 juil. 2017 =C3=A0 00:23, Nick Hilliard <nick@foobar.org> a =C3=A9crit :

Ole Troan wrote:
This a protocol problem. DAD is built with t= he assumption that
physical links are reliable. 20% packet loss= for multicast is common
on wifi...

most protocols will croak at 20% packet loss.  If wifi cannot sup= port
multicast properly, then this is an 802.11 problem rather than a probl= em
with DAD or any of the many other bits of ipv6 that depend on moderate= ly
reliable multicast.    

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
= --Apple-Mail-C69DB8C1-27AC-4271-BAC3-7AC6022E60C8-- From nobody Sun Jul 16 02:32:07 2017 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 69DB5131761 for ; Sun, 16 Jul 2017 02:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 vXeV3nv896iZ for ; Sun, 16 Jul 2017 02:32:04 -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 0005F127058 for ; Sun, 16 Jul 2017 02:32:03 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r126so64430827vkg.0 for ; Sun, 16 Jul 2017 02:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zJhtFMegWNAols9/C/nkT1OYQgbY5LqXzIrHQnmJuaI=; b=nhLRqaMfFLZVZSV0Nu6hoQ2d6Stwr/HPyJAxv0tsfvfl/pZ2yYi47NUbnVqxsnebix dQ9qeMfPrmbfAJZL80HqDI12WtN0r0agKOAuZj9wRXCJ+MTL9Ek75ubbjxFXwV/NM4a5 p5r2C8Tf/OffDYi+q74CJkrZr5HPIGS5TRRuk24CRcSKKHUKBHWpn7wrQoGzG+2lDlWu GgbWC84hR52Dz+9q+GldHqo8QYhPVEuy/0Unwe7dp0ejdTPXWw6PAYIiI9BTgvRXJfc1 T8XrUZ7ER9ppKJVtnyutn/KmEyDEqhy6iL4viNPKsYzjNlZFhhQMXzBPOptzzaZu2AWo 03OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zJhtFMegWNAols9/C/nkT1OYQgbY5LqXzIrHQnmJuaI=; b=CtvUF3hhNnnj4ONXCXfpL87dCpu4iusKnCo4Qms9pFAHmop9GQ0Th2UgnIpyVVd+wi 0T4xVG23URfMiS59ivlBwS4GK6gD+fImr29eDP6xKAVgnD17UBBqlclnjZAuAVRFvnDx 9Mr2cxHrABhBdYQLb7Fp5bIFSzCkbv8KQxfxn37yf6PawY7d6hnvhRCiwGKMba9Mx4HJ 3Vgr1ciMmG/nnJYkE/nWo2GXtJ6VxgQ75Muvdylmqkla/xRaJah1zCZ3uNwaUbO/H9Ec AkW5OBkOcJ3d/hDIZ+lnlYOtdtIBnoYShsIyJUaOiRRnMnwsR9fa6IYXAuFL/M7UGBaM j0GQ== X-Gm-Message-State: AIVw1127zGy0HXD4GXTS+oZK1LNuxIrWNpXtGgBlEq1ynRtKBPDMOcdE Ant3eEfi1uPvf+g+8gQ5xXecTG2yEJ3oMMY= X-Received: by 10.31.209.199 with SMTP id i190mr9656881vkg.125.1500197522578; Sun, 16 Jul 2017 02:32:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Sun, 16 Jul 2017 02:31:41 -0700 (PDT) In-Reply-To: <149909644776.22718.16227939850699261560@ietfa.amsl.com> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> From: Lorenzo Colitti Date: Sun, 16 Jul 2017 11:31:41 +0200 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Content-Type: multipart/alternative; boundary="001a114e6e186da68b05546bf486" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 09:32:05 -0000 --001a114e6e186da68b05546bf486 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 3, 2017 at 5:40 PM, wrote: > > 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 : IPv6 Node Requirements > Authors : Tim Chown > John Loughney > Timothy Winters > Filename : draft-ietf-6man-rfc6434-bis-01.txt > I see that the document still says: There will be a wide range of IPv6 deployment models and differences in address assignment requirements, some of which may require DHCPv6 for stateful address assignment. Consequently, all hosts SHOULD implement address configuration via DHCPv6. We should abandon this documentation, for two reasons. First, networks that require DHCPv6 assignment are explicitly NOT RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section 8 says "it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests". A DHCPv6-only network cannot meet this recommendation, because on a DHCPv6-only network, all addresses acquisition requires an explicit request to the network. Second, the draft says "Where devices are likely to be carried by users and attached to multiple visisted networks, DHCPv6 client anonymity profiles SHOULD be supported as described in [RFC7844]". But RFC 7844 says that hosts SHOULD prefer stateless address configuration over DHCPv6: "hosts using the anonymity profile SHOULD use stateless address configuration instead of stateful address configuration". So for such devices, there is a direct conflict: this document says they SHOULD do DHCPv6, but RFC 7844 says they SHOULD not if other addressing modes are available. I would propose the following text for section 6.5: [...] There will be a wide range of IPv6 deployment models and differences in address assignment requirements, some of which may use DHCPv6 for stateful address assignment in addition to other addressing modes. Using DHCPv6 as the only IPv6 address configuration mechanism is NOT RECOMMENDED [RFC 7934 section 8]. In the absence of a router, IPv6 nodes using DHCP for address assignment MAY initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of [RFC4862]. Where devices are likely to be carried by users and attached to multiple visisted networks, DHCPv6 client anonymity profiles SHOULD be supported as described in [RFC7844] to minimise the discolosure of identifying information. This profile recommends that the device prefer stateless address configuration over DHCPv6 address configuration. Devices that do not have particular anonymity requirements SHOULD implement address configuration via DHCPv6 in order to be able to take advantage of IPv6 addresses available only via DHCPv6. --001a114e6e186da68b05546bf486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 3, 2017 at 5:40 PM, <internet-drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 Maintenance of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Node Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tim = Chown
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Loughney
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Timothy Winters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6man-rfc6434-bis-01.txt

I see th= at the document still says:

=C2=A0 =C2=A0Ther= e will be a wide
=C2=A0 =C2=A0range of IPv6 deployment models and= differences in address assignment
=C2=A0 =C2=A0requirements, som= e of which may require DHCPv6 for stateful address
=C2=A0 =C2=A0a= ssignment.=C2=A0 Consequently, all hosts SHOULD implement address
=C2=A0 =C2=A0configuration via DHCPv6.

We s= hould abandon this documentation, for two reasons.

First, networks that require DHCPv6 assignment are explicitly NOT RECOMMEN= DED by current IETF best practices. Specifically,=C2=A0RFC 7934 section 8 s= ays "it is RECOMMENDED that the network give the host the ability to u= se new addresses without requiring explicit requests". A DHCPv6-only n= etwork cannot meet this recommendation, because on a DHCPv6-only network, a= ll addresses acquisition requires an explicit request to the network.
=

Second, the draft says "Where devices are likely t= o be carried by users and attached to multiple visisted networks, DHCPv6 cl= ient anonymity profiles SHOULD be supported as described in [RFC7844]"= .

But RFC 7844 says that hosts SHOULD prefer state= less address configuration over DHCPv6: "hosts using the anonymity pro= file SHOULD use stateless address configuration instead of stateful address= configuration".

So for such devices, there i= s a direct conflict: this document says they SHOULD do DHCPv6, but RFC 7844= says they SHOULD not if other addressing modes are available.
I would propose the following text for section 6.5:
=
=C2=A0 =C2=A0[...] There will be a wide
=C2= =A0 =C2=A0range of IPv6 deployment models and differences in address assign= ment
=C2=A0 =C2=A0requirements, some of which may use DHCPv6 for = stateful address
=C2=A0 =C2=A0assignment in addition to other add= ressing modes. Using DHCPv6 as the
=C2=A0 =C2=A0only IPv6 address= configuration mechanism is NOT RECOMMENDED
=C2=A0 =C2=A0[RFC 793= 4 section 8].

=C2=A0 =C2=A0In the absence of a rou= ter, IPv6 nodes using DHCP for address
=C2=A0 =C2=A0assignment MA= Y initiate DHCP to obtain IPv6 addresses and other
=C2=A0 =C2=A0c= onfiguration information, as described in Section 5.5.2 of
=C2=A0= =C2=A0[RFC4862].

=C2=A0 =C2=A0Where devices are l= ikely to be carried by users and attached to
=C2=A0 =C2=A0multipl= e visisted networks, DHCPv6 client anonymity profiles SHOULD
=C2= =A0 =C2=A0be supported as described in [RFC7844] to minimise the discolosur= e of
=C2=A0 =C2=A0identifying information. This profile recom= mends that the device prefer
=C2=A0 =C2=A0stateless address= configuration over DHCPv6 address configuration.

= =C2=A0 =C2=A0Devices that do not have particular anonymity requirements SHO= ULD
=C2=A0 =C2=A0implement address configuration via DHCPv6 in or= der to be able to
=C2=A0 =C2=A0take advantage of IPv6 addresses a= vailable only via DHCPv6.
--001a114e6e186da68b05546bf486-- From nobody Sun Jul 16 02:44:56 2017 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 A5E7F127058 for ; Sun, 16 Jul 2017 02:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, 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 OiJrifFyrmPt for ; Sun, 16 Jul 2017 02:44:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD9C1318EC for ; Sun, 16 Jul 2017 02:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26556; q=dns/txt; s=iport; t=1500198291; x=1501407891; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DRmX6dq2+ym1XuEt+YDKgyRh9Cc4g1otDrn0NkZ2Yc8=; b=iCPI3lOLhwkoWrzuIZK6b5g1l/SnqgGb62mi2iesjTkLS94qqc6olDL7 tdLhuLHcZMvUnF9Pq760IOqzZnpMmlk4Kajw+MJDcs36MiMYB9SyhOnpi isVRB7HEDlqd1sWZZ8mYc/VTF1bxalMyieELgHvV0Ys8Q9uHVCGMeWI5i I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAAD6NGtZ/5BdJa1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvPi1kgRQHjgSRX5YEghEhAQ6FFwIag1c/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBIQpBCxACAQgOAwQBASgDAgICJQsUCQgCBA4FCBOJMGQQMq0/g?= =?us-ascii?q?iaLEwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYN5gQyDJoEgWoJdgmEFiVy?= =?us-ascii?q?NZodyAodIjEOSOJVWAR84gQp1FR8qhRMcGYFOdgEBhhWBMoENAQEB?= X-IronPort-AV: E=Sophos; i="5.40,368,1496102400"; d="scan'208,217"; a="52644933" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 09:44:50 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6G9io9d025571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 09:44:50 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; Sun, 16 Jul 2017 04:44:49 -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; Sun, 16 Jul 2017 04:44:50 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan CC: Nick Hilliard , "ipv6@ietf.org" Subject: RE: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: ) Thread-Index: AQHS/a2ZuieUK0MP90SlnyedjyZgWqJVuZOAgAADEwCAAAKKgIAACwyAgAA8W16AAHJ2gP//sCyQ Date: Sun, 16 Jul 2017 09:44:33 +0000 Deferred-Delivery: Sun, 16 Jul 2017 09:43:51 +0000 Message-ID: References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <5C6E9C3 0-0217-4EEC-8A8D-F204002BE095@cisco.com> <61C67E77-3A8A-4177-B492-988017E7BC80@employees.org> In-Reply-To: <61C67E77-3A8A-4177-B492-988017E7BC80@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.215.96] Content-Type: multipart/alternative; boundary="_000_b742072481db41e98e79cc0a06110192XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 09:44:55 -0000 --_000_b742072481db41e98e79cc0a06110192XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gY2VydGFpbmx5IHNlbnNlIHRoZSBpcm9ueSBpbiBhc3NlcnRpbmcgdGhlcmXigJlzIHN1 Y2ggbWFnaWMuDQoNCkZvciBpbnN0YW5jZSwgd2hpY2ggbWFnaWMgbWFrZXMgaXQgc28gdGhhdCB3 ZSB3b3VsZCB0cnVzdCBiZXR0ZXIgREhDUCgtUEQpIGZvciBoYW5kaW5nIGEgdW5pcXVlIDE2LWJp dHMgd29yZCBvZiBwcmVmaXggc3BhY2UgYXMgb3Bwb3NlZCB0byBhIHVuaXF1ZSA2NGJpdHMgd29y ZCBvZiBJSUQgc3BhY2U/IEluIG15IGJvb2ssIHRoYXQgaXMgZWZmZWN0aXZlbHkgaGFyZGVyIHNp bmNlIHlvdSBjYW5ub3QgcmVseSBmb3IgbG9uZyBvbiBMUlUgdG8gZGVsYXkgcmVhc3NpZ25pbmcg YSBwcmV2aW91c2x5IGFzc2lnbmVkIHdvcmQsIHlvdSBnZXQgbGl0dGxlIGhlbHAgZnJvbSBlbnRy b3B5IHRvIGNvdmVyIGZvciB5b3VyIG1pc3Rha2VzIGFuZCByYWNlIGNvbmRpdGlvbnMsIGV0Y+KA pi4NCg0KQWxzbywgYXQgdGhlIHByZWZpeCBsZXZlbCwgd2UgZG8gbm90IGhhdmUgREFEIGFzIHRo ZSDigJx1bHRpbWF0ZeKAnSBwcm90ZWN0aW9uIGFnYWluc3Qgb3VyIGF1dG9tYXRlZCBvciBtYW51 YWwgYXNzaWdubWVudCBtaXN0YWtlczsgcm91dGluZyBpcyBub3QgZGV0ZXJyZWQgYnkgZHVwbGlj YXRpb24sIGl0IGp1c3Qgc2VlcyAyIGFkdmVydGlzZW1lbnRzIGFzIGFsdGVybmF0ZSB3YXlzIHRv IGdldCB0aGVyZS4gV2hpY2ggbWVhbnMgdGhhdCBpZiBhIC82NCBpcyBkdXBsaWNhdGVkLCBwYWNr ZXRzIHdpbGwgYmUgZGVsaXZlcmVkIHRvIHRoZSBuZWFyZXN0IG9mIHRoZSAyIG93bmVycyBmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgc291cmNlLiBOb3QgYSBncmVhdCBiZW5lZml0IGZyb20g dGhlIGN1cnJlbnQgc2l0dWF0aW9uLg0KDQpTbyBjZXJ0YWlubHkgeW91IHdhbnQgdG8gcXVhbGlm eSB3aGVuIGFuIGlkZWEgc3VjaCBhcyBhIC82NCBvciBzaG9ydGVyIGZvciBhbGwgYXBwbGllcyBw YXJ0aWN1bGFybHkgd2VsbCAoZS5nLiBhbiBldmVudCBzdGFydGluZyB3aXRoIGEgY2xlYW4gc2xh dGUsIHdpdGggbGVzcyBjb25uZWN0ZWQgZGV2aWNlcyBpbiB0aGUgcHVibGljIHRoYW4gYXZhaWxh YmxlIHByZWZpeGVzLCBhbmQgYSBjbGVhciBlbmQgb2YgdGltZSB3aGVuIGFsbCBwcmVmaXhlcyBh cmUgcmVsZWFzZWQpLCBhbmQgd2hlbiBpdCBzaG93cyBsaW1pdHMuIENvbWluZyBmcm9tIHRoZSB2 ZXJ5IGRpZmZlcmVudCBncm91bmQgb2YgSW9ULCBhbmQgdGhvdWdoIEkgYW0gcXVpdGUgY29udmlu Y2VkIGJ5IHRoYXQgcGFydGljdWxhciBpZGVhLCBJIGRvIG5vdCBiZWxpZXZlIGluIGEgb25lLWZp dHMtaXQtYWxsIHNvbHV0aW9uLg0KDQpJ4oCZZCByZWFsbHkgbG92ZSB0byBzZWUgYSBkcmFmdCB0 aGF0IGRvY3VtZW50cyBhIHNldCBvZiByZWZlcmVuY2UgbW9kZWxzIChwcm9maWxlcz8pIHRvIGhl bHAgb3VyIHVzZXJzIGRlcGxveSBhbiBJUHY2IGNhbXB1cyBuZXR3b3JrIHRoYXQgbWVldHMgdGhl aXIgZXhwZWN0YXRpb25zLiBSb3V0aW5nIHRvIHRoZSAvNjQgaXMgZGVmaW5pdGVseSBhIGdyZWF0 IG9uZS4NCg0KV2UgaGF2ZSBzb21lIG90aGVycyBpbiB0aGUgSU9UIHNwYWNlIHRvIHNlcnZlIGRp ZmZlcmVudCB1c2UgY2FzZXMgaW52b2x2aW5nIHZlcnkgbG9uZyB0ZXJtIGRlcGxveW1lbnRzLCBs YXJnZSBudW1iZXJzIG9mIGRldmljZXMsIGRvdHRpbmcgbGluZSBzdGF0ZSBvZiBjb25uZWN0aXZp dHksIG1vYmlsaXR5LCBhbmQgZHJhc3RpY2FsbHkgbGltaXRlZCBjYXBhYmlsaXR5IHRvIGRvIGNv bXBsZXggc3R1ZmYgc3VjaCBhcyBJUHY2IHJlbnVtYmVyaW5nLiAgVG8gc2VydmUgc3VjaCB1c2Ug Y2FzZXMsIHdlIGFyZSBlZmZlY3RpdmVseSBzcGVjaWZ5aW5nIE5EIG9wZXJhdGlvbiBhbmQgcHJv eHkuIEkgZG8gbm90IHNlZSB0aGF0IGFzIGNvbXBldGl0aW9uIHRvIHRoZSAvNjQgYXBwcm9hY2gu IEl0IGlzIGluIGZhY3QgZm9sbG93aW5nIHRoZSBjb21tb24gaWRlYSB0byByZWludHJvZHVjZSBz b21lIHJvdXRpbmcgd2hlbiB3ZSBoaXQgdGhlIGxpbWl0cyBvZiBicmlkZ2luZy4NCg0KVGhpcyBo YXMgY29uc2VxdWVuY2VzLiBBcyB3ZSBnZXQgcmlkIG9mIHRoZSBpbGx1c2lvbiBvZiB0aGUgZnJl ZSBhbmQgc3Bhbm5pbmcgYnJvYWRjYXN0IGRvbWFpbiwgd2UgbmVlZCB0byByZWNvbnNpZGVyIGhv dyB3ZSBhcHBseSBwcm90b2NvbHMgdGhhdCB1c2VkIHRvIHJlbHkgb24gTDIgYnJvYWRjYXN0LiBJ IGV4cGVjdCB0byBzZWUgbW9yZSBhbmQgbW9yZSBwcm94aWVzIHNob3dpbmcgdXAsIGxpa2UgdGhv c2Ugb24gdGhlIHdvcmtzIGZvciBORCBvciBETlMgU0QuDQoNCkFsbCBpbiBhbGwsIEkgZnVsbHkg YWdyZWUgb24gdGhlIGZ1bmRhbWVudGFscyBiZW5lYXRoIHdoYXQgeW914oCZcmUgc2F5aW5nLCB0 aGF0IHJvdXRpbmcgbXVzdCBiZSByZWludHJvZHVjZWQgYXQgdGhlIGJvcmRlcnMgb2YgTDIgbmV0 d29ya3Mgd2hlbiB0aGUgTDIgY2FwYWJpbGl0aWVzIGFyZSBzbyB3aWRlbHkgZGlmZmVyZW50IHRo YXQgYnJpZGdpbmcgd291bGQgZmFpbCB0byBwcm92aWRlIHRoZSBleHBlY3RlZCBMMiBzZXJ2aWNl cyBlbmQtdG8tZW5kLCB0eXBpY2FsbHkgYnJvYWRjYXN0LiBXZSBoYXZlIG9wZW5lZCB0aGUgUGFu ZG9yYSBCb3gsIGlsbHVzaW9ucyBhcmUgZGlzc29sdmluZywgYW5kIHNvbHV0aW9ucyBhcmUgZW1l cmdpbmcuIEdyZWF0IHN0dWZmLg0KDQpUYWtlIGNhcmUsDQoNClBhc2NhbA0KDQoNCkZyb206IE9s ZSBUcm9hbiBbbWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnXQ0KU2VudDogZGltYW5jaGUgMTYg anVpbGxldCAyMDE3IDEwOjQ4DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJl cnRAY2lzY28uY29tPg0KQ2M6IE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz47IGlwdjZA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBJUHY2IFJvdXRpbmcgJiBORCB2cy4gQWRkcmVzc2luZywg KFdhczogUmU6IDxkcmFmdC1pZXRmLTZtYW4tcmZjNDI5MWJpcy0wOS50eHQ+KQ0KDQpQYXNjYWws DQoNCkFncmVlIHdpdGggYWxsIHlvdSdyZSBzYXlpbmcuDQpUaGUgcHJhZ21hdGljIHNvbHV0aW9u cyBmcm9tIG91ciBwZXJzcGVjdGl2ZSBpcyB0byB0cmVhdCB0aGUgbWVkaWEgYXMgYSBzZXQgb2Yg cG9pbnQgdG8gcG9pbnQgbGlua3Mgd2l0aCAvNjQgdG8gZWFjaCBob3N0LiBUaGVuIGFsbCB0aGVz ZSBwcm9ibGVtcyBvZiBtdWx0aWNhc3QsIERBRCBldGMgbWFnaWNhbGx5IGRpc2FwcGVhci4NCg0K T2xlDQoNCk9uIDE2IEp1bCAyMDE3LCBhdCAwODo1OCwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KSA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+PiB3cm90ZToN CkkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLg0KDQpUaGVyZSBhcmUgYSBudW1iZXIgb2YgY2FzZXMg d2hlcmUgYW4gU0RPIGRlc2lnbnMgb24gZmFsc2UgYXNzdW1wdGlvbnMgb2Ygd2hhdCB0aGUgb3Ro ZXIgaXMgZG9pbmcuDQoNCklQdjYgTkQgZXhwZWN0cyB0aGF0IElFRUUgcHJvdG9jb2xzIGNhbiBz ZXJ2ZSAyXjI0IE11bGNhaXIgZ3JvdXBzIHdoaWNoIGVuYWJsZXMgREFEIGFuZCBkaXNjb3Zlcnkg dG8gYmUgcGVyZmVjdGx5IGZpbmUuIE5EIGFsc28gZXhwZWN0cyB0aGF0IHRoZSBjb3JlIHNlcnZp Y2UgdGhhdCA4MDIuMSBwcm92aWRlcyBvbiBFdGhlcm5ldCAocmVsaWFibGUgYnJvYWRjYXN0KSBl eHRlbmRzIHRvIHRoZSB3aG9sZSBFU1Mgc28gd2UgaGF2ZSBvdXIgcHJvYmxlbXMgc29sdmVkLiBT YWRseSwgbm8gc3VjaCB0aGluZy4NCg0KVGhlIHNhbWUgZXhpc3RzIGluIHRoZSBvdGhlciBkaXJl Y3Rpb24gYXMgd2VsbC4gSUVFRSBleHBlY3RzIHRoYXQgdGhlIEFQIHdpbGwgaW1wbGVtZW50IGEg bWFnaWNhbCBORCBwcm94eSBhbmQgdGhhdCBzb2x2ZXMgdGhlIHByb2JsZW0uIEFnYWluLCB0aGUg SUVURiBoYXMgbm8gc3VjaCB0aGluZywgYXQgbGVhc3QgZm9yIE5ELiBTb21lIHBlb3BsZSBhdCBJ RUVFIHRoaW5rIHRoYXQgYnJpZGdpbmcgNDhiaXRzIGFkZHJlc3MgdG8gNjRiaXRzIGFkZHJlc3Nl cyB3aWxsIGVuYWJsZSBicmlkZ2luZyB3aXRoIGFsbCBpdCdzIG5pY2UgcHJvcGVydGllcyBvbiA4 MDIuMTUuNCBsaW5rcy4gR29vZCB0aGluZyB0aGlzIGlsbHVzaW9uIGlzIGRpc3NvbHZpbmcgcmFw aWRseS4NCg0KVGhlIHNvbHV0aW9uIGlzIHByb2JhYmx5IHRvIHN0b3AgdGhyb3dpbmcgb3VyIHBy b2JsZW1zIG92ZXIgdGhlIGZlbmNlICh0aGFua3MgdG8gTm9ybSBGaW5uIGZvciB0aGUgcXVvdGUp LiBBcyB0aGV5IHNheSwgaWZfeW91X3dhbnRfYV90aGluZ19kb25lX3dlbGwsX2RvX2l0X3lvdXJz ZWxmPGh0dHBzOi8vZnIubS53aWt0aW9uYXJ5Lm9yZy93L2luZGV4LnBocD90aXRsZT1pZl95b3Vf d2FudF9hX3RoaW5nX2RvbmVfd2VsbCxfZG9faXRfeW91cnNlbGYmYWN0aW9uPWVkaXQmcmVkbGlu az0xPg0KDQpUaGUgc29sdXRpb24gaXMgcHJvYmFibHkgdG8gdW5kZXJzdGFuZCB0aGUgSUVFRSBk ZXNpZ24gb2YgYW4gRVNTIGZvciBMMiBvcGVyYXRpb25zIGFuZCBlbXVsYXRlIGl0IGF0IEwzLiBB IHN0ZXAgdG93YXJkcyByZWNvbmNpbGlhdGlvbiBvZiB0aGUgZGVzaWducyBtYXkgYmUgdG8gZWZm ZWN0aXZlbHkgcHJvdmlkZSB0aGUgcHJveHkgdGhhdCB0aGUgSUVFRSBleHBlY3RzIHRvIHNlZSBh dCB0aGUgYm91bmRhcnkgb2YgdGhlIG1lZGl1bXMuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2Fs DQoNCkxlIDE2IGp1aWwuIDIwMTcgw6AgMDA6MjMsIE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFy Lm9yZzxtYWlsdG86bmlja0Bmb29iYXIub3JnPj4gYSDDqWNyaXQgOg0KT2xlIFRyb2FuIHdyb3Rl Og0KDQpUaGlzIGEgcHJvdG9jb2wgcHJvYmxlbS4gREFEIGlzIGJ1aWx0IHdpdGggdGhlIGFzc3Vt cHRpb24gdGhhdA0KcGh5c2ljYWwgbGlua3MgYXJlIHJlbGlhYmxlLiAyMCUgcGFja2V0IGxvc3Mg Zm9yIG11bHRpY2FzdCBpcyBjb21tb24NCm9uIHdpZmkuLi4NCg0KbW9zdCBwcm90b2NvbHMgd2ls bCBjcm9hayBhdCAyMCUgcGFja2V0IGxvc3MuICBJZiB3aWZpIGNhbm5vdCBzdXBwb3J0DQptdWx0 aWNhc3QgcHJvcGVybHksIHRoZW4gdGhpcyBpcyBhbiA4MDIuMTEgcHJvYmxlbSByYXRoZXIgdGhh biBhIHByb2JsZW0NCndpdGggREFEIG9yIGFueSBvZiB0aGUgbWFueSBvdGhlciBiaXRzIG9mIGlw djYgdGhhdCBkZXBlbmQgb24gbW9kZXJhdGVseQ0KcmVsaWFibGUgbXVsdGljYXN0Lg0KDQpOaWNr DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlw djZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0K --_000_b742072481db41e98e79cc0a06110192XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGNlcnRhaW5seSBzZW5zZSB0aGUgaXJv bnkgaW4gYXNzZXJ0aW5nIHRoZXJl4oCZcyBzdWNoIG1hZ2ljLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3RhbmNlLCB3aGljaCBtYWdpYyBtYWtlcyBp dCBzbyB0aGF0IHdlIHdvdWxkIHRydXN0IGJldHRlciBESENQKC1QRCkgZm9yIGhhbmRpbmcgYSB1 bmlxdWUgMTYtYml0cyB3b3JkIG9mIHByZWZpeCBzcGFjZSBhcyBvcHBvc2VkIHRvIGEgdW5pcXVl IDY0Yml0cyB3b3JkDQogb2YgSUlEIHNwYWNlPyBJbiBteSBib29rLCB0aGF0IGlzIGVmZmVjdGl2 ZWx5IGhhcmRlciBzaW5jZSB5b3UgY2Fubm90IHJlbHkgZm9yIGxvbmcgb24gTFJVIHRvIGRlbGF5 IHJlYXNzaWduaW5nIGEgcHJldmlvdXNseSBhc3NpZ25lZCB3b3JkLCB5b3UgZ2V0IGxpdHRsZSBo ZWxwIGZyb20gZW50cm9weSB0byBjb3ZlciBmb3IgeW91ciBtaXN0YWtlcyBhbmQgcmFjZSBjb25k aXRpb25zLCBldGPigKYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BbHNvLCBhdCB0aGUgcHJlZml4IGxldmVsLCB3ZSBkbyBub3QgaGF2ZSBEQUQgYXMgdGhlIOKA nHVsdGltYXRl4oCdIHByb3RlY3Rpb24gYWdhaW5zdCBvdXIgYXV0b21hdGVkIG9yIG1hbnVhbCBh c3NpZ25tZW50IG1pc3Rha2VzOyByb3V0aW5nIGlzIG5vdCBkZXRlcnJlZCBieSBkdXBsaWNhdGlv biwNCiBpdCBqdXN0IHNlZXMgMiBhZHZlcnRpc2VtZW50cyBhcyBhbHRlcm5hdGUgd2F5cyB0byBn ZXQgdGhlcmUuIFdoaWNoIG1lYW5zIHRoYXQgaWYgYSAvNjQgaXMgZHVwbGljYXRlZCwgcGFja2V0 cyB3aWxsIGJlIGRlbGl2ZXJlZCB0byB0aGUgbmVhcmVzdCBvZiB0aGUgMiBvd25lcnMgZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgdGhlIHNvdXJjZS4gTm90IGEgZ3JlYXQgYmVuZWZpdCBmcm9tIHRo ZSBjdXJyZW50IHNpdHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNvIGNlcnRhaW5seSB5b3Ugd2FudCB0byBxdWFsaWZ5IHdoZW4gYW4gaWRlYSBzdWNo IGFzIGEgLzY0IG9yIHNob3J0ZXIgZm9yIGFsbCBhcHBsaWVzIHBhcnRpY3VsYXJseSB3ZWxsIChl LmcuIGFuIGV2ZW50IHN0YXJ0aW5nIHdpdGggYSBjbGVhbiBzbGF0ZSwgd2l0aCBsZXNzDQogY29u bmVjdGVkIGRldmljZXMgaW4gdGhlIHB1YmxpYyB0aGFuIGF2YWlsYWJsZSBwcmVmaXhlcywgYW5k IGEgY2xlYXIgZW5kIG9mIHRpbWUgd2hlbiBhbGwgcHJlZml4ZXMgYXJlIHJlbGVhc2VkKSwgYW5k IHdoZW4gaXQgc2hvd3MgbGltaXRzLiBDb21pbmcgZnJvbSB0aGUgdmVyeSBkaWZmZXJlbnQgZ3Jv dW5kIG9mIElvVCwgYW5kIHRob3VnaCBJIGFtIHF1aXRlIGNvbnZpbmNlZCBieSB0aGF0IHBhcnRp Y3VsYXIgaWRlYSwgSSBkbyBub3QgYmVsaWV2ZQ0KIGluIGEgb25lLWZpdHMtaXQtYWxsIHNvbHV0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmWQgcmVh bGx5IGxvdmUgdG8gc2VlIGEgZHJhZnQgdGhhdCBkb2N1bWVudHMgYSBzZXQgb2YgcmVmZXJlbmNl IG1vZGVscyAocHJvZmlsZXM/KSB0byBoZWxwIG91ciB1c2VycyBkZXBsb3kgYW4gSVB2NiBjYW1w dXMgbmV0d29yayB0aGF0IG1lZXRzIHRoZWlyIGV4cGVjdGF0aW9ucy4NCiBSb3V0aW5nIHRvIHRo ZSAvNjQgaXMgZGVmaW5pdGVseSBhIGdyZWF0IG9uZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBoYXZlIHNvbWUgb3RoZXJzIGluIHRoZSBJT1Qgc3BhY2Ug dG8gc2VydmUgZGlmZmVyZW50IHVzZSBjYXNlcyBpbnZvbHZpbmcgdmVyeSBsb25nIHRlcm0gZGVw bG95bWVudHMsIGxhcmdlIG51bWJlcnMgb2YgZGV2aWNlcywgZG90dGluZyBsaW5lIHN0YXRlIG9m IGNvbm5lY3Rpdml0eSwNCiBtb2JpbGl0eSwgYW5kIGRyYXN0aWNhbGx5IGxpbWl0ZWQgY2FwYWJp bGl0eSB0byBkbyBjb21wbGV4IHN0dWZmIHN1Y2ggYXMgSVB2NiByZW51bWJlcmluZy4gJm5ic3A7 VG8gc2VydmUgc3VjaCB1c2UgY2FzZXMsIHdlIGFyZSBlZmZlY3RpdmVseSBzcGVjaWZ5aW5nIE5E IG9wZXJhdGlvbiBhbmQgcHJveHkuIEkgZG8gbm90IHNlZSB0aGF0IGFzIGNvbXBldGl0aW9uIHRv IHRoZSAvNjQgYXBwcm9hY2guIEl0IGlzIGluIGZhY3QgZm9sbG93aW5nIHRoZSBjb21tb24NCiBp ZGVhIHRvIHJlaW50cm9kdWNlIHNvbWUgcm91dGluZyB3aGVuIHdlIGhpdCB0aGUgbGltaXRzIG9m IGJyaWRnaW5nLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo aXMgaGFzIGNvbnNlcXVlbmNlcy4gQXMgd2UgZ2V0IHJpZCBvZiB0aGUgaWxsdXNpb24gb2YgdGhl IGZyZWUgYW5kIHNwYW5uaW5nIGJyb2FkY2FzdCBkb21haW4sIHdlIG5lZWQgdG8gcmVjb25zaWRl ciBob3cgd2UgYXBwbHkgcHJvdG9jb2xzIHRoYXQgdXNlZCB0byByZWx5DQogb24gTDIgYnJvYWRj YXN0LiBJIGV4cGVjdCB0byBzZWUgbW9yZSBhbmQgbW9yZSBwcm94aWVzIHNob3dpbmcgdXAsIGxp a2UgdGhvc2Ugb24gdGhlIHdvcmtzIGZvciBORCBvciBETlMgU0QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbGwgaW4gYWxsLCBJIGZ1bGx5IGFncmVlIG9uIHRo ZSBmdW5kYW1lbnRhbHMgYmVuZWF0aCB3aGF0IHlvdeKAmXJlIHNheWluZywgdGhhdCByb3V0aW5n IG11c3QgYmUgcmVpbnRyb2R1Y2VkIGF0IHRoZSBib3JkZXJzIG9mIEwyIG5ldHdvcmtzIHdoZW4g dGhlIEwyIGNhcGFiaWxpdGllcw0KIGFyZSBzbyB3aWRlbHkgZGlmZmVyZW50IHRoYXQgYnJpZGdp bmcgd291bGQgZmFpbCB0byBwcm92aWRlIHRoZSBleHBlY3RlZCBMMiBzZXJ2aWNlcyBlbmQtdG8t ZW5kLCB0eXBpY2FsbHkgYnJvYWRjYXN0LiBXZSBoYXZlIG9wZW5lZCB0aGUgUGFuZG9yYSBCb3gs IGlsbHVzaW9ucyBhcmUgZGlzc29sdmluZywgYW5kIHNvbHV0aW9ucyBhcmUgZW1lcmdpbmcuIEdy ZWF0IHN0dWZmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGFr ZSBjYXJlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGFzY2Fs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT2xlIFRyb2FuIFttYWlsdG86 b3Ryb2FuQGVtcGxveWVlcy5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGltYW5jaGUgMTYganVp bGxldCAyMDE3IDEwOjQ4PGJyPg0KPGI+VG86PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQp ICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOaWNrIEhpbGxpYXJk ICZsdDtuaWNrQGZvb2Jhci5vcmcmZ3Q7OyBpcHY2QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBJUHY2IFJvdXRpbmcgJmFtcDsgTkQgdnMuIEFkZHJlc3NpbmcsIChXYXM6IFJlOiAm bHQ7ZHJhZnQtaWV0Zi02bWFuLXJmYzQyOTFiaXMtMDkudHh0Jmd0Oyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UGFzY2FsLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BZ3JlZSB3aXRoIGFsbCB5b3Un cmUgc2F5aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIHByYWdtYXRpYyBzb2x1 dGlvbnMgZnJvbSBvdXIgcGVyc3BlY3RpdmUgaXMgdG8gdHJlYXQgdGhlIG1lZGlhIGFzIGEgc2V0 IG9mIHBvaW50IHRvIHBvaW50IGxpbmtzIHdpdGggLzY0IHRvIGVhY2ggaG9zdC4gVGhlbiBhbGwg dGhlc2UgcHJvYmxlbXMgb2YgbXVsdGljYXN0LCBEQUQgZXRjIG1hZ2ljYWxseSBkaXNhcHBlYXIu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pk9sZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGJyPg0KT24gMTYgSnVsIDIwMTcsIGF0 IDA4OjU4LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRo dWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGVyZSBhcmUgYSBu dW1iZXIgb2YgY2FzZXMgd2hlcmUgYW4gU0RPIGRlc2lnbnMgb24gZmFsc2UgYXNzdW1wdGlvbnMg b2Ygd2hhdCB0aGUgb3RoZXIgaXMgZG9pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPklQdjYgTkQgZXhwZWN0cyB0aGF0IElFRUUgcHJvdG9jb2xz IGNhbiBzZXJ2ZSAyXjI0IE11bGNhaXIgZ3JvdXBzIHdoaWNoIGVuYWJsZXMgREFEIGFuZCBkaXNj b3ZlcnkgdG8gYmUgcGVyZmVjdGx5IGZpbmUuIE5EIGFsc28gZXhwZWN0cyB0aGF0IHRoZSBjb3Jl IHNlcnZpY2UgdGhhdCA4MDIuMSBwcm92aWRlcyBvbiBFdGhlcm5ldCAocmVsaWFibGUgYnJvYWRj YXN0KQ0KIGV4dGVuZHMgdG8gdGhlIHdob2xlIEVTUyBzbyB3ZSBoYXZlIG91ciBwcm9ibGVtcyBz b2x2ZWQuIFNhZGx5LCBubyBzdWNoIHRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGUgc2FtZSBleGlzdHMgaW4gdGhlIG90aGVyIGRpcmVj dGlvbiBhcyB3ZWxsLiBJRUVFIGV4cGVjdHMgdGhhdCB0aGUgQVAgd2lsbCBpbXBsZW1lbnQgYSBt YWdpY2FsIE5EIHByb3h5IGFuZCB0aGF0IHNvbHZlcyB0aGUgcHJvYmxlbS4gQWdhaW4sIHRoZSBJ RVRGIGhhcyBubyBzdWNoIHRoaW5nLCBhdCBsZWFzdCBmb3IgTkQuIFNvbWUgcGVvcGxlIGF0IElF RUUgdGhpbmsNCiB0aGF0IGJyaWRnaW5nIDQ4Yml0cyBhZGRyZXNzIHRvIDY0Yml0cyBhZGRyZXNz ZXMgd2lsbCBlbmFibGUgYnJpZGdpbmcgd2l0aCBhbGwgaXQncyBuaWNlIHByb3BlcnRpZXMgb24g ODAyLjE1LjQgbGlua3MuIEdvb2QgdGhpbmcgdGhpcyBpbGx1c2lvbiBpcyBkaXNzb2x2aW5nIHJh cGlkbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlRoZSBzb2x1dGlvbiBpcyBwcm9iYWJseSB0byBzdG9wIHRocm93aW5nIG91ciBwcm9ibGVtcyBv dmVyIHRoZSBmZW5jZSAodGhhbmtzIHRvIE5vcm0gRmlubiBmb3IgdGhlIHF1b3RlKS4gQXMgdGhl eSBzYXksJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9mci5tLndpa3Rpb25hcnkub3JnL3cvaW5kZXgu cGhwP3RpdGxlPWlmX3lvdV93YW50X2FfdGhpbmdfZG9uZV93ZWxsLF9kb19pdF95b3Vyc2VsZiZh bXA7YWN0aW9uPWVkaXQmYW1wO3JlZGxpbms9MSI+aWZfeW91X3dhbnRfYV90aGluZ19kb25lX3dl bGwsX2RvX2l0X3lvdXJzZWxmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5UaGUgc29sdXRpb24gaXMgcHJvYmFibHkgdG8gdW5kZXJzdGFuZCB0 aGUgSUVFRSBkZXNpZ24gb2YgYW4gRVNTIGZvciBMMiBvcGVyYXRpb25zIGFuZCBlbXVsYXRlIGl0 IGF0IEwzLiBBIHN0ZXAgdG93YXJkcyByZWNvbmNpbGlhdGlvbiBvZiB0aGUgZGVzaWducyBtYXkg YmUgdG8gZWZmZWN0aXZlbHkgcHJvdmlkZSB0aGUgcHJveHkgdGhhdCB0aGUgSUVFRSBleHBlY3Rz DQogdG8gc2VlIGF0IHRoZSBib3VuZGFyeSBvZiB0aGUgbWVkaXVtcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFsbCB0aGUgYmVzdCw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlBhc2NhbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxicj4NCkxlIDE2IGp1aWwuIDIw MTcgw6AgMDA6MjMsIE5pY2sgSGlsbGlhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrQGZvb2Jh ci5vcmciPm5pY2tAZm9vYmFyLm9yZzwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbGUgVHJvYW4gd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoaXMg YSBwcm90b2NvbCBwcm9ibGVtLiBEQUQgaXMgYnVpbHQgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0 PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnBoeXNpY2FsIGxpbmtzIGFyZSByZWxpYWJsZS4gMjAl IHBhY2tldCBsb3NzIGZvciBtdWx0aWNhc3QgaXMgY29tbW9uPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPm9uIHdpZmkuLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCm1vc3QgcHJvdG9jb2xz IHdpbGwgY3JvYWsgYXQgMjAlIHBhY2tldCBsb3NzLiAmbmJzcDtJZiB3aWZpIGNhbm5vdCBzdXBw b3J0PGJyPg0KbXVsdGljYXN0IHByb3Blcmx5LCB0aGVuIHRoaXMgaXMgYW4gODAyLjExIHByb2Js ZW0gcmF0aGVyIHRoYW4gYSBwcm9ibGVtPGJyPg0Kd2l0aCBEQUQgb3IgYW55IG9mIHRoZSBtYW55 IG90aGVyIGJpdHMgb2YgaXB2NiB0aGF0IGRlcGVuZCBvbiBtb2RlcmF0ZWx5PGJyPg0KcmVsaWFi bGUgbXVsdGljYXN0LiAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KTmljazxicj4NCjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2NiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b742072481db41e98e79cc0a06110192XCHRCD001ciscocom_-- From nobody Sun Jul 16 03:13:41 2017 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 05683126DC2 for ; Sun, 16 Jul 2017 03:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 wUY0l-ejJ6EV for ; Sun, 16 Jul 2017 03:13:37 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002: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 44018129B2C for ; Sun, 16 Jul 2017 03:13:37 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id a12so38560964ywh.3 for ; Sun, 16 Jul 2017 03:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d7318fwZyHCsGua+PuP6JF0W2pJi/kfvO0tArhK7q6U=; b=euqzw79/MKZFF+NvFPqLkiRyGLI6m60YWGLLVp78FnUOWBpb+8pTP7R+orL8wx9zbp xZHI/QdqZBRnsjaVb868NeRqcLGUhU50G4TF8M8n+/L9YeCQCo0kn46cRntl4sKAbd46 bXO085vQjhrJOqs72lg/0kKJKtNuNyscI3US+fEQMjHx0HBaW5ud64XDqBIza/O6P0QA 6L36mEx1i8//w16JzRuNSgMgRTKDNUJDFRgJsXXVAAk2OhdNvdKcrhSVmBup7PxRQiwf qI0h/OxY07DU3/VbY0eyA3XumzUprrkZCc6Uokj39qx0vQAy5OHet/U3NvPmkPJa41ER MFgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d7318fwZyHCsGua+PuP6JF0W2pJi/kfvO0tArhK7q6U=; b=jQjF/Uq7sjYwm8+BWbbG+TuI2rkujQ5sZzlni1FfaBtPUlW4WppB+XFVFjrBuT+SOZ v3e4cPbKiPlUQqjdpqVZgV+ulV/XdFv+KCfkFckEuUqx12Bq7MlkVxcWZh9mEC1D23C6 g5kpF7U6ic2Sf53Az6VcXB1ZEvHZwh4CuFp4FGWDE8P16DrF4xo+OE/jmW2fHdApwT1W IfBfOzqn5W7iP0hPHW9WUOr/Pr/FEMzrECdf/dF2kX+DQODEVhU8kwMorBcgjr3hGR1O Qcv7Xk5KF3/kqpk4rKEgaadVKVjRrdh6JSqeNzuPMQ+2GEGhPJ/1qa46Ivp+DnUK6PaE Qk8Q== X-Gm-Message-State: AIVw112riWUbPaNzc5XaHuTk1mbozkfXDO6S4QPWBiYV7ugyJewipptD lAKtRJ/xSMgYrD8bxzSZ7pxJCYZa0+jcYjA= X-Received: by 10.129.46.3 with SMTP id u3mr3649573ywu.312.1500200016186; Sun, 16 Jul 2017 03:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Sun, 16 Jul 2017 03:13:15 -0700 (PDT) In-Reply-To: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> From: Erik Kline Date: Sun, 16 Jul 2017 19:13:15 +0900 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Lorenzo Colitti Cc: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114080ce14da8305546c896c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:13:39 -0000 --001a114080ce14da8305546c896c Content-Type: text/plain; charset="UTF-8" On 16 July 2017 at 18:31, Lorenzo Colitti wrote: > On Mon, Jul 3, 2017 at 5:40 PM, wrote: >> >> 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 : IPv6 Node Requirements >> Authors : Tim Chown >> John Loughney >> Timothy Winters >> Filename : draft-ietf-6man-rfc6434-bis-01.txt > > > I see that the document still says: > > There will be a wide > range of IPv6 deployment models and differences in address assignment > requirements, some of which may require DHCPv6 for stateful address > assignment. Consequently, all hosts SHOULD implement address > configuration via DHCPv6. > > We should abandon this documentation, for two reasons. > > First, networks that require DHCPv6 assignment are explicitly NOT > RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section 8 > says "it is RECOMMENDED that the network give the host the ability to use > new addresses without requiring explicit requests". A DHCPv6-only network > cannot meet this recommendation, because on a DHCPv6-only network, all > addresses acquisition requires an explicit request to the network. > > Second, the draft says "Where devices are likely to be carried by users and > attached to multiple visisted networks, DHCPv6 client anonymity profiles > SHOULD be supported as described in [RFC7844]". > > But RFC 7844 says that hosts SHOULD prefer stateless address configuration > over DHCPv6: "hosts using the anonymity profile SHOULD use stateless address > configuration instead of stateful address configuration". > > So for such devices, there is a direct conflict: this document says they > SHOULD do DHCPv6, but RFC 7844 says they SHOULD not if other addressing > modes are available. > > I would propose the following text for section 6.5: > > [...] There will be a wide > range of IPv6 deployment models and differences in address assignment > requirements, some of which may use DHCPv6 for stateful address > assignment in addition to other addressing modes. Using DHCPv6 as the > only IPv6 address configuration mechanism is NOT RECOMMENDED > [RFC 7934 section 8]. > > In the absence of a router, IPv6 nodes using DHCP for address > assignment MAY initiate DHCP to obtain IPv6 addresses and other > configuration information, as described in Section 5.5.2 of > [RFC4862]. > > Where devices are likely to be carried by users and attached to > multiple visisted networks, DHCPv6 client anonymity profiles SHOULD > be supported as described in [RFC7844] to minimise the discolosure of > identifying information. This profile recommends that the device prefer > stateless address configuration over DHCPv6 address configuration. > > Devices that do not have particular anonymity requirements SHOULD > implement address configuration via DHCPv6 in order to be able to > take advantage of IPv6 addresses available only via DHCPv6. Sounds good to me. I also think that section 5.9 on RFC 4191 should be a MUST. We don't want to end up in a situation where routers are sending out PIOs with /56s and L=0 in order to maintain internal connectivity when RAs have default_router_lifetime=0, e.g. because the upstream network has gone away. --001a114080ce14da8305546c896c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgNK0FznculFml8H6RCLzA0OMvMu3BvoCN yy/KfJdWTp8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE2 MTAxMzM2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAIp4NaIraWafhsKfJzM+/qSmJqQ6OQ6wsrJ34AiNIojciDCcMMtl kQw0/PzhaAY0M/KPZyM9yQBFHL8TcFvgWihtkVvUtXce8OvFQWhenuJcLe9AMMUL5F2SmeuXxPSM gusy1pO8W0rRjm31rM/O/cis0l3kjpKHnnWWRfcTdrFcN4YMNsVRPzwJIDZoeRzOVcVFVieuHSUP LVqzSIfI8KpqMNeFQ15wkKFvxfnvxMTKwBm0TVDkEgMENnbBgCxYfCYboYi4AxQrbYxYB5OSiOE+ rc2ybJDhoKmnUQRkTxcI5PzUi8Z/g0Eh5IPS03FozKrN/l6SnpFYBQ+ZHLMgNzw= --001a114080ce14da8305546c896c-- From nobody Sun Jul 16 04:20:09 2017 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 0C0B912F268 for ; Sun, 16 Jul 2017 04:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 jHMwSRKHaG8m for ; Sun, 16 Jul 2017 04:20:07 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7A012EC4B for ; Sun, 16 Jul 2017 04:20:06 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6GBK23B049653 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2017 12:20:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596B4BE1.7020807@foobar.org> Date: Sun, 16 Jul 2017 12:20:01 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 11:20:09 -0000 Lorenzo Colitti wrote: > I see that the document still says: > > There will be a wide range of IPv6 deployment models and differences > in address assignment requirements, some of which may require DHCPv6 > for stateful address assignment. Consequently, all hosts SHOULD > implement address configuration via DHCPv6. > > We should abandon this documentation, for two reasons. > > First, networks that require DHCPv6 assignment are explicitly NOT > RECOMMENDED by current IETF best practices. Specifically, RFC 7934 > section 8 says "it is RECOMMENDED that the network give the host the > ability to use new addresses without requiring explicit requests". A > DHCPv6-only network cannot meet this recommendation, because on a > DHCPv6-only network, all addresses acquisition requires an explicit > request to the network. > > Second, the draft says "Where devices are likely to be carried by > users and attached to multiple visisted networks, DHCPv6 client > anonymity profiles SHOULD be supported as described in [RFC7844]". neither of these suggestions form anything even close to an adequate basis to drop the recommendation for dhcpv6. The self-selection addressing model does not suit the deployment requirements for many types of ipv6 networks, including enterprise, provider hosting, terrestrial access networks (e.g. docsis / gpon / ipoe) and others. If the recommendation for dhcpv6 is dropped, then there is no recommended ietf model for operator-assigned addressing, and this would leave a glaring hole in the ipv6 host specification. Just because SLAAC works for many types of ipv6 deployments, that doesn't make it a suitable model for every situation. Nick From nobody Sun Jul 16 04:25:35 2017 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 A425512F3CB for ; Sun, 16 Jul 2017 04:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 83DIRTVj0cck for ; Sun, 16 Jul 2017 04:25:32 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0B312F268 for ; Sun, 16 Jul 2017 04:25:32 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r125so64975668vkf.1 for ; Sun, 16 Jul 2017 04:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d8ndrpLtDyfV1aIR5+rKo+69B1+mUvcVAInwhxISYOk=; b=tf0ATVsr3c9Xp77XoL2Ev9fTuDMWYt40rkMdwHx9w6cPpcj1pe3DShhsUO/xH5BE6g gIRNw1jwHBp2smHAq5JYV4croxGHu2ptg6qyC1suXI2AW+CKDa20l4+2PKvfPd3eH7gW yWkrOjEC9Onn5DabItPBhuXrVWViRlxsaEsp7jMclsRmSiuTTwovIZm5jkF3AGRAK1+D ge5vADjI76Ju19JQGvEncnCRjnwoLUmfEdIWAtySSxGayrLK0RtV9V9+Bi2Bh3rwWoFS S+F32WIA1y0FGre8bcKn+9/OErMiWY5J0/GUjArvP6EIzkQup78Hk4g0zCPBnNrryUVj x2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d8ndrpLtDyfV1aIR5+rKo+69B1+mUvcVAInwhxISYOk=; b=kIuxY3S69tUjWdYe34NFKTuOk0WIQvsxkCpijo0OeS+IohpYHEqg+Xd5MnSBxm0qGz BXRx66I3MJuZbfPzlbYynovFoYiwLtoGbC3L80NbYG5KwzxPF61fux5WU+SuotclnnJ2 HQQbANI3Wy9MMKYJk+8Ew+RLiARzUbpTTFzV3fSDXxplUWHvAHP+CNaQy0ZXbVk1xh8u kJVjCkHQsC4QgQoTXp9ry52M8jdwn5WSISnhLHwviuH9ucLHOyLg7ms3oQdD/8YPTwBo q4oY/ul0oWqYlu6n2QI6buQ7ma6aYEjLPkxU1okVkTE35SrmW4PjpehLRGroDSFcXWAw rW4Q== X-Gm-Message-State: AIVw110tMhph4U7XNM3Lg2Nd2t3xRbSt/xp33MRUyYW9Hkv2LzV3qqwO IjecNJw2Co90oD8JCkH8+bDzFj2xKFS9 X-Received: by 10.31.181.1 with SMTP id e1mr9761717vkf.69.1500204331286; Sun, 16 Jul 2017 04:25:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Sun, 16 Jul 2017 04:25:10 -0700 (PDT) In-Reply-To: <596B4BE1.7020807@foobar.org> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> From: Lorenzo Colitti Date: Sun, 16 Jul 2017 13:25:10 +0200 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Nick Hilliard Cc: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Content-Type: multipart/alternative; boundary="001a1143a5704243c205546d8a85" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 11:25:34 -0000 --001a1143a5704243c205546d8a85 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard wrote: > The self-selection addressing model does not suit the deployment > requirements for many types of ipv6 networks, including enterprise, > provider hosting, terrestrial access networks (e.g. docsis / gpon / > ipoe) and others. If the recommendation for dhcpv6 is dropped, then > there is no recommended ietf model for operator-assigned addressing, and > this would leave a glaring hole in the ipv6 host specification. > That's a fair opinion to hold, but the fact of the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844. We shouldn't publish a host requirements document that contradicts the host address assignment BCP and that cites RFC7844 while contradicting that document's recommendation to use stateless in preference to stateful. --001a1143a5704243c205546d8a85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 16, 2017 at 1:20 PM, Nick Hilliard <nick@foobar.org> w= rote:
The self-selection addressing model= does not suit the deployment
requirements for many types of ipv6 networks, including enterprise,
provider hosting, terrestrial access networks (e.g. docsis / gpon /
ipoe) and others.=C2=A0 If the recommendation for dhcpv6 is dropped, then there is no recommended ietf model for operator-assigned addressing, and this would leave a glaring hole in the ipv6 host specification.

That's a fair opinion to hold, but the fact of= the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 784= 4.

We shouldn't publish a host requirements do= cument that contradicts the host address assignment BCP and that cites RFC7= 844 while contradicting that document's recommendation to use stateless= in preference to stateful.
--001a1143a5704243c205546d8a85-- From nobody Sun Jul 16 05:12:23 2017 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 6E12713178E for ; Sun, 16 Jul 2017 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 8fkpkshR0fcb for ; Sun, 16 Jul 2017 05:12:19 -0700 (PDT) Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) (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 7457E12EC06 for ; Sun, 16 Jul 2017 05:12:19 -0700 (PDT) Received: by mail-wr0-f179.google.com with SMTP id w4so10833502wrb.2 for ; Sun, 16 Jul 2017 05:12:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=e2YdrsUOA1UCDK2CN9VJ03OS8MFSjzerf99/XGrN6e8=; b=Ij0mFq9faBb5ykThlrQddj3kkTv3amYdgQhQ0NtgGIQm32kWNLvwD4rXHyIrbfW3uj VJ3v9x50K7fF8hYfx0rKYYN3VYL9UUcht9+WTXgzAPTlGiY+Ib/3nZ2kOuu/iQxvmCYX EzQM35ghHlhZBbN26O0gmNVl3ZGegjRLv0SiK3QfSwVqQ/H6TL8OhmKir/19OgnoUPoC q5UjqVQDOZMG4gbFXTmxv8LRMtMMmzLnKok0hVxzOHpVqU/3tWHAPeAazGabZd4baNui 7z8YerbK0tuBGeUwi0HJZ6STrbAZ7WUVKRGCrzpJLf5BXJ0gpTRqOq3gk9uJ6zVpe3aB 5bSA== X-Gm-Message-State: AIVw113ZCLmJDX0JzwcijhnV3YjkrT466b41Cqo1FrbplVTvBmivUfKa 7mZtWSBBiqbx5w3KL2ZymA== X-Received: by 10.223.139.21 with SMTP id n21mr8501080wra.42.1500207137760; Sun, 16 Jul 2017 05:12:17 -0700 (PDT) Received: from localhost ([62.168.35.69]) by smtp.gmail.com with ESMTPSA id y35sm14720544wrc.51.2017.07.16.05.12.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 05:12:16 -0700 (PDT) Date: Sun, 16 Jul 2017 14:12:08 +0200 From: Job Snijders To: Lorenzo Colitti Cc: Nick Hilliard , draft-ietf-6man-rfc6434-bis@tools.ietf.org, IETF IPv6 Mailing List Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Message-ID: <20170716121208.wns32djqm43jmn6u@Vurt.local> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 12:12:21 -0000 On Sun, Jul 16, 2017 at 01:25:10PM +0200, Lorenzo Colitti wrote: > On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard wrote: > > The self-selection addressing model does not suit the deployment > > requirements for many types of ipv6 networks, including enterprise, > > provider hosting, terrestrial access networks (e.g. docsis / gpon / > > ipoe) and others. If the recommendation for dhcpv6 is dropped, then > > there is no recommended ietf model for operator-assigned addressing, > > and this would leave a glaring hole in the ipv6 host specification. > > That's a fair opinion to hold, but the fact of the matter is that a > SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844. I think that the words 'opinion' and 'fact' may need to be swapped around in the above sentence. Operator-assigned addressing should not be left out or discouraged. Kind regards, Job From nobody Sun Jul 16 05:14:13 2017 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 25F5713178E for ; Sun, 16 Jul 2017 05:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Hw-pEYveApVU for ; Sun, 16 Jul 2017 05:14:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ADA130889 for ; Sun, 16 Jul 2017 05:14:09 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6GCE39f055969 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2017 13:14:03 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596B588A.2010701@foobar.org> Date: Sun, 16 Jul 2017 13:14:02 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 12:14:11 -0000 Lorenzo Colitti wrote: > That's a fair opinion to hold, but the fact of the matter is that a > SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844. "The fact of the matter"? :-) There is no conflict here. The "SHOULD" that you quoted in rfc7934 refers to how an opinion about people ought to run their networks, but does not conflict with the SHOULD in 6434bis, which refers to what the IETF is proposing ought to be supported on host devices. These two things are very different indeed. Nick From nobody Sun Jul 16 05:53:34 2017 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 504C512EBF4 for ; Sun, 16 Jul 2017 05:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcCsxWbZmDMa for ; Sun, 16 Jul 2017 05:53:31 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 948D0129B2C for ; Sun, 16 Jul 2017 05:53:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6A9484A; Sun, 16 Jul 2017 14:53:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1500209607; bh=WdiKxv1ra7RTwloc21c Xgm+d0JQG1HPiT9m17Z58z+8=; b=SLXqbFe2DOO9zh0N8Gld84CoU1+GOpKpc+7 tvgpWXZKFZKQHYujkwBxXGfRPCxTGDBESGtjRmhksxrfVidkS3z3wSBm1tm+r0aj YbqRCfrncl5HTdJkgkDsJ58Sobxz99jEa18X9qV8UjrdbILtrJwox9R2QWXTH3Ds LTr/P3U4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id c1EqOSS7TTep; Sun, 16 Jul 2017 14:53:27 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:9300:68b2:827c:4f19:1178] (unknown [IPv6:2a02:a213:a300:9300:68b2:827c:4f19:1178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 0346B49; Sun, 16 Jul 2017 14:53:26 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0B384C37-DD71-4EF1-AC64-74C3F284315A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Date: Sun, 16 Jul 2017 14:53:26 +0200 In-Reply-To: <596B588A.2010701@foobar.org> Cc: Lorenzo Colitti , draft-ietf-6man-rfc6434-bis@tools.ietf.org, IETF IPv6 Mailing List To: Nick Hilliard References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 12:53:33 -0000 --Apple-Mail=_0B384C37-DD71-4EF1-AC64-74C3F284315A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Op 16 jul. 2017, om 14:14 heeft Nick Hilliard het = volgende geschreven: >=20 > Lorenzo Colitti wrote: >> That's a fair opinion to hold, but the fact of the matter is that a >> SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844. >=20 > "The fact of the matter"? :-) >=20 > There is no conflict here. >=20 > The "SHOULD" that you quoted in rfc7934 refers to how an opinion about > people ought to run their networks, but does not conflict with the > SHOULD in 6434bis, which refers to what the IETF is proposing ought to > be supported on host devices. These two things are very different = indeed. +1 Cheers, Sander --Apple-Mail=_0B384C37-DD71-4EF1-AC64-74C3F284315A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZa2HGAAoJEKAtA7D+JBO5xZAH/31ml3TDiyPhA7eDxgu+3h6p nNHmujoitGJp2OUBHHXeXj6nS+XJY0Bx8ThQO0/lFBZvk04egwV9VZ90WCxvQ6L+ FVtErZcKO79J3SklTcmTLjXpPfAGV5dhVtRwfbqYLAlBLXNgjdOu9TC+qi4WWRMW 4X+4wAoZeJkVfMuQZSfIwhjjdGhh5IfwOTQNWDxVJrk7AsQ/puWEq8cVUG36tueF 8ios2A1nnpPpG3Crccbf+o9rjL0cL2npYnUePHFysFvi+pr9ee4hltde5RQ+366/ ANYAT5IIL4cH9WeSGDThVKJ00g2PxEYkgxDMY0hm6jd9AzJ+3VBFSgqWCAKgZVE= =mHvq -----END PGP SIGNATURE----- --Apple-Mail=_0B384C37-DD71-4EF1-AC64-74C3F284315A-- From nobody Sun Jul 16 06:48:04 2017 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 66B8E12706D for ; Sun, 16 Jul 2017 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 Fh7ShJmU_0VR for ; Sun, 16 Jul 2017 06:48:02 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 D14271200FC for ; Sun, 16 Jul 2017 06:48:01 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id y70so65084990vky.3 for ; Sun, 16 Jul 2017 06:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=axauypNIY2T+YnQ53wLmT2h4yg1XU6ZomBqP21ziq9w=; b=bgkl2feQ8YEORmEKRPEHw8+njWai4YiA4TzzL6meqzEIBr+zC8tWO/QKnhYsDB0kst rQrlNHZ2DUMZH+Ij/J9YFNR2P1NApedkKdPYETd93fbf+eK4zABjdqcWu/AIQNaDW9ox V5i7NWsUP30eQ6CJYQEm2sFowIcPdyWfYC5xYcRE9xemcQn7losvAd+KEEW/LwsIPrVw WwjeZPha1+MXVPZa4WUUJDBV2dUfYnreZQjth+GpuYQRn57zaBhnToHyUoC23zhwbO31 7y9VzgMRGrcdXj7WkVt3nmjvDJI/kFJbDiJIZychknleYL2+DbKq06iPBVefy1tEFHX2 nD6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=axauypNIY2T+YnQ53wLmT2h4yg1XU6ZomBqP21ziq9w=; b=I8UfvjRsojV0hJKLU4PhlPIJWobiTrq+ghmPmWbwQvEBbO2Wm+vOIqOB4jHCMpukV3 XUa7QNi6UcNd1OD6/VI1NDWTIJ97Vje1SsuV9mSwjtVnO4DJVeoka7TrCOO0zfS7hg8h CY/CA9zS8/Js/dxjcGXpnHAm42xFxpNlNXJLgkw0WwigSRKbUDTAZyZVaVOcM3jWOoHg R10+IoWGBp8eXytuFs3hlQZQVc1EF769PY0W10xM2uH9vo5GIQLVdLBsMJM0mdRRxO91 oHAOHHWeTpBUku7GfK6F22ilnixTEx3mceRHIZuGgbzjP2dPLTn2CEWTYf0G8H1S0s9C rHdg== X-Gm-Message-State: AIVw110rFXwvfS0vjJqUzLWxxDM4fFJ2Jj+OMFFxxSiYghgcWBCWYwIg FewGivG73gb2X6p9nkgrvFBttZe/ELJu X-Received: by 10.31.189.19 with SMTP id n19mr10139708vkf.53.1500212880633; Sun, 16 Jul 2017 06:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.48.129 with HTTP; Sun, 16 Jul 2017 06:47:39 -0700 (PDT) In-Reply-To: <596B588A.2010701@foobar.org> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> From: Lorenzo Colitti Date: Sun, 16 Jul 2017 15:47:39 +0200 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Nick Hilliard Cc: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Content-Type: multipart/alternative; boundary="001a114d3b12d7266305546f87f1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 13:48:03 -0000 --001a114d3b12d7266305546f87f1 Content-Type: text/plain; charset="UTF-8" vOn Sun, Jul 16, 2017 at 2:14 PM, Nick Hilliard wrote: > There is no conflict here. > > The "SHOULD" that you quoted in rfc7934 refers to how an opinion about > people ought to run their networks, but does not conflict with the > SHOULD in 6434bis, which refers to what the IETF is proposing ought to > be supported on host devices. These two things are very different indeed. > It's not an opinion, it's an IETF best practice. And I really don't see how you can say there's no contradiction. For the moment, let's consider mobile hosts that follow the anonymity profile. This document says that hosts SHOULD support DHCPv6 because operators might use it. But our current recommendations say that: 1. Such hosts SHOULD prefer SLAAC over DHCPv6 2. DHCPv6-only networks are NOT RECOMMENDED Due to #1, such hosts will always prefer SLAAC over DHCPv6 on networks that have both. So a "SHOULD support DHCPv6" requirement will only matter on networks that don't do SLAAC, which are NOT RECOMMENDED. So we're basically saying that they SHOULD implement IPv6 only for the purpose of connecting to networks that are NOT RECOMMENDED. How can we recommend something that is only used for something that is NOT RECOMMENDED? --001a114d3b12d7266305546f87f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
vOn = Sun, Jul 16, 2017 at 2:14 PM, Nick Hilliard <nick@foobar.org> wrote:
There is no c= onflict here.

The "SHOULD" that you quoted in rfc7934 refers to how an opinion = about
people ought to run their networks, but does not conflict with the
SHOULD in 6434bis, which refers to what the IETF is proposing ought to
be supported on host devices.=C2=A0 These two things are very different ind= eed.

It's not an opinion, it's = an IETF best practice. And I really don't see how you can say there'= ;s no contradiction. For the moment, let's consider mobile hosts that f= ollow the anonymity profile.

This document says th= at hosts SHOULD support DHCPv6 because operators might use it. But our curr= ent recommendations say that:
  1. Such hosts SHOULD prefer SL= AAC over DHCPv6
  2. DHCPv6-only networks are NOT RECOMMENDED
    3. Due to #1, such hosts will always prefer SLAAC over DHCPv6 on netwo= rks that have both. So a "SHOULD support DHCPv6" requirement will= only matter on networks that don't do SLAAC, which are NOT RECOMMENDED= .

    So we're basically saying that they SHOULD i= mplement IPv6 only for the purpose of connecting to networks that are NOT R= ECOMMENDED. How can we recommend something that is only used for something = that is NOT RECOMMENDED?
--001a114d3b12d7266305546f87f1-- From nobody Sun Jul 16 07:43:10 2017 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 05643127342 for ; Sun, 16 Jul 2017 07:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixM0R7XuL_SW for ; Sun, 16 Jul 2017 07:43:07 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 2B947126E3A for ; Sun, 16 Jul 2017 07:43:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 7106EC2C for ; Sun, 16 Jul 2017 14:43:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cUYeAQJ4zG7 for ; Sun, 16 Jul 2017 09:43:06 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 430CBBCC for ; Sun, 16 Jul 2017 09:43:06 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id c15so49125105vkf.12 for ; Sun, 16 Jul 2017 07:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9SWP0/oxSUUSOqLpJkjTqCVrMlZJ2F8J4B+7+NepVXE=; b=a8zrTmbxW+44pW7COMegQ/73EQmDE5++rTY0vhAyCp76Zc/54aD7bewrZjCW5H8oeL 0raWrMx0EvX6gY2t2zOBHTNIy42mMqJjV1iv7rz9Mx5QXJLfizBovpdL4oXwoA0yGyee RasXZ6p+4ZwgFzG0n2leW0ImD9d12Xgmpsm6/KD3RvODWUZ+54F+pM2+SJb19K5Vlr7y TkPevSgvVVM7QAcc91KqFXNUKQ5dSYU2Z/Q/bGvvr3ncA4F1G4np1Y6Jl72b+eoeU7gX 5QTETdKOGEakIvcQDXhJvuQq6mi/cIR7BxfweZDPqLlFb0ZZw9eX3t0XFtL4DkSK4LKk jF0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9SWP0/oxSUUSOqLpJkjTqCVrMlZJ2F8J4B+7+NepVXE=; b=qr7kaGVrNqQYq3jxt9JaIMzoCxH/nKgHgEp/CAhJGLoeCsaCfxZqiyb8BuSre/mCjU AQ7RqxWWwd31cNfGzlorVFqOn2aVUOYj4UGwrptRrX5vtrfrRcIO2O/jTnA1L4jsQhWZ qhBYJlZ48oRgjucobzPqkqLiqXht2zlo+5ErIsCL9FlS4HCJDnwJlg1ocSaMWItQ9EJq 2+f6tCiin6R0gqPBYPoJZS2d7a6dx4iBGIS/s/qYIHo0NXbeHN+FRUj1H3eyz5AwlYu9 MaARdMQlFX9BgPHc9d79Y/eKseVGURpAyy/2T/7qE7kiyTD4IujkiQc7QsKT2xQAkiCW M6bg== X-Gm-Message-State: AIVw113WacHe+rzpbo+/oeif+a0sTy1wK/Y9ZzdyOCovbolvq7v5lreg jCrgl1BTEGTSg/edlGmmWqsNhn5qXqk7jVNKArVcpS4tSoWQ1F68keDIwEEfvcRGYa7O5xIkkXQ znFHi4wekooSMUuc= X-Received: by 10.176.84.215 with SMTP id q23mr1116359uaa.27.1500216185470; Sun, 16 Jul 2017 07:43:05 -0700 (PDT) X-Received: by 10.176.84.215 with SMTP id q23mr1116349uaa.27.1500216185277; Sun, 16 Jul 2017 07:43:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sun, 16 Jul 2017 07:43:04 -0700 (PDT) In-Reply-To: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> From: David Farmer Date: Sun, 16 Jul 2017 09:43:04 -0500 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Lorenzo Colitti Cc: Nick Hilliard , draft-ietf-6man-rfc6434-bis@tools.ietf.org, IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="94eb2c1b1122cf67bc0554704c85" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:43:09 -0000 --94eb2c1b1122cf67bc0554704c85 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti wrote: > On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard wrote: > >> The self-selection addressing model does not suit the deployment >> requirements for many types of ipv6 networks, including enterprise, >> provider hosting, terrestrial access networks (e.g. docsis / gpon / >> ipoe) and others. If the recommendation for dhcpv6 is dropped, then >> there is no recommended ietf model for operator-assigned addressing, and >> this would leave a glaring hole in the ipv6 host specification. >> > > That's a fair opinion to hold, but the fact of the matter is that a SHOULD > for DHCPv6 conflicts with RFC 7934 and RFC 7844. > > We shouldn't publish a host requirements document that contradicts the > host address assignment BCP and that cites RFC7844 while contradicting that > document's recommendation to use stateless in preference to stateful. > Lets start with RFC 7934 it is a set of RECOMMENDATIONS for how networks should supply addresses to general purpose hosts. First, not everything fits into that scope and even within that scope as a RECOMMENDATION that means "there may exist valid reasons in particular circumstances to ignore a particular item" [RFC2119]. So, it by no means precludes the possibility that hosts could find them on a network that is only providing addresses via DHCPv6. Therefore, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me. As for RFC 7844, it is scoped to mobile hosts that want privacy from the DHCP server, and it says "The anonymity profiles have the effect of hiding the client identity from the DHCP server. This is not always desirable. ..." A document that itself recognizes it's primary purpose "is not always desirable" even within it's defined scope, isn't a strong argument for changing the RECOMMENDED behavior of all host. Further, a "recommendation to use stateless in preference to stateful" isn't a prohibition on stateful, Until, stateful is prohibited or all networks are required to provided stateless, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c1b1122cf67bc0554704c85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On S= un, Jul 16, 2017 at 1:20 PM, Nick Hilliard <nick@foobar.org> w= rote:
The self-selecti= on addressing model does not suit the deployment
requirements for many types of ipv6 networks, including enterprise,
provider hosting, terrestrial access networks (e.g. docsis / gpon /
ipoe) and others.=C2=A0 If the recommendation for dhcpv6 is dropped, then there is no recommended ietf model for operator-assigned addressing, and this would leave a glaring hole in the ipv6 host specification.

That's a fair opinion to hold, but the fact of= the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 784= 4.

We shouldn't publish a host requirements do= cument that contradicts the host address assignment BCP and that cites RFC7= 844 while contradicting that document's recommendation to use stateless= in preference to stateful.

Lets start with RFC 7934 it is a set= of RECOMMENDATIONS for how networks should supply addresses to general pur= pose hosts.=C2=A0 First, not everything fits into that scope and even withi= n that scope as a RECOMMENDATION that means "there may exist valid rea= sons in particular circumstances to ignore a particular item" [RFC2119= ].=C2=A0 So, it by no means precludes the possibility that hosts could find= them on a network that is only providing addresses via DHCPv6. Therefore, = a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.=

As for RFC 7844, it is scoped to mobile hosts tha= t want privacy from the DHCP server, and it says "The anonymity profil= es have the effect of hiding the client identity from the DHCP server.=C2= =A0 This is not always desirable. ..." =C2=A0A document that itself re= cognizes it's primary purpose "is not always desirable" even = within it's defined scope, isn't a strong argument for changing the= RECOMMENDED=C2=A0behavior of all host. =C2=A0

Fur= ther, a "recommendation to use stateless in preference to stateful&quo= t; isn't a prohibition on stateful, Until, stateful is prohibited or al= l networks are required to provided stateless, a SHOULD for DHCPv6 in the h= ost requirements still seems appropriate to me.

Th= anks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecom= munication Services
Office of Information Technology
University of Mi= nnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-81= 2-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
--94eb2c1b1122cf67bc0554704c85-- From nobody Sun Jul 16 07:50:35 2017 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 70E94126E3A for ; Sun, 16 Jul 2017 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 iE9Lxj4IT_M7 for ; Sun, 16 Jul 2017 07:50:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909841200C1 for ; Sun, 16 Jul 2017 07:50:32 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6GEoRD1074302 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2017 15:50:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596B7D32.2010206@foobar.org> Date: Sun, 16 Jul 2017 15:50:26 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Lorenzo Colitti CC: IETF IPv6 Mailing List , draft-ietf-6man-rfc6434-bis@tools.ietf.org Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:50:34 -0000 Lorenzo Colitti wrote: > For the moment, let's consider mobile hosts that follow the > anonymity profile. Here's a better idea: let's consider cable modems running on a DOCSIS3 network. > So we're basically saying that they SHOULD implement IPv6 only for > the purpose of connecting to networks that are NOT RECOMMENDED. How > can we recommend something that is only used for something that is > NOT RECOMMENDED? because there is no obligation to use dhcpv6, just a recommendation that it should be supported by the host. You're confusing the two issues and they are quite separate. Nick From nobody Sun Jul 16 07:54:40 2017 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 83B8A1200C1 for ; Sun, 16 Jul 2017 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DqeELRD7lNs for ; Sun, 16 Jul 2017 07:54:37 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1821D124D68 for ; Sun, 16 Jul 2017 07:54:36 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 5BA759EB for ; Sun, 16 Jul 2017 14:54:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVuJsQlAAi33 for ; Sun, 16 Jul 2017 09:54:36 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 239019EA for ; Sun, 16 Jul 2017 09:54:36 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id y70so48795394vky.13 for ; Sun, 16 Jul 2017 07:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vMDfTobBjnvTRpdJovb4jYyE6QkwNCuQ3lnHIUlyLH4=; b=FgBEUhPBo67dWyjgBScdoTE+P/IPo3YAnjBSOeOQJl7HWUqhkoaNTr2WjQwISyXOLY 9/hkR65qCsseycFHLhh9oISfi6EVzQR1i++CFH/DZLZkH78hdib0pOrL3mldSnDSlR/h QXM0Iwvqd6F1brlaJgRuo+RuNfx47MoAWZnikebgE0IMrUazFqlcTc8aUESZ3hb1QMJi nJNrydgYOmNtl0sDzBuPX08bHLmZQWFTHwTKNs/qcY2WWzp6rCQFxteWPM6XHReU8XxM JKSD5oMIEMf/LuiIttdlCIS0b4kdZZvsybrvoieob8embLLoba/mzmGyqbG7SkNwGc/y 8Jjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vMDfTobBjnvTRpdJovb4jYyE6QkwNCuQ3lnHIUlyLH4=; b=rr3KVEm5d8lxYtEWMcaoaoWBZ0r1tqJL/Yt86+1HrBGCj/cD3vr6o7XQkA/Y3uYkOV eXe8OgZoFP/B8rl1mvsvg6rDanHGNOrUXKDkS6Y4sCxFwhBLlVNxJi5Z+WGr96kOXNil j7YImSsuQQr6wGk+szPpbE9ylMEn4FaKUYBScTnw4ptnmzCys/KG8SzVvyUKSn8qrLzf Q1XrU8TmRpCGj1KO/dwhU3NivGa1+f8aTCxh4QP37ejz6aQFUDtw5rXGxgUseCjAhWWE eRN2MfT+PKBwGO/JAdtq81WHS3Hgpl09tzxdDmxjilktk9dpI3G6a8o7mFoUIuBQmr47 44og== X-Gm-Message-State: AIVw110643Hor8svjCoX/bx2wa2ucI+vgIYDxe/7LM8Hcfp7w3mm6XwQ arhRcycrqdiMJjG8iosV6NAyqcmv+1z5Vjk57e9wU6mmTRK9KcHeawvKjvtZnXS2lTzQTuZesaT lJfI+Ttsm2aZktEA= X-Received: by 10.176.93.224 with SMTP id l32mr10742320uag.154.1500216875183; Sun, 16 Jul 2017 07:54:35 -0700 (PDT) X-Received: by 10.176.93.224 with SMTP id l32mr10742316uag.154.1500216874993; Sun, 16 Jul 2017 07:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Sun, 16 Jul 2017 07:54:34 -0700 (PDT) In-Reply-To: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> From: David Farmer Date: Sun, 16 Jul 2017 09:54:34 -0500 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Lorenzo Colitti Cc: Nick Hilliard , draft-ietf-6man-rfc6434-bis@tools.ietf.org, IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary="f403043ee0c4eba1c105547075a2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:54:38 -0000 --f403043ee0c4eba1c105547075a2 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 16, 2017 at 9:43 AM, David Farmer wrote: > > > On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti > wrote: > >> On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard wrote: >> >>> The self-selection addressing model does not suit the deployment >>> requirements for many types of ipv6 networks, including enterprise, >>> provider hosting, terrestrial access networks (e.g. docsis / gpon / >>> ipoe) and others. If the recommendation for dhcpv6 is dropped, then >>> there is no recommended ietf model for operator-assigned addressing, and >>> this would leave a glaring hole in the ipv6 host specification. >>> >> >> That's a fair opinion to hold, but the fact of the matter is that a >> SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844. >> >> We shouldn't publish a host requirements document that contradicts the >> host address assignment BCP and that cites RFC7844 while contradicting that >> document's recommendation to use stateless in preference to stateful. >> > > Lets start with RFC 7934 it is a set of RECOMMENDATIONS for how networks > should supply addresses to general purpose hosts. First, not everything > fits into that scope and even within that scope as a RECOMMENDATION that > means "there may exist valid reasons in particular circumstances to ignore > a particular item" [RFC2119]. So, it by no means precludes the possibility > that hosts could find them on a network that is only providing addresses > via DHCPv6. Therefore, a SHOULD for DHCPv6 in the host requirements still > seems appropriate to me. > > As for RFC 7844, it is scoped to mobile hosts that want privacy from the > DHCP server, and it says "The anonymity profiles have the effect of hiding > the client identity from the DHCP server. This is not always desirable. > ..." A document that itself recognizes it's primary purpose "is not always > desirable" even within it's defined scope, isn't a strong argument for > changing the RECOMMENDED behavior of all host. > > Further, a "recommendation to use stateless in preference to stateful" > isn't a prohibition on stateful, Until, stateful is prohibited or all > networks are required to provided stateless, a SHOULD for DHCPv6 in the > host requirements still seems appropriate to me. > I should have added; while I don't think you are providing a valid argument against a SHOULD for DHCPv6 in the host requirements, it is a completely valid argument against a MUST for DHCPv6 in the host requirements. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403043ee0c4eba1c105547075a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 16, 2017 at 9:43 AM, David Farmer <farmer@umn.edu> wrote:


On Sun,= Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
On Sun, Jul 16,= 2017 at 1:20 PM, Nick Hilliard <nick@foobar.org> wrote:
The self-selection addressi= ng model does not suit the deployment
requirements for many types of ipv6 networks, including enterprise,
provider hosting, terrestrial access networks (e.g. docsis / gpon /
ipoe) and others.=C2=A0 If the recommendation for dhcpv6 is dropped, then there is no recommended ietf model for operator-assigned addressing, and this would leave a glaring hole in the ipv6 host specification.

That's a fair opinion to hold, but the fact of= the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 784= 4.

We shouldn't publish a host requirements do= cument that contradicts the host address assignment BCP and that cites RFC7= 844 while contradicting that document's recommendation to use stateless= in preference to stateful.

Lets start with RFC 7934 it is a set= of RECOMMENDATIONS for how networks should supply addresses to general pur= pose hosts.=C2=A0 First, not everything fits into that scope and even withi= n that scope as a RECOMMENDATION that means "there may exist valid rea= sons in particular circumstances to ignore a particular item" [RFC2119= ].=C2=A0 So, it by no means precludes the possibility that hosts could find= them on a network that is only providing addresses via DHCPv6. Therefore, = a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.=

As for RFC 7844, it is scoped to mobile hosts tha= t want privacy from the DHCP server, and it says "The anonymity profil= es have the effect of hiding the client identity from the DHCP server.=C2= =A0 This is not always desirable. ..." =C2=A0A document that itself re= cognizes it's primary purpose "is not always desirable" even = within it's defined scope, isn't a strong argument for changing the= RECOMMENDED=C2=A0behavior of all host. =C2=A0

Fur= ther, a "recommendation to use stateless in preference to stateful&quo= t; isn't a prohibition on stateful, Until, stateful is prohibited or al= l networks are required to provided stateless, a SHOULD for DHCPv6 in the h= ost requirements still seems appropriate to me.

I should have added; while I don't think you are= providing a valid argument against a SHOULD for DHCPv6 in the host require= ments, it is a completely valid argument against a MUST for DHCPv6 in the h= ost requirements. =C2=A0

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommun= ication Services
Office of Information Technology
University of Minne= sota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-995= 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043ee0c4eba1c105547075a2-- From nobody Sun Jul 16 08:19:41 2017 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 C997312711E for ; Sun, 16 Jul 2017 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 RIytgZ6PpHMw for ; Sun, 16 Jul 2017 08:19:38 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4D5124D68 for ; Sun, 16 Jul 2017 08:19:38 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6GFJS88077732 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2017 16:19:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596B83FF.1080304@foobar.org> Date: Sun, 16 Jul 2017 16:19:27 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Ole Troan CC: "Pascal Thubert (pthubert)" , "ipv6@ietf.org" Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) References: <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec 19-959e-a63f-ad0d316bbacf@gmail.com> <596A8A5 2.9030108@foobar.org> <596A95B7.6000408@foobar.org> <5C6E9C3 0-0217-4EEC-8A8D-F204002BE095@cisco.com> <61C67E77-3A8A-4177-B492-988017E7BC80@employees.org> In-Reply-To: <61C67E77-3A8A-4177-B492-988017E7BC80@employees.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 15:19:40 -0000 Ole Troan wrote: > Agree with all you're saying. so the assumptions of reasonable network-layer reliability have not been implemented in 802.11 for multicast, the combination of which is now causing protocols which depend on that reliability to break. What a mess. draft-mcbride-mboned-wifi-mcast-problem-statement was written up some while back and describes some of these problems. It would be useful to see some progress on this. > The pragmatic solutions from our perspective is to treat the media as a > set of point to point links with /64 to each host. Then all these > problems of multicast, DAD etc magically disappear. or virtual network segmentation using multicast->unicast replication at the AP using some form of multicast proxy. Neither these solutions would work for point-to-point wifi. All this is outside the context of rfc4291bis though. Nick From nobody Sun Jul 16 08:37:12 2017 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 E15BF127010 for ; Sun, 16 Jul 2017 08:37:10 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 B6ehBzP3K4Fp for ; Sun, 16 Jul 2017 08:37:08 -0700 (PDT) Received: from EMG3.irs.gov (emg3.irs.gov [IPv6:2610:30:4000:25::91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EE2126CC7 for ; Sun, 16 Jul 2017 08:37:08 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.40,370,1496116800"; d="scan'208,217"; a="85893773" Received: from unknown (HELO mem0200vprelay3.is.irs.gov) ([10.207.43.147]) by mtb0120emg3.mcc.irs.gov with ESMTP; 16 Jul 2017 11:37:04 -0400 Received: from MTB0120PPEXB020.ds.irsnet.gov (mtb0120ppexb020.ds.irsnet.gov [10.207.136.38]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id v6GFb0Uu031710 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 10:37:00 -0500 Received: from MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) by MTB0120PPEXB020.ds.irsnet.gov (10.207.136.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Sun, 16 Jul 2017 11:36:59 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969]) by MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969%19]) with mapi id 15.01.0845.034; Sun, 16 Jul 2017 11:37:00 -0400 From: Morizot Timothy S To: Lorenzo Colitti , Nick Hilliard CC: "draft-ietf-6man-rfc6434-bis@tools.ietf.org" , IETF IPv6 Mailing List Subject: RE: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Index: AQHS/hZUERf+nZtCPEClFdRvoEWdG6JWkc+AgAABcACAAA2nAIAAGiiA///PKtA= Date: Sun, 16 Jul 2017 15:36:59 +0000 Message-ID: <2068324e08614e4abae0a7417c9225eb@irs.gov> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.207.132.68] Content-Type: multipart/alternative; boundary="_000_2068324e08614e4abae0a7417c9225ebirsgov_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 15:37:11 -0000 --_000_2068324e08614e4abae0a7417c9225ebirsgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIGNvbW1lbnRlZCBvbiB0aGlzIHRvcGljIGluIHRoZSBwYXN0LCBidXQgd2lsbCBzaW1w bHkgbWFrZSBvbmUgbW9yZSBvYnNlcnZhdGlvbiBvbiB0aGlzIHNwZWNpZmljIHBvaW50LiBUaGUg UkZDIGlzIGluZm9ybWF0aW9uYWwsIHNvIGlzbuKAmXQgYSBtYXR0ZXIgb2YgaHVnZSBjb25jZXJu IGFzIGl0IGhhcyBubyBpbXBhY3Qgb24gcHJvZHVjdCBzZWxlY3Rpb24gb3IgdGhlIHByb2N1cmVt ZW50IHByb2Nlc3MuIElmIHRoZSBtYW51ZmFjdHVyZXIvZGV2ZWxvcGVyIG9mIGEgaG9zdCBkZWNp ZGVzIHRoZXkgZG9u4oCZdCB3YW50IHRvIG1ha2UgYSBwcm9kdWN0IHRoZXkgY2FuIHNlbGwgdG8g ZW50ZXJwcmlzZXMgdXRpbGl6aW5nIERIQ1B2NiBvbmx5IGhvc3QgbmV0d29ya3MgKGV4Y2VwdCBw ZXJoYXBzIGluIHNvbWUgdmVyeSBsaW1pdGVkLCByZXN0cmljdGVkIGNhcGFjaXR5KSwgdGhhdOKA mXMgZmluZS4gUGxlbnR5IG9mIG90aGVyIGNvbXBhbmllcyB3aWxsLiBIb3dldmVyLCBJIGRvIGFn cmVlIHRoZSByZWNvbW1lbmRhdGlvbiBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZsZWN0IHJlYWxp dHksIG90aGVyd2lzZSBJIHN1cHBvc2UgaXQgY291bGQgbGVhZCBkZXZlbG9wZXJzIG9mIHN1Y2gg aG9zdCBwcm9kdWN0cyB0aGF0IERIQ1B2NiBzdXBwb3J0IGlzIGFjdHVhbGx5IG9wdGlvbmFsLiBJ biBzb21lIGVudmlyb25tZW50cyBpdCBpcy4gSW4gb3RoZXJzIGl0IGlzIG5vdC4gQnV0IHRoZW4s IEkgYWxzbyBiZWxpZXZlIHRoZSBkZXZlbG9wZXJzIG9mIHN1Y2ggaG9zdHMgdW5kZXJzdGFuZCB0 aGVpciBtYXJrZXRzIGFuZCBhcmUgdW5saWtlbHkgdG8gYmUgbWlzbGVkIGJ5IGFuIGluZm9ybWF0 aW9uYWwgUkZDLg0KDQpJdCBkb2VzLCBob3dldmVyLCBzdHJpa2UgbWUgYXMgc29tZXdoYXQgc2ls bHkgZm9yIHRoZSBJRVRGIHRvIGNvbnRpbnVlIHRvIOKAnE5PVCBSRUNPTU1FTkTigJ0gKGFzIEkg Z2F0aGVyIGZyb20gdGhlIGFwcGVuZGl4IG9mIGNoYW5nZXMgd2FzIHRoZSBjYXNlIHdheSBiYWNr IGluIDQyOTQpIGEgdXNlIGNhc2UgdGhhdCBjb21wbGllcyB3aXRoIHRoZSBzdGFuZGFyZHMsIGhh cyBiZWVuIGRlcGxveWVkLCBpcyBiZWluZyBkZXBsb3llZCwgYW5kIHdpbGwgY29udGludWUgdG8g YmUgdXNlZCBpbiB0aGUgZnV0dXJlLiBJdOKAmXMgbm90IGV2ZW4gYSBtYXR0ZXIgb2Ygd2hldGhl ciBvciBub3QgY29ubmVjdGlvbiBzZWN1cml0eSBpcyBkZXBsb3llZCBvciBuZWlnaGJvciB0YWJs ZXMgKG9yIGFycCBmb3IgdjQpIGFuZCBvdGhlciBkYXRhIGFyZSBjb2xsZWN0ZWQgZnJvbSBuZXR3 b3JrIGRldmljZXMuIChBdCB0aGUgc29ydHMgb2Ygb3JnYW5pemF0aW9ucyBhbmQgbmV0d29ya3Mg d2l0aCB3aGljaCBJ4oCZbSBmYW1pbGlhciwgYm90aCBhcmUgb2Z0ZW4gdHJ1ZS4gVGhlcmUgYXJl IGV2ZW4gbmV0d29ya3Mgd2hlcmUgbm90aGluZyBidXQgbWFudWFsbHkgY29uZmlndXJlZCBkZXZp Y2VzIGFyZSBhbGxvd2VkIGFuZCBzd2l0Y2ggcG9ydHMgbXVzdCBiZSBtYW51YWxseSBlbmFibGVk LikgUmF0aGVyLCB0aGUgc2VjdXJpdHkgbW9uaXRvcmluZyBhbmQgYW5hbHlzaXMgcHJvY2Vzc2Vz IChhdXRvbWF0ZWQgYW5kIG1hbnVhbCkgYXJlIGluIHBhcnQgYnVpbHQgYXJvdW5kIGRoY3AgZm9y IGJhc2ljIGNsaWVudCBuZXR3b3Jrcy4gSXTigJlzIGEgcmVsYXRpdmVseSBzbWFsbCBsaWZ0IHRv IGV4dGVuZCB0aG9zZSBwcm9jZXNzZXMgdG8gREhDUHY2LiBJdCB3b3VsZCBiZSBhIG11Y2ggbGFy Z2VyIGxpZnQgdG8gZGV2ZWxvcCBlbnRpcmVseSBuZXcsIHBhcmFsbGVsIG9uZXMgdXNpbmcgZGlm ZmVyZW50IGRhdGEsIGV2ZW4gdGhvdWdoIHRoYXQgYWx0ZXJuYXRpdmUgZGF0YSBhcmUgbGlrZWx5 IGFsc28gY29sbGVjdGVkIGFuZCBhdmFpbGFibGUuIEl04oCZcyBwYXJ0aWN1bGFybHkgdW53aWVs ZHkgd2hpbGUgSVB2NCwgd2l0aCBpdHMgZXhpc3RpbmcgcHJvY2Vzc2VzLCBpcyBpbiB1c2Ugb24g c29tZSBvciBhbGwgb2YgdGhvc2UgbmV0d29ya3MuDQoNClBlcmhhcHMgaW4gdGhlIGZ1dHVyZSwg aWYgdGhlcmXigJlzIGV2ZXIgYSBjb21wZWxsaW5nIHVzZSBjYXNlIGZvciB3aWRlc3ByZWFkIGRl cGxveW1lbnQgb2YgU0xBQUMgb24gZ2VuZXJhbCBwdXJwb3NlIGhvc3QgZGF0YSBuZXR3b3JrcyBh bmQgSVB2NCBoYXMgbW9zdGx5IGJlZW4gcmV0aXJlZCBmcm9tIHRoZSBuZXR3b3JrIG91dHNpZGUg ZW5jbGF2ZXMgd2hlcmUgaXTigJlzIHN0aWxsIHJlcXVpcmVkIGZvciBvbmUgcmVhc29uIG9yIGFu b3RoZXIsIHRob3NlIHByb2Nlc3NlcyBjYW4gYW5kIHByb2JhYmx5IHdpbGwgYmUgcmV2aXNpdGVk LCBlc3BlY2lhbGx5IGFzIGRlcGxveWVkIHRvb2xzIGFyZSB1cGRhdGVkIG9yIHJlcGxhY2VkLiBV bnRpbCBzdWNoIHRpbWUsIEkga25vdyBmb3IgY2VydGFpbiB0aGF0IGF0IGxlYXN0IG9uIGNlcnRh aW4gc29ydHMgb2YgbGFyZ2UgZW50ZXJwcmlzZSBuZXR3b3JrcyBESENQdjYtb25seSBoYXMgYmVl biwgaXMsIGFuZCB3aWxsIGNvbnRpbnVlIHRvIGJlIGRlcGxveWVkIGFuZCB1c2VkLCBhdCBsZWFz dCBvbiBtb3N0IGdlbmVyYWwgcHVycG9zZSBob3N0IGRhdGEgbmV0d29ya3MgaW4gdGhlIGVudGVy cHJpc2UuIFRob3NlIGNvbXBhbmllcyB0aGF0IHdpc2ggdG8gZGV2ZWxvcCBnZW5lcmFsIHB1cnBv c2UgaG9zdCBkZXZpY2VzIHRoZXkgY2FuIHNlbGwgZm9yIHVzZSBvbiBzdWNoIG5ldHdvcmtzIHdp bGwgc3VwcG9ydCB0aGF0IHVzZSBjYXNlIHdoYXRldmVyIGluZm9ybWF0aW9uYWwgcmVjb21tZW5k YXRpb25zIHRoZSBJRVRGIGNob29zZXMgdG8gcHVibGlzaC4gU3BlY2lhbHR5IG5ldHdvcmtzIGZv ciBJT1QgZGV2aWNlcyAoc2Vuc29ycywgY2FtZXJhcywgbGlnaHRpbmcsIG9yIHdoYXRldmVyKSBh cmUgYSBkaWZmZXJlbnQgbWF0dGVyLiBUaG9zZSBzb3J0cyBvZiB0aGluZ3MgYXJlIGFscmVhZHkg c2VncmVnYXRlZCBpbnRvIHRoZWlyIG93biBuZXR3b3JrcyB3aGVuIHVzaW5nIElQdjQuIElmIHRo ZXkgaGF2ZSBzcGVjaWFsIG5ldHdvcmsgcmVxdWlyZW1lbnRzIGFuZCBvdGhlcndpc2UgbWVldCBv dXIgY2FwYWJpbGl0eSByZXF1aXJlbWVudHMsIHRob3NlIGFsd2F5cyBoYXZlIGJlZW4gYW5kIHdp bGwgY29udGludWUgdG8gYmUgYWNjb21tb2RhdGVkLg0KDQpUaGUgZW50ZXJwcmlzZSBzcGFjZSB2 YXJpZXMgYSBsb3QgYWNjb3JkaW5nIHRvIHRoZSBzb3J0IG9mIGVudGVycHJpc2UsIGJ1dCBpdOKA mXMgbmV2ZXIgZ29pbmcgdG8gcmVhbGx5IGxvb2sgbGlrZSBhIGdlbmVyYWwgaG9zdGluZyBjb21w YW55IG9yIGdlbmVyaWMgdXNlciBJU1AuIEVudGVycHJpc2VzIGNhbiBhbmQgZG8gcmVzdHJpY3Qg d2hhdCBjb25uZWN0cyBhbmQgZnVuY3Rpb25zIG9uIHRoZWlyIG5ldHdvcmtzLiBFbnRlcnByaXNl IG5ldHdvcmtzIGRvIG5vdCBoYXZlIHRvIHN1cHBvcnQgZXZlcnkga2luZCBvZiBkZXZpY2Ugb3Ig ZXZlcnkgY29uZmlndXJhdGlvbiBvcHRpb24uIEFuZCBtb3N0IGxhcmdlIG9uZXMgcHJvYmFibHkg d29u4oCZdC4gQnV0IG1hbnkgY29tcGFuaWVzIGRldmVsb3BpbmcgaG9zdCBkZXZpY2VzIHdvdWxk IHN0aWxsIGxpa2UgdG8gc2VsbCB0aGVtIHRvIGxhcmdlIGVudGVycHJpc2VzLiBBbmQgaWYgdGhl eSB3YW50IHRvIGRvIHNvLCB0aGV5IHNob3VsZCBjZXJ0YWlubHkgY29uc2lkZXIgc3VwcG9ydGlu ZyBESENQdjYuIEl0IHNlZW1zIHRvIG1lIHRoZSBJRVRGIHJlY29tbWVuZGF0aW9uIHNob3VsZCBy ZWZsZWN0IHRoYXQgcmVhbGl0eS4NCg0KU2NvdHQNCg0KTG9yZW56byBDb2xpdHRpIGxvcmVuem9A Z29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPiB3cm90ZToNClRoZSAiU0hPVUxE IiB0aGF0IHlvdSBxdW90ZWQgaW4gcmZjNzkzNCByZWZlcnMgdG8gaG93IGFuIG9waW5pb24gYWJv dXQNCnBlb3BsZSBvdWdodCB0byBydW4gdGhlaXIgbmV0d29ya3MsIGJ1dCBkb2VzIG5vdCBjb25m bGljdCB3aXRoIHRoZQ0KU0hPVUxEIGluIDY0MzRiaXMsIHdoaWNoIHJlZmVycyB0byB3aGF0IHRo ZSBJRVRGIGlzIHByb3Bvc2luZyBvdWdodCB0bw0KYmUgc3VwcG9ydGVkIG9uIGhvc3QgZGV2aWNl cy4gIFRoZXNlIHR3byB0aGluZ3MgYXJlIHZlcnkgZGlmZmVyZW50IGluZGVlZC4NCg0KVGhpcyBk b2N1bWVudCBzYXlzIHRoYXQgaG9zdHMgU0hPVUxEIHN1cHBvcnQgREhDUHY2IGJlY2F1c2Ugb3Bl cmF0b3JzIG1pZ2h0IHVzZSBpdC4gQnV0IG91ciBjdXJyZW50IHJlY29tbWVuZGF0aW9ucyBzYXkg dGhhdDoNCg0KICAxLiAgU3VjaCBob3N0cyBTSE9VTEQgcHJlZmVyIFNMQUFDIG92ZXIgREhDUHY2 DQogIDIuICBESENQdjYtb25seSBuZXR3b3JrcyBhcmUgTk9UIFJFQ09NTUVOREVEDQo= --_000_2068324e08614e4abae0a7417c9225ebirsgov_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc3NjQ4MTM2NDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MjQ4Nzg0MjgyO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SeKAmXZlIGNvbW1lbnRlZCBvbiB0aGlzIHRvcGljIGluIHRoZSBwYXN0LCBidXQg d2lsbCBzaW1wbHkgbWFrZSBvbmUgbW9yZSBvYnNlcnZhdGlvbiBvbiB0aGlzIHNwZWNpZmljIHBv aW50LiBUaGUgUkZDIGlzIGluZm9ybWF0aW9uYWwsIHNvIGlzbuKAmXQgYSBtYXR0ZXIgb2YgaHVn ZQ0KIGNvbmNlcm4gYXMgaXQgaGFzIG5vIGltcGFjdCBvbiBwcm9kdWN0IHNlbGVjdGlvbiBvciB0 aGUgcHJvY3VyZW1lbnQgcHJvY2Vzcy4gSWYgdGhlIG1hbnVmYWN0dXJlci9kZXZlbG9wZXIgb2Yg YSBob3N0IGRlY2lkZXMgdGhleSBkb27igJl0IHdhbnQgdG8gbWFrZSBhIHByb2R1Y3QgdGhleSBj YW4gc2VsbCB0byBlbnRlcnByaXNlcyB1dGlsaXppbmcgREhDUHY2IG9ubHkgaG9zdCBuZXR3b3Jr cyAoZXhjZXB0IHBlcmhhcHMgaW4gc29tZSB2ZXJ5IGxpbWl0ZWQsDQogcmVzdHJpY3RlZCBjYXBh Y2l0eSksIHRoYXTigJlzIGZpbmUuIFBsZW50eSBvZiBvdGhlciBjb21wYW5pZXMgd2lsbC4gSG93 ZXZlciwgSSBkbyBhZ3JlZSB0aGUgcmVjb21tZW5kYXRpb24gc2hvdWxkIGJlIHVwZGF0ZWQgdG8g cmVmbGVjdCByZWFsaXR5LCBvdGhlcndpc2UgSSBzdXBwb3NlIGl0IGNvdWxkIGxlYWQgZGV2ZWxv cGVycyBvZiBzdWNoIGhvc3QgcHJvZHVjdHMgdGhhdCBESENQdjYgc3VwcG9ydCBpcyBhY3R1YWxs eSBvcHRpb25hbC4gSW4NCiBzb21lIGVudmlyb25tZW50cyBpdCBpcy4gSW4gb3RoZXJzIGl0IGlz IG5vdC4gQnV0IHRoZW4sIEkgYWxzbyBiZWxpZXZlIHRoZSBkZXZlbG9wZXJzIG9mIHN1Y2ggaG9z dHMgdW5kZXJzdGFuZCB0aGVpciBtYXJrZXRzIGFuZCBhcmUgdW5saWtlbHkgdG8gYmUgbWlzbGVk IGJ5IGFuIGluZm9ybWF0aW9uYWwgUkZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgZG9lcywgaG93ZXZlciwgc3Ry aWtlIG1lIGFzIHNvbWV3aGF0IHNpbGx5IGZvciB0aGUgSUVURiB0byBjb250aW51ZSB0byDigJxO T1QgUkVDT01NRU5E4oCdIChhcyBJIGdhdGhlciBmcm9tIHRoZSBhcHBlbmRpeCBvZiBjaGFuZ2Vz IHdhcyB0aGUgY2FzZSB3YXkgYmFjayBpbg0KIDQyOTQpIGEgdXNlIGNhc2UgdGhhdCBjb21wbGll cyB3aXRoIHRoZSBzdGFuZGFyZHMsIGhhcyBiZWVuIGRlcGxveWVkLCBpcyBiZWluZyBkZXBsb3ll ZCwgYW5kIHdpbGwgY29udGludWUgdG8gYmUgdXNlZCBpbiB0aGUgZnV0dXJlLiBJdOKAmXMgbm90 IGV2ZW4gYSBtYXR0ZXIgb2Ygd2hldGhlciBvciBub3QgY29ubmVjdGlvbiBzZWN1cml0eSBpcyBk ZXBsb3llZCBvciBuZWlnaGJvciB0YWJsZXMgKG9yIGFycCBmb3IgdjQpIGFuZCBvdGhlciBkYXRh DQogYXJlIGNvbGxlY3RlZCBmcm9tIG5ldHdvcmsgZGV2aWNlcy4gKEF0IHRoZSBzb3J0cyBvZiBv cmdhbml6YXRpb25zIGFuZCBuZXR3b3JrcyB3aXRoIHdoaWNoIEnigJltIGZhbWlsaWFyLCBib3Ro IGFyZSBvZnRlbiB0cnVlLiBUaGVyZSBhcmUgZXZlbiBuZXR3b3JrcyB3aGVyZSBub3RoaW5nIGJ1 dCBtYW51YWxseSBjb25maWd1cmVkIGRldmljZXMgYXJlIGFsbG93ZWQgYW5kIHN3aXRjaCBwb3J0 cyBtdXN0IGJlIG1hbnVhbGx5IGVuYWJsZWQuKSBSYXRoZXIsDQogdGhlIHNlY3VyaXR5IG1vbml0 b3JpbmcgYW5kIGFuYWx5c2lzIHByb2Nlc3NlcyAoYXV0b21hdGVkIGFuZCBtYW51YWwpIGFyZSBp biBwYXJ0IGJ1aWx0IGFyb3VuZCBkaGNwIGZvciBiYXNpYyBjbGllbnQgbmV0d29ya3MuIEl04oCZ cyBhIHJlbGF0aXZlbHkgc21hbGwgbGlmdCB0byBleHRlbmQgdGhvc2UgcHJvY2Vzc2VzIHRvIERI Q1B2Ni4gSXQgd291bGQgYmUgYSBtdWNoIGxhcmdlciBsaWZ0IHRvIGRldmVsb3AgZW50aXJlbHkg bmV3LCBwYXJhbGxlbA0KIG9uZXMgdXNpbmcgZGlmZmVyZW50IGRhdGEsIGV2ZW4gdGhvdWdoIHRo YXQgYWx0ZXJuYXRpdmUgZGF0YSBhcmUgbGlrZWx5IGFsc28gY29sbGVjdGVkIGFuZCBhdmFpbGFi bGUuIEl04oCZcyBwYXJ0aWN1bGFybHkgdW53aWVsZHkgd2hpbGUgSVB2NCwgd2l0aCBpdHMgZXhp c3RpbmcgcHJvY2Vzc2VzLCBpcyBpbiB1c2Ugb24gc29tZSBvciBhbGwgb2YgdGhvc2UgbmV0d29y a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5QZXJoYXBzIGluIHRoZSBmdXR1cmUsIGlmIHRoZXJl4oCZcyBldmVyIGEg Y29tcGVsbGluZyB1c2UgY2FzZSBmb3Igd2lkZXNwcmVhZCBkZXBsb3ltZW50IG9mIFNMQUFDIG9u IGdlbmVyYWwgcHVycG9zZSBob3N0IGRhdGEgbmV0d29ya3MgYW5kIElQdjQgaGFzIG1vc3RseSBi ZWVuDQogcmV0aXJlZCBmcm9tIHRoZSBuZXR3b3JrIG91dHNpZGUgZW5jbGF2ZXMgd2hlcmUgaXTi gJlzIHN0aWxsIHJlcXVpcmVkIGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIsIHRob3NlIHByb2Nl c3NlcyBjYW4gYW5kIHByb2JhYmx5IHdpbGwgYmUgcmV2aXNpdGVkLCBlc3BlY2lhbGx5IGFzIGRl cGxveWVkIHRvb2xzIGFyZSB1cGRhdGVkIG9yIHJlcGxhY2VkLiBVbnRpbCBzdWNoIHRpbWUsIEkg a25vdyBmb3IgY2VydGFpbiB0aGF0IGF0IGxlYXN0IG9uIGNlcnRhaW4NCiBzb3J0cyBvZiBsYXJn ZSBlbnRlcnByaXNlIG5ldHdvcmtzIERIQ1B2Ni1vbmx5IGhhcyBiZWVuLCBpcywgYW5kIHdpbGwg Y29udGludWUgdG8gYmUgZGVwbG95ZWQgYW5kIHVzZWQsIGF0IGxlYXN0IG9uIG1vc3QgZ2VuZXJh bCBwdXJwb3NlIGhvc3QgZGF0YSBuZXR3b3JrcyBpbiB0aGUgZW50ZXJwcmlzZS4gVGhvc2UgY29t cGFuaWVzIHRoYXQgd2lzaCB0byBkZXZlbG9wIGdlbmVyYWwgcHVycG9zZSBob3N0IGRldmljZXMg dGhleSBjYW4gc2VsbCBmb3INCiB1c2Ugb24gc3VjaCBuZXR3b3JrcyB3aWxsIHN1cHBvcnQgdGhh dCB1c2UgY2FzZSB3aGF0ZXZlciBpbmZvcm1hdGlvbmFsIHJlY29tbWVuZGF0aW9ucyB0aGUgSUVU RiBjaG9vc2VzIHRvIHB1Ymxpc2guIFNwZWNpYWx0eSBuZXR3b3JrcyBmb3IgSU9UIGRldmljZXMg KHNlbnNvcnMsIGNhbWVyYXMsIGxpZ2h0aW5nLCBvciB3aGF0ZXZlcikgYXJlIGEgZGlmZmVyZW50 IG1hdHRlci4gVGhvc2Ugc29ydHMgb2YgdGhpbmdzIGFyZSBhbHJlYWR5IHNlZ3JlZ2F0ZWQNCiBp bnRvIHRoZWlyIG93biBuZXR3b3JrcyB3aGVuIHVzaW5nIElQdjQuIElmIHRoZXkgaGF2ZSBzcGVj aWFsIG5ldHdvcmsgcmVxdWlyZW1lbnRzIGFuZCBvdGhlcndpc2UgbWVldCBvdXIgY2FwYWJpbGl0 eSByZXF1aXJlbWVudHMsIHRob3NlIGFsd2F5cyBoYXZlIGJlZW4gYW5kIHdpbGwgY29udGludWUg dG8gYmUgYWNjb21tb2RhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGVudGVycHJpc2Ugc3BhY2UgdmFyaWVz IGEgbG90IGFjY29yZGluZyB0byB0aGUgc29ydCBvZiBlbnRlcnByaXNlLCBidXQgaXTigJlzIG5l dmVyIGdvaW5nIHRvIHJlYWxseSBsb29rIGxpa2UgYSBnZW5lcmFsIGhvc3RpbmcgY29tcGFueSBv ciBnZW5lcmljIHVzZXIgSVNQLg0KIEVudGVycHJpc2VzIGNhbiBhbmQgZG8gcmVzdHJpY3Qgd2hh dCBjb25uZWN0cyBhbmQgZnVuY3Rpb25zIG9uIHRoZWlyIG5ldHdvcmtzLiBFbnRlcnByaXNlIG5l dHdvcmtzIGRvIG5vdCBoYXZlIHRvIHN1cHBvcnQgZXZlcnkga2luZCBvZiBkZXZpY2Ugb3IgZXZl cnkgY29uZmlndXJhdGlvbiBvcHRpb24uIEFuZCBtb3N0IGxhcmdlIG9uZXMgcHJvYmFibHkgd29u 4oCZdC4gQnV0IG1hbnkgY29tcGFuaWVzIGRldmVsb3BpbmcgaG9zdCBkZXZpY2VzIHdvdWxkDQog c3RpbGwgbGlrZSB0byBzZWxsIHRoZW0gdG8gbGFyZ2UgZW50ZXJwcmlzZXMuIEFuZCBpZiB0aGV5 IHdhbnQgdG8gZG8gc28sIHRoZXkgc2hvdWxkIGNlcnRhaW5seSBjb25zaWRlciBzdXBwb3J0aW5n IERIQ1B2Ni4gSXQgc2VlbXMgdG8gbWUgdGhlIElFVEYgcmVjb21tZW5kYXRpb24gc2hvdWxkIHJl ZmxlY3QgdGhhdCByZWFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2NvdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvcmVuem8gQ29s aXR0aQ0KPGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bG9yZW56b0Bnb29nbGUu Y29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlICZxdW90 O1NIT1VMRCZxdW90OyB0aGF0IHlvdSBxdW90ZWQgaW4gcmZjNzkzNCByZWZlcnMgdG8gaG93IGFu IG9waW5pb24gYWJvdXQ8YnI+DQpwZW9wbGUgb3VnaHQgdG8gcnVuIHRoZWlyIG5ldHdvcmtzLCBi dXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGU8YnI+DQpTSE9VTEQgaW4gNjQzNGJpcywgd2hp Y2ggcmVmZXJzIHRvIHdoYXQgdGhlIElFVEYgaXMgcHJvcG9zaW5nIG91Z2h0IHRvPGJyPg0KYmUg c3VwcG9ydGVkIG9uIGhvc3QgZGV2aWNlcy4mbmJzcDsgVGhlc2UgdHdvIHRoaW5ncyBhcmUgdmVy eSBkaWZmZXJlbnQgaW5kZWVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBkb2N1bWVudCBzYXlzIHRoYXQgaG9zdHMgU0hPVUxEIHN1cHBvcnQgREhD UHY2IGJlY2F1c2Ugb3BlcmF0b3JzIG1pZ2h0IHVzZSBpdC4gQnV0IG91ciBjdXJyZW50IHJlY29t bWVuZGF0aW9ucyBzYXkgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBz dGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NClN1Y2ggaG9zdHMgU0hPVUxEIHByZWZlciBTTEFBQyBvdmVyIERIQ1B2Njxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCkRIQ1B2Ni1vbmx5IG5ldHdvcmtzIGFyZSBOT1QgUkVDT01NRU5ERUQ8bzpwPjwvbzpw PjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2068324e08614e4abae0a7417c9225ebirsgov_-- From nobody Sun Jul 16 08:56:52 2017 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 A2EBD129461 for ; Sun, 16 Jul 2017 08:56:50 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 nK18n-PhMi7T for ; Sun, 16 Jul 2017 08:56:49 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAA4126CC7 for ; Sun, 16 Jul 2017 08:56:49 -0700 (PDT) Received: from h.hanazo.no (unknown [128.65.74.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 2923E2D4F96; Sun, 16 Jul 2017 15:56:47 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3194DEBB28C6; Sun, 16 Jul 2017 17:57:16 +0200 (CEST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_2FCE0D06-ED63-43CF-9907-38C968AF31B9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Minute taker and jabber scribe Message-Id: <654257B0-AE96-4A29-B201-728287662C44@employees.org> Date: Sun, 16 Jul 2017 17:57:15 +0200 Cc: bob.hinden@gmail.com To: 6man WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 15:56:51 -0000 --Apple-Mail=_2FCE0D06-ED63-43CF-9907-38C968AF31B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, We are meeting first session Monday morning. Please volunteer as a minute taker: = http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-6man?useMonospaceFont=3D= true Or jabber scribe. Please let the chairs know via email or raise your hand when asked. Best regards, Ole --Apple-Mail=_2FCE0D06-ED63-43CF-9907-38C968AF31B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZa4zbAAoJEL7aWKiYQt92EFgP/jBw3EanE2MFgNmDKDujqCPy uf5+IOG69R3VRJ6iRGBwlRYUqdopC3U868C2ARMEsnAVgj8Ci8pT8mIbJEkoUFpt d+VZh96j2YpqhrymQtZLn/vUXaqH3Z6h+TtFuK1cmfZ4rGn64glfloSDYU80FHcI INKDhh3ITk/L+PP/VgH1eeQb+BNq4EvCtX3iyqCq83qYkBYk4VlAEKLpoKq5fFSK kl69Ms/aMD/gyU9TDLQDT0aVYbn1s7SX3Xkboi32pxeV4u0zJ483FdnERNEW9LaJ 3mqcsaEubNRHHMDvLM2biV12h4FX3LvSHcMiLFDwZVb6NC7LstxEXL9Jmp3NtHc1 BFBqnMigWHm4TEpCC7VhK44AK53p2x4PZrgCC9XK7Plqk6QszHv+g08wQdAiMi60 G1AckibIKBOOEBqoSowSW0ZrgJGd0mjWfZ+yxSCa6VObfrxMpAB2DlFxF0Fz7/9x R5haBtbDWqHIPyrEA0MQjpbYdDbMY+yZnb81d3RDea32aBr8zE49enlJFcd+bK/5 gzvRiHorxGKDEBRHSM3uuxZO28oOzuYsgG6F4JfzZ5mbN5I9D1CuL3uMAssQ2rZ9 LoAmV6gQoymZ9irn0apucbPJ+Z5X0jxhZi/8nN5nGkh/b0lsSBC4tcsSPM0jzs5o MJJ12yjVSeRKfziRVUKo =sVUj -----END PGP SIGNATURE----- --Apple-Mail=_2FCE0D06-ED63-43CF-9907-38C968AF31B9-- From nobody Sun Jul 16 13:58:27 2017 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 35C1712778E for ; Sun, 16 Jul 2017 13:58:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3I_pEDG3JoT7 for ; Sun, 16 Jul 2017 13:58:24 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB091243F3 for ; Sun, 16 Jul 2017 13:58:24 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id k14so69416614pgr.0 for ; Sun, 16 Jul 2017 13:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3Yarmy8fE4sXK9NObu4ZRj5TibKSzJRInDpkm5GTVdU=; b=YNks0nCRUsq0RvLAGXHL93XRocgDMa6Vx1bnnd53m8lTEyfVv2ssKY+VzkbNrdwrpJ m6heWT98njv6XzUwS5H0ebVfO1LPTAvUU0cCpFthnkaTKphlWg+UikwQr8hB0OPPJsYf hmrypm90/6HbikV4fFLIa/kfORJlpPJqMlL5S8ziTPh5CgVxhSLMLA5SIdOWpkUsoeV6 TENTjO3W4WQnZt4qo4h+eejrrW+K5AHhOVSytl3yrGK67RB2GscyBvyC2EhaRf6dM3VA KxfpN8B6QXAXfZ2z32m+POWadVGohqsyzA+AbA3CAtqeT70gGy4j8UJXDA5mK9riDqRR aaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3Yarmy8fE4sXK9NObu4ZRj5TibKSzJRInDpkm5GTVdU=; b=beDKozlyKei19GBgk8ysOyonGJHIYato+vMb6H7YNYwpZjmkDBwF3mJscVdRaI8SO3 ZgNMZPP807aQiOepzNBJ+15mQ0N0zDdkHX50sh2G8r69plnACYAq/jJk/0+yCVBQY7/9 MJ6UHBgw5o0h4SKtpNfpbGD4kgZimKCNA05rsIOoQ2uoAzVVLBpwyAvfOFrV54EkfcqW QQwN2KV87vuOW+tFvdordl5wN9ry3dyRCRwB88ug0xlYMWdtKC5ZvWnE1jp20KaGR9E9 zmUmVDTUHo3dhJXgOlVjYX++XtiERgcCZnaT0vuooUDOwBXZSkQ0h7oDw47+Uy1lFJhi uuVw== X-Gm-Message-State: AIVw113jf/9E3BT7z2blB1/tqTspBTkkuduSX5pEbReV6KgohV423oLb 6N9xjFwN3o7GMi75 X-Received: by 10.84.229.77 with SMTP id d13mr27165862pln.239.1500238703654; Sun, 16 Jul 2017 13:58:23 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id v64sm36686318pfk.126.2017.07.16.13.58.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 13:58:22 -0700 (PDT) Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: ) To: Mark Smith , "Pascal Thubert (pthubert)" Cc: "ipv6@ietf.org" References: <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9f43ab06-c7c9-9b73-2a28-73d92014963f@gmail.com> Date: Mon, 17 Jul 2017 08:58:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 20:58:26 -0000 On 16/07/2017 19:58, Mark Smith wrote: > On 16 July 2017 at 16:41, Pascal Thubert (pthubert) wrote: >> Hello Brian: >> >> I'd say that DAD detecting a duplication is not a failure; just doing = its job right. >> >> The DAD failure that hurts is DAD false negative like can be easily ob= tained on wireless because the reliability of the multicast is largely d= ifferent from that of wire. >> >> Are we ready to say that addresses that are generated with enough rand= omness in them do not need DAD? I'm not, for 3 reasons: 1. An address collision is so fatal that we cannot leave it open as even a remote possibility. It could be literally fatal in a safety-critic= al application. 2. Even if we specify pseudo-random IDs, we know that some people will nevertheless define them manually, which leads to a real risk of collision due to human error. See 1. 3. A bad actor might create an intentional collision. See 1. So, DAD needs to work. >=20 > I looked up RFC4862 to find out how many DAD attempts there were, > because I'd assumed 3 to 4, and if so, then if that many attempts > failed, I'd say the link is well beyond its capacity. Something would > need to be done to remedy a link capacity problem in that case. >=20 > I was surprised to find, as Ole mentioned, the number of attempts was > only 1 rather than 3 or 4. I'm more than surprised. I think that's a bug and IMHO it should be fixed= =2E > One thing it does say about that value is: >=20 > Default: 1, but may be overridden by a link-type specific value in > the document that covers issues related to the transmission of IP= > over a particular link type (e.g., [RFC2464]). >=20 > Although Wifi is emulating Ethernet at the IPv6 interface layer, it > doesn't have the same multicast characteristics, so perhaps there > should be an IPv6 over Wifi RFC that specifies IPv6's parameters to > suit. Pascal is correct about the intrinsic issues with relying on layer 2 multicast, but we are stuck with it for a while, so a fix seems necessary. Brian >=20 >=20 >=20 >=20 >> Pascal >> >>> Le 15 juil. 2017 =C3=A0 23:01, Brian E Carpenter a =C3=A9crit : >>> >>> On 16/07/2017 01:39, Philip Homburg wrote: >>>>> This is backwards. The goals of pseudo-random IIDs are to reduce th= e >>>>> probability that scanning attacks find hosts, and to reduce the ris= k >>>>> of IIDs being used to breach privacy. >>>>> >>>>> If these goals are met, the collision probability will in any case >>>>> be low, so DAD failure will be exceedingly rare. >>>> >>>> I completely disagree. A collision is fatal. We are nowhere near tra= nsparently >>>> handling all collisions. At best we can hope that DAD can make one n= ode >>>> continue unaffected. >>> >>> I'm confused. >>> >>> Firstly, do we have any experimental evidence that collisions >>> are a real operational problem? (Obviously, MAC address collisions ar= e >>> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) need= s to >>> detect them, they are irrelevant to the current discussion.) >>> >>> Secondly, if a collision does occur with IPv6+(pseudo-random IID), >>> recovery is obvious: after DAD failure, generate a new pseudo-random >>> IID and try again. This is perfectly compatible with RFC4862 section = 5.5 >>> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy= >>> addresses. >>> >>> Brian >>> >>>> >>>> In contrast, people have been scanning my IPv4 ranges for the past 2= 0 years >>>> or so. That may be annoying. That may amplify attacks opportunities.= But >>>> in it self it is not fatal. >>>> >>>> >>>> . >>>> >>> >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- >=20 From nobody Sun Jul 16 15:45:38 2017 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 7CBD512441E for ; Sun, 16 Jul 2017 15:45:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KzvTTXsIMpAk for ; Sun, 16 Jul 2017 15:45:36 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 0D51E12009C for ; Sun, 16 Jul 2017 15:45:36 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id q85so67690998pfq.1 for ; Sun, 16 Jul 2017 15:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D0KbkY63SBn7fVNpBUHGC4ZTpLFBOfbuEYtaQfw7s2k=; b=Qr3dj9W4fqhIdOuWX9o0uuqcT0sRVdwcJt2l1mM68Hft6xeM5wPyvO/ggr3OcvKYN+ +wlLn7fZO6X/Wb7UYhyvgjFzNM1exbipDkttgsbzAYD5I7IS1pnQSSeR5gFS4a6ifCyF wsnlBBlLpEIEEw/HDMQ8Nv4aCyg20nln3kEffl9LnBt+DIaIc/FKlTRyFud7fBCVym5w PZ7rmz7VHJhydF3AKoFMNZOfgdZfBhL0Q3ZQrpdym5DincTFx6D6d59hnF+cxX2gAoTr vbbZYDa9514KP7mOCruv7TUIQUDlHBIhxVFJSmCIsNuz0q66Z8nSvzH569/w5zDo+hIY Sw5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=D0KbkY63SBn7fVNpBUHGC4ZTpLFBOfbuEYtaQfw7s2k=; b=lrW/mnc5p1ZUfj4YZgAiHeuaTSnLdx+qvD/LOU0s0brHNeJiRSKB/Bn4+FsxJ+pprH dM0mlLna5madFMjeCgNHbKXzmC8XaLCNxLhe/oiKL+DdwVLMZKprdizdcs55LCM9nYTy vmZ95lPBUJTVYt/tXe0gygu9i2/UJM7zIS/bGarYvoklhUlsEYHCaC2oHYqpvjqTfs9a LRfpoIwNUi4f4ruSjmHxpK0byzTJgPUi7PRaSJ6tconeJ4y1/e54aRyLQDy1eYiUgXhe VDe9AiuuxIl1gO8gZiXVnG4uvzZ9g5FvLXtBF3AEkRLYrC3sVaZikznH9VgVILJSX+J0 Kq6A== X-Gm-Message-State: AIVw1137SdIwxlXSZuyxi/QvVmQXmfWWOgEbNMfN/VAx4n3b0umlHFkL dktAyo2UJUIwDx6k X-Received: by 10.84.214.22 with SMTP id h22mr26755701pli.277.1500245135217; Sun, 16 Jul 2017 15:45:35 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id 71sm708902pft.20.2017.07.16.15.45.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:45:34 -0700 (PDT) Subject: Re: 64bit IIDs are both recommended and required To: David Farmer , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 17 Jul 2017 10:45:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:45:37 -0000 On 16/07/2017 07:51, David Farmer wrote: ... > A minor tweak; > > Several components of IPv6 architecturally require Unicast Addresses with > fixed length Interface Identifiers that are 64 bits long, except addresses > that start with the binary value 000, primary of these is Stateless Address > Autoconfiguration (SLAAC) [RFC4862], other examples are discussed in > [RFC7421]. Whereas other components of IPv6 are explicitly designed operate > with Interface Identifiers of any length, Neighbor Discovery (ND) > [RFC4861], DHCPv6 [RFC3315] and unicast routing [RFC7608] are examples of > these. Therefore, the use of 64 bit Interface Identifiers are recommended > to ensure all components of IPv6 operate as designed. However, there are > several situations where Interface Identifiers of other lengths can safely > be used, these include loopback interfaces, point-to-point router links > [RFC6164], and links where all nodes are intended to be configured manually > or with DHCPv6. Although, links with any nodes that are intended to be > configured > with SLAAC require 64 bit Interface Identifiers. This is valid commentary, but I don't want to lose the clarity of the latest draft: Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. At this point I'm completely past caring whether it says "are" or "must" or "recommended", as long as all three exceptions are included. Brian From nobody Sun Jul 16 15:58:36 2017 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 8A3C5129562 for ; Sun, 16 Jul 2017 15:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 QOXoqknBPLbp for ; Sun, 16 Jul 2017 15:58:32 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C4E12009C for ; Sun, 16 Jul 2017 15:58:31 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6GMwSf3032786 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2017 23:58:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <596BEF93.6080805@foobar.org> Date: Sun, 16 Jul 2017 23:58:27 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Brian E Carpenter CC: David Farmer , 6man WG Subject: Re: 64bit IIDs are both recommended and required References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:58:34 -0000 Brian E Carpenter wrote: > This is valid commentary, but I don't want to lose the clarity of the latest > draft: > > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. > > At this point I'm completely past caring whether it says "are" or > "must" or "recommended", as long as all three exceptions are included. it would be appropriate for the exception list to include any address assignment mechanism where addresses are assigned by the network (as opposed to addresses which are self-selected by the host). Nick From nobody Sun Jul 16 15:59:41 2017 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 76449129AD1 for ; Sun, 16 Jul 2017 15:59:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y8XuD3FlvyVb for ; Sun, 16 Jul 2017 15:59:39 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e: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 2BA2F12009C for ; Sun, 16 Jul 2017 15:59:39 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id k14so70134336pgr.0 for ; Sun, 16 Jul 2017 15:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dcxBb4VmdXbIVyZBefa0M2fhhc6VKhAXE6oNkXKDwgg=; b=h4uAdMj16A3+AEGiNcVoSEEmjzbe8Z74ltZibT5Bt7SjPwv1uCDZsfsOYflDB0WFK9 //cITANT1Wfybz5V6nUKxByMwNFvtZbpyLWY7RnX9Mhn7X/ojLOkk/edPBuMGMQvKQr8 u9kKdRBdj7Gk5Vt3k2tWDKE82H5EfXXvgLZhoetZMMpmb3LD3z72Ff4aP0zGQmSam+Nb FnPfi8a0u81cTkH7TUb0WCBkynrYEzy9Wece2bVjNNAiP02W5YJtfN7ikWk56tLxTMk2 n9XVn79OVAo0ICmq2StJHupUx4oawKJsFIFi0bdrd2EBoOG6g9SMIawbvk5XzudpO4op yjuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dcxBb4VmdXbIVyZBefa0M2fhhc6VKhAXE6oNkXKDwgg=; b=gDRf5AFTn/RXtoyyA/I4M5AepJ+uH0NCZEpBEY4QAcA8PKeAwfcMcQc4P3MfwxRZGz +RslwsLEL9BqDswO7RegkWJAffeoJ7XxMXryIR6goSSAKTZTjyqzrComQl5tv3VFV+W+ PsddfkxxgUQ9mZjdPkPctmzCZCImHdBy6EkifHr2oenrF0TUtUlb77RDOuzMj2NGNj8p vSt5Hei1WwU738huUFfz4oveBuIro9K/nVOsllbA5Ve84asK4kkyj+KzpJtsRdQCJmze T37iCZCyvdm2NZ6xuqi+odCO8DALDJ0Wgrkybi0fnI7y27w5npbfpEnnGRGAaYlurfLY tsKQ== X-Gm-Message-State: AIVw111+C1D7pAyyp/FHcJCH8XxpLCPy7ZTv/AYzHqyx8Xup/GKCQiek /BWDVvSdZQMs9uxP X-Received: by 10.98.76.145 with SMTP id e17mr16228926pfj.78.1500245978446; Sun, 16 Jul 2017 15:59:38 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id p21sm31083415pgn.12.2017.07.16.15.59.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:59:37 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Morizot Timothy S , Lorenzo Colitti , Nick Hilliard Cc: "draft-ietf-6man-rfc6434-bis@tools.ietf.org" , IETF IPv6 Mailing List References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> <2068324e08614e4abae0a7417c9225eb@irs.gov> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 17 Jul 2017 10:59:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2068324e08614e4abae0a7417c9225eb@irs.gov> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:59:40 -0000 On 17/07/2017 03:36, Morizot Timothy S wrote: > I=E2=80=99ve commented on this topic in the past, but will simply make = one more observation on this specific point. The RFC is informational That's our choice. I think that with IPv6 being at Full Standard,=20 it's time to open the debate about whether 6434bis should be a BCP. > so isn=E2=80=99t a matter of huge concern as it has no impact on produc= t selection or the procurement process. Only for customers who treat RFC status as holy writ. Many people are more realistic and will use an RFC called "Node Requirements" as a requirements checklist. =2E..> This document says that hosts SHOULD support DHCPv6 because operat= ors might use it.=20 Operators might *require* it, so a recommended-to-implement requirement is entirely appropriate for a document aimed at implementers. > But our current recommendations say that: >=20 > 1. Such hosts SHOULD prefer SLAAC over DHCPv6 > 2. DHCPv6-only networks are NOT RECOMMENDED As others have said, that is compatible with recommended-to-implement. Brian From nobody Sun Jul 16 16:04:05 2017 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 901A3129AD1 for ; Sun, 16 Jul 2017 16:04:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 z_nN3an0h9iw for ; Sun, 16 Jul 2017 16:04:02 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E8F1200C1 for ; Sun, 16 Jul 2017 16:04:02 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u5so7657629pgq.3 for ; Sun, 16 Jul 2017 16:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5TA6JQjBt/vBkSSwXimfpqu/Wx0LXmdIWY0/Pzd8HIc=; b=urbIY8NVydRczEjQO5TfaGbuNe6KX8FBqFbJTp6WyQcCW6gD8lalP6tUmlYjMnB5GC qRh/Z0+/fNq5V16E2Y1rfOrAUpMbkP1QUdW2LWL3TaAI4yV/9nmMKObZ7R2JPfeoldWn 4icIkOO9/6bcb+N1dOCcUR4g6ku1MhXbl/B99uR7EEoNJU3LimMnZ2yX98ANM3lTiWyF PBaBCKgtI6D4BmCWs14Z06ELBKINHOALJUtvJvl/3ud3hIChGwapLtF/f7lyP7lCpbWd GPW4KxFl1uSlILE/bwQEqGdRTMEz6KgCqvx5oW/vDszUvepNGriu8JCncILSVAP4tWp7 8dVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5TA6JQjBt/vBkSSwXimfpqu/Wx0LXmdIWY0/Pzd8HIc=; b=Wx3c/0xE1LmlT6sqO56UDZcMmscr5vvwydM7VEVPNsOgSVV99b7COg0yKCKyjRKzzg +zopnzdAfqu40i7AYszVPSoTUxHQ3Fo1npAWct6IywgyFNy51l9tE+fqZnE5giawzO/2 y1iKYq1rtxfJUtq4ThLqKtKl2xZyjuaQEg0cZL7GvBKOA9CEniTXaxmB4NxdkK12npHB 6GyyAo43pBtZu++RkYf4Dhyc8EjOWMtBPJzn4W3JNHXwckQzGsaRo11AOkyaBpYElLf1 Gmh4w1KodkUhKwFKAg7DRN6Bos3pE/03LB+qccDugCaLONwDI3Uh0XbgZf4/gGQbXZVn wbuw== X-Gm-Message-State: AIVw113UqhqYHeCWzbv1BzkIUn/6CaGNF1HASsYAFwTV4/e4smwKSqJt cVTRcIxEXTrlJWqK X-Received: by 10.101.87.140 with SMTP id b12mr26396984pgr.174.1500246241784; Sun, 16 Jul 2017 16:04:01 -0700 (PDT) Received: from [192.168.178.21] (69.21.255.123.dynamic.snap.net.nz. [123.255.21.69]) by smtp.gmail.com with ESMTPSA id k127sm28877808pfc.75.2017.07.16.16.04.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 16:04:01 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt To: Timothy Winters Cc: 6man References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5a4d61e7-9ca4-b741-ddf3-2e3d3714d55c@gmail.com> Date: Mon, 17 Jul 2017 11:03:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:04:04 -0000 Tim, Trimming this just to your direct questions: On 16/07/2017 20:25, Timothy Winters wrote: ... >>> - IPv6 over ATM Networks [RFC2492] >> >> Is this still worth mentioning? >> > > Probably not, we'll remove this in the next draft. How do you feel about > Frame Relay? I don't really know - is it still deployed in the real world? If so, you could leave it in. ... >>> 6.6. Default Address Selection for IPv6 - RFC 6724 >>> >>> IPv6 nodes will invariably have multiple addresses configured >>> simultaneously, and thus will need to choose which addresses to use >>> for which communications. The rules specified in the Default Address >>> Selection for IPv6 [RFC6724] document MUST be implemented. >> >> I am concerned about the famous rule 5.5 in RFC6724. It's optional there, >> but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn >> promotes rule 5.5 to a SHOULD. Could we add that promotion here >> too? Otherwise there is a complicated trail for implementers to follow. >> > I like this idea, how about. > > Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD > implement this rule. Looks good. Thanks, Brian From nobody Sun Jul 16 16:13:16 2017 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 6B4E6129AD1 for ; Sun, 16 Jul 2017 16:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isJCx-n_pgPh for ; Sun, 16 Jul 2017 16:13:13 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A204C1200C1 for ; Sun, 16 Jul 2017 16:13:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 1CE7B9CF for ; Sun, 16 Jul 2017 23:13:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFfurUeIZkSx for ; Sun, 16 Jul 2017 18:13:13 -0500 (CDT) Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id ECA579C9 for ; Sun, 16 Jul 2017 18:13:12 -0500 (CDT) Received: by mail-it0-f69.google.com with SMTP id 188so156911032itx.9 for ; Sun, 16 Jul 2017 16:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oHqZFIi8Hy/Sqk8sjJMeQjRxKWh6nBmRzMtFx231Zwg=; b=Kt4p9OPIncP0uOh6OSws7e07zE4oVnQJvBdll43eMOLXXj0Cfm45B/0hHAONsp4rV3 VHmXv5qak4Ad//Kj0iBKvCvraGR0TXwvXuRata050cMargAIsQ/aUB2YieNQcTdiUfjp 0961NhZDJI9J03fcyHP7gNT/8vcl5EwIynSyZXLM2hVbT4O3p1BKfMSis2oKzlnrUp+P e3K96QSHirLz6EpDknYMW9orqPx1z7Gkmpdf0uVRbQLybDgOtcaPfnn9qpzsHYOLM4hA E2W8TWGHT3TYma/fXN5Gdbw8mrdgm0NLujiPIdgT/S/E3Zwc1FJOwZp2CEpOwOX8AERR r+/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oHqZFIi8Hy/Sqk8sjJMeQjRxKWh6nBmRzMtFx231Zwg=; b=b6IZrS2pU1rYk7dSY+EIcemLd0De6rUtOgUdHkYu1zR7Ck3GnwBgdUKqzPXcBK8hjq YI1cQX4mOqwLOQw2Sns0HWEi60MLeYOvmUbHaGQyFDEgVA7B199UE8vprRWWmI48U+fV oCMEchJunrJzzGnym4x2HBIAmTBP3r1YITt2ndaVgg/S01o54fQqlvvUVnC0QTqqLlVT HWatqCcdCc++LjryuD3tgl9jEzoBE1MfAtVJfnCbo2MbfuLixrMmJttAxI4rY2DoiKkw mxziLIe3guutw5N8L3gzki/FTrYEp9K0gTj3luzHFgAy47DgFt9OrFOTeqoTJKY/W8S1 6jzw== X-Gm-Message-State: AIVw110JVuU7LvPVqo+YIY+/oDHR/1qoPCClbrUDm72o83E7FVUIloNy 3OH0XuNm6KVZK6uE2mShue55j5TqeQhgvXTmjGdudIy3mOrt7CWGKqFmIea9UnSO+t/rlT8xJ3I = X-Received: by 10.36.237.12 with SMTP id r12mr3404430ith.45.1500246792237; Sun, 16 Jul 2017 16:13:12 -0700 (PDT) X-Received: by 10.36.237.12 with SMTP id r12mr3404419ith.45.1500246792008; Sun, 16 Jul 2017 16:13:12 -0700 (PDT) Received: from [10.174.89.216] (mobile-166-175-56-130.mycingular.net. [166.175.56.130]) by smtp.gmail.com with ESMTPSA id j126sm316826itj.15.2017.07.16.16.13.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 16:13:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: 64bit IIDs are both recommended and required From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sun, 16 Jul 2017 18:13:09 -0500 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <22BE1FA6-D992-4951-871F-299181396BB4@umn.edu> References: To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:13:15 -0000 Sent from my iPhone >> On Jul 16, 2017, at 17:45, Brian E Carpenter wrote: >>=20 >> On 16/07/2017 07:51, David Farmer wrote: >> ... >> A minor tweak; >>=20 >> Several components of IPv6 architecturally require Unicast Addresses with= >> fixed length Interface Identifiers that are 64 bits long, except addresse= s >> that start with the binary value 000, primary of these is Stateless Addre= ss >> Autoconfiguration (SLAAC) [RFC4862], other examples are discussed in >> [RFC7421]. Whereas other components of IPv6 are explicitly designed opera= te >> with Interface Identifiers of any length, Neighbor Discovery (ND) >> [RFC4861], DHCPv6 [RFC3315] and unicast routing [RFC7608] are examples of= >> these. Therefore, the use of 64 bit Interface Identifiers are recommended= >> to ensure all components of IPv6 operate as designed. However, there are >> several situations where Interface Identifiers of other lengths can safel= y >> be used, these include loopback interfaces, point-to-point router links >> [RFC6164], and links where all nodes are intended to be configured manual= ly >> or with DHCPv6. Although, links with any nodes that are intended to be >> configured >> with SLAAC require 64 bit Interface Identifiers. >=20 > This is valid commentary, but I don't want to lose the clarity of the late= st > draft: >=20 > Interface Identifiers are 64 bit long except if the first three bits > of the address are 000, or when the addresses are manually > configured, or by exceptions defined in standards track documents. >=20 > At this point I'm completely past caring whether it says "are" or > "must" or "recommended", as long as all three exceptions are included. >=20 > Brian The current text doesn't explicitly cover DHCPv6, given the level of debate b= ack and forth on this, the status of DHCPv6 in this should be abundantly cle= ar. Personally, I believe it has any length IIDs just like manual config. B= ut, even if I'm in the rough on this, I'll accept that, as long as it is exp= licitly clear either way.=20 When we're done with this there can't be open questions like the status of D= HCPv6.= From nobody Sun Jul 16 17:15:01 2017 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 EF6181205F0 for ; Sun, 16 Jul 2017 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 noflWotDkK16 for ; Sun, 16 Jul 2017 17:14:58 -0700 (PDT) Received: from EMG3.irs.gov (emg3.irs.gov [IPv6:2610:30:4000:25::91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5401277BB for ; Sun, 16 Jul 2017 17:14:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,372,1496116800"; d="scan'208";a="85925989" Received: from unknown (HELO mem0200vprelay3.is.irs.gov) ([10.207.43.147]) by mtb0120emg3.mcc.irs.gov with ESMTP; 16 Jul 2017 20:14:55 -0400 Received: from MTB0120PPEXB030.ds.irsnet.gov (mtb0120ppexb030.ds.irsnet.gov [10.207.136.39]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id v6H0Esuq028140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 19:14:54 -0500 Received: from MTB0120PPEXB060.ds.irsnet.gov (10.207.136.42) by MTB0120PPEXB030.ds.irsnet.gov (10.207.136.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Sun, 16 Jul 2017 20:14:53 -0400 Received: from MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969]) by MTB0120PPEXB060.ds.irsnet.gov ([fe80::8dd6:c2b6:71a0:5969%19]) with mapi id 15.01.0845.034; Sun, 16 Jul 2017 20:14:53 -0400 From: Morizot Timothy S To: IETF IPv6 Mailing List Subject: RE: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Index: AQHS/hZUERf+nZtCPEClFdRvoEWdG6JWkc+AgAABcACAAA2nAIAAGiiA///PKtCAAMsJgP//yrDg Date: Mon, 17 Jul 2017 00:14:53 +0000 Message-ID: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <596B588A.2010701@foobar.org> <2068324e08614e4abae0a7417c9225eb@irs.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.219.81.204] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 00:15:00 -0000 QnJpYW4gRSBDYXJwZW50ZXIgW2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gd3JvdGU6DQo+ IE9uIDE3LzA3LzIwMTcgMDM6MzYsIE1vcml6b3QgVGltb3RoeSBTIHdyb3RlOg0KPiA+IEnigJl2 ZSBjb21tZW50ZWQgb24gdGhpcyB0b3BpYyBpbiB0aGUgcGFzdCwgYnV0IHdpbGwgc2ltcGx5IG1h a2Ugb25lIG1vcmUNCj4gb2JzZXJ2YXRpb24gb24gdGhpcyBzcGVjaWZpYyBwb2ludC4gVGhlIFJG QyBpcyBpbmZvcm1hdGlvbmFsDQo+IA0KPiBUaGF0J3Mgb3VyIGNob2ljZS4gSSB0aGluayB0aGF0 IHdpdGggSVB2NiBiZWluZyBhdCBGdWxsIFN0YW5kYXJkLA0KPiBpdCdzIHRpbWUgdG8gb3BlbiB0 aGUgZGViYXRlIGFib3V0IHdoZXRoZXIgNjQzNGJpcyBzaG91bGQgYmUgYSBCQ1AuDQo+IA0KPiA+ IHNvIGlzbuKAmXQgYSBtYXR0ZXIgb2YgaHVnZSBjb25jZXJuIGFzIGl0IGhhcyBubyBpbXBhY3Qg b24gcHJvZHVjdCBzZWxlY3Rpb24gb3INCj4gdGhlIHByb2N1cmVtZW50IHByb2Nlc3MuDQo+IA0K PiBPbmx5IGZvciBjdXN0b21lcnMgd2hvIHRyZWF0IFJGQyBzdGF0dXMgYXMgaG9seSB3cml0LiBN YW55IHBlb3BsZSBhcmUNCj4gbW9yZSByZWFsaXN0aWMgYW5kIHdpbGwgdXNlIGFuIFJGQyBjYWxs ZWQgIk5vZGUgUmVxdWlyZW1lbnRzIiBhcw0KPiBhIHJlcXVpcmVtZW50cyBjaGVja2xpc3QuDQoN ClNvcnJ5LCBJIHJlYWxpemVkIHRoYXQgY29tbWVudCBkaWRuJ3QgY2xlYXJseSBzdGF0ZSB3aGF0 IEkgd2FzIHRoaW5raW5nLiBJIG1lYW50IGlmIGl0IHdlcmUgYSBzdGFuZGFyZHMgZG9jdW1lbnQg c3BlY2lmeWluZyB0aGF0IERIQ1B2NiBvbmx5IG5ldHdvcmtzLCBhIHBlcmZlY3RseSB2YWxpZCBj b25maWd1cmF0aW9uIGluIHRoZSBzdGFuZGFyZHMgdG8gZGF0ZSwgd2VyZSBub3QgcmVjb21tZW5k ZWQgKGluIGFueSBjb250ZXh0KSBvciBhIHN0YW5kYXJkcyBkb2N1bWVudCBzcGVjaWZ5aW5nIHRo YXQgREhDUHY2IGFzIGEgcHJvdG9jb2wgd2FzIG5vdCByZWNvbW1lbmRlZCwgdGhlbiBJIHdvdWxk IGhhdmUgbW9yZSBjb25jZXJucyBvdmVyIHRoZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQuIEl0IHdv dWxkbid0IGNoYW5nZSBhbnl0aGluZyBpbiBvcGVyYXRpb25hbCBjb25maWd1cmF0aW9uIG9yIHBy YWN0aWNlLCBidXQgd291bGQgY2xlYXJseSBiZSBhIG1vcmUgc2lnbmlmaWNhbnQgaXNzdWUuIEdp dmVuIHRoYXQgdGhpcyBpcyBhbiBpbmZvcm1hdGlvbiByZWNvbW1lbmRhdGlvbiBmb3IgaG9zdCBk ZXZlbG9wZXJzLCBpdCBoYXMgbm8gZGlyZWN0IGltcGFjdCBvbiB0aG9zZSBwdXJjaGFzaW5nIG9y IG90aGVyd2lzZSBlbGVjdGluZyB0byB1c2Ugc2FpZCBob3N0cy4gRXZlbiBpZiBpdCB3ZXJlIGEg QkNQICh3aGljaCB3b3VsZCBiZSBvZGQgdG8gY2FsbCBzb21ldGhpbmcgYSAiY29tbW9uIHByYWN0 aWNlIiBvZiBhbnkgc29ydCBpZiBpdCBkaWRuJ3QgcmVjb21tZW5kIGhvc3QgZGV2ZWxvcGVycyBj b25zaWRlciBESENQdjYgc3VwcG9ydCBzaW5jZSBtYW55IGhvc3RzIGRvIHN1cHBvcnQgaXQgdG9k YXkpLCB0aGF0IHdvdWxkIGhhdmUgbGl0dGxlIGltcGFjdCBzaW5jZSBhcyB0aG9zZSBwdXJjaGFz aW5nIG9yIGVsZWN0aW5nIHRvIHVzZSAiaG9zdHMiLCB3ZSB3cml0ZSBvdXIgb3duIHJlcXVpcmVt ZW50cyBmb3IgdGhlbS4gU28gSSB3YXMgcmVhbGx5IGp1c3QgdHJ5aW5nIHRvIG5vdGUgdGhhdCBJ IHdhcyBjb21tZW50aW5nIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRob3NlIHdobyBzcGVjaWZ5 IHJlcXVpcmVtZW50cyBmb3IgcHJvY3VyaW5nIGhvc3QgZGV2aWNlcywgbm90IGZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIHRob3NlIHdobyBkZXZlbG9wIHNhaWQgZGV2aWNlcy4NCg0KRnJvbSB0aGF0 IHBlcnNwZWN0aXZlLCBzaW5jZSBob3N0cyBtYXkgdmVyeSB3ZWxsIGZpbmQgdGhlbXNlbHZlcyBl eGNsdWRlZCBmcm9tIGNvbnNpZGVyYXRpb24gYnkgc29tZSBzb3J0cyBvZiBsYXJnZSBlbnRlcnBy aXNlcyBpZiB0aGV5IGRvIG5vdCBzdXBwb3J0IERIQ1B2NiwgYSBkb2N1bWVudCBhaW1lZCBhdCB0 aGVpciBkZXZlbG9wZXJzIG1ha2VzIG1vcmUgc2Vuc2UgaWYgaXQgbm90ZXMgdGhleSBzaG91bGQg Y29uc2lkZXIgc3VwcG9ydGluZyBESENQdjYuIFRoZSBkZXZlbG9wZXIgbWF5IGRlY2lkZSBpdCBk b2Vzbid0IGZpdCB0aGVpciBtb2RlbCBvciB0aGUgaG9zdCBtYXkgYmUgYSB2ZXJ5IHNwZWNpYWwg cHVycG9zZSBJT1Qgc29ydCBvZiBob3N0IHdoaWNoIGluIGEgbGFyZ2UgZW50ZXJwcmlzZSBtYXkg YmUgc2VncmVnYXRlZCBpbnRvIGl0cyBvd24gbmV0d29yayBhbnl3YXkuIEdpdmVuIHRoYXQsIHRo ZSBjaGFuZ2UgdG8gU0hPVUxEIHNlZW1zIHRvIG1ha2UgYSBsb3QgbW9yZSBzZW5zZSB0aGFuIHdo YXQgcGVvcGxlIG1heSBoYXZlIHRob3VnaHQgd2hlbiA0Mjk0IHdhcyB3cml0dGVuLiAoQWdhaW4s IGZyb20gdGhlIGFwcGVuZGl4IG9mIHRoaXMgYmlzLCBpdCBsb29rcyBsaWtlIHRoYXQncyB3aGF0 IGlzIGFjdHVhbGx5IGJlIHVwZGF0ZWQgaW4gdGhlIHJldmlzaW9uLikgRG9pbmcgYW55dGhpbmcg ZWxzZSBsb29rcyBsaWtlIHByZXR0eSBwb29yIGFkdmljZSB0byBkZXZlbG9wZXJzIG9mIGhvc3Rz LCBhZ2FpbiBmcm9tIG15IHBlcnNwZWN0aXZlLiBBbmQgZnJvbSBteSBvcGVyYXRpb25hbCBleHBl cmllbmNlLCBtYW55IGhvc3RzIHN1cHBvcnQgREhDUHY2IGFuZCBESENQdjYgb25seSBuZXR3b3Jr cyBqdXN0IGZpbmUgdG9kYXksIHdoYXRldmVyIHRoZSBjdXJyZW50IHJlY29tbWVuZGF0aW9ucyBt aWdodCBzYXkuIFVwZGF0aW5nIHRoZSByZWNvbW1lbmRhdGlvbnMgdG8gcmVmbGVjdCByZWFsaXR5 IHNlZW1zIHJlYXNvbmFibGUuDQoNClNjb3R0DQoNCg0K From nobody Sun Jul 16 18:52:26 2017 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 5F8F9131467 for ; Sun, 16 Jul 2017 18:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 MEZIQmN-_BkB for ; Sun, 16 Jul 2017 18:52:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 02C73127601 for ; Sun, 16 Jul 2017 18:52:23 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6H1jCmZ002564; Sun, 16 Jul 2017 21:52:20 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2brkf8gfwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Jul 2017 21:52:19 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6H1qHts013155; Sun, 16 Jul 2017 21:52:18 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6H1qCHh013105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Jul 2017 21:52:13 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 17 Jul 2017 01:52:02 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Sun, 16 Jul 2017 21:52:02 -0400 From: "STARK, BARBARA H" To: David Farmer , Lorenzo Colitti CC: "draft-ietf-6man-rfc6434-bis@tools.ietf.org" , IETF IPv6 Mailing List Subject: RE: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Index: AQHS9BLHY5q+ieK8u0qPkER7pDo7w6JWh5GAgAAeRYCAAAFwAIAAN0sAgAB0+rA= Date: Mon, 17 Jul 2017 01:52:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBCB6A8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.245.201] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DBCB6A8GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-17_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707170025 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 01:52:25 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DBCB6A8GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gU3VuLCBKdWwgMTYsIDIwMTcgYXQgNjoyNSBBTSwgTG9yZW56byBDb2xpdHRpIDxsb3Jlbnpv QGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gU3VuLCBK dWwgMTYsIDIwMTcgYXQgMToyMCBQTSwgTmljayBIaWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPG1h aWx0bzpuaWNrQGZvb2Jhci5vcmc+PiB3cm90ZToNClRoZSBzZWxmLXNlbGVjdGlvbiBhZGRyZXNz aW5nIG1vZGVsIGRvZXMgbm90IHN1aXQgdGhlIGRlcGxveW1lbnQNCnJlcXVpcmVtZW50cyBmb3Ig bWFueSB0eXBlcyBvZiBpcHY2IG5ldHdvcmtzLCBpbmNsdWRpbmcgZW50ZXJwcmlzZSwNCnByb3Zp ZGVyIGhvc3RpbmcsIHRlcnJlc3RyaWFsIGFjY2VzcyBuZXR3b3JrcyAoZS5nLiBkb2NzaXMgLyBn cG9uIC8NCmlwb2UpIGFuZCBvdGhlcnMuICBJZiB0aGUgcmVjb21tZW5kYXRpb24gZm9yIGRoY3B2 NiBpcyBkcm9wcGVkLCB0aGVuDQp0aGVyZSBpcyBubyByZWNvbW1lbmRlZCBpZXRmIG1vZGVsIGZv ciBvcGVyYXRvci1hc3NpZ25lZCBhZGRyZXNzaW5nLCBhbmQNCnRoaXMgd291bGQgbGVhdmUgYSBn bGFyaW5nIGhvbGUgaW4gdGhlIGlwdjYgaG9zdCBzcGVjaWZpY2F0aW9uLg0KDQpUaGF0J3MgYSBm YWlyIG9waW5pb24gdG8gaG9sZCwgYnV0IHRoZSBmYWN0IG9mIHRoZSBtYXR0ZXIgaXMgdGhhdCBh IFNIT1VMRCBmb3IgREhDUHY2IGNvbmZsaWN0cyB3aXRoIFJGQyA3OTM0IGFuZCBSRkMgNzg0NC4N Cg0KV2Ugc2hvdWxkbid0IHB1Ymxpc2ggYSBob3N0IHJlcXVpcmVtZW50cyBkb2N1bWVudCB0aGF0 IGNvbnRyYWRpY3RzIHRoZSBob3N0IGFkZHJlc3MgYXNzaWdubWVudCBCQ1AgYW5kIHRoYXQgY2l0 ZXMgUkZDNzg0NCB3aGlsZSBjb250cmFkaWN0aW5nIHRoYXQgZG9jdW1lbnQncyByZWNvbW1lbmRh dGlvbiB0byB1c2Ugc3RhdGVsZXNzIGluIHByZWZlcmVuY2UgdG8gc3RhdGVmdWwuDQoNCkxldHMg c3RhcnQgd2l0aCBSRkMgNzkzNCBpdCBpcyBhIHNldCBvZiBSRUNPTU1FTkRBVElPTlMgZm9yIGhv dyBuZXR3b3JrcyBzaG91bGQgc3VwcGx5IGFkZHJlc3NlcyB0byBnZW5lcmFsIHB1cnBvc2UgaG9z dHMuICBGaXJzdCwgbm90IGV2ZXJ5dGhpbmcgZml0cyBpbnRvIHRoYXQgc2NvcGUgYW5kIGV2ZW4g d2l0aGluIHRoYXQgc2NvcGUgYXMgYSBSRUNPTU1FTkRBVElPTiB0aGF0IG1lYW5zICJ0aGVyZSBt YXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8gaWdu b3JlIGEgcGFydGljdWxhciBpdGVtIiBbUkZDMjExOV0uICBTbywgaXQgYnkgbm8gbWVhbnMgcHJl Y2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGhvc3RzIGNvdWxkIGZpbmQgdGhlbSBvbiBhIG5l dHdvcmsgdGhhdCBpcyBvbmx5IHByb3ZpZGluZyBhZGRyZXNzZXMgdmlhIERIQ1B2Ni4gVGhlcmVm b3JlLCBhIFNIT1VMRCBmb3IgREhDUHY2IGluIHRoZSBob3N0IHJlcXVpcmVtZW50cyBzdGlsbCBz ZWVtcyBhcHByb3ByaWF0ZSB0byBtZS4NCg0KQXMgZm9yIFJGQyA3ODQ0LCBpdCBpcyBzY29wZWQg dG8gbW9iaWxlIGhvc3RzIHRoYXQgd2FudCBwcml2YWN5IGZyb20gdGhlIERIQ1Agc2VydmVyLCBh bmQgaXQgc2F5cyAiVGhlIGFub255bWl0eSBwcm9maWxlcyBoYXZlIHRoZSBlZmZlY3Qgb2YgaGlk aW5nIHRoZSBjbGllbnQgaWRlbnRpdHkgZnJvbSB0aGUgREhDUCBzZXJ2ZXIuICBUaGlzIGlzIG5v dCBhbHdheXMgZGVzaXJhYmxlLiAuLi4iICBBIGRvY3VtZW50IHRoYXQgaXRzZWxmIHJlY29nbml6 ZXMgaXQncyBwcmltYXJ5IHB1cnBvc2UgImlzIG5vdCBhbHdheXMgZGVzaXJhYmxlIiBldmVuIHdp dGhpbiBpdCdzIGRlZmluZWQgc2NvcGUsIGlzbid0IGEgc3Ryb25nIGFyZ3VtZW50IGZvciBjaGFu Z2luZyB0aGUgUkVDT01NRU5ERUQgYmVoYXZpb3Igb2YgYWxsIGhvc3QuDQoNCjxiaHM+ICsxLiBS RkMgNjQzNCBOb2RlIFJlcXVpcmVtZW50cyBhcmUgZ2VuZXJhbC1wdXJwb3NlIGZvciBhbGwgbm9k ZXMgb24gYWxsIG5ldHdvcmtzLiBBbmQgc2hvdWxkIHJlbWFpbiBzby4gVGhleSBzaG91bGQgbm90 IGJlIHRhaWxvcmVkIHRvIDNHUFAgbmV0d29ya3Mgb3IgbWFzcyBtYXJrZXQgZW5kIHVzZXIgbmV0 d29ya3Mgb3IgYW55IG90aGVyIHNwZWNpYWwgbmV0d29yay4gUkZDIDc5MzQgYW5kIDc4NDQgYXJl IG5vdCBmb3IgYWxsIG5vZGVzLiBCVFcsIG1hbnkgd2lyZWxpbmUgYWNjZXNzIG5ldHdvcmtzIGRv IG5vdCBzdXBwb3J0IFNMQUFDIGZvciBhZGRyZXNzIGFzc2lnbm1lbnQgdG8gdGhlIENFIFJvdXRl ci4gV2hpY2ggaXMgd2h5IFJGQyA3MDg0IGV4aXN0cyAtLSB0byBwcm92aWRlIHNwZWNpZmljIGd1 aWRhbmNlIGZvciB0aGF0IHNwZWNpZmljIHVzZSBjYXNlLiBSRkMgNzA4NCBkb2VzIG5vdCBjb25m bGljdCB3aXRoIFJGQyA2NDM0LiBCZWNhdXNlIGl0cyB1c2UgY2FzZSBpcyBkaXN0aW5jdCBmcm9t IHRoYXQgb2YgUkZDcyA3OTM0IGFuZCA3ODQ0LCBpdCBkb2VzbuKAmXQgY29uZmxpY3Qgd2l0aCB0 aGVtIGVpdGhlci4NCg0KRnVydGhlciwgYSAicmVjb21tZW5kYXRpb24gdG8gdXNlIHN0YXRlbGVz cyBpbiBwcmVmZXJlbmNlIHRvIHN0YXRlZnVsIiBpc24ndCBhIHByb2hpYml0aW9uIG9uIHN0YXRl ZnVsLCBVbnRpbCwgc3RhdGVmdWwgaXMgcHJvaGliaXRlZCBvciBhbGwgbmV0d29ya3MgYXJlIHJl cXVpcmVkIHRvIHByb3ZpZGVkIHN0YXRlbGVzcywgYSBTSE9VTEQgZm9yIERIQ1B2NiBpbiB0aGUg aG9zdCByZXF1aXJlbWVudHMgc3RpbGwgc2VlbXMgYXBwcm9wcmlhdGUgdG8gbWUuDQoNCjxiaHM+ ICsxDQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DBCB6A8GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBTdW4sIEp1bCAxNiwgMjAxNyBhdCA2OjI1IEFNLCBMb3JlbnpvIENvbGl0dGkg Jmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5s b3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1 bCAxNiwgMjAxNyBhdCAxOjIwIFBNLCBOaWNrIEhpbGxpYXJkICZsdDs8YSBocmVmPSJtYWlsdG86 bmlja0Bmb29iYXIub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmlja0Bmb29iYXIub3JnPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHNlbGYtc2VsZWN0aW9uIGFkZHJlc3NpbmcgbW9kZWwgZG9lcyBub3Qgc3VpdCB0aGUgZGVw bG95bWVudDxicj4NCnJlcXVpcmVtZW50cyBmb3IgbWFueSB0eXBlcyBvZiBpcHY2IG5ldHdvcmtz LCBpbmNsdWRpbmcgZW50ZXJwcmlzZSw8YnI+DQpwcm92aWRlciBob3N0aW5nLCB0ZXJyZXN0cmlh bCBhY2Nlc3MgbmV0d29ya3MgKGUuZy4gZG9jc2lzIC8gZ3BvbiAvPGJyPg0KaXBvZSkgYW5kIG90 aGVycy4mbmJzcDsgSWYgdGhlIHJlY29tbWVuZGF0aW9uIGZvciBkaGNwdjYgaXMgZHJvcHBlZCwg dGhlbjxicj4NCnRoZXJlIGlzIG5vIHJlY29tbWVuZGVkIGlldGYgbW9kZWwgZm9yIG9wZXJhdG9y LWFzc2lnbmVkIGFkZHJlc3NpbmcsIGFuZDxicj4NCnRoaXMgd291bGQgbGVhdmUgYSBnbGFyaW5n IGhvbGUgaW4gdGhlIGlwdjYgaG9zdCBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIGEgZmFpciBv cGluaW9uIHRvIGhvbGQsIGJ1dCB0aGUgZmFjdCBvZiB0aGUgbWF0dGVyIGlzIHRoYXQgYSBTSE9V TEQgZm9yIERIQ1B2NiBjb25mbGljdHMgd2l0aCBSRkMgNzkzNCBhbmQgUkZDIDc4NDQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHNob3Vs ZG4ndCBwdWJsaXNoIGEgaG9zdCByZXF1aXJlbWVudHMgZG9jdW1lbnQgdGhhdCBjb250cmFkaWN0 cyB0aGUgaG9zdCBhZGRyZXNzIGFzc2lnbm1lbnQgQkNQIGFuZCB0aGF0IGNpdGVzIFJGQzc4NDQg d2hpbGUgY29udHJhZGljdGluZyB0aGF0IGRvY3VtZW50J3MgcmVjb21tZW5kYXRpb24gdG8gdXNl IHN0YXRlbGVzcyBpbiBwcmVmZXJlbmNlIHRvIHN0YXRlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldHMgc3RhcnQgd2l0aCBSRkMgNzkzNCBpdCBpcyBh IHNldCBvZiBSRUNPTU1FTkRBVElPTlMgZm9yIGhvdyBuZXR3b3JrcyBzaG91bGQgc3VwcGx5IGFk ZHJlc3NlcyB0byBnZW5lcmFsIHB1cnBvc2UgaG9zdHMuJm5ic3A7IEZpcnN0LCBub3QgZXZlcnl0 aGluZyBmaXRzIGludG8gdGhhdCBzY29wZSBhbmQgZXZlbiB3aXRoaW4gdGhhdCBzY29wZSBhcyBh IFJFQ09NTUVOREFUSU9OIHRoYXQgbWVhbnMgJnF1b3Q7dGhlcmUgbWF5DQogZXhpc3QgdmFsaWQg cmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8gaWdub3JlIGEgcGFydGljdWxh ciBpdGVtJnF1b3Q7IFtSRkMyMTE5XS4mbmJzcDsgU28sIGl0IGJ5IG5vIG1lYW5zIHByZWNsdWRl cyB0aGUgcG9zc2liaWxpdHkgdGhhdCBob3N0cyBjb3VsZCBmaW5kIHRoZW0gb24gYSBuZXR3b3Jr IHRoYXQgaXMgb25seSBwcm92aWRpbmcgYWRkcmVzc2VzIHZpYSBESENQdjYuIFRoZXJlZm9yZSwg YSBTSE9VTEQgZm9yIERIQ1B2NiBpbiB0aGUNCiBob3N0IHJlcXVpcmVtZW50cyBzdGlsbCBzZWVt cyBhcHByb3ByaWF0ZSB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgUkZDIDc4NDQs IGl0IGlzIHNjb3BlZCB0byBtb2JpbGUgaG9zdHMgdGhhdCB3YW50IHByaXZhY3kgZnJvbSB0aGUg REhDUCBzZXJ2ZXIsIGFuZCBpdCBzYXlzICZxdW90O1RoZSBhbm9ueW1pdHkgcHJvZmlsZXMgaGF2 ZSB0aGUgZWZmZWN0IG9mIGhpZGluZyB0aGUgY2xpZW50IGlkZW50aXR5IGZyb20gdGhlIERIQ1Ag c2VydmVyLiZuYnNwOyBUaGlzIGlzIG5vdCBhbHdheXMgZGVzaXJhYmxlLiAuLi4mcXVvdDsgJm5i c3A7QSBkb2N1bWVudA0KIHRoYXQgaXRzZWxmIHJlY29nbml6ZXMgaXQncyBwcmltYXJ5IHB1cnBv c2UgJnF1b3Q7aXMgbm90IGFsd2F5cyBkZXNpcmFibGUmcXVvdDsgZXZlbiB3aXRoaW4gaXQncyBk ZWZpbmVkIHNjb3BlLCBpc24ndCBhIHN0cm9uZyBhcmd1bWVudCBmb3IgY2hhbmdpbmcgdGhlIFJF Q09NTUVOREVEJm5ic3A7YmVoYXZpb3Igb2YgYWxsIGhvc3QuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7YmhzJmd0OyAmIzQzOzEuIFJGQyA2NDM0IE5vZGUg UmVxdWlyZW1lbnRzIGFyZSBnZW5lcmFsLXB1cnBvc2UgZm9yIGFsbCBub2RlcyBvbiBhbGwgbmV0 d29ya3MuIEFuZCBzaG91bGQgcmVtYWluIHNvLiBUaGV5IHNob3VsZCBub3QgYmUgdGFpbG9yZWQg dG8gM0dQUCBuZXR3b3JrcyBvcg0KIG1hc3MgbWFya2V0IGVuZCB1c2VyIG5ldHdvcmtzIG9yIGFu eSBvdGhlciBzcGVjaWFsIG5ldHdvcmsuIFJGQyA3OTM0IGFuZCA3ODQ0IGFyZSBub3QgZm9yIGFs bCBub2Rlcy4gQlRXLCBtYW55IHdpcmVsaW5lIGFjY2VzcyBuZXR3b3JrcyBkbyBub3Qgc3VwcG9y dCBTTEFBQyBmb3IgYWRkcmVzcyBhc3NpZ25tZW50IHRvIHRoZSBDRSBSb3V0ZXIuIFdoaWNoIGlz IHdoeSBSRkMgNzA4NCBleGlzdHMgLS0gdG8gcHJvdmlkZSBzcGVjaWZpYyBndWlkYW5jZQ0KIGZv ciB0aGF0IHNwZWNpZmljIHVzZSBjYXNlLiBSRkMgNzA4NCBkb2VzIG5vdCBjb25mbGljdCB3aXRo IFJGQyA2NDM0LiBCZWNhdXNlIGl0cyB1c2UgY2FzZSBpcyBkaXN0aW5jdCBmcm9tIHRoYXQgb2Yg UkZDcyA3OTM0IGFuZCA3ODQ0LCBpdCBkb2VzbuKAmXQgY29uZmxpY3Qgd2l0aCB0aGVtIGVpdGhl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZ1cnRoZXIsIGEgJnF1b3Q7cmVjb21tZW5kYXRpb24gdG8gdXNlIHN0YXRlbGVzcyBp biBwcmVmZXJlbmNlIHRvIHN0YXRlZnVsJnF1b3Q7IGlzbid0IGEgcHJvaGliaXRpb24gb24gc3Rh dGVmdWwsIFVudGlsLCBzdGF0ZWZ1bCBpcyBwcm9oaWJpdGVkIG9yIGFsbCBuZXR3b3JrcyBhcmUg cmVxdWlyZWQgdG8gcHJvdmlkZWQgc3RhdGVsZXNzLCBhIFNIT1VMRCBmb3IgREhDUHY2IGluIHRo ZSBob3N0IHJlcXVpcmVtZW50cyBzdGlsbA0KIHNlZW1zIGFwcHJvcHJpYXRlIHRvIG1lLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7YmhzJmd0OyAmIzQzOzE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DBCB6A8GAALPA1MSGUSRBF_-- From nobody Sun Jul 16 22:15:14 2017 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 736D6129B3A for ; Sun, 16 Jul 2017 22:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 x36L3rwsukkH for ; Sun, 16 Jul 2017 22:15:06 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 5D2E5127869 for ; Sun, 16 Jul 2017 22:15:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6H5F4aR072991 for ; Mon, 17 Jul 2017 07:15:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3613820133B for ; Mon, 17 Jul 2017 07:15:04 +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 2A356201057 for ; Mon, 17 Jul 2017 07:15:04 +0200 (CEST) Received: from [132.166.84.9] ([132.166.84.9]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6H5F02H002580 for ; Mon, 17 Jul 2017 07:15:02 +0200 Subject: Re: 64bit IIDs are both recommended and required To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> Date: Mon, 17 Jul 2017 07:14:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:15:13 -0000 Le 15/07/2017 à 19:54, David Farmer a écrit : [...] > Also a problem statement was asked for, and I think that is it, "a > simple statement requiring or recommending 64 bit IIDs doesn't > accurately reflect the true nature of the IPv6 architecture." If a problem statement is formulated, it is worth adding the following. The 64bit IIDs make for a problem of 'growth at the edges'. Such a problem has to do with use-cases like when using a smartphone to 'tether'. Connect the smartphone on 4G and give others Internet on WiFi, such as to 'grow' the network. Similar use-cases are: a WiFi Access Point, an IoT Gateway, an automobile On-Board Router, a Road-Side Unit, an satcom-WiFi router in an airplane. Such a device is present at the edge of the Internet. It obtains a /64 from a provider (a cellular or an ADSL provider). It then has to make up other /64s to give others. It cant. That's the problem of growth at the edges. This problem is made worse by current technical difficulties in using DHCPv6 and DHCPv6-PD, like lack of interoperability. This problem has a counterpart problem that is a 'race to the bottom'. (a few people's ideas are in what I write above) [...] > I think the following more accurately conveys the true nature of the > IPv6 architecture in regards to IIDs; > > Several components of IPv6 architecturally require Unicast Addresses > with fixed length Interface Identifiers that are 64 bits long, except > addresses that start with the binary value 000, primary of these is > Stateless Address Autoconfiguration (SLAAC) [RFC4862], other examples > are discussed in [RFC7421]. Whereas other components of IPv6 are > explicitly designed operate with Interface Identifiers of any length, > Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast > routing [RFC7608] are examples of these. Therefore, the use of 64 bit > Interface Identifiers are recommended to ensure all components of > IPv6 operate as designed. However, there are several situations where > Interface Identifiers of other lengths can safely be used, these > include loopback interfaces, point-to-point router links [RFC6164], > and links where all nodes are configured manually or with DHCPv6. > Although, links with any nodes that are configured with SLAAC require > 64 bit Interface Identifiers. > > What do others think? The paragraph above makes sense in itself. But is it a problem statement, or is it a solution to add in the rfcbis? Alex > > -- =============================================== David Farmer > Email:farmer@umn.edu Networking & > Telecommunication Services Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: > 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sun Jul 16 22:49:15 2017 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 BDF5312EB4A for ; Sun, 16 Jul 2017 22:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qKC-YK_aNG-N for ; Sun, 16 Jul 2017 22:49:12 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 78C2B129562 for ; Sun, 16 Jul 2017 22:49:12 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 64so5272618uae.2 for ; Sun, 16 Jul 2017 22:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yclhUjIpTyfWeUP5Aqxa6PiziYEB8vLSN2K671xkTUE=; b=P6bqWSsg9cZqbJZFC+Xf8zBwQf9l4KcbTi0K+RKLX6Fw9DelypRMcCy6LFJn40fmCn 8wfluIxsfpGFs3AuXqwh8taoBtx86Ora/iodbSH+NEu+QD+7/4M5tXp1/4A49+xGIp5G mLIQevhyCQNIZL3g017kTqiNDb1sbZhJIqEfwahA3JF4ErVTabWsf98QY6pZ1cpTZGXK tSOLRI/pOmIZDf6G0Q4cTJ3Ix0UIJpsMP7ryWq6TV+kVvq0ajgWwpMZEX7HGQLBkWw/0 ruF/hi6NHV/c2PbfL1hQ77VbxYiMltWMYRuWdtaYLOXrj+blK+kxnFDIAddl6z8WOvhO KfFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yclhUjIpTyfWeUP5Aqxa6PiziYEB8vLSN2K671xkTUE=; b=EXlJObNWXHcBWbaTHcMwehzZdF574IafARDB2IPkrfcFyjpkR3WQQqiRa/OlRDm+bH MGM9wQVvSLfT16QOsIh5rXPFuO+Amw6HKHfiLEvhmttfj8z+ZVmL1ZmqXX1Jc/mKZhsO /MjCaYxUeJ4oQK6mllANjyb68Zp2yprDDrITCxfU42ACcDnW+5PXwy2L1UbYcC3Anzvb DTuNWb9NCdTvw1eNriIruAjGVq45pYioLEJ9XIqthB1FBeTPVKzArsYIXCnw0NQ5MyvQ Q8dKFfiezY/n9vj7MnrdUKXyJZSjB9XgCH5kfF1EIW2+7R458wcFf67JwXMiGFYcWSyL z5fA== X-Gm-Message-State: AIVw110bj8t/1wtwJsxy9WOCHTqn/+yCcSJVj/ccXw1Rg/TdD2FxDxA8 xWFH7YinRn9HiUx1Co//BHSJtb+EIA== X-Received: by 10.31.244.194 with SMTP id s185mr1037459vkh.0.1500270551453; Sun, 16 Jul 2017 22:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Sun, 16 Jul 2017 22:48:41 -0700 (PDT) In-Reply-To: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> References: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> From: Mark Smith Date: Mon, 17 Jul 2017 15:48:41 +1000 Message-ID: Subject: Re: 64bit IIDs are both recommended and required To: Alexandre Petrescu Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 05:49:14 -0000 On 17 July 2017 at 15:14, Alexandre Petrescu wrote: > Le 15/07/2017 =C3=A0 19:54, David Farmer a =C3=A9crit : > [...] >> >> Also a problem statement was asked for, and I think that is it, "a simpl= e >> statement requiring or recommending 64 bit IIDs doesn't accurately refle= ct >> the true nature of the IPv6 architecture." > > > If a problem statement is formulated, it is worth adding the following. > > The 64bit IIDs make for a problem of 'growth at the edges'. Such a > problem has to do with use-cases like when using a smartphone to > 'tether'. Connect the smartphone on 4G and give others Internet on > WiFi, such as to 'grow' the network. Similar use-cases are: a WiFi > Access Point, an IoT Gateway, an automobile On-Board Router, a Road-Side > Unit, an satcom-WiFi router in an airplane. > > Such a device is present at the edge of the Internet. It obtains a /64 > from a provider (a cellular or an ADSL provider). It then has to make > up other /64s to give others. It cant. > It can't because the cellular or ADSL provider doesn't want the device to be able to. If they did, then they should have no issue with providing multiple and enough /64s to do so, in particular given how cheap /64s are. The IETF facilitating further subdivision of a /64 in this case is purposely facilitating overriding a network operator's policy. It may be miserly or irrational choice, however it isn't an accidental one. That shouldn't be necessary, RFC6177 specifically says that if a site needs more than one subnet, then the site should be given multiple /64s. That's the IETF solution to this problem. Perhaps about the only issue with RFC6177 is that it is written as though a site is always physical location like a home, rather than being a bit more general and saying that a "site' is the edge of a downstream multi-subnet domain (e.g., the cellular phone case). There are of course possible work arounds, e.g., race to the bottom subdividing, NAPT etc. Developing those options is not a good spend of IETF time because there's a much cheaper and existing option - give out enough /64s to facilitate multiple downstream subnets. > That's the problem of growth at the edges. > A single /64 is purposely preventing growth at the edges. > This problem is made worse by current technical difficulties in using > DHCPv6 and DHCPv6-PD, like lack of interoperability. > > This problem has a counterpart problem that is a 'race to the bottom'. > > (a few people's ideas are in what I write above) > > [...] >> >> I think the following more accurately conveys the true nature of the IPv= 6 >> architecture in regards to IIDs; >> >> Several components of IPv6 architecturally require Unicast Addresses wit= h >> fixed length Interface Identifiers that are 64 bits long, except >> addresses that start with the binary value 000, primary of these is >> Stateless Address Autoconfiguration (SLAAC) [RFC4862], other examples >> are discussed in [RFC7421]. Whereas other components of IPv6 are >> explicitly designed operate with Interface Identifiers of any length, >> Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast >> routing [RFC7608] are examples of these. Therefore, the use of 64 bit >> Interface Identifiers are recommended to ensure all components of >> IPv6 operate as designed. However, there are several situations where >> Interface Identifiers of other lengths can safely be used, these >> include loopback interfaces, point-to-point router links [RFC6164], >> and links where all nodes are configured manually or with DHCPv6. >> Although, links with any nodes that are configured with SLAAC require >> 64 bit Interface Identifiers. >> >> What do others think? > > > The paragraph above makes sense in itself. But is it a problem > statement, or is it a solution to add in the rfcbis? > > Alex > >> >> -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Da= vid Farmer >> Email:farmer@umn.edu Networking & >> Telecommunication Services Office of Information Technology University o= f >> Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis,= MN >> 55414-3029 Cell: 612-812-9952 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> -------------------------------------------------------------------- >> 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 Mon Jul 17 00:14:53 2017 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 3BFC8131A57 for ; Mon, 17 Jul 2017 00:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLAP2oQFX2xj for ; Mon, 17 Jul 2017 00:14:37 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210F9131945 for ; Mon, 17 Jul 2017 00:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500275675; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=IMZPeW2FLShRd80bC5T8W56T8kfh76AD/SKMHBpCj5Y=; b=AwD6NtbfkCWbI0PJSENZF+NRcK7YmUJRFUoTCQ9+/1zsuNoftbPcYR7jNVmt8S195LOucabVGU3lC2LxFzlthqPZGY3yKAQ9hHqOPNLtfjRSKRkP4FzvLFqpXgO+Zy0jD0JQm/Sfon8N0hIYwOHLfgUzGKO1hdi/AChLp8NxP9Q= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0085.outbound.protection.outlook.com [94.245.120.85]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-111-r-3mf1IpMTWh74L4iXGkyg-1; Mon, 17 Jul 2017 08:14:32 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB466.eurprd07.prod.outlook.com (10.242.113.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 07:14:30 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 07:14:30 +0000 From: Tim Chown To: Timothy Winters CC: Brian E Carpenter , 6man Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Index: AQHS9BbBUsATtgvuN0uZCK2ByUXQ5KJV6YYAgABIVACAAXqJAA== Date: Mon, 17 Jul 2017 07:14:29 +0000 Message-ID: References: <149909644776.22718.16227939850699261560@ietfa.amsl.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.3273) x-originating-ip: [2001:67c:370:128:dc18:2a6:55aa:6261] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB466; 20:nJePnn+4x3pYSUDeEQ+wqNNAViZ8XWMNBDAcW1RiGW5GfJL7nebHokvD5Y1WMdXqlh1uEVMqJGi3zgMgwdZSG17n3x9JrCaOgoBxWlUVTXxxpTM+YNhg96joYoQIB03JjpbGqeeSoirgocLsa3J85y4iCOD6CjKx3yXdUGmAeQc= x-ms-office365-filtering-correlation-id: eb92ea90-46bc-467b-1556-08d4cce3777b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB466; x-ms-traffictypediagnostic: AM3PR07MB466: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(278428928389397)(236129657087228)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB466; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB466; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(24454002)(377454003)(51914003)(57704003)(42882006)(7736002)(8936002)(50226002)(189998001)(1720100001)(2900100001)(81166006)(2906002)(6116002)(102836003)(3660700001)(76176999)(33656002)(8676002)(82746002)(74482002)(50986999)(3280700002)(966005)(14454004)(5660300001)(72206003)(99286003)(39060400002)(6246003)(2171002)(38730400002)(110136004)(53366004)(53376002)(2950100002)(36756003)(230783001)(6486002)(57306001)(6506006)(229853002)(478600001)(6916009)(53546010)(86362001)(54906002)(6436002)(6512007)(305945005)(25786009)(53936002)(6306002)(5250100002)(83716003)(4326008)(493534005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB466; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <44F6CA5C29D0234FB160CF197F931BF0@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 07:14:29.9655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB466 X-MC-Unique: r-3mf1IpMTWh74L4iXGkyg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:14:40 -0000 SGksDQoNCkluLWxpbmUuLi4NCg0KPiBPbiAxNiBKdWwgMjAxNywgYXQgMDk6MjUsIFRpbW90aHkg V2ludGVycyA8dHdpbnRlcnNAaW9sLnVuaC5lZHU+IHdyb3RlOg0KPiANCj4gSGkgQnJpYW4sDQo+ IA0KPiBPbiBTdW4sIEp1bCAxNiwgMjAxNyBhdCAxMjowNiBBTSwgQnJpYW4gRSBDYXJwZW50ZXIg PGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gU29tZSBj b21tZW50cywgYnV0IG5vdCBhIGZ1bGwgcmV2aWV3Og0KPiANCj4gPiAgICAtICBJUHY2IG92ZXIg QVRNIE5ldHdvcmtzIFtSRkMyNDkyXQ0KPiANCj4gSXMgdGhpcyBzdGlsbCB3b3J0aCBtZW50aW9u aW5nPw0KPiANCj4gUHJvYmFibHkgbm90LCB3ZSdsbCByZW1vdmUgdGhpcyBpbiB0aGUgbmV4dCBk cmFmdC4gIEhvdyBkbyB5b3UgZmVlbCBhYm91dCBGcmFtZSBSZWxheT8NCg0KQXQgcHJlc2VudCBp dCBzZWVtcyB3ZeKAmWxsIGxlYXZlIHRoYXQgaW4uDQoNCj4gPiAgICAtICBJUCB2ZXJzaW9uIDYg b3ZlciBQUFAgW1JGQzUwNzJdDQo+ID4NCj4gPiAgICBJbiBhZGRpdGlvbiB0byB0cmFkaXRpb25h bCBwaHlzaWNhbCBsaW5rLWxheWVycywgaXQgaXMgYWxzbyBwb3NzaWJsZQ0KPiA+ICAgIHRvIHR1 bm5lbCBJUHY2IG92ZXIgb3RoZXIgcHJvdG9jb2xzLiAgRXhhbXBsZXMgaW5jbHVkZToNCj4gDQo+ IFNob3VsZG4ndCBQUFAgYmUgaW4gdGhpcyBsaXN0LCBub3QgdGhlIHByZXZpb3VzIGxpc3Q/DQo+ IFllcy4gDQo+IA0KPiA+ICAgIC0gIFRlcmVkbzogVHVubmVsaW5nIElQdjYgb3ZlciBVRFAgdGhy b3VnaCBOZXR3b3JrIEFkZHJlc3MNCj4gPiAgICAgICBUcmFuc2xhdGlvbnMgKE5BVHMpIFtSRkM0 MzgwXQ0KPiA+DQo+ID4gICAgLSAgU2VjdGlvbiAzIG9mICJCYXNpYyBUcmFuc2l0aW9uIE1lY2hh bmlzbXMgZm9yIElQdjYgSG9zdHMgYW5kDQo+ID4gICAgICAgUm91dGVycyIgW1JGQzQyMTNdDQo+ ID4NCj4gPiAgICAqKkJJUyBEbyB3ZSB3YW50IGEgc21hbGwgc2VjdGlvbiBzb21ld2hlcmUgb24g VURQIElQdjYgdHVubmVsaW5nLCBhbmQNCj4gPiAgICBpc3N1ZXMgbGlrZSBSRkMgNjkzNSwgb3Ig NjkzNj8qKg0KPiANCj4gTWF5YmUuIEJ1dCB0aGUgZmllbGQgaXMgZXZvbHZpbmc6IFRlcmVkbyBp cyBzdXJlbHkgb2Jzb2xlc2NlbnQsIHRoZXJlJ3MNCj4gYWxzbyBUU1AgKFJGQzU1NzIpLCBhbmQg ZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZSBpcyBpbiBwcm9ncmVzcy4gU28gSSB3b25kZXINCj4gd2hh dCB5b3UgY2FuIHJlYWxseSBzYXkuDQoNClNvIEkgdGhpbmsgd2XigJlsbCBub3QgYWQgdGV4dCBo ZXJlLg0KDQo+ID4gNS4xLiAgSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2IC0gUkZDIDI0NjAN Cj4gPg0KPiA+ICAgIFRoZSBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgaXMgc3BlY2lmaWVk IGluIFtSRkMyNDYwXS4gIFRoaXMNCj4gPiAgICBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgc3VwcG9y dGVkLg0KPiA+DQo+ID4gICAgKipCSVMgQWdhaW4sIHVwZGF0ZSBmb3IgUkZDIDI0NjAgLWJpcyAq Kg0KPiA+DQo+ID4gICAgQW55IHVucmVjb2duaXplZCBleHRlbnNpb24gaGVhZGVycyBvciBvcHRp b25zIE1VU1QgYmUgcHJvY2Vzc2VkIGFzDQo+ID4gICAgZGVzY3JpYmVkIGluIFJGQyAyNDYwLg0K PiANCj4gQXMgd2VsbCBhcyBzLzI0NjAvODIwMC8sIEkgc3VnZ2VzdCBzL3Byb2Nlc3NlZC90cmVh dGVkLyB0byBhdm9pZCBhbm90aGVyDQo+IGRlYmF0ZSBhYm91dCB0aGUgbWVhbmluZyBvZiAncHJv Y2Vzc2VkJyA7LSkuDQo+IA0KPiAoQW5kIGRvbid0IGZvcmdldCBzLzE5ODEvODIwMS8uKQ0KPiBU aGFua3MsIHdlJ2xsIG1ha2UgYWxsIHRob3NlIHVwZGF0ZXMuIA0KPiANCj4gPiA1LjcuICBJUHY2 IEp1bWJvZ3JhbXMgLSBSRkMgMjY3NQ0KPiAuLi4NCj4gPiAgICAgYW5kIHRoZXJlIGlzIGVzc2Vu dGlhbGx5IG5vIHJlcG9ydGVkIGV4cGVyaWVuY2UgZnJvbSB1c2FnZS4NCj4gPiAgICBDb25zZXF1 ZW50bHksIElQdjYgSnVtYm9ncmFtcyBbUkZDMjY3NV0gcmVtYWluIG9wdGlvbmFsIGF0IHRoaXMg dGltZS4NCj4gPg0KPiA+ICAgICoqQklTIEFyZSB0aGVzZSB1c2VkPyAgRG8gd2UgbmVlZCB0byBt b2RpZnkgdGhlIHRleHQgZm9yIHRoYXQ/ICoqDQo+IA0KPiBJIGRvbid0IHRoaW5rIHNvLiBUaGV5 IGFwcGVhciB0byBiZSBoYXJtbGVzcyBhbmQgbWF5YmUgc29tZWJvZHkgd2lsbA0KPiBuZWVkIHRo ZW0gb25lIGRheSwgc28gdGhlcmUgaXMgbm8gb2J2aW91cyBhcmd1bWVudCBmb3IgZGVwcmVjYXRp b24uDQo+IEssIHdlJ2xsIHJlbW92ZSB0aGUgbm90ZS4gDQo+IA0KPiA+IDUuMTAuICBGaXJzdC1I b3AgUm91dGVyIFNlbGVjdGlvbiAtIFJGQyA4MDI4DQo+IC4uLg0KPiA+ICAgIEhvc3RzIHRoYXQg bWF5IGJlIGRlcGxveWVkIGluIHN1Y2ggbXVsdGlob21lZCBlbnZpcm9ubWVudHMgU0hPVUxEDQo+ ID4gICAgZm9sbG93IHRoZSBndWlkYW5jZSBnaXZlbiBpbiBbUkZDODAyOF0uDQo+IA0KPiBXaGlj aCBzaG91bGQgdGhlcmVmb3JlIGJlIGxpc3RlZCBhcyBhIE5vcm1hdGl2ZSByZWZlcmVuY2UuDQo+ IFRoYW5rcywgd2UnbGwgdXBkYXRlIHRoYXQgdG8gTm9ybWF0aXZlLiANCj4gDQo+ID4gNi4xLiAg SVAgVmVyc2lvbiA2IEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlIC0gUkZDIDQyOTENCj4gPg0KPiA+ ICAgIFRoZSBJUHY2IEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlIFtSRkM0MjkxXSBNVVNUIGJlIHN1 cHBvcnRlZC4NCj4gPg0KPiA+ICAgICoqQklTIFVwZGF0ZSB0byA0MjkxLWJpcyAqKg0KPiANCj4g TWF5YmUgbm90IDotKA0KPiBJIHN0aWxsIGhhdmUgaG9wZS4uLi4uIA0KPiANCj4gPiAgICAqKkJJ UyBBZGQgbm90ZSBvbiBXaHkgLzY0PyAgUkZDIDc0MjEsIGFmdGVyIHRoZSBjb25jbHVzaW9uIG9m IHRoZQ0KPiA+ICAgIFJGQzQyOTEtYmlzIChsZW5ndGh5ISEhKSBkaXNjdXNzaW9ucyBvbiB0aGUg NjQtYml0IElJRCB0b3BpYy4gIEJ1dCBubw0KPiA+ICAgIG5lZWQgZm9yIC8xMjcgcDJwIHRleHQg UkZDIDYxNjQuICBBbmQgbm8gbmVlZCBmb3Igbm90ZSBvbiBJSUQNCj4gPiAgICBzaWduaWZpY2Fu Y2UsIGFzIHBlciBSRkMgNzEzNi4gKioNCj4gDQo+IEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIG1l bnRpb24gUkZDIDc0MjEgaGVyZSBhdCBhbGwuIElmIDQyOTFiaXMgZ2V0cw0KPiBwdWJsaXNoZWQs IGl0IHdpbGwgYmUgbWVudGlvbmVkIHRoZXJlLiBJZiBpdCBkb2Vzbid0IGdldCBwdWJsaXNoZWQs DQo+IDY0IHJlbWFpbnMgZml4ZWQgYW55d2F5Lg0KPiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4g DQoNClllcywgd2XigJlsbCBsZWF2ZSBpdCBhIGxpdHRsZSB3aGlsZSB0byBzZWUgaG93IDQyOTEt YmlzIHBhbnMgb3V0Lg0KDQo+ID4gNi4zLiAgSVB2NiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29u ZmlndXJhdGlvbiAtIFJGQyA0ODYyDQo+ID4NCj4gPiAgICBIb3N0cyBNVVNUIHN1cHBvcnQgSVB2 NiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBhcw0KPiA+ICAgIGRlZmluZWQg aW4gZWl0aGVyIFtSRkM0ODYyXSBvciBbUkZDNzIxN10uDQo+IA0KPiBUaGF0J3Mgd3JvbmcsIHN1 cmVseT8gU0xBQUMgaXMgZGVmaW5lZCBpbiA0ODYyLCBhbmQgNzIxNyBkb2Vzbid0IGV2ZW4NCj4g Zm9ybWFsbHkgdXBkYXRlIGl0LiBJIHRoaW5rIHlvdSBzaG91bGQgc2ltcGx5IGRlbGV0ZSAnb3Ig W1JGQzcyMTddJy4NCj4gDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCwNCj4gPiAgICB1bmxlc3MgdGhlcmUgaXMg YSBzcGVjaWZpYyByZXF1aXJlbWVudCBmb3IgTUFDIGFkZHJlc3NlcyB0byBiZQ0KPiA+ICAgIGVt YmVkZGVkIGluIGFuIElJRCwgbm9kZXMgZm9sbG93IHRoZSBwcm9jZWR1cmUgaW4gUkZDNzIxNyB0 byBnZW5lcmF0ZQ0KPiA+ICAgIFNMQUFDLWJhc2VkIGFkZHJlc3Nlcy4NCj4gDQo+IFRoYXQgb25s eSBhcHBsaWVzIGlmIGEgc3RhYmxlIElJRCBpcyB3YW50ZWQuICBJIHdvdWxkIHN1Z2dlc3Q6DQo+ IA0KPiBJdCBpcyByZWNvbW1lbmRlZCB0aGF0LA0KPiB1bmxlc3MgdGhlcmUgaXMgYSBzcGVjaWZp YyByZXF1aXJlbWVudCBmb3IgTUFDIGFkZHJlc3NlcyB0byBiZQ0KPiBlbWJlZGRlZCBpbiBhbiBJ SUQsIG5vZGVzIGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNzIxN10NCj4gb3IgW1JGQzQ5 NDFdIChzZWUgYmVsb3cpIHRvIGdlbmVyYXRlIFNMQUFDLWJhc2VkIGFkZHJlc3Nlcy4NCj4gDQo+ IChJIHRoaW5rIHdlJ3ZlIGFscmVhZHkgZXN0YWJsaXNoZWQgdGhhdCBpdCdzIHBvc3NpYmxlIHRv IG9wZXJhdGUNCj4gYSBub2RlIHRoYXQgaGFzIG5vIHN0YWJsZSBnbG9iYWwtc2NvcGUgYWRkcmVz cy4pDQo+IE9LLCB0aGlzIHRleHQgbG9va3MgZmluZSB0byBtZS4gDQoNCk9yIHdlIGNvdWxkIGp1 c3QgcG9pbnQgYXQgUkZDODA2ND8NCg0KPiA+IDYuNi4gIERlZmF1bHQgQWRkcmVzcyBTZWxlY3Rp b24gZm9yIElQdjYgLSBSRkMgNjcyNA0KPiA+DQo+ID4gICAgSVB2NiBub2RlcyB3aWxsIGludmFy aWFibHkgaGF2ZSBtdWx0aXBsZSBhZGRyZXNzZXMgY29uZmlndXJlZA0KPiA+ICAgIHNpbXVsdGFu ZW91c2x5LCBhbmQgdGh1cyB3aWxsIG5lZWQgdG8gY2hvb3NlIHdoaWNoIGFkZHJlc3NlcyB0byB1 c2UNCj4gPiAgICBmb3Igd2hpY2ggY29tbXVuaWNhdGlvbnMuICBUaGUgcnVsZXMgc3BlY2lmaWVk IGluIHRoZSBEZWZhdWx0IEFkZHJlc3MNCj4gPiAgICBTZWxlY3Rpb24gZm9yIElQdjYgW1JGQzY3 MjRdIGRvY3VtZW50IE1VU1QgYmUgaW1wbGVtZW50ZWQuDQo+IA0KPiBJIGFtIGNvbmNlcm5lZCBh Ym91dCB0aGUgZmFtb3VzIHJ1bGUgNS41IGluIFJGQzY3MjQuIEl0J3Mgb3B0aW9uYWwgdGhlcmUs DQo+IGJ1dCBlbHNld2hlcmUgeW91IGhhdmUgYSBTSE9VTEQgZm9yIFJGQzgwMjgsIHdob3NlIHNl Y3Rpb24gMy4zIGluIHR1cm4NCj4gcHJvbW90ZXMgcnVsZSA1LjUgdG8gYSBTSE9VTEQuIENvdWxk IHdlIGFkZCB0aGF0IHByb21vdGlvbiBoZXJlDQo+IHRvbz8gT3RoZXJ3aXNlIHRoZXJlIGlzIGEg Y29tcGxpY2F0ZWQgdHJhaWwgZm9yIGltcGxlbWVudGVycyB0byBmb2xsb3cuDQo+IEkgbGlrZSB0 aGlzIGlkZWEsIGhvdyBhYm91dC4NCj4gDQo+IFNpbmNlIFJGQyA4MDI4IHVwZGF0ZXMgcnVsZSA1 LjUgZnJvbSBSRkMgNjcyNCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGltcGxlbWVudCB0aGlzIHJ1 bGUuIA0KPiANCj4gPiAxNC4gIFJvdXRlci1TcGVjaWZpYyBGdW5jdGlvbmFsaXR5DQo+IA0KPiBJ IHRoaW5rIHlvdSBzaG91bGQgcmVxdWlyZSBCQ1AxOTggKFJGQzcwNjgpIHN1cHBvcnQuDQo+IElu dGVyZXN0aW5nIHRob3VnaHQgKHNob3VsZCBiZSBSRkM3NjA4KS4gICBJIGRvbid0IGhhdmUgYSBw cm9ibGVtIGFkZGluZyB0aGlzLCBJJ2xsIGNoZWNrIHdpdGggdGhlIGNvLWF1dGhvcnMuIA0KDQpO byBwcmVmZXJlbmNlIGVpdGhlciB3YXkgaGVyZS4NCg0KVGhhbmtzIEJyaWFuLA0KVGltDQoNCj4g DQo+IFJlZ2FyZHMNCj4gICAgICBCcmlhbg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2 IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3Ry YXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiAtLSANCj4gTm93IG9mZmVyaW5nIHRlc3Rp bmcgZm9yIFNETiBhcHBsaWNhdGlvbnMgYW5kIGNvbnRyb2xsZXJzIGluIG91ciBTRE4gc3dpdGNo IHRlc3QgYmVkLiBMZWFybiBtb3JlIHRvZGF5IGh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4g aXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Mon Jul 17 00:34:16 2017 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 34C59131945; Mon, 17 Jul 2017 00:34:15 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8Fne6MuW2-ZY; Mon, 17 Jul 2017 00:34:08 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 3E23D131A81; Mon, 17 Jul 2017 00:34:08 -0700 (PDT) X-AuditID: 60721c4c-fe5ff70000004e62-c4-596c686d8504 Received: from VAADCEX09.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D9.F2.20066.D686C695; Mon, 17 Jul 2017 03:34:07 -0400 (EDT) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX09.cable.comcast.com (147.191.102.76) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 03:34:04 -0400 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 17 Jul 2017 03:34:04 -0400 From: "Brzozowski, John" To: "draft-jjmb-v6ops-ietf-ipv6-only-incremental@ietf.org" , "ipv6@ietf.org" CC: Randy Bush , Alissa Cooper , Jim Martin , Jari Arkko , Suresh Krishnan , Russ Housley Subject: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings Thread-Topic: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for IETF Meetings Thread-Index: AQHS/s8RI63z6gNZjUSFIuX2qo9vvQ== Date: Mon, 17 Jul 2017 07:34:04 +0000 Message-ID: <2614FBAF-5142-4D0F-AF6F-74BCBB09EC46@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.252] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11UbUxbVRjOuf26VM683NL2UAsbd8HEDwoqmutHcD9m0sU16paodcnWS3vX Vi4t6W1h6A+Jzpi1JAPD6NYR1IWZfcKiI25kTFY7tSjiR5zZl4as0VFNBjIFXCTe097Crb/6 nuc57/s879OTS6roI3oL6Q+E+VCAExitXu0SN7G1QZ/grB/6GLLxr/8FbHSaYbM3L+vYmclb BLv//BEteymlYn99e4ZgU6cmNRtI++3MDGGPzv1A2M8mruvsg4NLhH1kMK617ztwENiPXbut eV73iv4pDy/42/hQXaNL75sd2KNp7a/bdeOtcW0n6LRFQQmJqAZ0cm5eGwV6kqY+IdBiz5R8 GAdo4laPJn9IA9Tz4XUVbtFSj6HTF67qMFFO9QE00H2VwAcVdRmgzOE+Db5loLag4dhFEAWk dOslND9qxXA5ZUO/vXNFi2s1VYOmTvTrcA2pjWho+UJOAFAmtDBxgsC1ijKjK5n3iLxXCg2e m1LlayOaubGckzJKMy/NHlXn8QfR5E8ZkK/r0cjh8zJejZYPDquxHRV1HxoercuPfwKdnB9Q 5+tq1Bublu2UofSBjNxqRp+lzmi6QUVC4SixOimhmJRQTEooJr0PNMdAVRvHedwtvmAkXP+w zc01CbzNHWxxc2IY/34E8HMIWTefAX/22ZOAIgFTClWc4KQ1XJvY0ZIEzSTBGOF32mYnvaYp 6OnwcaJvRygi8CJTDrUe6SZcgZsiQjNjgY0YNaygAb5dFPiw9P6YKngIDzKvcGJEbPW7/cGI uCMSEpIAkSppbNdWPNbDdbzGh4J5sSS4h1QzZnjv2VedNOXlwnwzz7fyoQLbTpIMguu9UmNZ iPfyu3b6hXCBlvoWH5AYSsnkzFZCNuV30iYlofBbDZ/EtEVJ/98yQZYkgZcslXz/wmPfYivX Ivq9srQBOnCcpQU0J1sBl/BVugAqJCvhizopIlOBKpabADFAJvYv/U2Qp+98uUDQ6kAwwFvM cNtOvB9u8kUCK4tbTDD9gstJ360gsAGLFXZh3KjAVz1Y1sGbmK1QsMU2Cl+RLHBLL8YAl7F6 qfSNWd2bho/gP+MuGcytjeA3+GmUyZhiayt04q2NMlOslpXiJaR4DY5cvGEurIz3miMXr4zK 8X7vyMUrg0XxxjFlKlDFSpZO8G23ZYuj1vBmV8fY3obdm9dOZx9X+5/+a019Sdbzz9o72vGh 3fC4+7nKVNu2xk0u2lfl2v5Btstm/TRztDb6THxutOZHbjbGZr7yvsueu/j5o4cW/3i5Jl2b tn2xVXhj39yYEG/Yvk7zuqe3fuPPe9tpw6nfYwt7mp7dQDWOjfT3Vo8xatHHPXS/KiRy/wEn 0izfuwUAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:34:15 -0000 QXBvbG9naWVzLCBJIHVuZGVyc3RhbmQgdGhpcyBtYWlsIGRpZCBub3QgbWFrZSBpdCB0byB0aGUg dmFyaW91cyBsaXN0cy4NCg0KSm9obg0KKzEtNDg0LTk2Mi0wMDYwDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIEJyem96b3dza2kgPEpvaG5fQnJ6b3pvd3NraUBDYWJs ZS5Db21jYXN0LmNvbT4NCkRhdGU6IFN1bmRheSwgSnVseSAxNiwgMjAxNyBhdCAyMDoyOA0KVG86 ICJkcmFmdC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsQGlldGYub3JnIiA8 ZHJhZnQtamptYi12Nm9wcy1pZXRmLWlwdjYtb25seS1pbmNyZW1lbnRhbEBpZXRmLm9yZz4NCkNj OiBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3Bl cncuaW4+LCBKaW0gTWFydGluIDxqaW1AZGFlZGVsdXMuY29tPiwgSmFyaSBBcmtrbyA8amFyaS5h cmtrb0BwaXVoYS5uZXQ+LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5j b20+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KU3ViamVjdDogSW5jcmVt ZW50YWwgRGVwbG95bWVudCBvZiBJUHY2LW9ubHkgV2ktRmkgZm9yIElFVEYgTWVldGluZ3MNCg0K ICAgIEZvbGtzLA0KICAgIA0KICAgIEFwb2xvZ2llcyBpbiBhZHZhbmNlIGZvciB0aGUgZ3JhdHVp dG91cyBjcm9zcyBwb3N0aW5nICh2Nm9wcywgaWV0ZiwgaXB2Niwgc3Vuc2V0NCwgc29mdHdpcmVz KS4gIEkgaG9wZSwgdG8geW91IGFsbCwgdGhpcyBpcyB3b3J0aCB0aGUgYWRkZWQgZW1haWwuDQog ICAgDQogICAgVGhlIGRyYWZ0IGJlbG93IHdhcyB3cml0dGVuIHRvIHByb3ZpZGUgdGhlIG5lY2Vz c2FyeSBkb2N1bWVudGF0aW9uIHRvIGVuYWJsZSB0aGUgSUVURiAodGhlIE5PQywgcGFydGljaXBh bnRzLCBldGMuKSB0byBtaWdyYXRlIHRvIGFuIElQdjYgb25seSBwcmltYXJ5IG5ldHdvcmsgY29u bmVjdGlvbiAoV2ktRmkgYW5kIHdpcmVkKSB0aGF0IHV0aWxpemVzIE5BVDY0K0ROUzY0IHRvIGFj Y2VzcyBJUHY0IG9ubHkgY29udGVudC4gIFRoZSByZXF1ZXN0IGZvciBJRVRGIDk5IGhhcyBiZWVu IHRvIGhhdmUgdGhlIHByaW1hcnkg4oCcaWV0ZuKAnSBTU0lEIGFkaGVyZSB0byB3aGF0IGlzIGRv Y3VtZW50ZWQgaW4gdGhlIEktRCBiZWxvdy4gIEkgdHJ1c3QgdGhlIG1vdGl2YXRpb24gaXMgdW5k ZXJzdG9vZC4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgbWFpbiDigJxpZXRm4oCdIFNTSUQgd291bGQg YmUgc3dpdGNoZWQgdG8gYmUgSVB2NiBvbmx5IHdpdGggTkFUNjQrRE5TNjQgKGF0IGxheWVyIDMp IHBlciB0aGUgSS1EIGJlbG93LiAgR2l2ZW4gdGhlIHRoYXQgSUVURjk5IGlzIHVwb24gdXMsIHRo aXMgbWF5IG9yIG1heSBub3QgYmUgZW50aXJlbHkgcG9zc2libGUuDQogICAgDQogICAgQXQgdGhp cyBzdGFnZSwgdGhlIGluZnJhc3RydWN0dXJlIHByZXBhcmF0aW9ucyBmb3IgSUVURiA5OSBzaG91 bGQgYmUgaW4gcGxhY2UgdG8gZW5zdXJlIHRoYXQgdGhlIElFVEYgaGFzIHRoZSBuZWNlc3Nhcnkg aGFyZHdhcmUgZm9yIHJlZHVuZGFuY3kgYW5kIHBlcmZvcm1hbmNlLg0KICAgIA0KICAgIFNvLCB3 ZSBhcmUgYWxsIHNlZWtpbmcgeW91ciBpbnB1dC4gIEdpdmVuIHRoZSBhYm92ZSwgd2hhdCB3b3Vs ZCBhbGwgeW91IHN1Z2dlc3QgaXMgdG9sZXJhYmxlIGZvciBJRVRGOTkgYXMgaXQgcGVydGFpbnMg dG8gdGhlIEktRCBiZWxvdz8NCiAgICANCiAgICDigKIgSVB2NiBvbmx5IHBlciB0aGUgSS1EIGZv ciB0aGUgYmFsYW5jZSBvZiBJRVRGIHdlZWs/DQogICAg4oCiIElQdjYgb25seSBwZXIgdGhlIEkt RCBmb3Igb25lIG9yIG1vcmUgZGF5cyB0aGlzIHdlZWs/DQogICAg4oCiIElQdjYgb25seSBwZXIg dGhlIEktRCBmb3IgdGhlIHBsZW5hcnk/DQogICAg4oCiIElQdjYgb25seSBwZXIgdGhlIEktRCBm b3IgdGhlIG5leHQgSUVURiBtZWV0aW5nPw0KICAgIA0KICAgIFBsZWFzZSBzZW5kIHVzIHlvdXIg ZmVlZGJhY2suDQogICAgDQogICAgUmVnYXJkcywNCiAgICANCiAgICBKb2huDQogICAgKzEtNDg0 LTk2Mi0wMDYwDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9t OiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K ICAgIERhdGU6IFNhdHVyZGF5LCBKdWx5IDEsIDIwMTcgYXQgMDM6MDQNCiAgICBUbzogTWFyY3Vz IEtlYW5lIDxtYXJjdXMua2VhbmVAbWljcm9zb2Z0LmNvbT4sIEplbiBMaW5rb3ZhIDxmdXJyeUBn b29nbGUuY29tPiwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+LCBKb2huIEJy em96b3dza2kgPEpvaG5fQnJ6b3pvd3NraUBDYWJsZS5Db21jYXN0LmNvbT4sIEVyaWsgS2xpbmUg PGVrQGdvb2dsZS5jb20+LCBKb2huIEJyem96b3dza2kgPEpvaG5fQnJ6b3pvd3NraUBDYWJsZS5D b21jYXN0LmNvbT4sIERhdmlkIFNjaGluYXppIDxkc2NoaW5hemlAYXBwbGUuY29tPiwgU3R1YXJ0 IENoZXNoaXJlIDxjaGVzaGlyZUBhcHBsZS5jb20+LCBKZW4gTGlua292YSA8ZnVycnlAZ29vZ2xl LmNvbT4sIFBhdWwgU2FhYiA8cHNAZmIuY29tPiwgRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aUBh cHBsZS5jb20+DQogICAgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsLTAwLnR4dA0KICAgIA0KICAg ICAgICANCiAgICAgICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpqbWItdjZvcHMtaWV0 Zi1pcHY2LW9ubHktaW5jcmVtZW50YWwtMDAudHh0DQogICAgICAgIGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSm9obiBKYXNvbiBCcnpvem93c2tpIGFuZCBwb3N0ZWQgdG8gdGhl DQogICAgICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICAgICAgDQogICAgICAgIE5hbWU6CQlkcmFm dC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsDQogICAgICAgIFJldmlzaW9u OgkwMA0KICAgICAgICBUaXRsZToJCUluY3JlbWVudGFsIERlcGxveW1lbnQgb2YgSVB2Ni1vbmx5 IFdpLUZpIGZvciBJRVRGIE1lZXRpbmdzDQogICAgICAgIERvY3VtZW50IGRhdGU6CTIwMTctMDYt MzANCiAgICAgICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICAgICAgUGFnZXM6 CQkxNQ0KICAgICAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWpqbWItdjZvcHMtaWV0Zi1pcHY2LW9ubHktaW5jcmVtZW50YWwtMDAu dHh0DQogICAgICAgIFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1qam1iLXY2b3BzLWlldGYtaXB2Ni1vbmx5LWluY3JlbWVudGFsLw0KICAgICAg ICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpqbWIt djZvcHMtaWV0Zi1pcHY2LW9ubHktaW5jcmVtZW50YWwtMDANCiAgICAgICAgSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtamptYi12Nm9w cy1pZXRmLWlwdjYtb25seS1pbmNyZW1lbnRhbC0wMA0KICAgICAgICANCiAgICAgICAgDQogICAg ICAgIEFic3RyYWN0Og0KICAgICAgICAgICBUaGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50IGlz IHRvIHByb3ZpZGUgYSBibHVlcHJpbnQgYW5kIGd1aWRhbmNlDQogICAgICAgICAgIGZvciBkZXBs b3lpbmcgSVB2Ni1vbmx5IFdpLUZpIGF0IElFVEYgbWVldGluZ3MuICBUaGlzIGRvY3VtZW50DQog ICAgICAgICAgIG91dGxpbmVzIGluZnJhc3RydWN0dXJlIGFuZCBvcGVyYXRpb25hbCBndWlkYW5j ZSB0aGF0IG9wZXJhdG9ycw0KICAgICAgICAgICBzaG91bGQgY29uc2lkZXIgd2hlbiBkZXBsb3lp bmcgSVB2Ni1vbmx5IG5ldHdvcmtzIHVzaW5nIE5BVDY0IGFuZA0KICAgICAgICAgICBETlM2NCB0 byBzdXBwb3J0IGNvbW11bmljYXRpb24gdG8gbGVnYWN5IElQdjQtb25seSBzZXJ2aWNlcy4NCiAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgDQogICAg ICAgIA0KICAgICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgICAgIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQog ICAgICAgIA0KICAgICAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgICAgICANCiAgICAgICAg DQogICAgICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Mon Jul 17 02:00:50 2017 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 3D3C812EB5F for ; Mon, 17 Jul 2017 02:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0-vrYVbrxjJ for ; Mon, 17 Jul 2017 02:00:46 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C671612EA7C for ; Mon, 17 Jul 2017 02:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500282044; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=Mvif31SSPVwhvT6BBJsBeoVUjv1Dy+sxPzAt9MlIFPs=; b=EdyFxnXtFzLIFsWyaLIgS2J7yZY+qCFwhADqXsuxE6Huh2CHHPKU44nPtscX+Dkvb9uAB1YKvY4WMWJ8VnipHmVfMHQ4pj0Q3/qg2Of+qxVb0Kz9QCnnwq1KNQvVfLtRP7/DBoZrFfONHs24t/Bc/pbmx4o6aDiGNkgY6KbFwN0= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0079.outbound.protection.outlook.com [94.245.120.79]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-130-qz1GbzUrNraeRge-71xBZA-1; Mon, 17 Jul 2017 10:00:36 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1204.eurprd07.prod.outlook.com (10.163.188.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 09:00:35 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 09:00:35 +0000 From: Tim Chown To: "STARK, BARBARA H" CC: IETF IPv6 Mailing List Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Topic: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt Thread-Index: AQHS9BbBUsATtgvuN0uZCK2ByUXQ5KJWRHuAgAAeRYCAAAFwAIAAN0sAgAC654CAAHe7gA== Date: Mon, 17 Jul 2017 09:00:34 +0000 Message-ID: References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <596B4BE1.7020807@foobar.org> <2D09D61DDFA73D4C884805CC7865E6114DBCB6A8@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBCB6A8@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:370:128:21ec:8d4a:5310:e823] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1204; 20:dGuWqkRpfHx35LJ7GB5E4VTLlRfE+4ojDlsD57Tm++UHMNe305OD6OHosh89a2riQvM7gsOMGxIGtabpdOXWeViSsv+PiJRGv4E8hGmViiBG0q1sxSQ7S3XDnpQmeEofioKgYZwHZOX4mA/iIgyf4cx0UiI5ZxwQOIUU2bBGNE4= x-ms-office365-filtering-correlation-id: 5854f6e2-084f-4472-00b1-08d4ccf2495b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1204; x-ms-traffictypediagnostic: AM3PR07MB1204: x-exchange-antispam-report-test: UriScan:(278178393323532)(158342451672863)(133145235818549)(236129657087228)(97927398514766)(211936372134217)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1204; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1204; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39840400002)(39400400002)(24454002)(377454003)(5660300001)(7736002)(478600001)(2950100002)(6916009)(50986999)(2906002)(76176999)(2900100001)(25786009)(50226002)(6246003)(8676002)(42882006)(81166006)(229853002)(4326008)(6506006)(38730400002)(6486002)(86362001)(305945005)(110136004)(8936002)(189998001)(3280700002)(3660700001)(82746002)(33656002)(230783001)(6512007)(93886004)(72206003)(74482002)(53936002)(14454004)(6116002)(102836003)(6436002)(57306001)(53546010)(99286003)(83716003)(36756003)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1204; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 09:00:35.0153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1204 X-MC-Unique: qz1GbzUrNraeRge-71xBZA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 09:00:48 -0000 SGksDQoNCkluLWxpbmUuLi4NCg0KPiBPbiAxNyBKdWwgMjAxNywgYXQgMDI6NTIsIFNUQVJLLCBC QVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPiB3cm90ZToNCj4gDQo+IE9uIFN1biwgSnVsIDE2LCAy MDE3IGF0IDY6MjUgQU0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPiB3cm90 ZToNCj4gT24gU3VuLCBKdWwgMTYsIDIwMTcgYXQgMToyMCBQTSwgTmljayBIaWxsaWFyZCA8bmlj a0Bmb29iYXIub3JnPiB3cm90ZToNCj4gVGhlIHNlbGYtc2VsZWN0aW9uIGFkZHJlc3NpbmcgbW9k ZWwgZG9lcyBub3Qgc3VpdCB0aGUgZGVwbG95bWVudA0KPiByZXF1aXJlbWVudHMgZm9yIG1hbnkg dHlwZXMgb2YgaXB2NiBuZXR3b3JrcywgaW5jbHVkaW5nIGVudGVycHJpc2UsDQo+IHByb3ZpZGVy IGhvc3RpbmcsIHRlcnJlc3RyaWFsIGFjY2VzcyBuZXR3b3JrcyAoZS5nLiBkb2NzaXMgLyBncG9u IC8NCj4gaXBvZSkgYW5kIG90aGVycy4gIElmIHRoZSByZWNvbW1lbmRhdGlvbiBmb3IgZGhjcHY2 IGlzIGRyb3BwZWQsIHRoZW4NCj4gdGhlcmUgaXMgbm8gcmVjb21tZW5kZWQgaWV0ZiBtb2RlbCBm b3Igb3BlcmF0b3ItYXNzaWduZWQgYWRkcmVzc2luZywgYW5kDQo+IHRoaXMgd291bGQgbGVhdmUg YSBnbGFyaW5nIGhvbGUgaW4gdGhlIGlwdjYgaG9zdCBzcGVjaWZpY2F0aW9uLg0KPiAgDQo+IFRo YXQncyBhIGZhaXIgb3BpbmlvbiB0byBob2xkLCBidXQgdGhlIGZhY3Qgb2YgdGhlIG1hdHRlciBp cyB0aGF0IGEgU0hPVUxEIGZvciBESENQdjYgY29uZmxpY3RzIHdpdGggUkZDIDc5MzQgYW5kIFJG QyA3ODQ0Lg0KPiAgDQo+IFdlIHNob3VsZG4ndCBwdWJsaXNoIGEgaG9zdCByZXF1aXJlbWVudHMg ZG9jdW1lbnQgdGhhdCBjb250cmFkaWN0cyB0aGUgaG9zdCBhZGRyZXNzIGFzc2lnbm1lbnQgQkNQ IGFuZCB0aGF0IGNpdGVzIFJGQzc4NDQgd2hpbGUgY29udHJhZGljdGluZyB0aGF0IGRvY3VtZW50 J3MgcmVjb21tZW5kYXRpb24gdG8gdXNlIHN0YXRlbGVzcyBpbiBwcmVmZXJlbmNlIHRvIHN0YXRl ZnVsLg0KPiAgDQo+IExldHMgc3RhcnQgd2l0aCBSRkMgNzkzNCBpdCBpcyBhIHNldCBvZiBSRUNP TU1FTkRBVElPTlMgZm9yIGhvdyBuZXR3b3JrcyBzaG91bGQgc3VwcGx5IGFkZHJlc3NlcyB0byBn ZW5lcmFsIHB1cnBvc2UgaG9zdHMuICBGaXJzdCwgbm90IGV2ZXJ5dGhpbmcgZml0cyBpbnRvIHRo YXQgc2NvcGUgYW5kIGV2ZW4gd2l0aGluIHRoYXQgc2NvcGUgYXMgYSBSRUNPTU1FTkRBVElPTiB0 aGF0IG1lYW5zICJ0aGVyZSBtYXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNp cmN1bXN0YW5jZXMgdG8gaWdub3JlIGEgcGFydGljdWxhciBpdGVtIiBbUkZDMjExOV0uICBTbywg aXQgYnkgbm8gbWVhbnMgcHJlY2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGhvc3RzIGNvdWxk IGZpbmQgdGhlbSBvbiBhIG5ldHdvcmsgdGhhdCBpcyBvbmx5IHByb3ZpZGluZyBhZGRyZXNzZXMg dmlhIERIQ1B2Ni4gVGhlcmVmb3JlLCBhIFNIT1VMRCBmb3IgREhDUHY2IGluIHRoZSBob3N0IHJl cXVpcmVtZW50cyBzdGlsbCBzZWVtcyBhcHByb3ByaWF0ZSB0byBtZS4NCj4gIA0KPiBBcyBmb3Ig UkZDIDc4NDQsIGl0IGlzIHNjb3BlZCB0byBtb2JpbGUgaG9zdHMgdGhhdCB3YW50IHByaXZhY3kg ZnJvbSB0aGUgREhDUCBzZXJ2ZXIsIGFuZCBpdCBzYXlzICJUaGUgYW5vbnltaXR5IHByb2ZpbGVz IGhhdmUgdGhlIGVmZmVjdCBvZiBoaWRpbmcgdGhlIGNsaWVudCBpZGVudGl0eSBmcm9tIHRoZSBE SENQIHNlcnZlci4gIFRoaXMgaXMgbm90IGFsd2F5cyBkZXNpcmFibGUuIC4uLiIgIEEgZG9jdW1l bnQgdGhhdCBpdHNlbGYgcmVjb2duaXplcyBpdCdzIHByaW1hcnkgcHVycG9zZSAiaXMgbm90IGFs d2F5cyBkZXNpcmFibGUiIGV2ZW4gd2l0aGluIGl0J3MgZGVmaW5lZCBzY29wZSwgaXNuJ3QgYSBz dHJvbmcgYXJndW1lbnQgZm9yIGNoYW5naW5nIHRoZSBSRUNPTU1FTkRFRCBiZWhhdmlvciBvZiBh bGwgaG9zdC4gIA0KPiAgDQo+IDxiaHM+ICsxLiBSRkMgNjQzNCBOb2RlIFJlcXVpcmVtZW50cyBh cmUgZ2VuZXJhbC1wdXJwb3NlIGZvciBhbGwgbm9kZXMgb24gYWxsIG5ldHdvcmtzLiBBbmQgc2hv dWxkIHJlbWFpbiBzby4gVGhleSBzaG91bGQgbm90IGJlIHRhaWxvcmVkIHRvIDNHUFAgbmV0d29y a3Mgb3IgbWFzcyBtYXJrZXQgZW5kIHVzZXIgbmV0d29ya3Mgb3IgYW55IG90aGVyIHNwZWNpYWwg bmV0d29yay4gUkZDIDc5MzQgYW5kIDc4NDQgYXJlIG5vdCBmb3IgYWxsIG5vZGVzLiBCVFcsIG1h bnkgd2lyZWxpbmUgYWNjZXNzIG5ldHdvcmtzIGRvIG5vdCBzdXBwb3J0IFNMQUFDIGZvciBhZGRy ZXNzIGFzc2lnbm1lbnQgdG8gdGhlIENFIFJvdXRlci4gV2hpY2ggaXMgd2h5IFJGQyA3MDg0IGV4 aXN0cyAtLSB0byBwcm92aWRlIHNwZWNpZmljIGd1aWRhbmNlIGZvciB0aGF0IHNwZWNpZmljIHVz ZSBjYXNlLiBSRkMgNzA4NCBkb2VzIG5vdCBjb25mbGljdCB3aXRoIFJGQyA2NDM0LiBCZWNhdXNl IGl0cyB1c2UgY2FzZSBpcyBkaXN0aW5jdCBmcm9tIHRoYXQgb2YgUkZDcyA3OTM0IGFuZCA3ODQ0 LCBpdCBkb2VzbuKAmXQgY29uZmxpY3Qgd2l0aCB0aGVtIGVpdGhlci4NCj4gIA0KPiBGdXJ0aGVy LCBhICJyZWNvbW1lbmRhdGlvbiB0byB1c2Ugc3RhdGVsZXNzIGluIHByZWZlcmVuY2UgdG8gc3Rh dGVmdWwiIGlzbid0IGEgcHJvaGliaXRpb24gb24gc3RhdGVmdWwsIFVudGlsLCBzdGF0ZWZ1bCBp cyBwcm9oaWJpdGVkIG9yIGFsbCBuZXR3b3JrcyBhcmUgcmVxdWlyZWQgdG8gcHJvdmlkZWQgc3Rh dGVsZXNzLCBhIFNIT1VMRCBmb3IgREhDUHY2IGluIHRoZSBob3N0IHJlcXVpcmVtZW50cyBzdGls bCBzZWVtcyBhcHByb3ByaWF0ZSB0byBtZS4NCj4gIA0KPiA8YmhzPiArMQ0KDQpUbyBzdXBwb3J0 IEJhcmJhcmHigJlzIGNvbW1lbnRzIGFib3ZlLCBpdCdzIHdvcnRoIG5vdGluZyB0aGF0IFJGQzc4 NDQgaW5jbHVkZXMgZXhjZXB0aW9ucywgc3BlY2lmaWNhbGx5IGluIFNlY3Rpb24gNSwgc3RhdGlu ZyB0aGF0IGFub255bWl0eSBwcm9maWxlcyBhcmUgbm90IGFsd2F5cyBkZXNpcmFibGU6DQoNCjUu ICBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgYW5vbnltaXR5IHByb2ZpbGVz IGhhdmUgdGhlIGVmZmVjdCBvZiBoaWRpbmcgdGhlIGNsaWVudCBpZGVudGl0eQ0KICAgZnJvbSB0 aGUgREhDUCBzZXJ2ZXIuICBUaGlzIGlzIG5vdCBhbHdheXMgZGVzaXJhYmxlLiAgU29tZSBESENQ DQogICBzZXJ2ZXJzIHByb3ZpZGUgZmFjaWxpdGllcyBsaWtlIHB1Ymxpc2hpbmcgbmFtZXMgYW5k IGFkZHJlc3NlcyBpbiB0aGUNCiAgIEROUywgb3IgZW5zdXJpbmcgdGhhdCByZXR1cm5pbmcgY2xp ZW50cyBnZXQgcmVhc3NpZ25lZCB0aGUgc2FtZQ0KICAgYWRkcmVzcy4NCg0KICAgQ2xpZW50cyB1 c2luZyBhbiBhbm9ueW1pdHkgcHJvZmlsZSBtYXkgYmUgY29uc3VtaW5nIG1vcmUgcmVzb3VyY2Vz Lg0KICAgRm9yIGV4YW1wbGUsIHdoZW4gYSBjbGllbnQgY2hhbmdlcyBpdHMgbGluay1sYXllciBh ZGRyZXNzIGFuZA0KICAgcmVxdWVzdHMgYSBuZXcgSVAgYWRkcmVzcywgdGhlIG9sZCBJUCBhZGRy ZXNzIGlzIHN0aWxsIG1hcmtlZCBhcw0KICAgbGVhc2VkIGJ5IHRoZSBzZXJ2ZXIuDQoNCiAgIFNv bWUgREhDUCBzZXJ2ZXJzIHdpbGwgb25seSBnaXZlIGFkZHJlc3NlcyB0byBwcmUtcmVnaXN0ZXJl ZCBNQUMNCiAgIGFkZHJlc3NlcywgZm9yY2luZyBjbGllbnRzIHRvIGNob29zZSBiZXR3ZWVuIHJl bWFpbmluZyBhbm9ueW1vdXMgYW5kDQogICBvYnRhaW5pbmcgY29ubmVjdGl2aXR5Lg0KDQogICBJ bXBsZW1lbnRlcnMgU0hPVUxEIHByb3ZpZGUgYSB3YXkgZm9yIGNsaWVudHMgdG8gY29udHJvbCB3 aGVuIHRoZQ0KICAgYW5vbnltaXR5IHByb2ZpbGVzIGFyZSB1c2VkIGFuZCB3aGVuIHN0YW5kYXJk IGJlaGF2aW9yIGlzIHByZWZlcnJlZC4NCg0KICAgSW1wbGVtZW50ZXJzIE1BWSBpbXBsZW1lbnQg dGhpcyBjb250cm9sIGJ5IHR5aW5nIHRoZSB1c2Ugb2YgdGhlDQogICBhbm9ueW1pdHkgcHJvZmls ZXMgdG8gdGhhdCBvZiBsaW5rLWxheWVyIGFkZHJlc3MgcmFuZG9taXphdGlvbi4NCg0KDQpUaW0= From nobody Mon Jul 17 04:54:17 2017 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 657A2131B3C for ; Mon, 17 Jul 2017 04:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 u0HGBTG9NVhV for ; Mon, 17 Jul 2017 04:54:13 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B0FE512ECC1 for ; Mon, 17 Jul 2017 04:54:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6HBsBf4002793; Mon, 17 Jul 2017 13:54:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F2648202B87; Mon, 17 Jul 2017 13:54:10 +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 E490520138C; Mon, 17 Jul 2017 13:54:10 +0200 (CEST) Received: from [132.166.84.41] ([132.166.84.41]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HBsAM9016142; Mon, 17 Jul 2017 13:54:10 +0200 Subject: Re: 64bit IIDs are both recommended and required To: Mark Smith Cc: 6man WG References: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> From: Alexandre Petrescu Message-ID: <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> Date: Mon, 17 Jul 2017 13:54:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:54:15 -0000 Le 17/07/2017 à 07:48, Mark Smith a écrit : > On 17 July 2017 at 15:14, Alexandre Petrescu > wrote: >> Le 15/07/2017 à 19:54, David Farmer a écrit : >> [...] >>> >>> Also a problem statement was asked for, and I think that is it, "a simple >>> statement requiring or recommending 64 bit IIDs doesn't accurately reflect >>> the true nature of the IPv6 architecture." >> >> >> If a problem statement is formulated, it is worth adding the following. >> >> The 64bit IIDs make for a problem of 'growth at the edges'. Such a >> problem has to do with use-cases like when using a smartphone to >> 'tether'. Connect the smartphone on 4G and give others Internet on >> WiFi, such as to 'grow' the network. Similar use-cases are: a WiFi >> Access Point, an IoT Gateway, an automobile On-Board Router, a Road-Side >> Unit, an satcom-WiFi router in an airplane. >> >> Such a device is present at the edge of the Internet. It obtains a /64 >> from a provider (a cellular or an ADSL provider). It then has to make >> up other /64s to give others. It cant. >> > > It can't because the cellular or ADSL provider doesn't want the device > to be able to. If they did, then they should have no issue with > providing multiple and enough /64s to do so, in particular given how > cheap /64s are. I can agree to that, but it does not make it less of a Problem. Further, I heard today other problems during the meeting: - network management: ANIMA work may need longer-than-64bit prefix lenghts - Android emulator may not allow for NAT Alex [...] From nobody Mon Jul 17 05:09:42 2017 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 8E0F913146E for ; Mon, 17 Jul 2017 05:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 CZ-0MIuwiOwe for ; Mon, 17 Jul 2017 05:09:40 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46C813145A for ; Mon, 17 Jul 2017 05:09:39 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6HC9TiI034475 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jul 2017 13:09:35 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <596CA8F9.6090806@foobar.org> Date: Mon, 17 Jul 2017 13:09:29 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Brian E Carpenter CC: Timothy Winters , 6man Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt References: <149909644776.22718.16227939850699261560@ietfa.amsl.com> <5a4d61e7-9ca4-b741-ddf3-2e3d3714d55c@gmail.com> In-Reply-To: <5a4d61e7-9ca4-b741-ddf3-2e3d3714d55c@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:09:41 -0000 Brian E Carpenter wrote: > On 16/07/2017 20:25, Timothy Winters wrote: >> Probably not, we'll remove this in the next draft. How do you feel about >> Frame Relay? > > I don't really know - is it still deployed in the real world? If so, > you could leave it in. legacy situations only and it disappeared off the sales catalogues of most providers 15-20 years ago. There aren't any good reasons to include it in the draft. Nick From nobody Mon Jul 17 08:15:03 2017 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 8F9F2126D73 for ; Mon, 17 Jul 2017 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 6G1P5EeafG7M for ; Mon, 17 Jul 2017 08:15:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71E7131C56 for ; Mon, 17 Jul 2017 08:14:57 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8D9D258C4F9 for ; Mon, 17 Jul 2017 17:14:53 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 577EFB0C5ED; Mon, 17 Jul 2017 17:14:53 +0200 (CEST) Date: Mon, 17 Jul 2017 17:14:53 +0200 From: Toerless Eckert To: ipv6@ietf.org Subject: Stupid 4291 question Message-ID: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:15:02 -0000 So, if i create a loopback interface with a /128 IPv6 global address to use for various purposes (routing protocol identifier, mgmt address, etc. pp), how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK common practice in networks. To me it looks as if it would violate 2.5.1 and i also haven't seen something in the RFCs updating 4291. But i just browsed quickly. Thank! Toerless From nobody Mon Jul 17 09:24:51 2017 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 8B28E131C71 for ; Mon, 17 Jul 2017 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA-hZeWkK1Pf for ; Mon, 17 Jul 2017 09:24:47 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 A5AA1128BC8 for ; Mon, 17 Jul 2017 09:24:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id E5B287B3 for ; Mon, 17 Jul 2017 16:24:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JfniEQ4L8P7 for ; Mon, 17 Jul 2017 11:24:46 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id ADDF29AB for ; Mon, 17 Jul 2017 11:24:46 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id f9so17844539uaf.1 for ; Mon, 17 Jul 2017 09:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KthCdR6y4+JLui3aMjxvOq8eFQpAhCejEAjANszEhuM=; b=lN44q1HXazkbPR316A/I+jQZpW2W1JNKNTvte8joGIFs2VwaZveDckr7YS+ACG5NUK Vk0nM7ybIPTGYsPcRj7ZJIcNAmRAlPP8rjVGDx6tP1nmwBwiK/myN+t7VWnb/5fFKEig MW9f3TDcoYgi86NWtR2oYMwu8xxTdQJpfo8jTLmhihzEztcwi6OadlsbQXlfZVYo6ROe tRL9EiF/g0wvgOYfe3ToGXvkgRVllrC5VSw1U3RoFL9sCIoxBbfEoogfvbr9YPLOzrqN DtT3bdjdZiAfgfxsPR/7zU/P4XKp74ygVpcO+qTzmKgLjVo69LXTVPlu7ap2XA67STyF YobA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KthCdR6y4+JLui3aMjxvOq8eFQpAhCejEAjANszEhuM=; b=rNYmWTzizqra8Eq2AF2kWqJaMLeHGTSiVZTasbmLJx+CEEdHCXBTqO0LwxRdmBh4pq 2q/wB9gdtahKNMW8xe6r92lqRf0P2Iz6WCCA2GLrsjD9UTX9muijf+bne/r/JCW/JUgG 8WHujMw+Zt9+zFcRidLo4D9NwKIKCTOGSK0PmVvXSy8oeKqGZdz5uG4HbLPnZTdfn4/l 5ncDOCJhAuKbfnyK5UOg+0GZwjKM4vM+vq/5URkJeLmsUeOsXVYCY3Ub9lBU0MGDZv/2 FyexMfVxuodB7cXYzwwrJhLMx0CZKFfcJec6lfoftaMON5oqW+Y7IsPMmOEWLdDdI39n TgyQ== X-Gm-Message-State: AIVw110+aRYHVPY8CNVyoNbwmESQHfnpF3E3gR+F/GkAWKyA5tyhQNX4 uDRhGBQGRXlfiJFgnLMdQjFBMM6GLORffidOevs1oW8eEJA6gKWRgBASqVfOUsKpbepvBMYyYeS f9xHTe0R5jTwQDoQ= X-Received: by 10.159.52.79 with SMTP id s15mr9012067uab.157.1500308685841; Mon, 17 Jul 2017 09:24:45 -0700 (PDT) X-Received: by 10.159.52.79 with SMTP id s15mr9012056uab.157.1500308685621; Mon, 17 Jul 2017 09:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 17 Jul 2017 09:24:45 -0700 (PDT) In-Reply-To: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> From: David Farmer Date: Mon, 17 Jul 2017 11:24:45 -0500 Message-ID: Subject: Re: Stupid 4291 question To: Toerless Eckert Cc: 6man WG Content-Type: multipart/alternative; boundary="f403043ed1d443003b055485d666" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:24:49 -0000 --f403043ed1d443003b055485d666 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 17, 2017 at 10:14 AM, Toerless Eckert wrote: > So, if i create a loopback interface with a /128 IPv6 global address > to use for various purposes (routing protocol identifier, mgmt address, > etc. pp), > how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK > common > practice in networks. > > To me it looks as if it would violate 2.5.1 and i also haven't seen > something in the RFCs > updating 4291. But i just browsed quickly. > > Thank! > Toerless > It's a little more complicated, simply assigning a /128 or other on-link prefix length to any interface, loopback or otherwise, doesn't imply there is not a 64bit IID is being used. If each loopback /128 is assigned out of it's own unique /64, you are fine. Each link has a /64 and the IIDs from that /64 are only associated with that link, the loopback interface. The whole /64 just isn't on-link, only the one /128 in this case. However, if you assign any /128s from that /64 to a different loopback interface on that or any other router, then you violate section 2.5.1 of RFC4291. However, I think it is fairly common practice to assign loopback interfaces for a whole network out of a common /64, maybe assigning point-to-point router links out of that common /64 too, and that is where the problem is, all of the 64bit IID are not associated with the same link, not that act of assigning a /128 to a loopback by itself. At least that is my interpretation of it. Now the current RFC4291bis has an exception for manually configured interfaces. I think most loopback interfaces are manually configured. However, I think it would be better to call out loopback interfaces explicitly, just so we don't have to get into the philosophical argument about whether or not generating configs out of puppet or something like that is actually manual configuration or not. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403043ed1d443003b055485d666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 17, 2017 at 10:14 AM, Toerless Eckert <= ;tte@cs.fau.de> wrote:
So, if i = create a loopback interface with a /128 IPv6 global address
to use for various purposes (routing protocol identifier, mgmt address, etc= . pp),
how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK co= mmon
practice in networks.

To me it looks as if it would violate 2.5.1 and i also haven't seen som= ething in the RFCs
updating 4291. But i just browsed quickly.

Thank!
=C2=A0 =C2=A0 Toerless

It's a littl= e more complicated, simply assigning a /128 or other on-link prefix length = to any interface, loopback or otherwise, doesn't imply there is not a 6= 4bit IID is being used. =C2=A0

If each loopback /1= 28 is assigned out of it's own unique /64, you are fine.=C2=A0 Each lin= k has a /64 and the IIDs from that /64 are only associated with that link, = the loopback interface.=C2=A0 The whole /64 just isn't on-link, only th= e one /128 in this case.=C2=A0 However, if you assign any /128s from that /= 64 to a different loopback interface on that or any other router, then you = violate section 2.5.1 of RFC4291.

However, I think= it is fairly common practice to assign loopback interfaces for a whole net= work out of a common /64, maybe assigning point-to-point router links out o= f that common /64 too, and that is where the problem is, all of the 64bit I= ID are not associated with the same link, not that act of assigning a /128 = to a loopback by itself.=C2=A0

At least that is my= interpretation of it. Now the current RFC4291bis has an exception for manu= ally configured interfaces. I think most loopback interfaces are manually c= onfigured. However, I think it would be better to call out loopback interfa= ces explicitly, just so we don't have to get into the philosophical=C2= =A0argument about whether or not generating configs out of puppet or someth= ing like that is actually manual configuration or not. =C2=A0
Thanks.
--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farme= r=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networ= king & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--f403043ed1d443003b055485d666-- From nobody Mon Jul 17 09:42:36 2017 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 20C7D131B33 for ; Mon, 17 Jul 2017 09:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BsPEl-U1Ypvd for ; Mon, 17 Jul 2017 09:42:33 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 DCC6A131A88 for ; Mon, 17 Jul 2017 09:42:32 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 21so35559138qtx.3 for ; Mon, 17 Jul 2017 09:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=V1pGMbRMVP3IwHCLdkOnmkyp692dM6FOUucQhlT/V9E=; b=Uybuck1MfWlKwEnaWLGiCfL1KbmuIIiPJHg8wohb+cN2xU4FWRzkC+WXan4wOh4RRK gHVUUrxSFE90LgYpVX6pcczZhG5U7Q/iIC+SwNZ4WwQInDwslqROKcA/RI8YTsGr5gZK eeU/foXxOAwULb66JHGE8G3iVjv5x91TRR4zrRTFH6nYZX5oaCMHfW/ejECEio5pxITh FX57wNgl7BSkqFbz6851Uik8+JzPrl4MeYG/gpXA4i75gK6UXd1y5y/VeegHS8iEaH+c 5SsHQZUJQ8XaX/iCEHyaiBgNZ5gcSBUE5vPiHopZoSZP0E0WdqmASUYxcAAaE/i4wL1a Ytdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=V1pGMbRMVP3IwHCLdkOnmkyp692dM6FOUucQhlT/V9E=; b=g8FJEeCXkPzcGct5xw0DLVDopVvKXesqXP9z+52HklgCw+CxPxQ8Ro31z/ibLvrnFf yE9Iz+bW1qjvKEpgyHSA7jgyoi9/TOGdaFk3lV6drmSr2WDuUg31DtqaHm8+4XMiBwBc kUKyZA77oEW0qcUXFksP8BiN/ylEUm0peRtq/YbPnM78b7BmjaYdWEl8CnkomTQ4DQxS vpEBt+7hdq+AhjTdnKHmM0Qc80H0XdJem+zYkhVP7RRDl7uKV0+TW8UZ3bMP4liB3W8m M8uBfZKoY2Haw5LdYXGCvby3LTRIC/QXkm21lkCHeFAyGSy4Wi5Rspw5HN5w2P49yi/K JHpw== X-Gm-Message-State: AIVw1125Qe+ajnd9jsIZPo59iQLPrKN7q45F8IVLYTATffmZfVKjyyol ce8dXWnZFYbl3sVYov2Zt2TL2VaI+g== X-Received: by 10.200.36.6 with SMTP id c6mr29641876qtc.124.1500309751852; Mon, 17 Jul 2017 09:42:31 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Mon, 17 Jul 2017 09:42:31 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 17 Jul 2017 09:42:31 -0700 X-Google-Sender-Auth: e3dKeIRqh_WpO6MiAgZRyhxKb-c Message-ID: Subject: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing) To: Brian E Carpenter Cc: Mark Smith , "Pascal Thubert (pthubert)" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:42:34 -0000 At Mon, 17 Jul 2017 08:58:18 +1200, Brian E Carpenter wrote: > > I looked up RFC4862 to find out how many DAD attempts there were, > > because I'd assumed 3 to 4, and if so, then if that many attempts > > failed, I'd say the link is well beyond its capacity. Something would > > need to be done to remedy a link capacity problem in that case. > > > > I was surprised to find, as Ole mentioned, the number of attempts was > > only 1 rather than 3 or 4. > > I'm more than surprised. I think that's a bug and IMHO it should be fixed. Although it's probably true that at the time of RFC4862 we didn't expect networks with much higher packet loss to be so dominantly deployed, I don't necessarily think the current parameter of RFC4862 is a "bug". First off, "1" is just the default of DupAddrDetectTransmits, not a fixed constant. Secondly, my understanding is that DAD as defined in RFC4862 (or its predecessors) has never been considered a very reliable duplicate detection mechanism, so it didn't bother to make it arbitrarily less unreliable by default (when 1 is may not be enough, there's no guarantee that 3 or 4 is enough anyway). I also thought the "official answer" for a high packet-loss environment is to use a more sophisticated mechanism such as RFC4429. (That said, I wouldn't necessarily be opposed to updating the default value if and when we update RFC4862 so it will match the latest deployments for leaf networks better). -- JINMEI, Tatuya From nobody Mon Jul 17 09:44:49 2017 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 E225A131CB7 for ; Mon, 17 Jul 2017 09:44:47 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AaMmLXHJdRGI for ; Mon, 17 Jul 2017 09:44:46 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F803131B48 for ; Mon, 17 Jul 2017 09:44:43 -0700 (PDT) Received: from [10.190.216.225] (77.16.40.225.tmi.telenormobil.no [77.16.40.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 8266E2D5001; Mon, 17 Jul 2017 16:44:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Stupid 4291 question From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> Date: Mon, 17 Jul 2017 18:44:36 +0200 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <43BF6C78-AAB9-408C-BE18-A941A94C4770@employees.org> References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:44:48 -0000 As a general note it might be worth remembering that the address/prefix-leng= th notation is just a short-hand that is commonly used in implementations.=20= An address is always 128-bit and does not need to have an associated prefix-= length with it.=20 To spell out Toerless' example: Interface loopback0 ipv6 address 2001:db8::1 ipv6 on-link prefix 2001:db8::1/128 In this case specifying an onlink prefix length of 128 is of course redundan= t.=20 But you can of course specify an IPv6 address on an interface without any as= sociated on-link prefix.=20 Cheers=20 Ole > On 17 Jul 2017, at 17:14, Toerless Eckert wrote: >=20 > So, if i create a loopback interface with a /128 IPv6 global address > to use for various purposes (routing protocol identifier, mgmt address, et= c. pp), > how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK c= ommon > practice in networks. >=20 > To me it looks as if it would violate 2.5.1 and i also haven't seen someth= ing in the RFCs > updating 4291. But i just browsed quickly. >=20 > Thank! > Toerless >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jul 17 10:06:16 2017 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 3EF95131668 for ; Mon, 17 Jul 2017 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NeDiD0O-UZdk for ; Mon, 17 Jul 2017 10:06:14 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AA11300CE for ; Mon, 17 Jul 2017 10:06:14 -0700 (PDT) Received: from [10.227.125.145] (77.16.77.145.tmi.telenormobil.no [77.16.77.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4E4D92D5003; Mon, 17 Jul 2017 17:06:13 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-B1B30C3D-23FA-4060-9277-86C4B636DD1C Mime-Version: 1.0 (1.0) Subject: Re: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing) From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: Date: Mon, 17 Jul 2017 19:06:10 +0200 Cc: Brian E Carpenter , "Pascal Thubert (pthubert)" , "ipv6@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:06:15 -0000 --Apple-Mail-B1B30C3D-23FA-4060-9277-86C4B636DD1C Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit > On 17 Jul 2017, at 18:42, $B?@L@C#:H(B wrote: > > At Mon, 17 Jul 2017 08:58:18 +1200, > Brian E Carpenter wrote: > >>> I looked up RFC4862 to find out how many DAD attempts there were, >>> because I'd assumed 3 to 4, and if so, then if that many attempts >>> failed, I'd say the link is well beyond its capacity. Something would >>> need to be done to remedy a link capacity problem in that case. >>> >>> I was surprised to find, as Ole mentioned, the number of attempts was >>> only 1 rather than 3 or 4. >> >> I'm more than surprised. I think that's a bug and IMHO it should be fixed. > > Although it's probably true that at the time of RFC4862 we didn't > expect networks with much higher packet loss to be so dominantly > deployed, I don't necessarily think the current parameter of RFC4862 > is a "bug". First off, "1" is just the default of > DupAddrDetectTransmits, not a fixed constant. Secondly, my > understanding is that DAD as defined in RFC4862 (or its predecessors) > has never been considered a very reliable duplicate detection > mechanism, so it didn't bother to make it arbitrarily less unreliable > by default (when 1 is may not be enough, there's no guarantee that 3 > or 4 is enough anyway). I also thought the "official answer" for a > high packet-loss environment is to use a more sophisticated mechanism > such as RFC4429. > > (That said, I wouldn't necessarily be opposed to updating the default > value if and when we update RFC4862 so it will match the latest > deployments for leaf networks better). It's a tradeoff between how long it takes before the address is usable. I wasn't aware tgat 4429 was more robust. During the efficient nd work, Erik did: https://tools.ietf.org/html/draft-nordmark-6man-dad-approaches-02 And https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01 I think we essentially need ACD. cheers Ole --Apple-Mail-B1B30C3D-23FA-4060-9277-86C4B636DD1C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 17 Ju= l 2017, at 18:42, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:

At Mon, 17 Jul 2017 08:58:18 +1200,
Brian E Carpenter <bria= n.e.carpenter@gmail.com> wrote:

I looked up RFC4862 to find o= ut how many DAD attempts there were,
because I'd assumed 3= to 4, and if so, then if that many attempts
failed, I'd s= ay the link is well beyond its capacity. Something would
n= eed to be done to remedy a link capacity problem in that case.
<= span>
I was surprised to find, as Ole mentioned, the numbe= r of attempts was
only 1 rather than 3 or 4.

I'm more than surprised. I think that's a= bug and IMHO it should be fixed.

Although it's probably true that at the time of RFC4862 we didn't=
expect networks with much higher packet loss to be so dominantly
deployed, I don't necessarily think the current parameter of R= FC4862
is a "bug".  First off, "1" is just the default o= f
DupAddrDetectTransmits, not a fixed constant.  Second= ly, my
understanding is that DAD as defined in RFC4862 (or i= ts predecessors)
has never been considered a very reliable d= uplicate detection
mechanism, so it didn't bother to make it= arbitrarily less unreliable
by default (when 1 is may not b= e enough, there's no guarantee that 3
or 4 is enough anyway)= .  I also thought the "official answer" for a
high pack= et-loss environment is to use a more sophisticated mechanism
such as RFC4429.

(That said, I wouldn't ne= cessarily be opposed to updating the default
value if and wh= en we update RFC4862 so it will match the latest
deployments= for leaf networks better).

It's a tra= deoff between how long it takes before the address is usable. 

I wasn't aware tgat 4429 was more robust. 
<= br>
During the efficient nd work, Erik did:

And

I think we essentially need ACD.&n= bsp;

cheers 
Ole
= --Apple-Mail-B1B30C3D-23FA-4060-9277-86C4B636DD1C-- From nobody Mon Jul 17 10:21:56 2017 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 789FC129AD2 for ; Mon, 17 Jul 2017 10:21:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 AJLNI40tKtyR for ; Mon, 17 Jul 2017 10:21:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2976124E15 for ; Mon, 17 Jul 2017 10:21:53 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-8110.meeting.ietf.org [31.133.129.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 1B73F1F8F5; Mon, 17 Jul 2017 17:21:52 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3E69BC86; Mon, 17 Jul 2017 19:21:45 +0200 (CEST) From: Michael Richardson To: David Farmer cc: Toerless Eckert , 6man WG Subject: Re: Stupid 4291 question In-reply-to: References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to David Farmer message dated "Mon, 17 Jul 2017 11:24:45 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 Jul 2017 19:21:45 +0200 Message-ID: <5980.1500312105@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:21:55 -0000 --=-=-= Content-Type: text/plain David Farmer wrote: > If each loopback /128 is assigned out of it's own unique /64, you are > fine. Each link has a /64 and the IIDs from that /64 are only > associated with that link, the loopback interface. The whole /64 just > isn't on-link, only the one /128 in this case. However, if you assign > any /128s from that /64 to a different loopback interface on that or > any other router, then you violate section 2.5.1 of RFC4291. I don't see why you say that. > However, I think it is fairly common practice to assign loopback > interfaces for a whole network out of a common /64, maybe assigning > point-to-point router links out of that common /64 too, and that is > where the problem is, all of the 64bit IID are not associated with the > same link, not that act of assigning a /128 to a loopback by itself. Are you claiming that having a /64 for all loopbacks (which is never used in SLAAC or on any broadcast link that could have RAs) is some kind violation? I'm pretty sure that that has been beat to death on this list already. > At least that is my interpretation of it. Now the current RFC4291bis > has an exception for manually configured interfaces. I think most > loopback interfaces are manually configured. Yes, this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZbPIpAAoJEJVM4Vb9/EKQONMIAKsKbk/WWiTCFSGUS7PxYswt IseRXweEStksinzSurCU78SpWW0lxCHnHJjrjdtFJlXS1lXm/bTLZAXrI97oY21k ymLR47fZupG3wjDM9Udv3k2hsIZWPhImKhBIz5VMdpVCUP98dJULIaauhAwF2bs4 zRWPqj1nzJtml2OgJjJkwH4GNV5/KK135Vg6a9T/qNMplrTEUkolncTtWoeHWNNX HKyL3VSYlDlAQsMkq0J96j1C8prsg8YCBN/5R0i23TpGDqlf46PXWrOmB4sJFXZh v9/NXVAfufFyAjZYnINo7N7M+1KBuzkFW5dFSYZe7GbHLzzF3alqFSoYhiFb/jA= =b9/1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 17 10:26:53 2017 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 2B1C4131BF6 for ; Mon, 17 Jul 2017 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 sNT51UEkui3r for ; Mon, 17 Jul 2017 10:26:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4369A131CC9 for ; Mon, 17 Jul 2017 10:26:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dX9nE-0000HMC; Mon, 17 Jul 2017 19:26:48 +0200 Message-Id: To: ipv6@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing) From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com In-reply-to: Your message of "Mon, 17 Jul 2017 09:42:31 -0700 ." Date: Mon, 17 Jul 2017 19:26:46 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:26:52 -0000 >(That said, I wouldn't necessarily be opposed to updating the default >value if and when we update RFC4862 so it will match the latest >deployments for leaf networks better). One problem here is that the collision risk is the highest in networks with a large number of hosts on a single link. One common example of those are the very big wifi networks found at conferences, etc. However, in a big wifi network, multicast is expensive. So those networks benefit from keeping DupAddrDetectTransmits as low as possible. Pseudo random IIDs have the interesting property that if the IID length is big enough and the local random number generator is of good quality, then broken hosts on the same link cannot increase the probability of a collision. So if we keep IIDs at 64 bit, then we can probably argue that for pseudo random IIDs we can ignore DAD, because any proper implementation will never see a collision anyhow. From nobody Mon Jul 17 10:28:45 2017 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 77D3D1294A2 for ; Mon, 17 Jul 2017 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wW1rbLsL1Xra for ; Mon, 17 Jul 2017 10:28:42 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 7DE76128AB0 for ; Mon, 17 Jul 2017 10:28:42 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id z37so2891003ybh.1 for ; Mon, 17 Jul 2017 10:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5iLkJo4a8szZlGRsKonXDa9j/kXk7XVuqla/dqrxMSE=; b=vPHNSOZcGdyQqJ1v/yBElFuBPTs4LV4FhM/UYlUp73lEV4mvAcupCM6yUgyUx15iKj Y9q8VrA0Dxgxg7JS9c7BuEXAJRUUar5Sm3WLOpY7Y6y3Ef7sAiIYKfy24flSD9Yj4mQo lVL0pG0lhUvF3p9dHnHSp2quSuILuEoBlAkisA1SLDWaytgQBK9lYyLvBWw5v4n6onbW ep24mEUvhapAloRqLcthZXx16ovyPPR26E6GdFnc/xT/o6HQJtjSFAcggpCLrdLjgkT6 kLpZm8evwYtTJ5SOwoIoJURUE7PUss3mGRTVv0+YXH6KuPXPBpnB+azOLv7p/3RdwF3W xWgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5iLkJo4a8szZlGRsKonXDa9j/kXk7XVuqla/dqrxMSE=; b=Efdg3Vh5L6/LF4diYGCM9YbD2ela6NO2oM4eq/MvWIZBRpnr9hNFaS3QgEdFL3wCdp NNAUrLU8Sg1gjCjJJYxj7sa1gjCnfpBzP7yOc7ZY0WOGxMoBfSBih8WA7MPKoox5R1XI dED0VPZSjAj4mblnvLUE9ExWptpAqTW/1ZDSX/32xel5+QMu/DTeBgCf0KujEGocWd09 y8Y5+xOi50VmZsZGIWw+Bvp2MpZbMqu7gJFVpLtFSlAYxZfnkz46cVhnA+PJO8F1LJ1s sFS0Fj0MVHJywiuFnH1JiS4XA9J2xO5oJVh9tNaU4yS3bB6XMC6XeMtBWPsjVZKA6rrB 4sqQ== X-Gm-Message-State: AIVw110yFugdUdRdKp1ZlJ10XXsU9bUUwp+SLKgPiJev7DzTU18Cw5Sg L+sDi2HKDWnLLwzgFgGnJTn6xsudHZjO X-Received: by 10.37.178.9 with SMTP id i9mr19136098ybj.8.1500312521509; Mon, 17 Jul 2017 10:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Mon, 17 Jul 2017 10:28:20 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 18 Jul 2017 02:28:20 +0900 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing) To: Ole Troan Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Pascal Thubert (pthubert)" , "ipv6@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045f37feecd239055486ba87" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:28:44 -0000 --f403045f37feecd239055486ba87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 July 2017 at 02:06, Ole Troan wrote: > > > On 17 Jul 2017, at 18:42, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > At Mon, 17 Jul 2017 08:58:18 +1200, > Brian E Carpenter wrote: > > I looked up RFC4862 to find out how many DAD attempts there were, > > because I'd assumed 3 to 4, and if so, then if that many attempts > > failed, I'd say the link is well beyond its capacity. Something would > > need to be done to remedy a link capacity problem in that case. > > > I was surprised to find, as Ole mentioned, the number of attempts was > > only 1 rather than 3 or 4. > > > I'm more than surprised. I think that's a bug and IMHO it should be fixed= . > > > Although it's probably true that at the time of RFC4862 we didn't > expect networks with much higher packet loss to be so dominantly > deployed, I don't necessarily think the current parameter of RFC4862 > is a "bug". First off, "1" is just the default of > DupAddrDetectTransmits, not a fixed constant. Secondly, my > understanding is that DAD as defined in RFC4862 (or its predecessors) > has never been considered a very reliable duplicate detection > mechanism, so it didn't bother to make it arbitrarily less unreliable > by default (when 1 is may not be enough, there's no guarantee that 3 > or 4 is enough anyway). I also thought the "official answer" for a > high packet-loss environment is to use a more sophisticated mechanism > such as RFC4429. > > (That said, I wouldn't necessarily be opposed to updating the default > value if and when we update RFC4862 so it will match the latest > deployments for leaf networks better). > > > It's a tradeoff between how long it takes before the address is usable. > > I wasn't aware tgat 4429 was more robust. > > During the efficient nd work, Erik did: > https://tools.ietf.org/html/draft-nordmark-6man-dad-approaches-02 > > And > https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01 > > I think we essentially need ACD. > > cheers > Ole We could recommend to do two things in concert: use optimistic addresses and raise DAD to 3,4,5,... --f403045f37feecd239055486ba87 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgjmVdwgIOZT+GSAVGM9eXqDQnd5srlWnG vcE1O+xjMUUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE3 MTcyODQxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBALJd0occ4WeI3fQQ15ci2fhFAIjPpV/WyQBpEfTtFW7bx4r14MiI HN1IJ86LEKgkjnScDEqOfGVeDSESWChjm3jW6Oj6+sjp5UDMsPtqJJ+baN+ISYl073wkk7xg7v0i xz6a/ozqPeP2zSAM0mVDV+pUbLFW9eCPfuA42mylT4cJbPIhiQRfW4NTKs6dMpZ1mcRdhbqvvOb7 l+O6ewLEyQntyKVFWonRqGNDkvThpkIjUkKSMkRAQrB0dWgeJ/sAwnhqVA4F1kO5Xj/7DENPOwu9 xMgvS/6gWbP5womFPfLLxDGI2AFjtVpwoMnFXvVEoZBYupnB7Z/BGyp0q5jtzjM= --f403045f37feecd239055486ba87-- From nobody Mon Jul 17 11:11:31 2017 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 ADBB5131CCA for ; Mon, 17 Jul 2017 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 KCSkyJp2B4cy for ; Mon, 17 Jul 2017 11:11:26 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 EB0C8131CCC for ; Mon, 17 Jul 2017 11:11:25 -0700 (PDT) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v6HIBLR8023561 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Jul 2017 11:11:23 -0700 Subject: Re: rationale for the default of DupAddrDetectTransmits (Re: IPv6 Routing & ND vs. Addressing) To: ipv6@ietf.org References: From: Erik Nordmark Message-ID: Date: Mon, 17 Jul 2017 20:11:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVbuY4K1cDDd2gbCMISbOnI3olOYRVE3R7lmFdp1v1B7CJCwiEHHnF5xCGSD86IYtyfQ91Ish76UfVWaAPATs6yo X-Sonic-ID: C;7IlzVhtr5xGrhfsKk0eh0A== M;ijZuVxtr5xGrhfsKk0eh0A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 18:11:28 -0000 On 07/17/2017 06:42 PM, 神明é”哉 wrote: > Although it's probably true that at the time of RFC4862 we didn't > expect networks with much higher packet loss to be so dominantly > deployed, I don't necessarily think the current parameter of RFC4862 > is a "bug". First off, "1" is just the default of > DupAddrDetectTransmits, not a fixed constant. Secondly, my > understanding is that DAD as defined in RFC4862 (or its predecessors) > has never been considered a very reliable duplicate detection > mechanism, so it didn't bother to make it arbitrarily less unreliable > by default (when 1 is may not be enough, there's no guarantee that 3 > or 4 is enough anyway). I also thought the "official answer" for a > high packet-loss environment is to use a more sophisticated mechanism > such as RFC4429. > > (That said, I wouldn't necessarily be opposed to updating the default > value if and when we update RFC4862 so it will match the latest > deployments for leaf networks better). Jinmei, Some of the failure modes is when the link isn't usable when the host configures the interface. This could be because it is on an Ethernet port with STP configured, and as a result all of the packets are dropped by the Ethernet bridge for the first 40 odd seconds. Or there is an dsl/cable modem bridge and the connection isn't up when the DAD packet is sent; it typically takes many seconds to synchronize the link. Thus I don't think send 4 packets makes current DAD more robust. The links that Ole pointed at has more information on this. Regards, Erik From nobody Mon Jul 17 11:40:24 2017 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 855BE12ECB7 for ; Mon, 17 Jul 2017 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LmpNfY6tjBcg for ; Mon, 17 Jul 2017 11:40:20 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 BBCF7129789 for ; Mon, 17 Jul 2017 11:40:20 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a66so114114977qkb.0 for ; Mon, 17 Jul 2017 11:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=XfezVO6w73ESZBBX85qYcHthExtKqaxQw/Ndj/GUNtg=; b=Aula5mja2es2UTZDdPPHPS1FJQN14YUY+irdUs9ob7rwa0L+8tYYs8bu5Mlsn4vOzR 0Mr9R9YfixtpIG41EpXYaXsNzMQas0t1AlUcPDc7XM2kDwhezLeOlaF5fGL2G9XlLDEq DHR/CUos0WSqgJNXA9SdBVYylc0Vr1grLq+TOhLzDN64EQIVBrCyNwWZJF0GW4HO5QTh e93HsZGVCalsCYAgVIxhLlZmUoaRvEJuiWRRtVZFOlsl+WNgzOfeM4VOKMZmrBhmP+R1 AVnLe4IaO/kvooRsqwYyFDYKZl8BquOa5OpA/PESA2k93o8f6wRTzUg5pkD/Bv7UqSPS tRsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=XfezVO6w73ESZBBX85qYcHthExtKqaxQw/Ndj/GUNtg=; b=UwMRajThtNPMzb3B1Qi6/p6xtgUSoRm8MtTnol+kQS6fkXAq9Bn+m5s7VZtlPDYb9W aEHjI8v+TY9YY6UdlR5KQZ7udm6ESIJzzjPJhw/3kZUjUnHK+f31b0PoxlqpTa6orvtd cLbnPB2n8K8bM2eNJHkbpL4XOwmBjLPsBjKYVvo+z7lL1GC15a4xhU1+pzDVLyHykSgu ITNNqQk70A4X/NgQ1G+OzrXIhO3heQvCLmQfN0QSLdGmgXiB0HgRaprl6N2cghu14ovs EXTDkJMVIox/073j8ltC5DE0HV1AO/huObSOqmbjVOge0B0LJGLb11WTwvxLNC5dynTw J62Q== X-Gm-Message-State: AIVw111VFLKphHRAGUKlVWJEK9W6f9VpzqC0qc/RxFSliYOghUHXBh8Q 4fb663PcSeEUuQ6o4cbQxH0GlSvm0g== X-Received: by 10.55.150.134 with SMTP id y128mr29135039qkd.29.1500316819677; Mon, 17 Jul 2017 11:40:19 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Mon, 17 Jul 2017 11:40:19 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 17 Jul 2017 11:40:19 -0700 X-Google-Sender-Auth: kQk3O9iC9B5VAaKrREORioptYV4 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Erik Nordmark Cc: IPv6 IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 18:40:22 -0000 At Mon, 17 Jul 2017 20:11:20 +0200, Erik Nordmark wrote: > > Although it's probably true that at the time of RFC4862 we didn't > > expect networks with much higher packet loss to be so dominantly > > deployed, I don't necessarily think the current parameter of RFC4862 > > is a "bug". [...] > > (That said, I wouldn't necessarily be opposed to updating the default > > value if and when we update RFC4862 so it will match the latest > > deployments for leaf networks better). > Some of the failure modes is when the link isn't usable when the host > configures the interface. This could be because it is on an Ethernet > port with STP configured, and as a result all of the packets are dropped > by the Ethernet bridge for the first 40 odd seconds. Or there is an > dsl/cable modem bridge and the connection isn't up when the DAD packet > is sent; it typically takes many seconds to synchronize the link. > > Thus I don't think send 4 packets makes current DAD more robust. > The links that Ole pointed at has more information on this. Perhaps I unintentionally confused others by saying I wouldn't be opposed to increasing the default of DupAddrDetectTransmits, but I guess we are basically on the same page. My main point in my previous message was that, in a response to earlier messages saying as if the current default (1) were *the* problem and changing it is the solution, RFC4862-version of DAD wasn't expected to be robust that much anyway and blaming the current default or tweaking that parameter as a kind of solution would be misdirected. I understand the failure mode you mentioned above, and I agree just increasing DupAddrDetectTransmits wouldn't make DAD more robust. Isn't it consistent with my main point? -- JINMEI, Tatuya From nobody Mon Jul 17 11:45:30 2017 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 448E0131686 for ; Mon, 17 Jul 2017 11:45:26 -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, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BZAVRybJMnvB for ; Mon, 17 Jul 2017 11:45:25 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 6E5A913167F for ; Mon, 17 Jul 2017 11:45:24 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n42so16833735qtn.0 for ; Mon, 17 Jul 2017 11:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=2pa3mBC79ziMoDgLyVmeRRveGQLl55PnUo6wCGa3WlI=; b=AN/PIHuDl4B7sjcLAnFd4EQTHwupqSTdmso/uJ5F7US/CFDyqwG2x3Vdniv6D/+7bi xYwOrA19+foFG8NIc1smGe9eagF5F9SoupoynN3xji9iEaqaxH/HSlweCEN1BWaF60AJ sBvioe4LSNvZ9flktXx30nWnUWQYhrLyKzD7v6JnNwLWryiZhaqGIqnVXNCE4FO8eqzh U5c2ZpNSO0Sc4rbf4NR5X7Rk7HbzJggWGXtSVbDTt36fJVIrh8rpoaQ8/Kr1J20kbK0Z WsRRK9zdn0mdn3XCLCQaWtwg2HtzHAGc4kMZ0GPgjApmqyrozGvsikstHIJ+u1BzVF4T iN/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=2pa3mBC79ziMoDgLyVmeRRveGQLl55PnUo6wCGa3WlI=; b=G1LldTb/zo/zj04Qq60tcXhMV9GLsBdX6/0GNvQC81qBbFQvjuFsndaxwUB6Gte4eO FSJT+9Xgelwc5WdD9i/Fj0n2Bd30+Mv6Zu5cZ1NWuInts52bx715NF5RSqvOaEPh6XrR FvAkBBEF2U1i0NMnUAssnSR/3/RuaHmvKcfI7Tl5aBnQif4qXFzPjjpULvZNzAD8DHIY jiEHDvE5ukUK1P14bQLG6hjBIce7sSToTA4MsBceRtSuBb/wNly0mG4kC/7131jSFvWp AD2sf7EqZ4Ti9PC8IVTh3VsJEiU122N8auFraJr2c2ukf23gOLU55lllpa/4D3x7qws3 6JCw== X-Gm-Message-State: AIVw113gvJ8T2L/CxGcG5BM8/vRO0Ql88cDBVZeAEMRsuZQZAVRWZBDq 0P1bF4B/n825G74AOeFxMGqE7B0ekYUr X-Received: by 10.200.36.70 with SMTP id d6mr29225977qtd.42.1500317123478; Mon, 17 Jul 2017 11:45:23 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Mon, 17 Jul 2017 11:45:23 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 17 Jul 2017 11:45:23 -0700 X-Google-Sender-Auth: TS6znWsbEdcClv0_WDmNWvkemRg Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Philip Homburg Cc: IPv6 IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 18:45:30 -0000 At Mon, 17 Jul 2017 19:26:46 +0200, Philip Homburg wrote: > >(That said, I wouldn't necessarily be opposed to updating the default > >value if and when we update RFC4862 so it will match the latest > >deployments for leaf networks better). I shouldn't have made this remark, which was not really my main point... > One problem here is that the collision risk is the highest in networks > with a large number of hosts on a single link. > > One common example of those are the very big wifi networks found at > conferences, etc. > > However, in a big wifi network, multicast is expensive. So those networks > benefit from keeping DupAddrDetectTransmits as low as possible. I wasn't trying to suggest increasing the default of DupAddrDetectTransmits. See my response to Erik. I also didn't intend to make any comments about whether we can safely ignore DAD with 64-bit IIDs. That's one reason why I changed the subject. > Pseudo random IIDs have the interesting property that if the IID length > is big enough and the local random number generator is of good quality, > then broken hosts on the same link cannot increase the probability of a > collision. > > So if we keep IIDs at 64 bit, then we can probably argue that for > pseudo random IIDs we can ignore DAD, because any proper implementation > will never see a collision anyhow. -- JINMEI, Tatuya From nobody Mon Jul 17 12:16:29 2017 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 37E82127B57 for ; Mon, 17 Jul 2017 12:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJYbt_T_bf8 for ; Mon, 17 Jul 2017 12:16:27 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 753A812702E for ; Mon, 17 Jul 2017 12:16:27 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id F13AC14E for ; Mon, 17 Jul 2017 19:16:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CknhmrRUC2IM for ; Mon, 17 Jul 2017 14:16:26 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id AF01C602 for ; Mon, 17 Jul 2017 14:16:26 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id x35so30691890uax.11 for ; Mon, 17 Jul 2017 12:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TIPpk0cU6u71VAl/qHfucocT4o38jezH7/FNx2Tgb9Q=; b=WCmLKD64rZzmgpANhEb1r0ggan1UqdthjHzGlpbRJwnNObp5Kpb2FD4SFzPrEwVTDw nGN3t4CUSQ6w8j9Y60aZeSXAmBVZ+bNhaTGqLjgFzA2kS8KJLk/eTvikM+qdrls3uHR7 mu1e34GcIAKFr2b2cFGFWzFgBzwyKQuVMO4AVs5FxCqFgUpOdwrCTTuJ3Lo96i1Yc8J1 TJzg16gOu0N/PgjezFoQDz7K6pcjXtg2EdwMv1he3O8gRKjWb2eqxQYYFBYvc/aRQKTo LhcoZViXQPwt/dJKDnU/ugEmTY2ah2BXiCVku0jkxivDWZGzLkLaGz3wv0tvASgMYP/g 3AvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TIPpk0cU6u71VAl/qHfucocT4o38jezH7/FNx2Tgb9Q=; b=Xp7vj9kanwQa+8wIiCDi2dNb7maAOmPw8LZ8yrLF+auSH3XTY86TZiU1lX7bYIbgCV FNvNiHuNwtT6WS30LuvHeYG6Pqs7RPhLHzlCcM2Ke2CWU9P+Ig4WtjmRcZnhdVFjSgAD cw0nxzuJUU0Xxln7DVQ7p9WMiay0Tuf4d2c+f3jvpCeqBmmM5IL/99cy6lKqbLCld/Oi IDeiXhmS3qEU3J0BhLtcy/U/OUXUj/3OUuucBWkTH0T470gf1l942gNNDlS+Chk2G1qL l8BxpF3nL7yZCjqsO474n+r1o1NNhCtjTSrwIOdz/zkZ6ZFahOEP7cfI0Fldy1U/inPC ffmQ== X-Gm-Message-State: AIVw111YQ8rpUfzOqC+rCquXugIWdS1/jxJJa6J5KSy1VzD2k1QQp8Y0 uUg7Mb4Sc4h9mmVSUT58aQlRbUh44qfU9OehplG1DMo8tgqNtKoeRxWQdPubiI4qAguZjVci8hu FFuQAoF+CgWk5wWQ= X-Received: by 10.176.86.204 with SMTP id c12mr4187655uab.126.1500318985773; Mon, 17 Jul 2017 12:16:25 -0700 (PDT) X-Received: by 10.176.86.204 with SMTP id c12mr4187646uab.126.1500318985528; Mon, 17 Jul 2017 12:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 17 Jul 2017 12:16:24 -0700 (PDT) In-Reply-To: <5980.1500312105@dooku.sandelman.ca> References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> <5980.1500312105@dooku.sandelman.ca> From: David Farmer Date: Mon, 17 Jul 2017 14:16:24 -0500 Message-ID: Subject: Re: Stupid 4291 question To: Michael Richardson Cc: Toerless Eckert , 6man WG Content-Type: multipart/alternative; boundary="94eb2c1b048a2f19ff0554883c8a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 19:16:29 -0000 --94eb2c1b048a2f19ff0554883c8a Content-Type: text/plain; charset="UTF-8" On Mon, Jul 17, 2017 at 12:21 PM, Michael Richardson wrote: > > David Farmer wrote: > > If each loopback /128 is assigned out of it's own unique /64, you are > > fine. Each link has a /64 and the IIDs from that /64 are only > > associated with that link, the loopback interface. The whole /64 just > > isn't on-link, only the one /128 in this case. However, if you assign > > any /128s from that /64 to a different loopback interface on that or > > any other router, then you violate section 2.5.1 of RFC4291. > > I don't see why you say that. > > > However, I think it is fairly common practice to assign loopback > > interfaces for a whole network out of a common /64, maybe assigning > > point-to-point router links out of that common /64 too, and that is > > where the problem is, all of the 64bit IID are not associated with > the > > same link, not that act of assigning a /128 to a loopback by itself. > > Are you claiming that having a /64 for all loopbacks (which is never used > in > SLAAC or on any broadcast link that could have RAs) is some kind violation? > I'm pretty sure that that has been beat to death on this list already. > The question was, or at least I interpreted the question as being asked about RFC4291, since bis wasn't included in the title and section 2.5.1 about IIDs, and it is now 2.4.1 in 4291bis. So, 4291 says IID are required to be 64 bits, that is not scoped to SLAAC, scoping this to SLAAC in RFC4291bis is one way to go, but it is currently making an exception for manually configured interfaces. > > At least that is my interpretation of it. Now the current RFC4291bis > > has an exception for manually configured interfaces. I think most > > loopback interfaces are manually configured. > > Yes, this. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c1b048a2f19ff0554883c8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 17, 2017 at 12:21 PM, Michael Richardson = <mcr+ietf@san= delman.ca> wrote:

David Farmer <farmer= @umn.edu> wrote:
=C2=A0 =C2=A0 > If each loopback /128 is assigned out of it's own un= ique /64, you are
=C2=A0 =C2=A0 > fine. Each link has a /64 and the IIDs from that /64 are= only
=C2=A0 =C2=A0 > associated with that link, the loopback interface. The w= hole /64 just
=C2=A0 =C2=A0 > isn't on-link, only the one /128 in this case. Howev= er, if you assign
=C2=A0 =C2=A0 > any /128s from that /64 to a different loopback interfac= e on that or
=C2=A0 =C2=A0 > any other router, then you violate section 2.5.1 of RFC4= 291.

I don't see why you say that.

=C2=A0 =C2=A0 > However, I think it is fairly common practice to assign = loopback
=C2=A0 =C2=A0 > interfaces for a whole network out of a common /64, mayb= e assigning
=C2=A0 =C2=A0 > point-to-point router links out of that common /64 too, = and that is
=C2=A0 =C2=A0 > where the problem is, all of the 64bit IID are not assoc= iated with the
=C2=A0 =C2=A0 > same link, not that act of assigning a /128 to a loopbac= k by itself.

Are you claiming that having a /64 for all loopbacks (which is never used i= n
SLAAC or on any broadcast link that could have RAs) is some kind violation?=
I'm pretty sure that that has been beat to death on this list already.<= br>

The question was, or at least I interpr= eted the question as being asked about RFC4291, since bis wasn't includ= ed in the title and section 2.5.1 about IIDs, and it is now 2.4.1 in 4291bi= s.=C2=A0 So, 4291 says IID are required to be 64 bits, that is not scoped t= o SLAAC, scoping this to SLAAC in RFC4291bis is one way to go, but it is cu= rrently making an exception for manually configured interfaces.=C2=A0
=
=C2=A0
=C2=A0 =C2=A0 > At least that is my interpretation of it. Now the curren= t RFC4291bis
=C2=A0 =C2=A0 > has an exception for manually configured interfaces. I t= hink most
=C2=A0 =C2=A0 > loopback interfaces are manually configured.

Yes, this.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [



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






--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Service= s
Office of Information Technology
University of Minnesota=C2=A0=C2= =A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-081= 5
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c1b048a2f19ff0554883c8a-- From nobody Mon Jul 17 12:33:42 2017 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 DE89E127B57 for ; Mon, 17 Jul 2017 12:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-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 7eqjpUmxuZmd for ; Mon, 17 Jul 2017 12:33:38 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 BB984129B30 for ; Mon, 17 Jul 2017 12:33:38 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6HJXbdG026170 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 17 Jul 2017 19:33:38 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6HJXbxc025570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 17 Jul 2017 19:33:37 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6HJXb00030238 for ; Mon, 17 Jul 2017 19:33:37 GMT Received: from [192.168.1.20] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jul 2017 12:33:36 -0700 To: ipv6@ietf.org From: Rao Shoaib Subject: What is the correct behavior Message-ID: Date: Mon, 17 Jul 2017 12:33:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 19:33:40 -0000 I am looking at a system which is configured for IPv6 only but sits in a network that serves both IPv4 and IPv6. When an IPv4 packet with a destination broadcast address is sent out (in this case DHCP) the system accepts it and since it does not have any route to the sender it prints the Linux Martian packet message. Sure, we can turn off the Martian message and maybe the system should be in an IPv6 only network but the question that is being asked is that is it correct for the system to accept and process an IPv4 broadcast packet in the first place ? Can the experts help me out here. Thanks, Shoaib Please include me in the reply as I am not subscribed to the list. From nobody Mon Jul 17 12:42:40 2017 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 80A57131676 for ; Mon, 17 Jul 2017 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0gFaIzD5BjCY for ; Mon, 17 Jul 2017 12:42:37 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 38625131B15 for ; Mon, 17 Jul 2017 12:42:14 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id x125so52070625ywa.0 for ; Mon, 17 Jul 2017 12:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VcFXiDMY2A2vOicxYdoprnyfuGG8NDnMx4BPlfBXoGA=; b=iJ6rsovV5fFnr+87PAPrFU2F3lKOmVRjUlqS/dkOuI3tzEi8FgvDuYXGz7cR8+YQQ4 Ylds3CviCXOfC11DJB5LzM27E9xFtTwD4iDH1j9vdzk7pkwei9EBR0OIp8O1B2vGTaJI 7dcvFmed++gUOBDpMpRqr36MHepegzRy6b3wkDHqzt8We7YD/Ra9nxIr2ucI8eQSCfNO R04hzOu/v0CxZ291PI4I+mbP1awuG+gFKKhjjAn2O5CjuKPulTycdxDW4ZGxJmtGnEYb SJtLvGTvWX6jidDdC2+fGWcrxcjb/8j/BsxQmEEDN43R1BGWKrfgNNV+GBnm1Y/Ktg0p MGOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VcFXiDMY2A2vOicxYdoprnyfuGG8NDnMx4BPlfBXoGA=; b=akOEszb5DdDSu/+5Ul4Al4bYI+LoErrkSYEsPwzsylCe2QKMgCzw1Ti6jTX+zaPwR2 UOxgI5o/U0WhVrHAUjsEYwh98KKF2zBgljNp/6+B4PmP3msaf0pQGjhLteWhha99cJo1 9UAPxC4tS435wtOgivmLt3j4VPxbW2DZPKUKPJAHsEwnDr7mWvvgBGigTibO805fkgZ/ 95PkkIUUbSbRVo9aK/60nZOM4l0dUcAWn4+5sTepXQMoVacKJTVc4QwMgoNsgy3gwKN6 9RCB3BBZ3ZKZZzv3Ym+5IKMXGPNinYBTGXUx0HgBjkUrb7ULfynM+04TRBL+i9GB8N8m pZxQ== X-Gm-Message-State: AIVw112BBmwCbImLambjhnQgtNkdUqZYB6xm6IJceo4iAZpkGqHAsQ9V CXZ9DANzQPyQc/u/+dnImC6Yz3kq4xwF X-Received: by 10.129.92.3 with SMTP id q3mr16809854ywb.298.1500320533205; Mon, 17 Jul 2017 12:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Mon, 17 Jul 2017 12:41:52 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 18 Jul 2017 04:41:52 +0900 Message-ID: Subject: Re: What is the correct behavior To: Rao Shoaib Cc: IETF IPv6 Mailing List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114d6f027617960554889818" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 19:42:38 -0000 --001a114d6f027617960554889818 Content-Type: text/plain; charset="UTF-8" I'm not sure there is any standards behaviour applicable here. The device is likely receiving many other non-0x86dd frame types as well (LLDP, 802.1q, ...). If you don't want them, probably best to just filter them. On 18 July 2017 at 04:33, Rao Shoaib wrote: > I am looking at a system which is configured for IPv6 only but sits in a > network that serves both IPv4 and IPv6. When an IPv4 packet with a > destination broadcast address is sent out (in this case DHCP) the system > accepts it and since it does not have any route to the sender it prints the > Linux Martian packet message. > > Sure, we can turn off the Martian message and maybe the system should be in > an IPv6 only network but the question that is being asked is that is it > correct for the system to accept and process an IPv4 broadcast packet in the > first place ? Can the experts help me out here. > > Thanks, > > Shoaib > > Please include me in the reply as I am not subscribed to the list. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a114d6f027617960554889818 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgwnsJYQ601MCOSrWABDbRKNqMoMAmbyrv TsL1ZMc5WGswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE3 MTk0MjEzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAlMYKcLQM9YQy/r9EjJMpFpU5aGkzXiOfJZGGjtXDB6XT/KMPnB JE06y9V2AAk4OaluIG91dVUdvXanyM3sCs6ImzEzGEEKO+HF+KrJwxXvOces0C3qxR81NOov1Y8z NEGJJuXi6SjoQZrGovgQJ12XwsA0qia4d4jht9YD3YypiWxjJ0rcEWqdtB403FgLOua2ca+2grci mKmsIdpcnkYDHS9bb12ooWNcWFXY9OwE2qaHbiAVG1BvW2ivMvzqLpppBTB8KYfig331otmmskIw rV5kwh1nbkQF1IPm1If4yQHNapWbIEs+AmeRZlpeKRVkRDnToQ4osxKG82I2VSc= --001a114d6f027617960554889818-- From nobody Mon Jul 17 12:48:39 2017 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 3B5B912EC01 for ; Mon, 17 Jul 2017 12:48:38 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XVtM1Nxd0rgc for ; Mon, 17 Jul 2017 12:48:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 F23C2126BF0 for ; Mon, 17 Jul 2017 12:48:36 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6HJmZiR009744 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2017 19:48:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6HJmY2f011029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jul 2017 19:48:34 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v6HJmYOR026108; Mon, 17 Jul 2017 19:48:34 GMT Received: from [192.168.1.20] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jul 2017 12:48:32 -0700 Subject: Re: What is the correct behavior To: Erik Kline Cc: IETF IPv6 Mailing List References: From: Rao Shoaib Message-ID: <02663898-a5f6-6b48-3da3-7576cadc3332@oracle.com> Date: Mon, 17 Jul 2017 12:48:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 19:48:38 -0000 On 07/17/2017 12:41 PM, Erik Kline wrote: > I'm not sure there is any standards behaviour applicable here. > > The device is likely receiving many other non-0x86dd frame types as > well (LLDP, 802.1q, ...). If you don't want them, probably best to > just filter them. Sure, filtering is an option but don't you think handling of ipv4 broadcast needs to be specified by IETF so all implementations do that the same thing. I want to submit a patch for the Linux kernel to not process the packet, but since the standard does not say anything it will most likely be not accepted. Rao. > > On 18 July 2017 at 04:33, Rao Shoaib wrote: >> I am looking at a system which is configured for IPv6 only but sits in a >> network that serves both IPv4 and IPv6. When an IPv4 packet with a >> destination broadcast address is sent out (in this case DHCP) the system >> accepts it and since it does not have any route to the sender it prints the >> Linux Martian packet message. >> >> Sure, we can turn off the Martian message and maybe the system should be in >> an IPv6 only network but the question that is being asked is that is it >> correct for the system to accept and process an IPv4 broadcast packet in the >> first place ? Can the experts help me out here. >> >> Thanks, >> >> Shoaib >> >> Please include me in the reply as I am not subscribed to the list. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Mon Jul 17 13:34:02 2017 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 D135D126CD6 for ; Mon, 17 Jul 2017 13:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 4ktQ22qpcOKF for ; Mon, 17 Jul 2017 13:33:55 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 0C2A4131B33 for ; Mon, 17 Jul 2017 13:33:55 -0700 (PDT) Received: from [31.133.155.189] (dhcp-9bbd.meeting.ietf.org [31.133.155.189]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v6HKXoVN004199 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Jul 2017 13:33:52 -0700 Subject: Re: rationale for the default of DupAddrDetectTransmits To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Erik Nordmark Cc: IPv6 IPv6 List References: From: Erik Nordmark Message-ID: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> Date: Mon, 17 Jul 2017 22:33:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYeypaOJMVEfMpGSFaF0OUXfH+IikUTnX+mg/DijSFJcnugAZAC/ECZonFg8uhlBPTDfpiOVoDxIYDx4fwpAdYkpJIXXN61MeA= X-Sonic-ID: C;GBi+PS9r5xG/HcGbEi49jA== M;4Bu6Pi9r5xG/HcGbEi49jA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:33:56 -0000 On 07/17/2017 08:40 PM, 神明é”哉 wrote: > I understand the failure mode you mentioned above, and I agree just > increasing DupAddrDetectTransmits wouldn't make DAD more robust. > Isn't it consistent with my main point? Yes, we're on the same page. Regards, Erik From nobody Mon Jul 17 13:35:38 2017 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 C9E1A131C1F for ; Mon, 17 Jul 2017 13:35:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 p-wgbTKjmkSQ for ; Mon, 17 Jul 2017 13:35:35 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 C25E5131C4B for ; Mon, 17 Jul 2017 13:35:34 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u5so318858pgq.3 for ; Mon, 17 Jul 2017 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=92vnmq8yzM7Zp38hgVdRVyd7+sZvyf2gI3czzQj+wMY=; b=Nq1j6dafxpS88QlgMTuslU8SXgM+E/XZZFQsgTWUWIRavxy/OzWywBlE+r301YPt+h ISFljJ5wo1XUPsReX3IT7iZ4cnlOFj88QesjKBAcBK+dH/Okza926d9kDA1iQt5JxS6I xImBovxt8NjrGeXWA1J6e8Yj9PL8LTdqc5JdW9sEldyYg8Akp8/haRGvsZUtXoPC7eQx buTrNXWRbXrA318r+3n1nmeN9md8RB3m+mrN0CpODLCjfbjZxbR01JqR8rIDguie60jT CbESzmWl3Or6Gl+Nm+JoWt5dfgv9h2o94uH11A1W6FR2dEIAkb5QauuoG+Wa6S7jLMC2 JxiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=92vnmq8yzM7Zp38hgVdRVyd7+sZvyf2gI3czzQj+wMY=; b=WUaZN8zbI0bAyDs7M4hG0WgfcyXKpi2gHKLirX14cAhi2F5hDb3mGGUnLPZutbBPwP gZWtpRqi7yxjbuZVgR9SM/fYcvN203tCBrsXOK3jsxE1INJUeTBVZt9xbTyinn3LamYN vGDI6lA8NidG9wUAYI6AHyU8Ypn9Z8LXY1UCnOgT5jB2fhT28LalYP35i3F9VmfYw9Jp TirjHBB60/rV6EyjJgY2rExxWjxS54LwMBrP5bwKrH+qgIrE83z1XjYtbdOs/89RVN48 MvlG1DlY1DmFAVtyA6GO+wJvjlrdKns/+7ITZ7IGJqO9U954j1p/xb0lbRS/MGvym5/a GZPQ== X-Gm-Message-State: AIVw110nLPHms7mw377RR1C63Kb65C96WHwiIPNi929zMKy+r4pHM0jn IJblSzA9Wcr06ueg X-Received: by 10.99.174.14 with SMTP id q14mr19371103pgf.111.1500323734207; Mon, 17 Jul 2017 13:35:34 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t4sm216229pgs.22.2017.07.17.13.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 13:35:33 -0700 (PDT) Subject: Re: 64bit IIDs are both recommended and required To: Alexandre Petrescu , Mark Smith Cc: 6man WG References: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 18 Jul 2017 08:35:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:35:37 -0000 On 17/07/2017 23:54, Alexandre Petrescu wrote: ... >> It can't because the cellular or ADSL provider doesn't want the device >> to be able to. If they did, then they should have no issue with >> providing multiple and enough /64s to do so, in particular given how >> cheap /64s are. > > I can agree to that, but it does not make it less of a Problem. > > Further, I heard today other problems during the meeting: > - network management: ANIMA work may need longer-than-64bit prefix > lenghts That's not a real problem. Anima doesn't need longer prefixes for address allocation purposes - it really allocates /128s directly to nodes in the autonomic control plane. It does need to use longer prefixes for routing within the autonomic control plane, consistent with BCP198, but that isn't a problem at all. (This has become clear since yesterday's meeting.) > - Android emulator may not allow for NAT You'll have to explain to me why I care about that. Brian > > Alex From nobody Mon Jul 17 13:59:33 2017 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 4B2EF131C6A for ; Mon, 17 Jul 2017 13:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 qJAQ7UV7Bdfh for ; Mon, 17 Jul 2017 13:59:21 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 9BF93131C5D for ; Mon, 17 Jul 2017 13:59:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6HKxJm0023630; Mon, 17 Jul 2017 22:59:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7C9120587C; Mon, 17 Jul 2017 22:59:19 +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 8E9F72057E5; Mon, 17 Jul 2017 22:59:19 +0200 (CEST) Received: from [132.166.84.163] ([132.166.84.163]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6HKxFI2005788; Mon, 17 Jul 2017 22:59:15 +0200 Subject: Re: 64bit IIDs are both recommended and required To: Brian E Carpenter , Mark Smith Cc: 6man WG References: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> From: Alexandre Petrescu Message-ID: <4ad19dd3-e9b4-ebbc-131f-598f161b3361@gmail.com> Date: Mon, 17 Jul 2017 22:59:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:59:25 -0000 Le 17/07/2017 à 22:35, Brian E Carpenter a écrit : > On 17/07/2017 23:54, Alexandre Petrescu wrote: > ... >>> It can't because the cellular or ADSL provider doesn't want the device >>> to be able to. If they did, then they should have no issue with >>> providing multiple and enough /64s to do so, in particular given how >>> cheap /64s are. >> >> I can agree to that, but it does not make it less of a Problem. >> >> Further, I heard today other problems during the meeting: >> - network management: ANIMA work may need longer-than-64bit prefix >> lenghts > > That's not a real problem. Anima doesn't need longer prefixes for > address allocation purposes - it really allocates /128s directly > to nodes in the autonomic control plane. It does need to use longer > prefixes for routing within the autonomic control plane, consistent > with BCP198, but that isn't a problem at all. (This has become clear > since yesterday's meeting.) > >> - Android emulator may not allow for NAT > > You'll have to explain to me why I care about that. The person who has to explain that is the person who expressed that view at the microphone. Lorenzo? Alex > > Brian > >> >> Alex > From nobody Mon Jul 17 14:42:29 2017 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 141D6126CC7 for ; Mon, 17 Jul 2017 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El9yG4wxgDzg for ; Mon, 17 Jul 2017 14:42:26 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30027124234 for ; Mon, 17 Jul 2017 14:42:26 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id B603C5D7 for ; Mon, 17 Jul 2017 21:42:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHc8Wd6iZReF for ; Mon, 17 Jul 2017 16:42:25 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 7172A9CC for ; Mon, 17 Jul 2017 16:42:25 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id 35so1549611uax.6 for ; Mon, 17 Jul 2017 14:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3KDUbPar7p9kgm4g5K6EH8VOp1i8//VegSzjkyKoi/o=; b=ck+U6TPhObjaY/Xd+LkEIPxnOb/q5yqFnoBn6Dm13ssr/pMSSNmYmfYxSNHU1j1QEL Ywmb7WelZD4zhYrth9POvWE9qd8HmTyt+eEguV5CJE5wxctfbhtIJPBgKTF21JwgEABb pGixyBF71o3c6imOF+as1Z4rYvmU9AGlJ8vEHwbfVttg9d3Az1whU2knqwX+O+M2xwd+ zEaDOTb2x+M6qbeWwKN2bT4NClKrtfFcc7ve2B8179MBhUBIAOSwhkcJDzQ9SNzNT/lB 8tsbxqr/xHs46zaK5oj0449TsaHEJd7sBEcxec12uoYxVGkUDE07aV/tcw3362fVVgko Fexw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3KDUbPar7p9kgm4g5K6EH8VOp1i8//VegSzjkyKoi/o=; b=Q20cLXeFP0h4m60in1cqgcsoyldRHN4nMdcUC8BA+iv5YdaxMWi3PaMwkzDWwGhMMW BqkBvwzFq4yIZI0pkWk2deeYXHeow0pJoCpPQBH/mY2wKTVYroFtZ58luD69SEOzqMlc kGgrOhUmDcCtyqfNmkQAQCfXJWbHsswGyQa+x+O8+N4+37448IAVycFGtrk3x2g3XEzR YJeGFiNyViOJIVMLT9WtQVWWK6trJQGH50lzR396C204KXNboUVWc/mRRS0w4BTBDBSA hTKA9RF83FF/2il4oBI1L3RScJKyT8O0WctNddiqzZLv+2bVIAQgnaXAhPl4+oT6Az7U iEJg== X-Gm-Message-State: AIVw111ksatR8MyXMsKRifV/jfwqOT/Tq1wqBTZ5cp/HoiAzZUJb3ONv /SAhA6Lm4y8zR1dQnx4YfDd8XtwNLAJc4ol7iCPM2WbApe8zodt0AlQYC29lXa+P+Dg4nZNqfpG ahl0mwjE5YXALuac= X-Received: by 10.176.86.204 with SMTP id c12mr4543938uab.126.1500327744553; Mon, 17 Jul 2017 14:42:24 -0700 (PDT) X-Received: by 10.176.86.204 with SMTP id c12mr4543928uab.126.1500327744320; Mon, 17 Jul 2017 14:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.144 with HTTP; Mon, 17 Jul 2017 14:42:23 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: David Farmer Date: Mon, 17 Jul 2017 16:42:23 -0500 Message-ID: Subject: Re: To: Lorenzo Colitti Cc: Bob Hinden , IPv6 List Content-Type: multipart/alternative; boundary="94eb2c1b048a3fbd0a05548a462e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:42:28 -0000 --94eb2c1b048a3fbd0a05548a462e Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 8:24 PM, Lorenzo Colitti wrote: > On Tue, Jul 4, 2017 at 2:36 AM, Bob Hinden wrote: > >> I published a new 6man w.g. version (-09) of the RFC4291bis draft. See >> links below. >> > > Actually, after lots of thought, I object to this document in its current > form, specifically due to the text "or by exceptions defined in standards > track documents". I feel that this text is a net negative in terms of the > functionality provided by the protocol to its users. > > Allowing IIDs shorter than 64 bits has no value that I can see that is not > already covered by the exception for manual configuration. Pretty much the > only thing we can do with it is support SLAAC with shorter IIDs, and > *nobody* has yet answered the question of how that would be beneficial in > the long therm. > > In the short term we might tell ourselves that shorter IIDs will allow > users to extend the network at the edges. But the reality is that in the > long term we'll just see some networks provide the minimum allocation that > is accepted by hosts. (There are examples of this today, in the case of > cable networks that only provide a single /64 to the home.) Because hosts > adapt to the lowest-common denominator network, over time the only effect > is to move the commonly-used subnet boundary between subnet prefix and IID > from 64 towards 128. This will be accelerated by networks whose policies > include limiting the number of devices allowed on a particular connection. > (Again, there are examples today: enterprise networks that want one GUA per > host, mobile carriers have a requirement to allow only x devices to tether > behind a smartphone, etc.) I don't think that's a use case. > > So, what are the other use cases? If there are no use cases, we should not > make this change. > > I understand Brian and David's position that this is just a parameter and > that the architecture is inconsistent, but better an inconsistent network > architecture than a degradation of function. > I've begun to think there are two real problems here; 1. RFC4291 categorically says architecturally IIDs are 64bits, and seems to imply this is the case for all components of IPv6. While it is the case for several components of IPv6, it is not the case for other important components. Neighbor Discovery, DHCPv6, and Routing, etc... are not architecturally based on 64bit IIDs at all, in fact they are clearly based on IIDs of any length. 2. The fact that some components of IPv6 are architecturally based on 64bit IIDs doesn't mean that operationally IIDs are always required to be 64 bits. Rather than implying that operationally IID are required to be 64bits, how about simply stating that operationally 64 bit IIDs are recommended. This eliminates the need to enumerate all the exceptions, which probably isn't something an architectural document should be doing. So, I would propose the following for RFC4291bis; Several components of IPv6 are architecturally based on a requirement that Interface Identifiers are 64 bit long except if the first three bits of the address are 000. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. However, other components of IPv6 are architecturally based on Interface Identifiers of any length, most importantly Neighbor Discovery [RFC4861]. Neither of these two architectures override or invalidate the other. Accordingly, 64 bit Interface Identifiers are recommended for operational use. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c1b048a3fbd0a05548a462e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 8:24 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On T= ue, Jul 4, 2017 at 2:36 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
I publishe= d a new 6man w.g. version (-09) of the RFC4291bis draft.=C2=A0 See links be= low.

Actually, after lots of thought, I= object to this document in its current form, specifically due to the text = "or by exceptions defined in standards track documents". I feel t= hat this text is a net negative in terms of the functionality provided by t= he protocol to its users.

Allowing IIDs shorter th= an 64 bits has no value that I can see that is not already covered by the e= xception for manual configuration. Pretty much the only thing we can do wit= h it is support SLAAC with shorter IIDs, and *nobody* has yet answered the = question of how that would be beneficial in the long therm.

<= /div>
In the short term we might tell ourselves that shorter IIDs will = allow users to extend the network at the edges. But the reality is that in = the long term we'll just see some networks provide the minimum allocati= on that is accepted by hosts. (There are examples of this today, in the cas= e of cable networks that only provide a single /64 to the home.) Because ho= sts adapt to the lowest-common denominator network, over time the only effe= ct is to move the commonly-used subnet boundary between subnet prefix and I= ID from 64 towards 128. This will be accelerated by networks whose policies= include limiting the number of devices allowed on a particular connection.= (Again, there are examples today: enterprise networks that want one GUA pe= r host, mobile carriers have a requirement to allow only x devices to tethe= r behind a smartphone, etc.) I don't think that's a use case.
=

So, what are the other use cases? If there are no use c= ases, we should not make this change.

I understand= Brian and David's position that this is just a parameter and that the = architecture is inconsistent, but better an inconsistent network architectu= re than a degradation of function.

I've begun to t= hink there are two real problems here;

=
1.=C2=A0 RFC4291 categorically says archit= ecturally IIDs are 64bits, and seems to imply this is the case for all comp= onents of IPv6. While it is the case for several components of IPv6, it is = not the case for other important components. Neighbor Discovery, DHCPv6, an= d Routing, etc... are not architecturally based=C2=A0on 64bit IIDs at all, = in fact they are clearly based on IIDs of any length.=C2=A0

2. The fact that some= components of IPv6 are architecturally=C2=A0based on 64bit IIDs doesn'= t mean that operationally IIDs are always required to be 64 bits. Rather th= an implying that operationally IID are required to be 64bits, how about sim= ply stating that operationally 64 bit IIDs are recommended. This eliminates= the need to enumerate all the exceptions, which probably isn't somethi= ng an architectural=C2=A0document should be doing.

So, I would propose the follow= ing for RFC4291bis;

Several components of I= Pv6 are=C2=A0architecturally=C2=A0b= ased on a requirement that Interface Identifiers are 64 bit long except if = the first three bits of the address are 000. The rationale for using 64 bit= Interface Identifiers can be found in [RFC7421]. However, other components= of IPv6 are=C2=A0architecturally= =C2=A0based on Interface Identifiers of any length, most importantly=C2=A0N= eighbor Discovery [RFC4861]. Neither of these two architectures override or= invalidate the other.=C2=A0Accordingly, 64 bit Interface Identifiers are recommended for operational use.

Thanks= .



=

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
Networking & Telecommunication Services
Office of Inform= ation Technology
University of Minnesota=C2=A0=C2=A0
2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, M= N 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c1b048a3fbd0a05548a462e-- From nobody Mon Jul 17 15:01:43 2017 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 46711126C23 for ; Mon, 17 Jul 2017 15:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 eDM70y1H_s7O for ; Mon, 17 Jul 2017 15:01:38 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238DB126BFD for ; Mon, 17 Jul 2017 15:01:37 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 707CC58C4B1; Tue, 18 Jul 2017 00:01:33 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 34432B0C5F6; Tue, 18 Jul 2017 00:01:33 +0200 (CEST) Date: Tue, 18 Jul 2017 00:01:33 +0200 From: Toerless Eckert To: David Farmer Cc: 6man WG Subject: Re: Stupid 4291 question Message-ID: <20170717220132.GA7498@faui40p.informatik.uni-erlangen.de> References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 22:01:40 -0000 inline On Mon, Jul 17, 2017 at 11:24:45AM -0500, David Farmer wrote: > On Mon, Jul 17, 2017 at 10:14 AM, Toerless Eckert wrote: > > > So, if i create a loopback interface with a /128 IPv6 global address > > to use for various purposes (routing protocol identifier, mgmt address, > > etc. pp), > > how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK > > common > > practice in networks. > > > > To me it looks as if it would violate 2.5.1 and i also haven't seen > > something in the RFCs > > updating 4291. But i just browsed quickly. > > > > Thank! > > Toerless > > > > It's a little more complicated, simply assigning a /128 or other on-link > prefix length to any interface, loopback or otherwise, doesn't imply there > is not a 64bit IID is being used. > > If each loopback /128 is assigned out of it's own unique /64, you are > fine. Each link has a /64 and the IIDs from that /64 are only associated > with that link, the loopback interface. The whole /64 just isn't on-link, > only the one /128 in this case. However, if you assign any /128s from that > /64 to a different loopback interface on that or any other router, then you > violate section 2.5.1 of RFC4291. > > However, I think it is fairly common practice to assign loopback interfaces > for a whole network out of a common /64, maybe assigning point-to-point > router links out of that common /64 too, and that is where the problem is, > all of the 64bit IID are not associated with the same link, not that act of > assigning a /128 to a loopback by itself. Right. That would have been my interpretation as well. > At least that is my interpretation of it. Now the current RFC4291bis has an > exception for manually configured interfaces. I think most loopback > interfaces are manually configured. > However, I think it would be better to > call out loopback interfaces explicitly, just so we don't have to get into > the philosophical argument about whether or not generating configs out of > puppet or something like that is actually manual configuration or not. You're not allowed to do this from an SDN controller *rotfl* Well, in IP multicast i also started to explain to folks a long time ago how to do something called "prioritycast" which we use for redundant addresses in Bidir-PIM (or even for other use cases with predictable selection of instance). Eg: Instead of anycast where everybody converges to the closest instance of a redundant address (aka: all instances have /128), you need to make sure that everybody converges to one instance. The trick of course is that you would assign to the primary instance a /128 address on a loopack and distribute into routing protocol), to the secondary a /127, and so on (rarely more than three redundant instances use). Aka: in all these "inside baseball", oops: "inside network infrastructure" addressing tricks its irritating to have to go back to this IID /64 consideration in rfc4291. And its also somewhat confusing to read the section in 4291 about "in routing, any prefix is permitted" and then trying to figure out how to create any form of prefix given how they all needed to be a prefix on some interface and those prefixes could be > 64 but would need to still waste each one a /64 due to 2.5.1, except .... oh well, how about these prioritycast/anycast cases explained above. Is that actually breaking rule 2.5.1 ? Is not mean to be a separate logical subnet, its just a redundant instance of a single logical subnet distributed over different routers. Cheers Toerless From nobody Mon Jul 17 15:05:17 2017 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 0BE76126C23 for ; Mon, 17 Jul 2017 15:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 0M4x09lipV-E for ; Mon, 17 Jul 2017 15:05:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAB7131CCF for ; Mon, 17 Jul 2017 15:05:13 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BDE0458C4BB; Tue, 18 Jul 2017 00:05:09 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7FABEB0C5F6; Tue, 18 Jul 2017 00:05:09 +0200 (CEST) Date: Tue, 18 Jul 2017 00:05:09 +0200 From: Toerless Eckert To: Ole Troan Cc: ipv6@ietf.org Subject: Re: Stupid 4291 question Message-ID: <20170717220509.GB7498@faui40p.informatik.uni-erlangen.de> References: <20170717151453.GV3889@faui40p.informatik.uni-erlangen.de> <43BF6C78-AAB9-408C-BE18-A941A94C4770@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BF6C78-AAB9-408C-BE18-A941A94C4770@employees.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 22:05:15 -0000 Ole: In your example, would you be allowed to have a /128 with the same 2001:db8:: on another router according to 4291 ? On Mon, Jul 17, 2017 at 06:44:36PM +0200, Ole Troan wrote: > As a general note it might be worth remembering that the address/prefix-length notation is just a short-hand that is commonly used in implementations. > > An address is always 128-bit and does not need to have an associated prefix-length with it. > > To spell out Toerless' example: > Interface loopback0 > ipv6 address 2001:db8::1 > ipv6 on-link prefix 2001:db8::1/128 > > In this case specifying an onlink prefix length of 128 is of course redundant. > > But you can of course specify an IPv6 address on an interface without any associated on-link prefix. > > Cheers > Ole > > > On 17 Jul 2017, at 17:14, Toerless Eckert wrote: > > > > So, if i create a loopback interface with a /128 IPv6 global address > > to use for various purposes (routing protocol identifier, mgmt address, etc. pp), > > how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK common > > practice in networks. > > > > To me it looks as if it would violate 2.5.1 and i also haven't seen something in the RFCs > > updating 4291. But i just browsed quickly. > > > > Thank! > > Toerless > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Mon Jul 17 16:10:11 2017 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 6F5BC131BD9 for ; Mon, 17 Jul 2017 16:10:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ngnQQ97X1b_g for ; Mon, 17 Jul 2017 16:10:09 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 38887126CC7 for ; Mon, 17 Jul 2017 16:10:09 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q85so1998006pfq.1 for ; Mon, 17 Jul 2017 16:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FGiG5jkW5rJJrukEnEzSwgqpka86M2zjh5jqXyppFDc=; b=LAShiNAmWTwayY36XsuoLX1vfNbScjl98ps2pUO79xZOybdSuIR1q7LlabnW4XmnvB sCOE48tPud4c+u9McP7jnKtnhi/ZLEGEyDoEkXea/4dE7egq0HQPqS2gUaJJOe7d8DzN 3sznCGSuXRnLFsHM1n/w2tkANvCsCssTDHut7npD3ZvymI4V3+zjhgs6kAimxVeTogjP jHTW63RShoYxaH3XMMskGStXED+YjaoXI5dnQ4ulxKBlTt0063Te6QTT/cuSvcCiF0wD bh4+teCodBOZ9fPaVEughAtrVya+NlGjYRqLqeKrfjCMgFh6csp8hv+FZ9ZYXP02ACPA 4ytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FGiG5jkW5rJJrukEnEzSwgqpka86M2zjh5jqXyppFDc=; b=fvFhhCV9R+Bs7AQIHQcTnOe/d98644rdZx3Kg9HV86Q0GZZU1e8lijxo7OZ2RiyUIr hW8tHbxjlGcqN1vm2L5IC6Qn8nrc0C1Oy/tXvjO/X4L9d4Uw6PhoCdv9XZBfQmJKcFkW JEFx7YYikIckKEnueOzbsG7nW8Ii1kUu3LKcLmWFq7JyShAp5USHgg8SutcAKHtAeFjG 44jEBdCILI03ZdYt+Tdg1JzZIas7ah0hu2ryMS6nOLTL9qGvYCDFk1waZVfVTiqIlESW 4+8Y0L+oaa5swop7sc9XaGWX206mpPR+XKL9xsA/41GBWCMJwMQUosUnWrrgGC+UdRNi rJag== X-Gm-Message-State: AIVw112eUIMuNq/FEIxQ4VThKJ9+0wNfwBBbp2f2DCPJL6rLpF3rvM++ vKIWgD2ikeDxPa6f X-Received: by 10.98.11.135 with SMTP id 7mr21279851pfl.45.1500333008611; Mon, 17 Jul 2017 16:10:08 -0700 (PDT) Received: from [130.216.38.122] (sc-cs-316965.cs.auckland.ac.nz. [130.216.38.122]) by smtp.gmail.com with ESMTPSA id f15sm570973pga.5.2017.07.17.16.10.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 16:10:07 -0700 (PDT) Subject: Re: rationale for the default of DupAddrDetectTransmits To: Erik Nordmark , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 18 Jul 2017 11:10:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 23:10:10 -0000 On 18/07/2017 08:33, Erik Nordmark wrote: > On 07/17/2017 08:40 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >=20 >> I understand the failure mode you mentioned above, and I agree just >> increasing DupAddrDetectTransmits wouldn't make DAD more robust. >> Isn't it consistent with my main point? > Yes, we're on the same page. Fair enough. My original point was that having DAD be less reliable than basic ND, under adverse conditions such as an overloaded 802.11 network, is IMHO a real problem. Yes, duplicates should be extremely rare but they can also be extremely harmful. Brian From nobody Mon Jul 17 16:42:48 2017 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 65138129ACD for ; Mon, 17 Jul 2017 16:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RI16cJjxLAsC for ; Mon, 17 Jul 2017 16:42:46 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 4728D12441E for ; Mon, 17 Jul 2017 16:42:46 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id z22so5354111uah.1 for ; Mon, 17 Jul 2017 16:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UWnw3+1sXJuCBDSt9lghFWa/yugJ31ZlwewlzLat6GI=; b=cb/ZUPT9DSt46H6e29Fmr/4xmnYTnTDBSP/oFIRNtoTmMe2g/9xuj71Z1Uh7Vxmyn2 W2IdEcxK6ns0FMQ3eNRAG0AcQOs64aOgHk57g9Ok/xMy2MCZvgWplyWrGs5JyV5KIm8Z FOSdVotmaULfo21K5TS3snjDcEZnWquXcE0HT775cN0epf3S44OgNwE4heUXZtXE37Y7 phRatfrh3R3H68IA2pBeWLrCn6fW1EcoXnl9F1OyBFzzlK6l1LYAAFvAVjJWhm5IKqUT w/WOMEvL/ldTWvu5Dm6vZgOGjnYy1aN3yTWfohhzhXSONFRhRR78nhBGefnWu6eikoBM S1gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UWnw3+1sXJuCBDSt9lghFWa/yugJ31ZlwewlzLat6GI=; b=cH31JnwhUjb/BspKAWClIeBfMwVpoWy8PwhGzu7F3CqcK07S6l6yQXjg8oqYfTuMRJ xX3CyBe6iIgd5By1NNybGRjM3iSEJ/l/FDvUo9R265LSP6Gqr5Z6cdt4gnkniYkTSaBg OCFko8XotiO4aMZOqN1cHpcmtrAs4gJykZlQmP3Muzu2vB4CHrwuvZfcMRRPpTnpbx3o EYSqneSaOkcvUaXTKYcMoh0gGIhCVBQgc7vg1YZdIl2eameRH4G1F35pzPo65dXTMvw0 VkGXfZcaL2a61vcxmyo1Ms8hIRSJuPZ4vQW5ZhgeQcpIB1seRg/tyt34plvfHypNrIND LO6g== X-Gm-Message-State: AIVw112ByJe6gei5YGE1oiJBfVK100Hw8U6Bi79rIbbNv8q9ID72xa2O FcF2roc1su8iOZWW4Mc4OO3ofBPs8w== X-Received: by 10.176.92.108 with SMTP id a44mr39201uag.88.1500334965349; Mon, 17 Jul 2017 16:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.94.135 with HTTP; Mon, 17 Jul 2017 16:42:12 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Mark Smith Date: Tue, 18 Jul 2017 09:42:12 +1000 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Brian E Carpenter Cc: Erik Nordmark , =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 23:42:47 -0000 On 18 July 2017 at 09:10, Brian E Carpenter w= rote: > On 18/07/2017 08:33, Erik Nordmark wrote: >> On 07/17/2017 08:40 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> >>> I understand the failure mode you mentioned above, and I agree just >>> increasing DupAddrDetectTransmits wouldn't make DAD more robust. >>> Isn't it consistent with my main point? >> Yes, we're on the same page. > > Fair enough. My original point was that having DAD be less reliable > than basic ND, under adverse conditions such as an overloaded > 802.11 network, is IMHO a real problem. Yes, duplicates should > be extremely rare but they can also be extremely harmful. > So it makes me wonder if DAD was supposed to be to detect an error that is considered fatal or just to issue a warning about what might be a tolerable situation. This text from RFC4862 reads like it is to detect an error considered fatal, so it should be reliable in most cases except perhaps when the link is beyond its designed capacity (and therefore other link capacity related failures are likely to occur too.) "A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface, and the node SHOULD log a system management error." In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on a link before IPv4 DAD (and DHCPv4) became available. I'd much rather reliable DAD and failure of DAD to be considered fatal. Regards, Mark. From nobody Mon Jul 17 18:15:38 2017 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 A04D012EAAA for ; Mon, 17 Jul 2017 18:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jHzIVhvUaEq4 for ; Mon, 17 Jul 2017 18:15:35 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 292351277BB for ; Mon, 17 Jul 2017 18:15:35 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so6698775uax.3 for ; Mon, 17 Jul 2017 18:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o08mkSQgHB7uv2/oky6vVQe0wuBmy13IWjfLeHNYBvU=; b=JSL4IYxpaAWqHtUaT6PnetBmsGIP4kq/ZzeYs9aCA0xRuTkGn3ZSoH0mLAC00qd2hX SR1R0DnF4zB21UD1uHP/Cu4npqCpiRrTwTr+2qUw/vM1iXPd7cTorGKRpzNy3wipCVaE 8mia3M1GyzrKM3U8GEY+otf4JxZZaHwHYd/gnqPKwoCnlvVrUcMFiqs/Q/eTJ2W/8fgj jcWN6oeSh2gKXqvD8mC6SbPDmY3an4M41dOguGSIhuo00Ii20oHMYP9GNVTZl2WgmPXI Mfk7ZlXReS2AZBiOXIjnlkRYV5mzZcUIiky5FYRWAN+Ucjuk8bJ+YuPwjqui5jSY4VOA WBjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o08mkSQgHB7uv2/oky6vVQe0wuBmy13IWjfLeHNYBvU=; b=BpQsKU8aCFwBzgaKybx2gFa6AAQxlurxo/l91BpOUJAAQB4X1f6mfxqchn51Cb71/P sM2+AdoAEX783YL6X16x7yrzpbFTGqFSDjPgzpEqmVhDYb0pu5qxAOMQ3VFRk0jRWGAt PCMC9KghDYiwjQAh32l3hGZGOOil2Z0RXRB/mxpX7/eihzGNQa6++s/Dmz4ODV0ZAuGZ 5l4PRRQZBTFpsLCXB9pkjw6f8lAxf52lFNXKGB2b7oj35aEm4Qcy5Ztsu2H5Lni0Cp+e ySkOKzXKWy4JrXE38NMvdRnLnHimzbhulmLdcWleYBwRJv13z8UBvfT3iHhVe4N0wit8 R+xw== X-Gm-Message-State: AIVw113VqZGMPTrrZq2EusH0Gd9LU91CxJqgEYSqqUUG18h0Z+ZCCm06 2LeAGOUhVi07CxP64stRQs3r9Wm20Q== X-Received: by 10.159.53.45 with SMTP id o42mr224607uao.84.1500340534179; Mon, 17 Jul 2017 18:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Mon, 17 Jul 2017 18:15:03 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 18 Jul 2017 11:15:03 +1000 Message-ID: Subject: Re: What is the correct behavior To: Erik Kline Cc: Rao Shoaib , IETF IPv6 Mailing List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 01:15:37 -0000 On 18 July 2017 at 05:41, Erik Kline wrote: > I'm not sure there is any standards behaviour applicable here. > > The device is likely receiving many other non-0x86dd frame types as > well (LLDP, 802.1q, ...). If you don't want them, probably best to > just filter them. > A related issue might be that DHCPv4 specifically suffers from a chicken-and-egg problem, meaning that it is processing IPv4/UDP packets before IP has been configured. Consequently the DHCPv4 servers sniff packets off of the wire and do their own IPv4/UDP processing. So even though your interface to the network isn't "IPv4 enabled" by having an IPv4 address, if a DHCPv4 server is listening on that interface then IPv4 packets such as broadcasts will be making it into the DHCPv4 server process and then the DHCPv4 server process might be passing them onto and into the IPv4 protocol implementation in the kernel, causing the martian error. > On 18 July 2017 at 04:33, Rao Shoaib wrote: >> I am looking at a system which is configured for IPv6 only but sits in a >> network that serves both IPv4 and IPv6. When an IPv4 packet with a >> destination broadcast address is sent out (in this case DHCP) the system >> accepts it and since it does not have any route to the sender it prints the >> Linux Martian packet message. >> >> Sure, we can turn off the Martian message and maybe the system should be in >> an IPv6 only network but the question that is being asked is that is it >> correct for the system to accept and process an IPv4 broadcast packet in the >> first place ? Can the experts help me out here. You may be encountering the DHCPv4 chicken-and-egg problem, meaning that DHCP has to process IPv4/UDP packets before IP has been configured by DHCP. That means that DHCPv4 servers sniff packets off of the wire and do their own IPv4/UDP processing. >> >> Thanks, >> >> Shoaib >> >> Please include me in the reply as I am not subscribed to the list. >> >> -------------------------------------------------------------------- >> 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 Mon Jul 17 22:54:19 2017 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 9A56C12706D for ; Mon, 17 Jul 2017 22:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 C1CMHz_G0ta4 for ; Mon, 17 Jul 2017 22:54:17 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 6A47C126B72 for ; Mon, 17 Jul 2017 22:54:17 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 35so11342077uax.3 for ; Mon, 17 Jul 2017 22:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jm3lb4fCca5umI8eQL5SHWtqzQcTtJiq9uMW95VRQZ0=; b=iBvi62gVGLErVBexMpJtKpsaWO7oIEsXU8UvwiST2n9Qd9sv+xUeyK7wOKl4P+1PlJ sNz/9AJT733VohLRz3UEhgshLz5fT58vSf/1JtUrc5jB8+1m9F4LFnGg2e+NzX9qI6qq HEigToEg5RUtoj260n/Vsu7XPNWcnpM73kU8CIC9pX7x4n+1aTJvnZDpDpIGbDJz0TIp f15ahghEkaLIn6H9hbSMuBE65CbWPD4XQhZV3ot/XrsPwCLPLqBQvOGoQyszp+0zyzYP 4jHg2lEePfiVOstyIXn5sn7Dh05mbrAS7RZCLUhxGRbaWufUWUKMHx2xGpTixutMwqX3 LdBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jm3lb4fCca5umI8eQL5SHWtqzQcTtJiq9uMW95VRQZ0=; b=TYdhnk7A9loeuBUEd3/o62BGLmaZ1pnM9IT9UPWoK3WQeuMkh+gWNc3PKLgpLmEEDu MUHYQSGnKGB75g/7sEh++CrKr2fGWHZpuTjzQclW7GLkDJ1egGtKsKB8z/QfQ77h1YiB hj4gBZzS42EcOjaKEKDaaXgLH0fJW8rfZHCwo8PZpTGwNna276UQqfkWsVFs00PUfW+4 8e4QrDsioKIctPFQ6zUi0GIJfk03ofiSgVMaBtae7ieYhQYp6mcp2gLBVVuOkRZCxdzA qULxOyv7nGgfqB6GjtbOi6dS0t4/iTbS18kpx1Txy5+70aUIV48U0XAS80kSNRGMRvi4 oLSw== X-Gm-Message-State: AIVw112NqNny/bvDVizJlEr5khhLh34BJzZpsK/9vL1oMoXXzXtdhwd1 5sewiXhtmV6lIo/FC0eS6k4yXNRoBw== X-Received: by 10.31.196.71 with SMTP id u68mr19116vkf.8.1500357256422; Mon, 17 Jul 2017 22:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Mon, 17 Jul 2017 22:53:45 -0700 (PDT) In-Reply-To: <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> References: <17fdc91e-3ae0-986f-3261-ffa2a60a779f@gmail.com> <234f21dc-60fa-7434-e076-9660f144108a@gmail.com> From: Mark Smith Date: Tue, 18 Jul 2017 15:53:45 +1000 Message-ID: Subject: Re: 64bit IIDs are both recommended and required To: Alexandre Petrescu Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 05:54:19 -0000 On 17 July 2017 at 21:54, Alexandre Petrescu wrote: > > > Le 17/07/2017 =C3=A0 07:48, Mark Smith a =C3=A9crit : >> >> On 17 July 2017 at 15:14, Alexandre Petrescu >> wrote: >>> >>> Le 15/07/2017 =C3=A0 19:54, David Farmer a =C3=A9crit : >>> [...] >>>> >>>> >>>> Also a problem statement was asked for, and I think that is it, "a >>>> simple >>>> statement requiring or recommending 64 bit IIDs doesn't accurately >>>> reflect >>>> the true nature of the IPv6 architecture." >>> >>> >>> >>> If a problem statement is formulated, it is worth adding the following. >>> >>> The 64bit IIDs make for a problem of 'growth at the edges'. Such a >>> problem has to do with use-cases like when using a smartphone to >>> 'tether'. Connect the smartphone on 4G and give others Internet on >>> WiFi, such as to 'grow' the network. Similar use-cases are: a WiFi >>> Access Point, an IoT Gateway, an automobile On-Board Router, a Road-Sid= e >>> Unit, an satcom-WiFi router in an airplane. >>> >>> Such a device is present at the edge of the Internet. It obtains a /64 >>> from a provider (a cellular or an ADSL provider). It then has to make >>> up other /64s to give others. It cant. >>> >> >> It can't because the cellular or ADSL provider doesn't want the device >> to be able to. If they did, then they should have no issue with >> providing multiple and enough /64s to do so, in particular given how >> cheap /64s are. > > > I can agree to that, but it does not make it less of a Problem. I think it makes it less of a problem. We need to assume and cater to the common and sensible cases. If we start trying to accommodate or work around either unnecessary and irrational cases or cases with specifically and consciously chosen constraints, we end up rewarding those exceptions with our time and penalising the sensible and more accommodating. If a network has chosen not to give out more than one /64, despite them having a minimum of 4 294 967 296 x /64s i.e., a /32's worth from an RIR, and despite the advice in RFC6177, why should we spend valuable time overcoming that? Better to advise the end-user to find a better network where their provider actually satisfies their needs (or use an IPv6 in IPv6 tunnel provided by somebody else to get more than a /64). Better to advise the provider to follow the advice in RFC6177 and better facilitate their customers' needs. It's a slippery slope that eventually leads to a /128 and NAPT. If you want to accommodate > /64, then the easiest and quickest way to do that is to assume the worst and only case of a /128 and work on that. You'll never be able to guarantee more than that from somebody who wants to go past /64, so there is always a risk that what you're given won't be enough to give each device its own address. > > Further, I heard today other problems during the meeting: > - network management: ANIMA work may need longer-than-64bit prefix > lenghts > - Android emulator may not allow for NAT Once the boundary becomes arbitrary, Android and other similar devices will have only two choices: - to include NAPT code to work around the case of not being given enough addresses to address each device individually - refuse to connect to a network that doesn't give out enough addresses to address each device individually Regards, Mark. From nobody Tue Jul 18 00:10:48 2017 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 ED7EE131D6A for ; Tue, 18 Jul 2017 00:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, 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 w1JUxHHv2ShB for ; Tue, 18 Jul 2017 00:10:46 -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 10B40131D69 for ; Tue, 18 Jul 2017 00:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1500361846; x=1501571446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tcSl4oQilpu70VOWoZw/YIEJR6aE1vtWKTLGR2tFx0g=; b=P3aXw0DISFoS6/troFg7KfJsej5GsPKrl2usHSPD0+A7rJqfpHIS5EHF xpZrEycb82U25g1AATyDTZdk4Vm/gTNjmc6bnHvtv95/54NIB+maZIqJT Aa4cDMx90LRED7lZUQAF/Z/DdbStnpT30iA0clwukIsetNblLBHfeRLzP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAD4s21Z/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRSOC5FiiC6NVoEyA1whC4UbAoNMPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQE4MQMLBQsCAQgYHhAhBgslAgQOBYoXAw0IELJDhzgNg0YBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMohS4rgnmCV4F9FoNDgjEFiVwFlRg7Ao8khHC?= =?us-ascii?q?CDIVPilSMColMAR84TD51FUkSAYcDdohYAQEB?= X-IronPort-AV: E=Sophos;i="5.40,377,1496102400"; d="scan'208";a="269149128" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2017 07:10:45 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6I7Ajjg008442 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 07:10:45 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; Tue, 18 Jul 2017 02:10:44 -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, 18 Jul 2017 02:10:44 -0500 From: "Bernie Volz (volz)" To: Mark Smith CC: Erik Kline , IETF IPv6 Mailing List , "Rao Shoaib" Subject: Re: What is the correct behavior Thread-Topic: What is the correct behavior Thread-Index: AQHS/2Noj9qYOxAh9kSqgzfYgjomSKJZKyri Date: Tue, 18 Jul 2017 07:10:44 +0000 Message-ID: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:10:48 -0000 >> That means that DHCPv4 servers sniff packets off of the wire and do their own IPv4/UDP processing. That's typically not necessary for DHCP servers to do that. The one I work = on certainly doesn't do that as using the standard Linux socket interface w= orks just fine. - Bernie (from iPhone) > On Jul 18, 2017, at 3:15 AM, Mark Smith wrote: >=20 >> On 18 July 2017 at 05:41, Erik Kline wrote: >> I'm not sure there is any standards behaviour applicable here. >>=20 >> The device is likely receiving many other non-0x86dd frame types as >> well (LLDP, 802.1q, ...). If you don't want them, probably best to >> just filter them. >>=20 >=20 > A related issue might be that DHCPv4 specifically suffers from a > chicken-and-egg problem, meaning that it is processing IPv4/UDP > packets before IP has been configured. Consequently the DHCPv4 servers > sniff packets off of the wire and do their own IPv4/UDP processing. >=20 > So even though your interface to the network isn't "IPv4 enabled" by > having an IPv4 address, if a DHCPv4 server is listening on that > interface then IPv4 packets such as broadcasts will be making it into > the DHCPv4 server process and then the DHCPv4 server process might be > passing them onto and into the IPv4 protocol implementation in the > kernel, causing the martian error. >=20 >=20 >>> On 18 July 2017 at 04:33, Rao Shoaib wrote: >>> I am looking at a system which is configured for IPv6 only but sits in = a >>> network that serves both IPv4 and IPv6. When an IPv4 packet with a >>> destination broadcast address is sent out (in this case DHCP) the syst= em >>> accepts it and since it does not have any route to the sender it prints= the >>> Linux Martian packet message. >>>=20 >>> Sure, we can turn off the Martian message and maybe the system should b= e in >>> an IPv6 only network but the question that is being asked is that is it >>> correct for the system to accept and process an IPv4 broadcast packet i= n the >>> first place ? Can the experts help me out here. >=20 >=20 > You may be encountering the DHCPv4 chicken-and-egg problem, meaning > that DHCP has to process IPv4/UDP packets before IP has been > configured by DHCP. >=20 > That means that DHCPv4 servers sniff packets off of the wire and do > their own IPv4/UDP processing. >=20 >>>=20 >>> Thanks, >>>=20 >>> Shoaib >>>=20 >>> Please include me in the reply as I am not subscribed to the list. >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jul 18 01:04:21 2017 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 4637512ECF0 for ; Tue, 18 Jul 2017 01:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 lXZxk5N6X9GX for ; Tue, 18 Jul 2017 01:04:18 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 E312A1317AD for ; Tue, 18 Jul 2017 01:04:14 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 12so17141764wrb.1 for ; Tue, 18 Jul 2017 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=WMryO3sNc0hieAlSzeo/Sg4pAj4I9T4UCgffXErND9M=; b=V7MEN31Ya74F4JNjGw5DU/8DPF+7IdD4iFU97mkilxFWAXou3FMUYxksRnwDdFsJWg vs6GnBcyDYwzGDOvB/JwuSmbACFaa4Xn5X7vRCr94A39kP9lv6bhE/bvmJI5oTw46uBH N8oaZPF0jAixnhcg8CYl+xc+YgQzQUZbSEnyayFR43gjH/CQwfc5BTQ4aXqQXwSKk7eU UrDqmympzIAgt38GP5ZA6eeJvR7BnpX5g6vsB0Yhm7F2kcb00FicXNjGyW7mjcQZRJRW AnbcsynNOkObQ+3Oi7vyoOiZWAKq02XzE7xkgtPI+HwFdR7GNPZBffAvaOjEp4MezN9S hjKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=WMryO3sNc0hieAlSzeo/Sg4pAj4I9T4UCgffXErND9M=; b=odBBKQWSnl+IgtjuTxyBpG6Vsv0xvhjKs4iT/vUcj2WHet5VPa6NTWW05EpixN3WZn ie10YKGVeSlJi0Df9SyBTdwgD+4CcLqFgLY7wBWql7bFtF0mHTX0s+wSb6aPRbPtI+2b BEzKaza0PEY3rh85FBBfpMgKRBTnd04wu+yJEI6A2pN1gQmmvMI305vyWc4tZOGWHDRS eBkv68R/RZ4xOEjWS3fDJftjetJz6YiMv/Gw/Xe8BTyz7QcvCSAqvIH8X55qR6wEgvKA Fm3yxcM7ZhaDUwfnrjn6J/8vCw309t0oI9h/147of538kSi9GcuTWD9DpdzThssfZ4s3 bqdw== X-Gm-Message-State: AIVw113C2kEgW9pCSmglvaDrK+md/fNpQk1ZJWW50eXC6TBaNK2HwGQc qxMdnd+3TMGXtT5ZcYmdog== X-Received: by 10.223.132.163 with SMTP id 32mr307317wrg.204.1500365053070; Tue, 18 Jul 2017 01:04:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:558e:1b16:4020:5e56? ([2001:67c:370:1998:558e:1b16:4020:5e56]) by smtp.gmail.com with ESMTPSA id k23sm1322425wre.1.2017.07.18.01.04.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 01:04:12 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_6D50AEB5-020B-42FB-93EC-3972A10F1B3E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Tue, 18 Jul 2017 10:04:11 +0200 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> To: IPv6 List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:04:19 -0000 --Apple-Mail=_6D50AEB5-020B-42FB-93EC-3972A10F1B3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 17, 2017, at 23:42, David Farmer wrote: >=20 > I've begun to think there are two real problems here; >=20 > 1. RFC4291 categorically says architecturally IIDs are 64bits, and = seems to imply this is the case for all components of IPv6. While it is = the case for several components of IPv6, it is not the case for other = important components. Neighbor Discovery, DHCPv6, and Routing, etc... = are not architecturally based on 64bit IIDs at all, in fact they are = clearly based on IIDs of any length.=20 Those other components aren=E2=80=99t based on IIDs at all. They=E2=80=99r= e based on IPv6 addresses and routing prefixes, but they=E2=80=99re not = based on IIDs. That RFC 4291 still has this obsolescent concept of an = IID that comes from embedding Modified EUI-64 transformations of MAC = addresses isn=E2=80=99t actually causing any real problem that I=E2=80=99m= seeing stated anywhere. It seems perfectly safe to me to promote to = Standard a minor revision of RFC 4291 that retains the existing = definition of the IID in the architecture. > 2. The fact that some components of IPv6 are architecturally based on = 64bit IIDs doesn't mean that operationally IIDs are always required to = be 64 bits. Rather than implying that operationally IID are required to = be 64bits, how about simply stating that operationally 64 bit IIDs are = recommended. This eliminates the need to enumerate all the exceptions, = which probably isn't something an architectural document should be = doing. See above. --james woodyatt > --Apple-Mail=_6D50AEB5-020B-42FB-93EC-3972A10F1B3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 17, 2017, at 23:42, David Farmer <farmer@umn.edu> = wrote:

I've begun to think there are two real problems = here;

1.  RFC4291 categorically says = architecturally IIDs are 64bits, and seems to imply this is the case for = all components of IPv6. While it is the case for several components of = IPv6, it is not the case for other important components. Neighbor = Discovery, DHCPv6, and Routing, etc... are not architecturally = based on 64bit IIDs at all, in fact they are clearly based on IIDs = of any length. 

Those other components aren=E2=80=99t based on = IIDs at all. They=E2=80=99re based on IPv6 addresses and routing = prefixes, but they=E2=80=99re not based on IIDs. That RFC 4291 still has = this obsolescent concept of an IID that comes from embedding Modified = EUI-64 transformations of MAC addresses isn=E2=80=99t actually causing = any real problem that I=E2=80=99m seeing stated anywhere. It seems = perfectly safe to me to promote to Standard a minor revision of RFC 4291 = that retains the existing definition of the IID in the = architecture.

2. = The fact that some components of IPv6 are architecturally based on = 64bit IIDs doesn't mean that operationally IIDs are always required to = be 64 bits. Rather than implying that operationally IID are required to = be 64bits, how about simply stating that operationally 64 bit IIDs are = recommended. This eliminates the need to enumerate all the exceptions, = which probably isn't something an architectural document should be = doing.

See = above.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_6D50AEB5-020B-42FB-93EC-3972A10F1B3E-- From nobody Tue Jul 18 07:52:31 2017 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 BE474131AA9 for ; Tue, 18 Jul 2017 07:52:27 -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 FlWKkOa6Mkud for ; Tue, 18 Jul 2017 07:52:26 -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 EAE961317CA for <6man@ietf.org>; Tue, 18 Jul 2017 07:52:25 -0700 (PDT) Received: from [192.168.0.11] (unknown [46.13.174.201]) (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 2E8F18270B; Tue, 18 Jul 2017 16:53:54 +0200 (CEST) To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont Subject: "RFC4941bis" and draft-gont-6man-non-stable-iids Message-ID: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> Date: Tue, 18 Jul 2017 17:52:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:52:28 -0000 Folks, Among the list of RFCs to be progressed to full std is/was RFC4941 ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). As it stands, RFC4941 has a number of issues: * Using the same IID for multiple prefixes * Not changing the IID upon "security events" (including e.g., change in the underlying MAC address) * Using MD5 as opposed to something better * Requiring the use of temporary addresses along stable addresses (preventing use of temporary-only, for nodes that feel like) * Not treating IIDs as opaque values (see RFC7136) when generating the randomized IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one specific algorithm, when the same goals/properties can be achieved with multiple algorithms (see section 4 of draft-gont-6man-non-stable-iids-01) Based on the above, I personally don't think that it would make sense to progress RFC4941 to Internet Standard, but rather think that we should work on a replacement of it -- our proposal being draft-gont-6man-non-stable-iids-01. Thoughts? 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 18 08:58:41 2017 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 99048131B84 for ; Tue, 18 Jul 2017 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-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 oP45kHfaQ04J for ; Tue, 18 Jul 2017 08:58:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 03113129B5E for ; Tue, 18 Jul 2017 08:58:36 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6IFwXFv020348 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Jul 2017 15:58:33 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6IFwXwX029411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Jul 2017 15:58:33 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6IFwX6l009367; Tue, 18 Jul 2017 15:58:33 GMT Received: from [192.168.1.20] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jul 2017 08:58:33 -0700 Subject: Re: What is the correct behavior To: "Bernie Volz (volz)" , Mark Smith Cc: Erik Kline , IETF IPv6 Mailing List References: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@cisco.com> From: Rao Shoaib Message-ID: Date: Tue, 18 Jul 2017 08:58:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:58:38 -0000 On 07/18/2017 12:10 AM, Bernie Volz (volz) wrote: >>> That means that DHCPv4 servers sniff packets off of the wire and do > their own IPv4/UDP processing. > > That's typically not necessary for DHCP servers to do that. The one I work on certainly doesn't do that as using the standard Linux socket interface works just fine. > > - Bernie (from iPhone) In this case the host is a client that is getting the DHCP packet destined for another host. If the system does not have V4 configured than should it not be required to use DHCP v6 ? Shoaib > >> On Jul 18, 2017, at 3:15 AM, Mark Smith wrote: >> >>> On 18 July 2017 at 05:41, Erik Kline wrote: >>> I'm not sure there is any standards behaviour applicable here. >>> >>> The device is likely receiving many other non-0x86dd frame types as >>> well (LLDP, 802.1q, ...). If you don't want them, probably best to >>> just filter them. >>> >> A related issue might be that DHCPv4 specifically suffers from a >> chicken-and-egg problem, meaning that it is processing IPv4/UDP >> packets before IP has been configured. Consequently the DHCPv4 servers >> sniff packets off of the wire and do their own IPv4/UDP processing. >> >> So even though your interface to the network isn't "IPv4 enabled" by >> having an IPv4 address, if a DHCPv4 server is listening on that >> interface then IPv4 packets such as broadcasts will be making it into >> the DHCPv4 server process and then the DHCPv4 server process might be >> passing them onto and into the IPv4 protocol implementation in the >> kernel, causing the martian error. >> >> >>>> On 18 July 2017 at 04:33, Rao Shoaib wrote: >>>> I am looking at a system which is configured for IPv6 only but sits in a >>>> network that serves both IPv4 and IPv6. When an IPv4 packet with a >>>> destination broadcast address is sent out (in this case DHCP) the system >>>> accepts it and since it does not have any route to the sender it prints the >>>> Linux Martian packet message. >>>> >>>> Sure, we can turn off the Martian message and maybe the system should be in >>>> an IPv6 only network but the question that is being asked is that is it >>>> correct for the system to accept and process an IPv4 broadcast packet in the >>>> first place ? Can the experts help me out here. >> >> You may be encountering the DHCPv4 chicken-and-egg problem, meaning >> that DHCP has to process IPv4/UDP packets before IP has been >> configured by DHCP. >> >> That means that DHCPv4 servers sniff packets off of the wire and do >> their own IPv4/UDP processing. >> >>>> Thanks, >>>> >>>> Shoaib >>>> >>>> Please include me in the reply as I am not subscribed to the list. >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Tue Jul 18 08:58:47 2017 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 D8932129B5E for ; Tue, 18 Jul 2017 08:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XIe7lBRKHiES for ; Tue, 18 Jul 2017 08:58:38 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 3046E128C81 for <6man@ietf.org>; Tue, 18 Jul 2017 08:58:37 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 64so28959615uae.2 for <6man@ietf.org>; Tue, 18 Jul 2017 08:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RTwoeunanTX4DCQUbXrNpNiAM1m3UMQLUmgZLXI5p+A=; b=SISZ4VtQ99VKtr0+eO0jz6qLCGFh8tpkiGSc/yT9gyM9zefLYVanC7ieGPXclCAtw4 LaAyx6bcCKhtO5GIfgxqtItpb9B2qrB5oLSKzIEn66mU6+//XL9LQfnmHdmCNo+KE4oO FM8rgsAt1Tw38+3lg8Xr7KqI1NykTl35yyC+ywxt9y8vdzr77W7NIcaKpJAP/zxEQuLb CqQPovjctTaPLyYRzVIIWCtumqfbZHZ2ylO2aYDZG+4rNKbznKLJfFg1LrrxeT2VBPYQ +OnkVAkGDF1Z04IxRyIQpcN18jUZ+7VoLvDwqHlZ4HyopQPIgHC8L2Mlw7RYB3wTzJa0 a/pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RTwoeunanTX4DCQUbXrNpNiAM1m3UMQLUmgZLXI5p+A=; b=WXCJMJ5etZzjjXXDbUuLy0UArfb94t2d6VpzV6hbTf6C4dKDA9mujLowMkAygosiUo gKC27fkNCYu12Y0fQRsdmK/nbl4vFL6ZB2mq7+gADcBBz0LNb74ubFh0jEczVYXeCwFL 9n68JzLn4uGxT4nml1rY/x5HfbkUOE6uRQTm04gAb+fq+l982zLQdGkcz3FqQQ+3+t63 1gd91pXPBaBIJhfdQB5viz4USU1/Z+2rb1vFiAjIZeJhU/SeYMYgT5I0UvAbNu5aaADr 83UgYxhyxsMlfVfgHw9uXdB9FIbWbhS2Csb0CqfW2MOXpqZgtGg4Y/GaIFahSRvwWDp1 1bvw== X-Gm-Message-State: AIVw112Ona3RoCCiu/WKRkWyVIj7zpSfoE7FEAGA2LpXRrPT/S7o+niM IGkIx+VY3oodPnXkv7Lf43nfFH/NLw== X-Received: by 10.31.99.5 with SMTP id x5mr1305616vkb.62.1500393516249; Tue, 18 Jul 2017 08:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Tue, 18 Jul 2017 08:58:05 -0700 (PDT) In-Reply-To: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> From: Mark Smith Date: Wed, 19 Jul 2017 01:58:05 +1000 Message-ID: Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:58:40 -0000 +1 On 19 July 2017 at 00:52, Fernando Gont wrote: > Folks, > > Among the list of RFCs to be progressed to full std is/was RFC4941 > ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). > > As it stands, RFC4941 has a number of issues: > > * Using the same IID for multiple prefixes > * Not changing the IID upon "security events" (including e.g., change in > the underlying MAC address) > * Using MD5 as opposed to something better > * Requiring the use of temporary addresses along stable addresses > (preventing use of temporary-only, for nodes that feel like) > * Not treating IIDs as opaque values (see RFC7136) when generating the > randomized IIDs (see step 3 in section 3.2.1 of RFC4941) > * Mandating one specific algorithm, when the same goals/properties can > be achieved with multiple algorithms (see section 4 of > draft-gont-6man-non-stable-iids-01) > > > Based on the above, I personally don't think that it would make sense to > progress RFC4941 to Internet Standard, but rather think that we should > work on a replacement of it -- our proposal being > draft-gont-6man-non-stable-iids-01. > > Thoughts? > > 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 > -------------------------------------------------------------------- From nobody Tue Jul 18 09:13:57 2017 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 4C72B1200FC for ; Tue, 18 Jul 2017 09:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, 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 kimvaU-aYtxW for ; Tue, 18 Jul 2017 09:13:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D8F12EC15 for ; Tue, 18 Jul 2017 09:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1500394433; x=1501604033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OIBiiTVe2NDxjR1nhu1HrVkpOj6ae3nu07yt/Hoik0s=; b=LtqNNgl2/oOa/bYV5HBcldTvoCtZLFMZzXYcnVDo587usFoMSz/lyHvm CR+RtU1DlVORbbEVg4e6lC7xIpcmIfxBWPndX4MwC2XOx189JBxFg6RaB ldKYFgvxRz7ABZXgLasLq8cnR2U6hJIe0JqmMPe0fXJajDBffoxrjF868 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAAAcM25Z/4kNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRSOC5FmiC6NVoEyA1whC4UbAoNRPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQE4MQMLBQsCAQgYHhAhBgslAgQOBYoXAw0IELFIhzYNgz4BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMohS4rgnmCV4F9FoNDgjEFiVwFlRg7Ao8khHC?= =?us-ascii?q?CDIVPilSMColMAR84TD51FUkSAYcDdohYAQEB?= X-IronPort-AV: E=Sophos;i="5.40,378,1496102400"; d="scan'208";a="275141726" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2017 16:13:52 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6IGDqeM019632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 16:13:52 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 11:13:51 -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, 18 Jul 2017 11:13:51 -0500 From: "Bernie Volz (volz)" To: Rao Shoaib CC: Mark Smith , Erik Kline , "IETF IPv6 Mailing List" Subject: Re: What is the correct behavior Thread-Topic: What is the correct behavior Thread-Index: AQHS/2Noj9qYOxAh9kSqgzfYgjomSKJZKyrigADnQYD//7B+Lw== Date: Tue, 18 Jul 2017 16:13:51 +0000 Message-ID: <1D49BD8D-C140-435F-96FE-40E3E4A9EE80@cisco.com> References: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@cisco.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 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.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:13:55 -0000 This can happen if a client on the LAN requests a broadcast response (or th= e relay or server broadcasts it for other reasons). See the broadcast flag = in RFC2131. - Bernie (from iPhone) > On Jul 18, 2017, at 5:58 PM, Rao Shoaib wrote: >=20 >=20 >=20 > On 07/18/2017 12:10 AM, Bernie Volz (volz) wrote: >>>> That means that DHCPv4 servers sniff packets off of the wire and do >> their own IPv4/UDP processing. >>=20 >> That's typically not necessary for DHCP servers to do that. The one I wo= rk on certainly doesn't do that as using the standard Linux socket interfac= e works just fine. >>=20 >> - Bernie (from iPhone) > In this case the host is a client that is getting the DHCP packet destine= d for another host. If the system does not have V4 configured than should i= t not be required to use DHCP v6 ? >=20 > Shoaib >>=20 >>>> On Jul 18, 2017, at 3:15 AM, Mark Smith wrote= : >>>>=20 >>>> On 18 July 2017 at 05:41, Erik Kline wrote: >>>> I'm not sure there is any standards behaviour applicable here. >>>>=20 >>>> The device is likely receiving many other non-0x86dd frame types as >>>> well (LLDP, 802.1q, ...). If you don't want them, probably best to >>>> just filter them. >>>>=20 >>> A related issue might be that DHCPv4 specifically suffers from a >>> chicken-and-egg problem, meaning that it is processing IPv4/UDP >>> packets before IP has been configured. Consequently the DHCPv4 servers >>> sniff packets off of the wire and do their own IPv4/UDP processing. >>>=20 >>> So even though your interface to the network isn't "IPv4 enabled" by >>> having an IPv4 address, if a DHCPv4 server is listening on that >>> interface then IPv4 packets such as broadcasts will be making it into >>> the DHCPv4 server process and then the DHCPv4 server process might be >>> passing them onto and into the IPv4 protocol implementation in the >>> kernel, causing the martian error. >>>=20 >>>=20 >>>>> On 18 July 2017 at 04:33, Rao Shoaib wrote: >>>>> I am looking at a system which is configured for IPv6 only but sits i= n a >>>>> network that serves both IPv4 and IPv6. When an IPv4 packet with a >>>>> destination broadcast address is sent out (in this case DHCP) the sy= stem >>>>> accepts it and since it does not have any route to the sender it prin= ts the >>>>> Linux Martian packet message. >>>>>=20 >>>>> Sure, we can turn off the Martian message and maybe the system should= be in >>>>> an IPv6 only network but the question that is being asked is that is = it >>>>> correct for the system to accept and process an IPv4 broadcast packet= in the >>>>> first place ? Can the experts help me out here. >>>=20 >>> You may be encountering the DHCPv4 chicken-and-egg problem, meaning >>> that DHCP has to process IPv4/UDP packets before IP has been >>> configured by DHCP. >>>=20 >>> That means that DHCPv4 servers sniff packets off of the wire and do >>> their own IPv4/UDP processing. >>>=20 >>>>> Thanks, >>>>>=20 >>>>> Shoaib >>>>>=20 >>>>> Please include me in the reply as I am not subscribed to the list. >>>>>=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 >>>> -------------------------------------------------------------------- >>>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 From nobody Tue Jul 18 10:59:49 2017 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 B822C131A66 for ; Tue, 18 Jul 2017 10:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-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 Rp5fXQsaOwCN for ; Tue, 18 Jul 2017 10:59:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 D0FB012EC15 for ; Tue, 18 Jul 2017 10:59:45 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6IHxfTm015952 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jul 2017 17:59:41 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6IHxf1k005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jul 2017 17:59:41 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6IHxfNF023085; Tue, 18 Jul 2017 17:59:41 GMT Received: from [192.168.1.20] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jul 2017 10:59:41 -0700 Subject: Re: What is the correct behavior To: "Bernie Volz (volz)" Cc: Mark Smith , Erik Kline , IETF IPv6 Mailing List References: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@cisco.com> <1D49BD8D-C140-435F-96FE-40E3E4A9EE80@cisco.com> From: Rao Shoaib Message-ID: <5c2b93c5-65d8-66f6-9250-e48c7fd6ab81@oracle.com> Date: Tue, 18 Jul 2017 10:59:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1D49BD8D-C140-435F-96FE-40E3E4A9EE80@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 17:59:48 -0000 On 07/18/2017 09:13 AM, Bernie Volz (volz) wrote: > This can happen if a client on the LAN requests a broadcast response (or the relay or server broadcasts it for other reasons). See the broadcast flag in RFC2131. > > - Bernie (from iPhone) Correct. The response is legal but is the behavior of the V6 node to accept and process a V4 broadcast packet correct ? Shoaib > >> On Jul 18, 2017, at 5:58 PM, Rao Shoaib wrote: >> >> >> >> On 07/18/2017 12:10 AM, Bernie Volz (volz) wrote: >>>>> That means that DHCPv4 servers sniff packets off of the wire and do >>> their own IPv4/UDP processing. >>> >>> That's typically not necessary for DHCP servers to do that. The one I work on certainly doesn't do that as using the standard Linux socket interface works just fine. >>> >>> - Bernie (from iPhone) >> In this case the host is a client that is getting the DHCP packet destined for another host. If the system does not have V4 configured than should it not be required to use DHCP v6 ? >> >> Shoaib >>>>> On Jul 18, 2017, at 3:15 AM, Mark Smith wrote: >>>>> >>>>> On 18 July 2017 at 05:41, Erik Kline wrote: >>>>> I'm not sure there is any standards behaviour applicable here. >>>>> >>>>> The device is likely receiving many other non-0x86dd frame types as >>>>> well (LLDP, 802.1q, ...). If you don't want them, probably best to >>>>> just filter them. >>>>> >>>> A related issue might be that DHCPv4 specifically suffers from a >>>> chicken-and-egg problem, meaning that it is processing IPv4/UDP >>>> packets before IP has been configured. Consequently the DHCPv4 servers >>>> sniff packets off of the wire and do their own IPv4/UDP processing. >>>> >>>> So even though your interface to the network isn't "IPv4 enabled" by >>>> having an IPv4 address, if a DHCPv4 server is listening on that >>>> interface then IPv4 packets such as broadcasts will be making it into >>>> the DHCPv4 server process and then the DHCPv4 server process might be >>>> passing them onto and into the IPv4 protocol implementation in the >>>> kernel, causing the martian error. >>>> >>>> >>>>>> On 18 July 2017 at 04:33, Rao Shoaib wrote: >>>>>> I am looking at a system which is configured for IPv6 only but sits in a >>>>>> network that serves both IPv4 and IPv6. When an IPv4 packet with a >>>>>> destination broadcast address is sent out (in this case DHCP) the system >>>>>> accepts it and since it does not have any route to the sender it prints the >>>>>> Linux Martian packet message. >>>>>> >>>>>> Sure, we can turn off the Martian message and maybe the system should be in >>>>>> an IPv6 only network but the question that is being asked is that is it >>>>>> correct for the system to accept and process an IPv4 broadcast packet in the >>>>>> first place ? Can the experts help me out here. >>>> You may be encountering the DHCPv4 chicken-and-egg problem, meaning >>>> that DHCP has to process IPv4/UDP packets before IP has been >>>> configured by DHCP. >>>> >>>> That means that DHCPv4 servers sniff packets off of the wire and do >>>> their own IPv4/UDP processing. >>>> >>>>>> Thanks, >>>>>> >>>>>> Shoaib >>>>>> >>>>>> Please include me in the reply as I am not subscribed to the list. >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- From nobody Tue Jul 18 11:59:02 2017 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 2A019131468 for ; Tue, 18 Jul 2017 11:59:01 -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 0Tp6tjlmT-Zh for ; Tue, 18 Jul 2017 11:58:59 -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 E546612EB96 for <6man@ietf.org>; Tue, 18 Jul 2017 11:58:58 -0700 (PDT) Received: from [192.168.0.11] (unknown [46.13.174.201]) (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 6AF558274D; Tue, 18 Jul 2017 21:00:25 +0200 (CEST) To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont Subject: Any input on revamped temporary addresses? (draft-gont-6man-non-stable-iids) Message-ID: Date: Tue, 18 Jul 2017 21:59:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:59:01 -0000 Folks, We are interested in receiving any feedback on our document draft-gont-6man-non-stable-iids, such that we can tackle any issues before e.g. the wg can decide whether the wg wants to work on this document. The document is pretty much short and self-contained, and is available at: Thanks in advance! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 18 12:19:56 2017 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 3E442120724 for ; Tue, 18 Jul 2017 12:19:55 -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 BusyEQv8FWiW for ; Tue, 18 Jul 2017 12:19:54 -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 F2F541201F2 for ; Tue, 18 Jul 2017 12:19:53 -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 v6IJJqAs015204; Tue, 18 Jul 2017 12:19:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6IJJh0a014664 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 18 Jul 2017 12:19:43 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 12:19:42 -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.1263.000; Tue, 18 Jul 2017 12:19:42 -0700 From: "Manfredi, Albert E" To: james woodyatt , IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHS/0Wed3esQDb6ikC6XZkOC9tAJKJZr62AgABBS5A= Date: Tue, 18 Jul 2017 19:19:42 +0000 Message-ID: <30e4e247f1be4fe3a333a0b39f6eb4a3@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 19:19:55 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMjM6NDIsIERhdmlkIEZhcm1lciA8 ZmFybWVyQHVtbi5lZHU+IHdyb3RlOg0KDQo+PiBJJ3ZlIGJlZ3VuIHRvIHRoaW5rIHRoZXJlIGFy ZSB0d28gcmVhbCBwcm9ibGVtcyBoZXJlOw0KPj4NCj4+IDEuwqAgUkZDNDI5MSBjYXRlZ29yaWNh bGx5IHNheXMgYXJjaGl0ZWN0dXJhbGx5IElJRHMgYXJlIDY0Yml0cywNCg0KQWN0dWFsbHksIGEg YmV0dGVyIHdheSB0byBzdGF0ZSB0aGlzLCB0byBnZXQgcGFzdCB0aGlzICJyZXF1aXJlZCIgcHJv YmxlbSB0aGF0IGtlZXBzIHJlY3VycmluZywgaXMgdG8gc2F5IHRoYXQgUkZDIDQyOTEgImNhdGVn b3JpY2FsbHkgc3RhdGVzIHRoYXQgSUlEcyBtdXN0IGNvbnNpc3Qgb2YgRVVJLTY0IGZvcm1hdC4i IFRoZW4gdGhhdCBzaG91bGQgcHV0IGluIHBlcnNwZWN0aXZlIHRoaXMgd2hvbGUgaXNzdWUuIFF1 b3Rpbmc6DQoNCiAgIEZvciBhbGwgdW5pY2FzdCBhZGRyZXNzZXMsIGV4Y2VwdCB0aG9zZSB0aGF0 IHN0YXJ0IHdpdGggdGhlIGJpbmFyeQ0KICAgdmFsdWUgMDAwLCBJbnRlcmZhY2UgSURzIGFyZSBy ZXF1aXJlZCB0byBiZSA2NCBiaXRzIGxvbmcgYW5kIHRvIGJlDQogICBjb25zdHJ1Y3RlZCBpbiBN b2RpZmllZCBFVUktNjQgZm9ybWF0Lg0KDQpCZXNpZGVzIHdoaWNoLCBTTEFBQyBSRkMgNDg2MiBp cyBhZ25vc3RpYyBpbiBwcmluY2lwbGUsIG9uIHRoZSBsZW5ndGggb2YgdGhlIElJRC4gRXZlcnl0 aGluZyBiZWNvbWVzIGEgbWF0dGVyIG9mIFJGQyAyNDY0IChJUHY2IG92ZXIgRXRoZXJuZXQpLCB3 aGljaCBpcyBubyBiZXR0ZXIgdGhhbiBSRkMgNDI5MS4gSXQgdG9vICJjYXRlZ29yaWNhbGx5IG1h bmRhdGVzIiB1c2Ugb2YgRVVJLTY0IGFzIElJRC4NCg0KUkZDIDQ4NjI6DQoNCiAgIFRoZQ0KICAg bGVuZ3RoIG9mIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllciBpcyBkZWZpbmVkIGluIGEgc2VwYXJh dGUgbGluay0NCiAgIHR5cGUtc3BlY2lmaWMgZG9jdW1lbnQsIHdoaWNoIHNob3VsZCBhbHNvIGJl IGNvbnNpc3RlbnQgd2l0aCB0aGUNCiAgIGFkZHJlc3MgYXJjaGl0ZWN0dXJlIFtSRkM0MjkxXSAo c2VlIFNlY3Rpb24gMikuDQoNClJGQyAyNDY0Og0KDQogICBUaGUgSW50ZXJmYWNlIElkZW50aWZp ZXIgW0FBUkNIXSBmb3IgYW4gRXRoZXJuZXQgaW50ZXJmYWNlIGlzIGJhc2VkDQogICBvbiB0aGUg RVVJLTY0IGlkZW50aWZpZXIgW0VVSTY0XSBkZXJpdmVkIGZyb20gdGhlIGludGVyZmFjZSdzIGJ1 aWx0LQ0KICAgaW4gNDgtYml0IElFRUUgODAyIGFkZHJlc3MuDQoNCkVuZmluIGJyZWYsIG1heSBJ IHN1Z2dlc3QgdGhhdCBhbGwgb2Ygb3VyIG1vcmUgcmVjZW50IGRlY2lzaW9ucyBhbmQgY29uc2lk ZXJhdGlvbnMgaGF2ZSBnb25lIHdlbGwgYmV5b25kIHdoYXQgdGhlc2Ugb3V0ZGF0ZWQgUkZDcyBh cmUgc2F5aW5nPyBJIHRoaW5rIHRoYXQgYW55IG5vdGlvbiBvZiAibWFuZGF0ZWQgNjQtYml0IElJ RHMiIGlzIGEgYml0IGxpa2UgY2hlcnJ5LXBpY2tpbmcgb25seSBvbmUgcGhyYXNlIG9mIHRoZSBy ZXF1aXJlbWVudCwgYW5kIGlnbm9yaW5nIHRoZSBvdGhlciBwaHJhc2UgY29uY2VybmluZyBFVUkt NjQuIA0KDQo+IFRob3NlIG90aGVyIGNvbXBvbmVudHMgYXJlbuKAmXQgYmFzZWQgb24gSUlEcyBh dCBhbGwuIFRoZXnigJlyZSBiYXNlZCBvbg0KPiBJUHY2IGFkZHJlc3NlcyBhbmQgcm91dGluZyBw cmVmaXhlcywgYnV0IHRoZXnigJlyZSBub3QgYmFzZWQgb24gSUlEcy4NCg0KR29vZCBwb2ludC4g U3RpbGwsIGlmIGEgcHJlZml4IGlzIHBlcm1pdHRlZCB0byBiZSAxMjggYml0cyBsb25nLCB0aGF0 IGtpbmQgb2YgaW1wbGllcyBzb21ldGhpbmcgYWJvdXQgSUlEcyB0b28uIEluZGlyZWN0bHkuDQoN Cj4gVGhhdCBSRkMgNDI5MSBzdGlsbCBoYXMgdGhpcyBvYnNvbGVzY2VudCBjb25jZXB0IG9mIGFu IElJRCB0aGF0IGNvbWVzDQo+IGZyb20gZW1iZWRkaW5nIE1vZGlmaWVkIEVVSS02NCB0cmFuc2Zv cm1hdGlvbnMgb2YgTUFDIGFkZHJlc3NlcyBpc27igJl0DQo+IGFjdHVhbGx5IGNhdXNpbmcgYW55 IHJlYWwgcHJvYmxlbSB0aGF0IEnigJltIHNlZWluZyBzdGF0ZWQgYW55d2hlcmUuDQoNCldlbGws IG5vIG9uZSB3YW50cyB0byBzYXkgdGhhdCBlbWJlZGRpbmcgRVVJLTY0IGlzIGEgZ29vZCBpZGVh IGFueW1vcmUuIEJ1dCB0aGUgd2F5IHdlIGhhdmUgYWdyZWVkIHRvIHByb2NlZWQsIHdpdGggU0xB QUMgcmV0YWluaW5nIGEgNjQtYml0IGJvdW5kYXJ5LCBhbmQgb3RoZXJ3aXNlIGtlZXBpbmcgdGhl IG1hdHRlciBmbGV4aWJsZSwgaXMgdGhlIHJpZ2h0IHdheSB0byBnby4NCg0KPiBSYXRoZXIgdGhh biBpbXBseWluZyB0aGF0IG9wZXJhdGlvbmFsbHkgSUlEIGFyZSByZXF1aXJlZCB0byBiZSA2NGJp dHMsDQo+IGhvdyBhYm91dCBzaW1wbHkgc3RhdGluZyB0aGF0IG9wZXJhdGlvbmFsbHkgNjQgYml0 IElJRHMgYXJlIHJlY29tbWVuZGVkLg0KDQpBbWVuLg0KDQpCZXJ0DQoNCg== From nobody Tue Jul 18 14:12:29 2017 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 CEAC3127B73 for ; Tue, 18 Jul 2017 14:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 eyp5Xh6jUJGA for ; Tue, 18 Jul 2017 14:12:25 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 E8890126CD6 for ; Tue, 18 Jul 2017 14:12:24 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id y43so46740484wrd.3 for ; Tue, 18 Jul 2017 14:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=zAR0TsW3o28TYF5KkJprTr3WaYZisfJZpUn0jVnLfFA=; b=Q2UdBn/KlCkmzhQDhbSQrFZKTTA58op0CnSSobmPZbdMFQeSil3qWuKCJNNBL5jCkZ r/FYwxXodXE16cPTLHy7UUXHrDC51ys1QS3AU37wfBTgMtSMb4l02IlZPMolEqlveNVG pfTNkgCuCiR3yDL/1FZdgPN+mRpVYKHG1rKGRLOkQZyOqhheAIyePBksfzIjyRHlBxl2 VeWECCgcCA+uCp2OYVkAjuoq+x3LU975NDeiRHRm7nQ/xzuZNGCya0omB0sEcYwIGwYB 1SI4c71YvF3DMdeSr1JrG2jbm7xqdfwPfi2cuLwdI5p3YBF48TRxs8b5k2u97zc6KcbR Bh6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=zAR0TsW3o28TYF5KkJprTr3WaYZisfJZpUn0jVnLfFA=; b=dM5yLIq4d6oQ+mdSPdCAaLdVdclw3Wqpn6UXTlvgUQEo6bctB2sxWXrGmzV738/xm+ XIVgNH+pZCrypqaXWo0uliPODhs911dRW4KNX8w54RrjI6+RWbUKaGL+u9nh5QbREwcu OiCPP++yNx7qa0VolBquI23GDrqtmKzn+mR2/J+jKrce0yRpoUutfSLywxNeIrovB097 n7fQyqb95IzkJ62wCoxLNmp8nHDVQ6dAw2CeKbe/2UXmQje8h1eFV/UGBmjEaDMGSemx 87sx0kdR416Ec1/l144FgZL53NApXLXOmsxwHtxoiV2ZSrDjLoG6xOZu1qPxUZqyeuFP Xrhw== X-Gm-Message-State: AIVw113g53oprOS80EtEqP6UYcEm21/31diIVasS89mIH3ECOLSpXyUI OfVwXs1eo8jgQyW+jZ5Jbw== X-Received: by 10.28.180.70 with SMTP id d67mr3186270wmf.121.1500412342964; Tue, 18 Jul 2017 14:12:22 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:ecdf:ba71:7ab0:a322? ([2001:67c:1232:144:ecdf:ba71:7ab0:a322]) by smtp.gmail.com with ESMTPSA id 24sm4185279wrw.0.2017.07.18.14.12.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 14:12:22 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_0571F7F9-DD35-43C5-B413-07FA90795062" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: In consideration of I-D.templin-6man-rio-redirect Message-Id: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> Date: Tue, 18 Jul 2017 23:12:21 +0200 To: 6MAN Working Group X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 21:12:28 -0000 --Apple-Mail=_0571F7F9-DD35-43C5-B413-07FA90795062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear 6MAN, We exhausted our available time discussing = > in the = session yesterday, and since this draft seems to both Fred and me to be = ready for working group adoption, I=E2=80=99d like to prompt further = discussion on the list toward that end. Some participants would like = further clarifications about the reasoning behind the technical choices = we made in this draft, and I hope we can do that here on the list. I=E2=80= =99m going to use a Q&A format to present various paraphrased versions = of the questions we=E2=80=99ve noted in talking without other = participants, and try to provide more satisfying answers here. Question: What is this draft *really* about? I=E2=80=99m just all = confused about its basic problem statement. Answer: Most popular host IPv6 implementations, e.g. Linux, Darwin, = Windows, et cetera, have host route tables capable of representing = routes more specific than a simple default route, but RFC 4191 hasn=E2=80=99= t been widely adopted in default configurations=E2=80=94 so, the "Type = C=E2=80=9D hosts it defines, which process RIO options in RA messages, = are not commonly deployed in general purpose hosts. I mean, yes, you can = turn it on with a sysctl variable or some such advanced configuration = parameter, but out of the box? No, it=E2=80=99s not enabled. This draft = is *really* all about revising RFC 4191=E2=80=94 in a completely = backward compatible way=E2=80=94 to make automatically and dynamically = updating host route tables with information from the network more = appropriate for widespread deployment in general purpose hosts. In other = words, we hope Linux, FreeBSD, Windows and the like will adopt this, and = turn it on by default out of the box. Question: So why isn=E2=80=99t RFC 4191 good enough as it is? Why do we = need to revise it? Answer: One reason host implementations are not Type C in default = configurations is the concern about =E2=80=9Crogue advertisers=E2=80=9D = poisoning host route tables then using that as a platform to mount = attacks on the security associations in various kinds of cryptographic = protocols. The perception (arguably a misperception, but let=E2=80=99s = leave that aside) is that it=E2=80=99s not always safe in general = purpose hosts to process RIO options in RA messages. Our draft = introduces new features to the existing protocol to narrow the attack = surface on hosts that process RIO options so that simple RA guards can = be deployed on links to block rogue advertisers and hosts will still = optimize transmission for sending to the best router for specific = destinations. Question: Why even do this with ICMPv6 neighbor discovery at all? = Couldn=E2=80=99t you just provision host route tables with stateful = DHCPv6 options? Answer: That=E2=80=99s an *excellent* question, because it illustrates = the situation very well! The simple answer is =E2=80=9Cfor all the same = reasons we don=E2=80=99t configure hosts with Default Router addresses = using DHCPv6,=E2=80=9D while the complete answer is that host routing = tables often need to be dynamically updated in response to dynamic = routing protocol events, and that would mean a tight coupling between = the DHCPv6 server and the dynamic routing protocol agent so that DHCPv6 = Reconfigure messages can be sent to prompt hosts to make = Information-request messages for route table updates in a timely manner. = And there is the whole fate-sharing thing. Plus, a couple other points: = a) the ICMPv6 neighbor and router discovery protocols are the natural = place in the IPv6 architecture for doing this stuff; and b) it has some = attractive qualities in typical host implementations, which handle = ICMPv6 entirely inside the kernel, whereas DHCPv6 and various dynamic = routing protocols are usually implemented as daemons. Question: In the draft, Figure 1: "Classical Redirection Scenario=E2=80=9D= is confusing. Is the Target a router too? What kind of node is the = Source? Answer: The draft uses Source and Target here because it=E2=80=99s = talking about the names of the fields in the ND Redirect packet where = the IPv6 address of the relevant interface on the corresponding nodes = shown in the diagram. The node labeled Target is a gateway=E2=80=94 with = one interface on the link with the Router (which sends the ND Redirect = to Source for Target), and another interface on the link with the hosts = H1, H2, H3, et cetera. The gateway need not be a dynamic router, i.e. a = gateway that uses a routing protocol like RIP, OSPF, IS-IS or Babel. It = could be a simple gateway that obtains its prefix delegation from Router = with DHCPv6-PD, and it=E2=80=99s an important point that the Source that = processes RIO elements doesn=E2=80=99t have any need to know how the = gateway obtained the prefix to which it forwards packets, or how the = routing domain is controlled and managed. In the simple case, the Source = node is just a host, and it neither needs nor =E2=80=9Cwants=E2=80=9D to = participate in the dynamic routing protocol used by the Router and the = Target nodes. Question: Why are you using NS/NA for the RIO confirmation lockstep? Why = not use RS/RA instead? Answer: In fact, the draft has a whole section about that, =C2=A74.2.6 = =E2=80=9CWhy NS/NA?=E2=80=9D and paraphrasing here: mainly because, to = send RA messages entails delay and rate limiting that do not apply when = sending NA messages. Also, RA messages are typically multicast, which is = less reliable on many wireless link types, but these interactions are = better done with unicast from Target directly to Source without any = delays. Finally, if simple RA guards are deployed without whitelisting = all the potential targets that may receive DHCPv6-PD delegations, then = those RA messages will be filtered out and the system won=E2=80=99t = work. Better to use NS/NA interchanges here, and keep the system simple. Question: Okay, this makes a lot more sense now that you=E2=80=99ve = explained things more clearly! Can you update the draft with all this? Answer: Yes! Let=E2=80=99s adopt the draft as a working group item, then = we can debate the best way to clarify the text so that it conveys all = this as clearly as possible! Can we please adopt the draft as a working = group item? That would be excellent. Let=E2=80=99s do that right away. --james woodyatt > --Apple-Mail=_0571F7F9-DD35-43C5-B413-07FA90795062 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear 6MAN,

We exhausted our available time discussing = <https://tools.ietf.org/html/draft-templin-6man-rio-redirect= > in the session yesterday, and since this draft seems to both Fred = and me to be ready for working group adoption, I=E2=80=99d like to = prompt further discussion on the list toward that end. Some participants = would like further clarifications about the reasoning behind the = technical choices we made in this draft, and I hope we can do that here = on the list. I=E2=80=99m going to use a Q&A format to present = various paraphrased versions of the questions we=E2=80=99ve noted in = talking without other participants, and try to provide more satisfying = answers here.

Question: What is this draft *really* about? I=E2=80=99m just = all confused about its basic problem statement.

Answer: Most popular host IPv6 = implementations, e.g. Linux, Darwin, Windows, et cetera, have host route = tables capable of representing routes more specific than a simple = default route, but RFC 4191 hasn=E2=80=99t been widely adopted in = default configurations=E2=80=94 so, the "Type C=E2=80=9D hosts it = defines, which process RIO options in RA messages, are not commonly = deployed in general purpose hosts. I mean, yes, you can turn it on with = a sysctl variable or some such advanced configuration parameter, but out = of the box? No, it=E2=80=99s not enabled. This draft is *really* all = about revising RFC 4191=E2=80=94 in a completely backward compatible = way=E2=80=94 to make automatically and dynamically updating host route = tables with information from the network more appropriate for widespread = deployment in general purpose hosts. In other words, we hope Linux, = FreeBSD, Windows and the like will adopt this, and turn it on by default = out of the box.

Question: So why isn=E2=80=99t RFC 4191 good enough as it is? = Why do we need to revise it?

Answer: One reason host implementations = are not Type C in default configurations is the concern about =E2=80=9Crog= ue advertisers=E2=80=9D poisoning host route tables then using that as a = platform to mount attacks on the security associations in various kinds = of cryptographic protocols. The perception (arguably a misperception, = but let=E2=80=99s leave that aside) is that it=E2=80=99s not always safe = in general purpose hosts to process RIO options in RA messages. Our = draft introduces new features to the existing protocol to narrow the = attack surface on hosts that process RIO options so that simple RA = guards can be deployed on links to block rogue advertisers and hosts = will still optimize transmission for sending to the best router for = specific destinations.

Question: Why even do this with ICMPv6 neighbor discovery at = all? Couldn=E2=80=99t you just provision host route tables with stateful = DHCPv6 options?

Answer: That=E2=80=99s an *excellent* question, because it = illustrates the situation very well! The simple answer is =E2=80=9Cfor = all the same reasons we don=E2=80=99t configure hosts with Default = Router addresses using DHCPv6,=E2=80=9D while the complete answer is = that host routing tables often need to be dynamically updated in = response to dynamic routing protocol events, and that would mean a tight = coupling between the DHCPv6 server and the dynamic routing protocol = agent so that DHCPv6 Reconfigure messages can be sent to prompt hosts to = make Information-request messages for route table updates in a timely = manner. And there is the whole fate-sharing thing. Plus, a couple other = points: a) the ICMPv6 neighbor and router discovery protocols are the = natural place in the IPv6 architecture for doing this stuff; and b) it = has some attractive qualities in typical host implementations, which = handle ICMPv6 entirely inside the kernel, whereas DHCPv6 and various = dynamic routing protocols are usually implemented as daemons.

Question: In the draft, = Figure 1: "Classical Redirection Scenario=E2=80=9D is confusing. Is the = Target a router too? What kind of node is the Source?

Answer: The draft uses = Source and Target here because it=E2=80=99s talking about the names of = the fields in the ND Redirect packet where the IPv6 address of the = relevant interface on the corresponding nodes shown in the diagram. The = node labeled Target is a gateway=E2=80=94 with one interface on the link = with the Router (which sends the ND Redirect to Source for Target), and = another interface on the link with the hosts H1, H2, H3, et cetera. The = gateway need not be a dynamic router, i.e. a gateway that uses a routing = protocol like RIP, OSPF, IS-IS or Babel. It could be a simple gateway = that obtains its prefix delegation from Router with DHCPv6-PD, and = it=E2=80=99s an important point that the Source that processes RIO = elements doesn=E2=80=99t have any need to know how the gateway obtained = the prefix to which it forwards packets, or how the routing domain is = controlled and managed. In the simple case, the Source node is just a = host, and it neither needs nor =E2=80=9Cwants=E2=80=9D to participate in = the dynamic routing protocol used by the Router and the Target = nodes.

Question:= Why are you using NS/NA for the RIO confirmation lockstep? Why not use = RS/RA instead?

Answer: In fact, the draft has a whole section about that, = =C2=A74.2.6 =E2=80=9CWhy NS/NA?=E2=80=9D and paraphrasing here: mainly = because, to send RA messages entails delay and rate limiting that do not = apply when sending NA messages. Also, RA messages are typically = multicast, which is less reliable on many wireless link types, but these = interactions are better done with unicast from Target directly to Source = without any delays. Finally, if simple RA guards are deployed without = whitelisting all the potential targets that may receive DHCPv6-PD = delegations, then those RA messages will be filtered out and the system = won=E2=80=99t work. Better to use NS/NA interchanges here, and keep the = system simple.

Question: Okay, this makes a lot more sense now that you=E2=80=99= ve explained things more clearly! Can you update the draft with all = this?

Answer: = Yes! Let=E2=80=99s adopt the draft as a working group item, then we can = debate the best way to clarify the text so that it conveys all this as = clearly as possible! Can we please adopt the draft as a working group = item? That would be excellent. Let=E2=80=99s do that right = away.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_0571F7F9-DD35-43C5-B413-07FA90795062-- From nobody Tue Jul 18 14:17:10 2017 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 C9A8F12EB5F for ; Tue, 18 Jul 2017 14:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, SPF_HELO_PASS=-0.001, 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 GFJ9kUyQstZW for ; Tue, 18 Jul 2017 14:17:07 -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 D5921127B73 for ; Tue, 18 Jul 2017 14:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4738; q=dns/txt; s=iport; t=1500412626; x=1501622226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zVollZxVtRmJsdYWG/BdMTI/Rrd6Fl3qGfMxCgs4i10=; b=SYdppbx+z2bstKURfVdoY+pUjWZXp7DG6wjnAp0vwa0SCDB1TqGYBLwU LSmPjcueHh5XxlKA3MWO1zQ9Y2ylnZRqW2aJNCOaCSEhxxqiDKCf4d1lH 6AMh4ejYvnkOxuixT8SJO9lHmcyjd5mgqdonB4p9ZkG151Nn2R+ybPkRv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAACceW5Z/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRSOC5FFIogujVaBMgNcIQuFGwKDUj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBODEDCwULAgEIGB4QIQYLJQIEDgWKFwMNCBCxdocyDYM+AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDKIUuKwuCboJXgX0Wg0OCMQWJXAWVGDsCjyS?= =?us-ascii?q?EcIIMhU+KVIwKiUwBHzhMPnUVSRIBhwN2iFMBAQE?= X-IronPort-AV: E=Sophos;i="5.40,378,1496102400"; d="scan'208";a="457627613" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2017 21:17:05 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6ILH5i0012140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 21:17:05 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 16:17:05 -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, 18 Jul 2017 16:17:05 -0500 From: "Bernie Volz (volz)" To: Rao Shoaib CC: Mark Smith , Erik Kline , "IETF IPv6 Mailing List" Subject: Re: What is the correct behavior Thread-Topic: What is the correct behavior Thread-Index: AQHS/2Noj9qYOxAh9kSqgzfYgjomSKJZKyrigADnQYD//7B+L4AAcWGA///jWBM= Date: Tue, 18 Jul 2017 21:17:05 +0000 Message-ID: <25E63DE3-A0B9-4173-B115-1D61639BF92E@cisco.com> References: <2C6940EB-A5A3-4D7D-9F7A-14D89111600A@cisco.com> <1D49BD8D-C140-435F-96FE-40E3E4A9EE80@cisco.com>, <5c2b93c5-65d8-66f6-9250-e48c7fd6ab81@oracle.com> In-Reply-To: <5c2b93c5-65d8-66f6-9250-e48c7fd6ab81@oracle.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: 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.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 21:17:09 -0000 I don't see why a v6 client or server would be processing a v4 packet. DHCP= v6 uses a different port. Perhaps the code supports both and that is why it is processing it.=20 - Bernie (from iPhone) > On Jul 18, 2017, at 7:59 PM, Rao Shoaib wrote: >=20 >=20 >=20 >> On 07/18/2017 09:13 AM, Bernie Volz (volz) wrote: >> This can happen if a client on the LAN requests a broadcast response (or= the relay or server broadcasts it for other reasons). See the broadcast fl= ag in RFC2131. >>=20 >> - Bernie (from iPhone) > Correct. The response is legal but is the behavior of the V6 node to acce= pt and process a V4 broadcast packet correct ? >=20 > Shoaib >>=20 >>> On Jul 18, 2017, at 5:58 PM, Rao Shoaib wrote: >>>=20 >>>=20 >>>=20 >>> On 07/18/2017 12:10 AM, Bernie Volz (volz) wrote: >>>>>> That means that DHCPv4 servers sniff packets off of the wire and do >>>> their own IPv4/UDP processing. >>>>=20 >>>> That's typically not necessary for DHCP servers to do that. The one I = work on certainly doesn't do that as using the standard Linux socket interf= ace works just fine. >>>>=20 >>>> - Bernie (from iPhone) >>> In this case the host is a client that is getting the DHCP packet desti= ned for another host. If the system does not have V4 configured than should= it not be required to use DHCP v6 ? >>>=20 >>> Shoaib >>>>>> On Jul 18, 2017, at 3:15 AM, Mark Smith wro= te: >>>>>>=20 >>>>>> On 18 July 2017 at 05:41, Erik Kline wrote: >>>>>> I'm not sure there is any standards behaviour applicable here. >>>>>>=20 >>>>>> The device is likely receiving many other non-0x86dd frame types as >>>>>> well (LLDP, 802.1q, ...). If you don't want them, probably best to >>>>>> just filter them. >>>>>>=20 >>>>> A related issue might be that DHCPv4 specifically suffers from a >>>>> chicken-and-egg problem, meaning that it is processing IPv4/UDP >>>>> packets before IP has been configured. Consequently the DHCPv4 server= s >>>>> sniff packets off of the wire and do their own IPv4/UDP processing. >>>>>=20 >>>>> So even though your interface to the network isn't "IPv4 enabled" by >>>>> having an IPv4 address, if a DHCPv4 server is listening on that >>>>> interface then IPv4 packets such as broadcasts will be making it into >>>>> the DHCPv4 server process and then the DHCPv4 server process might be >>>>> passing them onto and into the IPv4 protocol implementation in the >>>>> kernel, causing the martian error. >>>>>=20 >>>>>=20 >>>>>>> On 18 July 2017 at 04:33, Rao Shoaib wrote: >>>>>>> I am looking at a system which is configured for IPv6 only but sits= in a >>>>>>> network that serves both IPv4 and IPv6. When an IPv4 packet with a >>>>>>> destination broadcast address is sent out (in this case DHCP) the = system >>>>>>> accepts it and since it does not have any route to the sender it pr= ints the >>>>>>> Linux Martian packet message. >>>>>>>=20 >>>>>>> Sure, we can turn off the Martian message and maybe the system shou= ld be in >>>>>>> an IPv6 only network but the question that is being asked is that i= s it >>>>>>> correct for the system to accept and process an IPv4 broadcast pack= et in the >>>>>>> first place ? Can the experts help me out here. >>>>> You may be encountering the DHCPv4 chicken-and-egg problem, meaning >>>>> that DHCP has to process IPv4/UDP packets before IP has been >>>>> configured by DHCP. >>>>>=20 >>>>> That means that DHCPv4 servers sniff packets off of the wire and do >>>>> their own IPv4/UDP processing. >>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Shoaib >>>>>>>=20 >>>>>>> Please include me in the reply as I am not subscribed to the list. >>>>>>>=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 >>>>>> -------------------------------------------------------------------- >>>>>>=20 >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >=20 From nobody Tue Jul 18 16:15:56 2017 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 5699412EC39 for ; Tue, 18 Jul 2017 16:15:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 stzianOxba71 for ; Tue, 18 Jul 2017 16:15:53 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51A513169C for ; Tue, 18 Jul 2017 16:15:53 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u5so20353995pgq.3 for ; Tue, 18 Jul 2017 16:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LnKvw0YupDVylqu4umScHx7TLA/qvQUL1Ei5+x+6KaM=; b=RCSyNEzKi9UWcb8/W0pYxqFQ68TQoeEIGKlHsNQs3gl1DmxaFGzTV4oFe5XjfrSG4r d3tzKpLoqXWIdtV3v6coKIVYhU8V9HMrDqWXW39Wuo9NLYd98K6xtDu6gx40vD+2hR1h jJpi5zaZIV2nyqZMlQRT8EWs4UwQS+sldFgSGA283xdgxMGJuok2kEvOCS3bj7QLb2Es ZjgTcdB9DIvG6rFdBysa6Wrxmov/M7s9YNV8MiC/5s72i2EyuwYD0BZXYJhWmIGSoXfq FBUtFetvumG+Z6Ox6qhbzaY0wNC89itk41R/b99Oexf/FPLXmytIWJ5THkLDebaRJcV/ 6YVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LnKvw0YupDVylqu4umScHx7TLA/qvQUL1Ei5+x+6KaM=; b=Y5/RhABSPkksd/uchqp2pGDqIxvq4E71sTSVvDboKnGVrfESidIYSZ40S4b9ixKYRV JYmQ3fCHSIiIUVq1iCCwKTfGdzNEJGDZFdSp0BsipHBePEr0aU90F1+Ya8cyMomrg3un shhZYFQ3VUbZeG0/mv1X9HWvwELnHjZVLwuoLlDXBuF2QnzULCB1nQZ40kNptRU//fje UZZObqHgcJ4kxzy6gHoVnyONd/iWmSTPVYTtwrCktP7DduWlVPWXSwgY8vwn1/AaYzhM 0BtQa+QRXXPxvNqag6Q1OZ950bk0N9YCcpzFSsbRfCsVurAqWNy+3Ai3Zvt25DF15OOL i90g== X-Gm-Message-State: AIVw113imvBdG7OPyGILI1OVIPsjU4FEOqvNGozqFL+TiBz9YZOALxDx BvqDpG6JoYowvwxe X-Received: by 10.84.217.16 with SMTP id o16mr4188024pli.31.1500419753256; Tue, 18 Jul 2017 16:15:53 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y26sm7443179pfk.46.2017.07.18.16.15.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 16:15:52 -0700 (PDT) Subject: Re: To: james woodyatt References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: Brian E Carpenter Organization: University of Auckland Cc: IPv6 List Message-ID: <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> Date: Wed, 19 Jul 2017 11:15:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 23:15:55 -0000 On 18/07/2017 20:04, james woodyatt wrote: > On Jul 17, 2017, at 23:42, David Farmer wrote: >> >> I've begun to think there are two real problems here; >> >> 1. RFC4291 categorically says architecturally IIDs are 64bits, and se= ems to imply this is the case for all components of IPv6. While it is the= case for several components of IPv6, it is not the case for other import= ant components. Neighbor Discovery, DHCPv6, and Routing, etc... are not a= rchitecturally based on 64bit IIDs at all, in fact they are clearly based= on IIDs of any length.=20 >=20 > Those other components aren=E2=80=99t based on IIDs at all. They=E2=80=99= re based on IPv6 addresses and routing prefixes, but they=E2=80=99re not = based on IIDs.=20 Hmm. Let's consider a case in which the last-hop route to a given LAN has= a prefix of length, say, /80. What is the name of the bit-string from bits 81 through= 127 of the host address? If they aren't called the "IID" what are they called? > That RFC 4291 still has this obsolescent concept of an IID that comes f= rom embedding Modified EUI-64 transformations of MAC addresses isn=E2=80=99= t actually causing any real problem that I=E2=80=99m seeing stated anywhe= re. It seems perfectly safe to me to promote to Standard a minor revision= of RFC 4291 that retains the existing definition of the IID in the archi= tecture. In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a mino= r revision? I'm unaware of any single place that anyone would need to modify their co= de if that text was published as an RFC. That's a major part of the criteria= for Internet Standard. Brian From nobody Tue Jul 18 23:22:58 2017 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 D78B812EB2B for ; Tue, 18 Jul 2017 23:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 6rgSU7FGyevN for ; Tue, 18 Jul 2017 23:22:54 -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 17D56127369 for ; Tue, 18 Jul 2017 23:22:53 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w126so92234088wme.0 for ; Tue, 18 Jul 2017 23:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=LPVuvMZ4tTIyPAtr3jfrQ/AmMuj30RWGpeWHbdi0IK8=; b=FxuJewGFzNug5cawTv0QuMRQlZyI2IR/5AIg0NJs69R5YwfJBsWubNSq/ywWb+HUXb 9N1zbW28kZ29o4LwSfeqG7ywfONEz381lij1+rjLARh4PZ2NciZqDC5/AkTqqs/xb34M aVJMC6n3GXsVHOZJmIGclOjygKaKRJIFnAycAu4xE9ZfXBHtKVzaOYo7dSqKBfxf+P/X 5w/d50bW2BL2Qj+8lJRUNGf++CfDfPk2Yrj1FeTMqmYC3x2JAygu2ftm7kg04p5bN23G YGyp0g385inpd8F9VfgBogj8kgJH4e5Nqz9pqcU5xPqb1ZOt22oWzAwzzgsUMcsE1njk apsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=LPVuvMZ4tTIyPAtr3jfrQ/AmMuj30RWGpeWHbdi0IK8=; b=a85yvNS6jbhkL6e8ogGlokbT5Owwe74a6vZDFLc6QCBMWb5nx6EIQJRje+mJ59M8Up 87qv2qXpw/w7qGD+3lNiTED36OBx6p5MHM4mu2BzQbzcrjQIDGG72gyp6H/3H6ntgdRt sGfFuamOP6ikWk5TRXaQ/wnWGc6OSRNV5xab2fvBisqgdb+0GLyeSbxoWmCZq4TBxrT4 vcf1XhUIQ3bi5KJxObxpV90GuhslqdchZqnKo+eb4MXzlLqwPjLl0T/uvpsLDP8Xj9PG imFKUW0nTOSrWsbaRzETy7yBpK/lOZ74kWB5gLlHolJVIHMj+s9tdubYYatPgSJTLHe0 Lz+g== X-Gm-Message-State: AIVw113BYDOSr6uvMuzP3RBJhOIc+zBqE7cqoFalv0zCF8HPTferTcSC 1b8hO60bhG8utlFh65HMFw== X-Received: by 10.28.23.11 with SMTP id 11mr177843wmx.125.1500445372085; Tue, 18 Jul 2017 23:22:52 -0700 (PDT) Received: from dhcp-9e57.meeting.ietf.org (dhcp-9e57.meeting.ietf.org. [31.133.158.87]) by smtp.gmail.com with ESMTPSA id t14sm3192901wra.44.2017.07.18.23.22.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 23:22:51 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_E8480FAB-6E4A-4748-9B55-F413B62F9F50" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 19 Jul 2017 08:22:50 +0200 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> To: IPv6 List In-Reply-To: <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> Message-Id: <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:22:56 -0000 --Apple-Mail=_E8480FAB-6E4A-4748-9B55-F413B62F9F50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 19, 2017, at 01:15, Brian E Carpenter = wrote: >=20 > Hmm. Let's consider a case in which the last-hop route to a given LAN = has a prefix of > length, say, /80. What is the name of the bit-string from bits 81 = through 127 of the > host address? If they aren't called the "IID" what are they called? If have yet to find where RFC 4291 clearly names the part of an IPv6 = address that follows a *routing* prefix apart from a *subnet* prefix. = Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is = not equivalent to the concept of a subnet, and such a routing prefix is = not equivalent to a subnet prefix. As RFC 5942 clarifies. >> That RFC 4291 still has this obsolescent concept of an IID that comes = from embedding Modified EUI-64 transformations of MAC addresses isn=E2=80=99= t actually causing any real problem that I=E2=80=99m seeing stated = anywhere. It seems perfectly safe to me to promote to Standard a minor = revision of RFC 4291 that retains the existing definition of the IID in = the architecture. >=20 > In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a = minor revision? None. I think it succeeds. I=E2=80=99m happy with = I-D.ietf-6man-rfc4291bis-09, and I think it should be published with a = fresh STD number. > I'm unaware of any single place that anyone would need to modify their = code > if that text was published as an RFC. That's a major part of the = criteria for > Internet Standard. Agreed. --james woodyatt > --Apple-Mail=_E8480FAB-6E4A-4748-9B55-F413B62F9F50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 19, 2017, at 01:15, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Hmm. Let's consider a case in which the last-hop route to a = given LAN has a prefix of
length, say, /80. What is the = name of the bit-string from bits 81 through 127 of the
host = address? If they aren't called the "IID" what are they called?

If = have yet to find where RFC 4291 clearly names the part of an IPv6 = address that follows a *routing* prefix apart from a *subnet* prefix. = Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is = not equivalent to the concept of a subnet, and such a routing prefix is = not equivalent to a subnet prefix. As RFC 5942 clarifies.

That RFC 4291 still has = this obsolescent concept of an IID that comes from embedding Modified = EUI-64 transformations of MAC addresses isn=E2=80=99t actually causing = any real problem that I=E2=80=99m seeing stated anywhere. It seems = perfectly safe to me to promote to Standard a minor revision of RFC 4291 = that retains the existing definition of the IID in the architecture.

In what respect does = draft-ietf-6man-rfc4291bis-09 fail to be such a minor revision?

None. = I think it succeeds. I=E2=80=99m happy with I-D.ietf-6man-rfc4291bis-09, = and I think it should be published with a fresh STD number.

I'm unaware of any single place that anyone would need to = modify their code
if that text was published as an RFC. = That's a major part of the criteria for
Internet = Standard.

Agreed.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_E8480FAB-6E4A-4748-9B55-F413B62F9F50-- From nobody Wed Jul 19 00:58:02 2017 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 83A77131C07 for ; Wed, 19 Jul 2017 00:58:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HL2nzOnCAbQX for ; Wed, 19 Jul 2017 00:57:58 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858BF131532 for ; Wed, 19 Jul 2017 00:57:58 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 123so26827288pgj.1 for ; Wed, 19 Jul 2017 00:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OZg2nUXfP41/+XQD9emlZyyiChN5OXPEBlLTQ+O3594=; b=QM+Fg/wvuN5DC4aiEAtuFmgInoQHGLNXbov7Kxs5d5Tlr7EqlGaJcMM6Z9qElUDQgC i4036C1nSbZkddvFyFpucA0612Pf0AQq3OY5fOotXe5/Ud+gLkUxb245yiDHwOpf4vJI 5giQOflKC3YRswqheQ3t+eSnjb4ZOGTGwp9ENyvRpMRgNmjr6nGU7SpXIFMr4Gb/s0Eh EtRDcG/5LjYhgkL0CYJWnDh1Dq6DSkkdDF6BZwPKmHpggo9rQCCv36xqyCmMdDHl6jSu IDS2T9DjQmqkMTx3o+IDDTGRFqcWAHmKBJg7JW6GP4x5VTpusy5Zc1NvDd282Kjss1nN DH6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OZg2nUXfP41/+XQD9emlZyyiChN5OXPEBlLTQ+O3594=; b=uC1o4yP6JLCKcZmDkodzbdFuyBjLLeI+IM0p8U+wuog+ojwhvXcudwyMYch6bksOdb kLG5oLPKCsHsrwlPAYp1GkksgX2j1mXz0y2EjWVDe1mIJhyF9SetXaG7HW+AjYR5eKI7 sKcJivZ2NfapdCi1Pwwg+4/EfLdmURCGd4utG6K3fOeDJtMEcHjxNbHZKTAMev1qvUgI NHpJi2LXDFHd6OpPbXbhgtHcclOdrFXYdeJqYxgCY9jfITTd9mEZtRRghVYRi4m6oe3M JRN+JuIcKQ5eALE7J7uwlhA/S+hpwrCn9BrcDkbcV9hZvqae9NyHA23neyU5TLgmdY9E ArLA== X-Gm-Message-State: AIVw112e2VSDwTwlPFDTB/q06V0cb7IdPXNVuXCg3CyQczYW1c2/cawK Hfa8DLoKCZ56dwO2 X-Received: by 10.84.129.7 with SMTP id 7mr1853532plb.133.1500451077855; Wed, 19 Jul 2017 00:57:57 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s206sm9780857pfs.55.2017.07.19.00.57.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 00:57:57 -0700 (PDT) Subject: Re: To: james woodyatt , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> Date: Wed, 19 Jul 2017 19:57:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:58:01 -0000 On 19/07/2017 18:22, james woodyatt wrote: > On Jul 19, 2017, at 01:15, Brian E Carpenter wrote: >> >> Hmm. Let's consider a case in which the last-hop route to a given LAN = has a prefix of >> length, say, /80. What is the name of the bit-string from bits 81 thro= ugh 127 of the >> host address? If they aren't called the "IID" what are they called? >=20 > If have yet to find where RFC 4291 clearly names the part of an IPv6 ad= dress that follows a *routing* prefix apart from a *subnet* prefix. Moreo= ver, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is not eq= uivalent to the concept of a subnet, and such a routing prefix is not equ= ivalent to a subnet prefix. As RFC 5942 clarifies. Agreed, but I phrased my question in full knowledge of that. What do we c= all those trailing bits of the address? (I was reading the source of the Python 'ipaddress' = module yesterday, and saw a comment about 'host bits', but that seems very 20th century, gi= ven that the IPv6 architecture refers to interfaces.) Brian >=20 >>> That RFC 4291 still has this obsolescent concept of an IID that comes= from embedding Modified EUI-64 transformations of MAC addresses isn=E2=80= =99t actually causing any real problem that I=E2=80=99m seeing stated any= where. It seems perfectly safe to me to promote to Standard a minor revis= ion of RFC 4291 that retains the existing definition of the IID in the ar= chitecture. >> >> In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a m= inor revision? >=20 > None. I think it succeeds. I=E2=80=99m happy with I-D.ietf-6man-rfc4291= bis-09, and I think it should be published with a fresh STD number. >=20 >> I'm unaware of any single place that anyone would need to modify their= code >> if that text was published as an RFC. That's a major part of the crite= ria for >> Internet Standard. >=20 > Agreed. >=20 > --james woodyatt > >=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 Wed Jul 19 01:12:31 2017 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 DE88513167A for ; Wed, 19 Jul 2017 01:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 zvwYuk-CWdzB for ; Wed, 19 Jul 2017 01:12:27 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 46389131600 for ; Wed, 19 Jul 2017 01:12:27 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id 12so55266807wrb.1 for ; Wed, 19 Jul 2017 01:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4Ozmk69u+SH/HJGX1hZVDx2ZyK/Z/wCS0aQG9MyMoNA=; b=rknEZ4w5qREdu2Ty4PaaGng9NljCgdnw6rfMky7xGOBVSXOQDGke5PZs6CZXPXUIaJ Kzec34BGLvj6NdiaRCsRNMPkVq1poXzXhTvYz/Jz5OcyvTmmONN0SVMwT0XQIgHcci0w VvyrUv5p2ESNHWrfWa1Mdq4VuIkgAzw2sSXzS9S3TN5Po21aw/71gt6q4scPo+05Hccy OlihfPj1uKFvawgRJsNmpSuniQxBAnaAmOKJyNC9CDug0icvDsvWz8XeRjrvQ2PqRJ8y xJ/niZdEoJ0EsZ+LI2blKMzLyWrbPRKiP0CZ6MSfolrDq7Xl+cYkC0SlqGPzqWsGCvh5 GXaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4Ozmk69u+SH/HJGX1hZVDx2ZyK/Z/wCS0aQG9MyMoNA=; b=jHanfsJubCiiHqVIQmyEg87dMP4Tf4v+v+tIyIhb8n0M3iqFrfCUfZBxWhFmXwF1hY C/sFYwIE0DFitODjJcvTfqor48MWCDrmFSIx8cGBXRK3BVolleRE0ewysMQfdzzZPKil 4dpFdsegfTi8JDC7bxRNeWfS8Pl44b4H4h0NIn5h4bYRCxZms+VIRC/ensUgclJhfWXq If2XTCWYBW/8rr0IP5RGxnhDcD4OP2ZDODLgOFOBg++Dk9bX0LG3JClbU6lEgO6WIjYA l/VhStiWlPTpu3vwUXGEvYwj+sEipz9g1HN2xTXOU2SunQrSw7b0NEGdYHOoV3O/DYiT OP1Q== X-Gm-Message-State: AIVw113eByzErImvtBGFfeP27GotfVnyq5kU62MoZtq6a8APXAnqWgiy zojhJjZkZYUx2Gav X-Received: by 10.223.128.42 with SMTP id 39mr3704584wrk.175.1500451945676; Wed, 19 Jul 2017 01:12:25 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:c9ba:4d58:aff9:2b6f? ([2001:67c:1232:144:c9ba:4d58:aff9:2b6f]) by smtp.gmail.com with ESMTPSA id 90sm3616992wrk.38.2017.07.19.01.12.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 01:12:25 -0700 (PDT) From: james woodyatt Message-Id: <345495C4-030E-41FA-98CD-B403509B9402@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4FAB642E-A512-4905-AE02-341F2AE35CD9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Wed, 19 Jul 2017 10:12:23 +0200 In-Reply-To: <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> Cc: IPv6 List To: Brian E Carpenter References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:12:29 -0000 --Apple-Mail=_4FAB642E-A512-4905-AE02-341F2AE35CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 19, 2017, at 09:57, Brian E Carpenter = wrote: > On 19/07/2017 18:22, james woodyatt wrote: >> On Jul 19, 2017, at 01:15, Brian E Carpenter = > = wrote: >>>=20 >>> Hmm. Let's consider a case in which the last-hop route to a given = LAN has a prefix of >>> length, say, /80. What is the name of the bit-string from bits 81 = through 127 of the >>> host address? If they aren't called the "IID" what are they called? >>=20 >> If have yet to find where RFC 4291 clearly names the part of an IPv6 = address that follows a *routing* prefix apart from a *subnet* prefix. = Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is = not equivalent to the concept of a subnet, and such a routing prefix is = not equivalent to a subnet prefix. As RFC 5942 clarifies. >=20 > Agreed, but I phrased my question in full knowledge of that. What do = we call those trailing > bits of the address? (I was reading the source of the Python = 'ipaddress' module yesterday, > and saw a comment about 'host bits', but that seems very 20th century, = given that the > IPv6 architecture refers to interfaces.) I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for = this concept, and I find that I rarely have much need for it. I suppose = if I were using on-link prefixes longer than /64, then I=E2=80=99d need = it so I could differentiate between the 64-bit Interface ID and the = shorter part of the address that follows the on-link prefix. --james woodyatt > --Apple-Mail=_4FAB642E-A512-4905-AE02-341F2AE35CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 19, 2017, at 09:57, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 19/07/2017 18:22, james woodyatt = wrote:
On Jul 19, 2017, at 01:15, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Hmm. = Let's consider a case in which the last-hop route to a given LAN has a = prefix of
length, say, /80. What is the name of the = bit-string from bits 81 through 127 of the
host address? = If they aren't called the "IID" what are they called?

If have yet to find where RFC = 4291 clearly names the part of an IPv6 address that follows a *routing* = prefix apart from a *subnet* prefix. Moreover, the phrase =E2=80=9Clast-ho= p route to a given LAN=E2=80=9D is not equivalent to the concept of a = subnet, and such a routing prefix is not equivalent to a subnet prefix. = As RFC 5942 clarifies.

Agreed, but I phrased my question in full = knowledge of that. What do we call those trailing
bits of the address? (I was reading the source = of the Python 'ipaddress' module yesterday,
and saw a comment about 'host bits', but that = seems very 20th century, given that the
IPv6 architecture = refers to interfaces.)

I=E2=80=99ve been mentally using =E2=80=9Caddress = suffix=E2=80=9D for this concept, and I find that I rarely have much = need for it. I suppose if I were using on-link prefixes longer than /64, = then I=E2=80=99d need it so I could differentiate between the 64-bit = Interface ID and the shorter part of the address that follows the = on-link prefix.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_4FAB642E-A512-4905-AE02-341F2AE35CD9-- From nobody Wed Jul 19 01:27:03 2017 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 39362131C2A for ; Wed, 19 Jul 2017 01:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 BYGzJbGyTTnu for ; Wed, 19 Jul 2017 01:26:59 -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 EDBF1131C2C for ; Wed, 19 Jul 2017 01:26:58 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v127so16316854itd.0 for ; Wed, 19 Jul 2017 01:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xd33+KFQQFeaQIHM3MetDx7Cerupz9AA4QdTUwHEOfM=; b=G4kjM+7USZYtJf8FPePauBkci0+ptesYccs/uBteeo6pvr3kr3YpEo7sG1GK3cwY5r OwWjQGi8RIS/WORJ2+yCQW+RZuCm3K8LAz3+pD8m871cmXCqSSJO3qYU5Kq7izXDF6CN FeqOeL7USwfsRWvxcM0PpJ92OJXiYkJL6AFV5C2O7nx/nubSvsdVUWjUCbXS9wMV3jIa 7aZvhdYMrEPIWa/sesH7pZrE/7lZS1AlIsAXjGICGHXfaPYEJVN5ZapsydzFvR/zHfx8 zryQsaLWVeFBrnaxcn6R7bjS25xkEYUyNdYEl3ms8UPaXP2LckZRblpKBAPq8rgIYdVf g1lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xd33+KFQQFeaQIHM3MetDx7Cerupz9AA4QdTUwHEOfM=; b=uhc6HhgnoongRSYOoPMQhjMtH3TJ04R+hgInT2Wcex6+eCwRyUoT4AGoP7FZOjiQY/ af26KPletc/Ht608ZLUVBKdcNzwknfs663j38GMczNSDUFaHehVsDUH5mOe2DmNpm8tO OSdrSorbYcG9i8FNze5IglBdV0wmFG+L7AvNFKn7ylS9w7qgHLPJj5TYgQ8WJ35a52ig rDpGpQSMd1QsLvh21sbhVxojDanztIZEXNw+ZCXbzSon9MuhOg0xeuRNd18aDmLZ7+fB 1NKnqw3ufHixIyBWIxBoDAjTMD4wHM9MMIxvWHScpFM5CvyM3AMx/+NeKI64fFFx2DG3 rdvw== X-Gm-Message-State: AIVw112XR1ElTOr6kz3iXsK26O7CXnps1SkvzQqTvWyYKWvEjR87H51Y 20riM2O0SNiZESCAmy6QjYf5P6lT+7uA X-Received: by 10.36.106.5 with SMTP id l5mr1084653itc.95.1500452817955; Wed, 19 Jul 2017 01:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.164 with HTTP; Wed, 19 Jul 2017 01:26:37 -0700 (PDT) In-Reply-To: <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> From: Lorenzo Colitti Date: Wed, 19 Jul 2017 10:26:37 +0200 Message-ID: Subject: Re: To: james woodyatt Cc: IPv6 List Content-Type: multipart/alternative; boundary="001a1147236a381cd10554a76551" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:27:00 -0000 --001a1147236a381cd10554a76551 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 8:22 AM, james woodyatt wrote: > If have yet to find where RFC 4291 clearly names the part of an IPv6 > address that follows a *routing* prefix apart from a *subnet* prefix. > There is no name for this concept because it doesn't make sense. The zero or more on-link prefixes on a link are entirely separate from any IP addresses the host might have on that link. Any address the host has on that interface might be covered by zero on-link prefixes, one on-link prefix, or more than one. Similarly, any on-link prefix may cover zero or more addresses that the host has on that interface. --001a1147236a381cd10554a76551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 19, 2017 at 8:22 AM, james woodyatt <jhw@google.com> = wrote:
If have yet to find where RFC 4291 clearly names the part of an= IPv6 address that follows a *routing* prefix apart from a *subnet* prefix.=

There is no name for thi= s concept because it doesn't make sense.

The z= ero or more on-link prefixes on a link are entirely separate from any IP ad= dresses the host might have on that link.

Any addr= ess the host has on that interface might be covered by zero on-link prefixe= s, one on-link prefix, or more than one. Similarly, any on-link prefix may = cover zero or more addresses that the host has on that interface.
--001a1147236a381cd10554a76551-- From nobody Wed Jul 19 01:50:45 2017 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 C1563131C21 for ; Wed, 19 Jul 2017 01:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 VN6S-m5vQ6mT for ; Wed, 19 Jul 2017 01:50:41 -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 CC676131C3B for ; Wed, 19 Jul 2017 01:50:40 -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 v6J8oeQp057263; Wed, 19 Jul 2017 01:50:40 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6J8oaGm057251 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 01:50:36 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 01:50:35 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 01:50:35 -0700 From: "Templin, Fred L" To: james woodyatt , 6MAN Working Group Subject: RE: In consideration of I-D.templin-6man-rio-redirect Thread-Topic: In consideration of I-D.templin-6man-rio-redirect Thread-Index: AQHTAAqYiPckzv4gME6Aj7m1B2sutqJa1WkA Date: Wed, 19 Jul 2017 08:50:35 +0000 Message-ID: <4a50273fd30849c8836ebc1dda0076d3@XCH15-06-08.nw.nos.boeing.com> References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> In-Reply-To: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_4a50273fd30849c8836ebc1dda0076d3XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:50:44 -0000 --_000_4a50273fd30849c8836ebc1dda0076d3XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFtZXMsDQoNClRvIHdoYXQgeW91IHNhaWQgdmVyeSB3ZWxsIGluIHlvdXIgbWVzc2FnZSwg SSB3aWxsIGFkZCB0aGF0IHRoaXMgZHJhZnQgY29tcGxlbWVudHMNCnRoZSBub3Rpb24gb2YgZ2l2 aW5nIGEgLzY0IHRvIGVhY2ggaG9zdCBhcyBoYXMgYmVlbiBkaXNjdXNzZWQgd2lkZWx5IGluIHJl Y2VudCBsaXN0DQptZXNzYWdlcy4gVGhlcmUgbmVlZHMgdG8gYmUgc29tZSB3YXkgZm9yIG5laWdo Ym9ycyB0byBkaXNjb3ZlciB0aGUgLzY0cyBvZg0KcGVlcnMgb24gdGhlIGxpbmssIGFuZCBzaGlw cGluZyB0aGUgLzY0cyBhcm91bmQgaW4gUklPcyBpbiBJUHY2IE5EIG1lc3NhZ2VzIGlzDQpJTUhP IHRoZSByaWdodCB3YXkgdG8gZ28gd2hlbiBydW5uaW5nIGEgZHluYW1pYyByb3V0aW5nIHByb3Rv Y29sIGlzIGltcHJhY3RpY2FsLg0KDQpBcyB0byB1c2UgY2FzZXMsIGNvbnNpZGVyIGEgbGFyZ2Ug TEFOIHdpdGggbG90cyBvZiBob3N0cyB0aGF0IGhhdmUgcmVjZWl2ZWQgLzY0cy4NCkEgc3BlY2lm aWMgZXhhbXBsZSB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgdGhlIElFVEYgY29uZmVyZW5jZSBTU0lE cy4gU28sIEkgYWdyZWUNCnRoYXQgd2Ugc2hvdWxkIGJyaW5nIHRoaXMgaW4gYXMgYSB3ZyBkb2N1 bWVudCBzbyB3ZSBjYW4gYWRkcmVzcyB0aGVzZSB1c2UgY2FzZXMuDQoNClRoYW5rcyAtIEZyZWQN Cg0KRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGphbWVzIHdvb2R5YXR0DQpTZW50OiBUdWVzZGF5LCBKdWx5IDE4LCAyMDE3IDI6MTIgUE0NClRv OiA2TUFOIFdvcmtpbmcgR3JvdXAgPGlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJbiBjb25zaWRl cmF0aW9uIG9mIEktRC50ZW1wbGluLTZtYW4tcmlvLXJlZGlyZWN0DQoNCkRlYXIgNk1BTiwNCg0K V2UgZXhoYXVzdGVkIG91ciBhdmFpbGFibGUgdGltZSBkaXNjdXNzaW5nIDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdD4gaW4gdGhlIHNl c3Npb24geWVzdGVyZGF5LCBhbmQgc2luY2UgdGhpcyBkcmFmdCBzZWVtcyB0byBib3RoIEZyZWQg YW5kIG1lIHRvIGJlIHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLCBJ4oCZZCBsaWtl IHRvIHByb21wdCBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgdG93YXJkIHRoYXQgZW5k LiBTb21lIHBhcnRpY2lwYW50cyB3b3VsZCBsaWtlIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgYWJv dXQgdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhlIHRlY2huaWNhbCBjaG9pY2VzIHdlIG1hZGUgaW4g dGhpcyBkcmFmdCwgYW5kIEkgaG9wZSB3ZSBjYW4gZG8gdGhhdCBoZXJlIG9uIHRoZSBsaXN0LiBJ 4oCZbSBnb2luZyB0byB1c2UgYSBRJkEgZm9ybWF0IHRvIHByZXNlbnQgdmFyaW91cyBwYXJhcGhy YXNlZCB2ZXJzaW9ucyBvZiB0aGUgcXVlc3Rpb25zIHdl4oCZdmUgbm90ZWQgaW4gdGFsa2luZyB3 aXRob3V0IG90aGVyIHBhcnRpY2lwYW50cywgYW5kIHRyeSB0byBwcm92aWRlIG1vcmUgc2F0aXNm eWluZyBhbnN3ZXJzIGhlcmUuDQoNClF1ZXN0aW9uOiBXaGF0IGlzIHRoaXMgZHJhZnQgKnJlYWxs eSogYWJvdXQ/IEnigJltIGp1c3QgYWxsIGNvbmZ1c2VkIGFib3V0IGl0cyBiYXNpYyBwcm9ibGVt IHN0YXRlbWVudC4NCg0KQW5zd2VyOiBNb3N0IHBvcHVsYXIgaG9zdCBJUHY2IGltcGxlbWVudGF0 aW9ucywgZS5nLiBMaW51eCwgRGFyd2luLCBXaW5kb3dzLCBldCBjZXRlcmEsIGhhdmUgaG9zdCBy b3V0ZSB0YWJsZXMgY2FwYWJsZSBvZiByZXByZXNlbnRpbmcgcm91dGVzIG1vcmUgc3BlY2lmaWMg dGhhbiBhIHNpbXBsZSBkZWZhdWx0IHJvdXRlLCBidXQgUkZDIDQxOTEgaGFzbuKAmXQgYmVlbiB3 aWRlbHkgYWRvcHRlZCBpbiBkZWZhdWx0IGNvbmZpZ3VyYXRpb25z4oCUIHNvLCB0aGUgIlR5cGUg Q+KAnSBob3N0cyBpdCBkZWZpbmVzLCB3aGljaCBwcm9jZXNzIFJJTyBvcHRpb25zIGluIFJBIG1l c3NhZ2VzLCBhcmUgbm90IGNvbW1vbmx5IGRlcGxveWVkIGluIGdlbmVyYWwgcHVycG9zZSBob3N0 cy4gSSBtZWFuLCB5ZXMsIHlvdSBjYW4gdHVybiBpdCBvbiB3aXRoIGEgc3lzY3RsIHZhcmlhYmxl IG9yIHNvbWUgc3VjaCBhZHZhbmNlZCBjb25maWd1cmF0aW9uIHBhcmFtZXRlciwgYnV0IG91dCBv ZiB0aGUgYm94PyBObywgaXTigJlzIG5vdCBlbmFibGVkLiBUaGlzIGRyYWZ0IGlzICpyZWFsbHkq IGFsbCBhYm91dCByZXZpc2luZyBSRkMgNDE5MeKAlCBpbiBhIGNvbXBsZXRlbHkgYmFja3dhcmQg Y29tcGF0aWJsZSB3YXnigJQgdG8gbWFrZSBhdXRvbWF0aWNhbGx5IGFuZCBkeW5hbWljYWxseSB1 cGRhdGluZyBob3N0IHJvdXRlIHRhYmxlcyB3aXRoIGluZm9ybWF0aW9uIGZyb20gdGhlIG5ldHdv cmsgbW9yZSBhcHByb3ByaWF0ZSBmb3Igd2lkZXNwcmVhZCBkZXBsb3ltZW50IGluIGdlbmVyYWwg cHVycG9zZSBob3N0cy4gSW4gb3RoZXIgd29yZHMsIHdlIGhvcGUgTGludXgsIEZyZWVCU0QsIFdp bmRvd3MgYW5kIHRoZSBsaWtlIHdpbGwgYWRvcHQgdGhpcywgYW5kIHR1cm4gaXQgb24gYnkgZGVm YXVsdCBvdXQgb2YgdGhlIGJveC4NCg0KUXVlc3Rpb246IFNvIHdoeSBpc27igJl0IFJGQyA0MTkx IGdvb2QgZW5vdWdoIGFzIGl0IGlzPyBXaHkgZG8gd2UgbmVlZCB0byByZXZpc2UgaXQ/DQoNCkFu c3dlcjogT25lIHJlYXNvbiBob3N0IGltcGxlbWVudGF0aW9ucyBhcmUgbm90IFR5cGUgQyBpbiBk ZWZhdWx0IGNvbmZpZ3VyYXRpb25zIGlzIHRoZSBjb25jZXJuIGFib3V0IOKAnHJvZ3VlIGFkdmVy dGlzZXJz4oCdIHBvaXNvbmluZyBob3N0IHJvdXRlIHRhYmxlcyB0aGVuIHVzaW5nIHRoYXQgYXMg YSBwbGF0Zm9ybSB0byBtb3VudCBhdHRhY2tzIG9uIHRoZSBzZWN1cml0eSBhc3NvY2lhdGlvbnMg aW4gdmFyaW91cyBraW5kcyBvZiBjcnlwdG9ncmFwaGljIHByb3RvY29scy4gVGhlIHBlcmNlcHRp b24gKGFyZ3VhYmx5IGEgbWlzcGVyY2VwdGlvbiwgYnV0IGxldOKAmXMgbGVhdmUgdGhhdCBhc2lk ZSkgaXMgdGhhdCBpdOKAmXMgbm90IGFsd2F5cyBzYWZlIGluIGdlbmVyYWwgcHVycG9zZSBob3N0 cyB0byBwcm9jZXNzIFJJTyBvcHRpb25zIGluIFJBIG1lc3NhZ2VzLiBPdXIgZHJhZnQgaW50cm9k dWNlcyBuZXcgZmVhdHVyZXMgdG8gdGhlIGV4aXN0aW5nIHByb3RvY29sIHRvIG5hcnJvdyB0aGUg YXR0YWNrIHN1cmZhY2Ugb24gaG9zdHMgdGhhdCBwcm9jZXNzIFJJTyBvcHRpb25zIHNvIHRoYXQg c2ltcGxlIFJBIGd1YXJkcyBjYW4gYmUgZGVwbG95ZWQgb24gbGlua3MgdG8gYmxvY2sgcm9ndWUg YWR2ZXJ0aXNlcnMgYW5kIGhvc3RzIHdpbGwgc3RpbGwgb3B0aW1pemUgdHJhbnNtaXNzaW9uIGZv ciBzZW5kaW5nIHRvIHRoZSBiZXN0IHJvdXRlciBmb3Igc3BlY2lmaWMgZGVzdGluYXRpb25zLg0K DQpRdWVzdGlvbjogV2h5IGV2ZW4gZG8gdGhpcyB3aXRoIElDTVB2NiBuZWlnaGJvciBkaXNjb3Zl cnkgYXQgYWxsPyBDb3VsZG7igJl0IHlvdSBqdXN0IHByb3Zpc2lvbiBob3N0IHJvdXRlIHRhYmxl cyB3aXRoIHN0YXRlZnVsIERIQ1B2NiBvcHRpb25zPw0KDQpBbnN3ZXI6IFRoYXTigJlzIGFuICpl eGNlbGxlbnQqIHF1ZXN0aW9uLCBiZWNhdXNlIGl0IGlsbHVzdHJhdGVzIHRoZSBzaXR1YXRpb24g dmVyeSB3ZWxsISBUaGUgc2ltcGxlIGFuc3dlciBpcyDigJxmb3IgYWxsIHRoZSBzYW1lIHJlYXNv bnMgd2UgZG9u4oCZdCBjb25maWd1cmUgaG9zdHMgd2l0aCBEZWZhdWx0IFJvdXRlciBhZGRyZXNz ZXMgdXNpbmcgREhDUHY2LOKAnSB3aGlsZSB0aGUgY29tcGxldGUgYW5zd2VyIGlzIHRoYXQgaG9z dCByb3V0aW5nIHRhYmxlcyBvZnRlbiBuZWVkIHRvIGJlIGR5bmFtaWNhbGx5IHVwZGF0ZWQgaW4g cmVzcG9uc2UgdG8gZHluYW1pYyByb3V0aW5nIHByb3RvY29sIGV2ZW50cywgYW5kIHRoYXQgd291 bGQgbWVhbiBhIHRpZ2h0IGNvdXBsaW5nIGJldHdlZW4gdGhlIERIQ1B2NiBzZXJ2ZXIgYW5kIHRo ZSBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgYWdlbnQgc28gdGhhdCBESENQdjYgUmVjb25maWd1 cmUgbWVzc2FnZXMgY2FuIGJlIHNlbnQgdG8gcHJvbXB0IGhvc3RzIHRvIG1ha2UgSW5mb3JtYXRp b24tcmVxdWVzdCBtZXNzYWdlcyBmb3Igcm91dGUgdGFibGUgdXBkYXRlcyBpbiBhIHRpbWVseSBt YW5uZXIuIEFuZCB0aGVyZSBpcyB0aGUgd2hvbGUgZmF0ZS1zaGFyaW5nIHRoaW5nLiBQbHVzLCBh IGNvdXBsZSBvdGhlciBwb2ludHM6IGEpIHRoZSBJQ01QdjYgbmVpZ2hib3IgYW5kIHJvdXRlciBk aXNjb3ZlcnkgcHJvdG9jb2xzIGFyZSB0aGUgbmF0dXJhbCBwbGFjZSBpbiB0aGUgSVB2NiBhcmNo aXRlY3R1cmUgZm9yIGRvaW5nIHRoaXMgc3R1ZmY7IGFuZCBiKSBpdCBoYXMgc29tZSBhdHRyYWN0 aXZlIHF1YWxpdGllcyBpbiB0eXBpY2FsIGhvc3QgaW1wbGVtZW50YXRpb25zLCB3aGljaCBoYW5k bGUgSUNNUHY2IGVudGlyZWx5IGluc2lkZSB0aGUga2VybmVsLCB3aGVyZWFzIERIQ1B2NiBhbmQg dmFyaW91cyBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSB1c3VhbGx5IGltcGxlbWVudGVk IGFzIGRhZW1vbnMuDQoNClF1ZXN0aW9uOiBJbiB0aGUgZHJhZnQsIEZpZ3VyZSAxOiAiQ2xhc3Np Y2FsIFJlZGlyZWN0aW9uIFNjZW5hcmlv4oCdIGlzIGNvbmZ1c2luZy4gSXMgdGhlIFRhcmdldCBh IHJvdXRlciB0b28/IFdoYXQga2luZCBvZiBub2RlIGlzIHRoZSBTb3VyY2U/DQoNCkFuc3dlcjog VGhlIGRyYWZ0IHVzZXMgU291cmNlIGFuZCBUYXJnZXQgaGVyZSBiZWNhdXNlIGl04oCZcyB0YWxr aW5nIGFib3V0IHRoZSBuYW1lcyBvZiB0aGUgZmllbGRzIGluIHRoZSBORCBSZWRpcmVjdCBwYWNr ZXQgd2hlcmUgdGhlIElQdjYgYWRkcmVzcyBvZiB0aGUgcmVsZXZhbnQgaW50ZXJmYWNlIG9uIHRo ZSBjb3JyZXNwb25kaW5nIG5vZGVzIHNob3duIGluIHRoZSBkaWFncmFtLiBUaGUgbm9kZSBsYWJl bGVkIFRhcmdldCBpcyBhIGdhdGV3YXnigJQgd2l0aCBvbmUgaW50ZXJmYWNlIG9uIHRoZSBsaW5r IHdpdGggdGhlIFJvdXRlciAod2hpY2ggc2VuZHMgdGhlIE5EIFJlZGlyZWN0IHRvIFNvdXJjZSBm b3IgVGFyZ2V0KSwgYW5kIGFub3RoZXIgaW50ZXJmYWNlIG9uIHRoZSBsaW5rIHdpdGggdGhlIGhv c3RzIEgxLCBIMiwgSDMsIGV0IGNldGVyYS4gVGhlIGdhdGV3YXkgbmVlZCBub3QgYmUgYSBkeW5h bWljIHJvdXRlciwgaS5lLiBhIGdhdGV3YXkgdGhhdCB1c2VzIGEgcm91dGluZyBwcm90b2NvbCBs aWtlIFJJUCwgT1NQRiwgSVMtSVMgb3IgQmFiZWwuIEl0IGNvdWxkIGJlIGEgc2ltcGxlIGdhdGV3 YXkgdGhhdCBvYnRhaW5zIGl0cyBwcmVmaXggZGVsZWdhdGlvbiBmcm9tIFJvdXRlciB3aXRoIERI Q1B2Ni1QRCwgYW5kIGl04oCZcyBhbiBpbXBvcnRhbnQgcG9pbnQgdGhhdCB0aGUgU291cmNlIHRo YXQgcHJvY2Vzc2VzIFJJTyBlbGVtZW50cyBkb2VzbuKAmXQgaGF2ZSBhbnkgbmVlZCB0byBrbm93 IGhvdyB0aGUgZ2F0ZXdheSBvYnRhaW5lZCB0aGUgcHJlZml4IHRvIHdoaWNoIGl0IGZvcndhcmRz IHBhY2tldHMsIG9yIGhvdyB0aGUgcm91dGluZyBkb21haW4gaXMgY29udHJvbGxlZCBhbmQgbWFu YWdlZC4gSW4gdGhlIHNpbXBsZSBjYXNlLCB0aGUgU291cmNlIG5vZGUgaXMganVzdCBhIGhvc3Qs IGFuZCBpdCBuZWl0aGVyIG5lZWRzIG5vciDigJx3YW50c+KAnSB0byBwYXJ0aWNpcGF0ZSBpbiB0 aGUgZHluYW1pYyByb3V0aW5nIHByb3RvY29sIHVzZWQgYnkgdGhlIFJvdXRlciBhbmQgdGhlIFRh cmdldCBub2Rlcy4NCg0KUXVlc3Rpb246IFdoeSBhcmUgeW91IHVzaW5nIE5TL05BIGZvciB0aGUg UklPIGNvbmZpcm1hdGlvbiBsb2Nrc3RlcD8gV2h5IG5vdCB1c2UgUlMvUkEgaW5zdGVhZD8NCg0K QW5zd2VyOiBJbiBmYWN0LCB0aGUgZHJhZnQgaGFzIGEgd2hvbGUgc2VjdGlvbiBhYm91dCB0aGF0 LCDCpzQuMi42IOKAnFdoeSBOUy9OQT/igJ0gYW5kIHBhcmFwaHJhc2luZyBoZXJlOiBtYWlubHkg YmVjYXVzZSwgdG8gc2VuZCBSQSBtZXNzYWdlcyBlbnRhaWxzIGRlbGF5IGFuZCByYXRlIGxpbWl0 aW5nIHRoYXQgZG8gbm90IGFwcGx5IHdoZW4gc2VuZGluZyBOQSBtZXNzYWdlcy4gQWxzbywgUkEg bWVzc2FnZXMgYXJlIHR5cGljYWxseSBtdWx0aWNhc3QsIHdoaWNoIGlzIGxlc3MgcmVsaWFibGUg b24gbWFueSB3aXJlbGVzcyBsaW5rIHR5cGVzLCBidXQgdGhlc2UgaW50ZXJhY3Rpb25zIGFyZSBi ZXR0ZXIgZG9uZSB3aXRoIHVuaWNhc3QgZnJvbSBUYXJnZXQgZGlyZWN0bHkgdG8gU291cmNlIHdp dGhvdXQgYW55IGRlbGF5cy4gRmluYWxseSwgaWYgc2ltcGxlIFJBIGd1YXJkcyBhcmUgZGVwbG95 ZWQgd2l0aG91dCB3aGl0ZWxpc3RpbmcgYWxsIHRoZSBwb3RlbnRpYWwgdGFyZ2V0cyB0aGF0IG1h eSByZWNlaXZlIERIQ1B2Ni1QRCBkZWxlZ2F0aW9ucywgdGhlbiB0aG9zZSBSQSBtZXNzYWdlcyB3 aWxsIGJlIGZpbHRlcmVkIG91dCBhbmQgdGhlIHN5c3RlbSB3b27igJl0IHdvcmsuIEJldHRlciB0 byB1c2UgTlMvTkEgaW50ZXJjaGFuZ2VzIGhlcmUsIGFuZCBrZWVwIHRoZSBzeXN0ZW0gc2ltcGxl Lg0KDQpRdWVzdGlvbjogT2theSwgdGhpcyBtYWtlcyBhIGxvdCBtb3JlIHNlbnNlIG5vdyB0aGF0 IHlvdeKAmXZlIGV4cGxhaW5lZCB0aGluZ3MgbW9yZSBjbGVhcmx5ISBDYW4geW91IHVwZGF0ZSB0 aGUgZHJhZnQgd2l0aCBhbGwgdGhpcz8NCg0KQW5zd2VyOiBZZXMhIExldOKAmXMgYWRvcHQgdGhl IGRyYWZ0IGFzIGEgd29ya2luZyBncm91cCBpdGVtLCB0aGVuIHdlIGNhbiBkZWJhdGUgdGhlIGJl c3Qgd2F5IHRvIGNsYXJpZnkgdGhlIHRleHQgc28gdGhhdCBpdCBjb252ZXlzIGFsbCB0aGlzIGFz IGNsZWFybHkgYXMgcG9zc2libGUhIENhbiB3ZSBwbGVhc2UgYWRvcHQgdGhlIGRyYWZ0IGFzIGEg d29ya2luZyBncm91cCBpdGVtPyBUaGF0IHdvdWxkIGJlIGV4Y2VsbGVudC4gTGV04oCZcyBkbyB0 aGF0IHJpZ2h0IGF3YXkuDQoNCg0KLS1qYW1lcyB3b29keWF0dCA8amh3QGdvb2dsZS5jb208bWFp bHRvOmpod0Bnb29nbGUuY29tPj4NCg0KDQoNCg== --_000_4a50273fd30849c8836ebc1dda0076d3XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGkgSmFtZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UbyB3aGF0IHlvdSBzYWlkIHZlcnkgd2VsbCBpbiB5b3VyIG1lc3NhZ2UsIEkg d2lsbCBhZGQgdGhhdCB0aGlzIGRyYWZ0IGNvbXBsZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRo ZSBub3Rpb24gb2YgZ2l2aW5nIGEgLzY0IHRvIGVhY2ggaG9zdCBhcyBoYXMgYmVlbiBkaXNjdXNz ZWQgd2lkZWx5IGluIHJlY2VudCBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm1lc3NhZ2VzLiBUaGVy ZSBuZWVkcyB0byBiZSBzb21lIHdheSBmb3IgbmVpZ2hib3JzIHRvIGRpc2NvdmVyIHRoZSAvNjRz IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnBlZXJzIG9uIHRoZSBsaW5rLCBhbmQgc2hpcHBpbmcgdGhl IC82NHMgYXJvdW5kIGluIFJJT3MgaW4gSVB2NiBORCBtZXNzYWdlcyBpczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JTUhPIHRoZSByaWdodCB3YXkgdG8gZ28gd2hlbiBydW5uaW5nIGEgZHluYW1pYyByb3V0 aW5nIHByb3RvY29sIGlzIGltcHJhY3RpY2FsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+QXMgdG8gdXNlIGNhc2VzLCBjb25zaWRlciBhIGxhcmdlIExBTiB3aXRo IGxvdHMgb2YgaG9zdHMgdGhhdCBoYXZlIHJlY2VpdmVkIC82NHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkEgc3BlY2lmaWMgZXhhbXBsZSB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgdGhlIElFVEYgY29uZmVy ZW5jZSBTU0lEcy4gU28sIEkgYWdyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhdCB3ZSBzaG91bGQg YnJpbmcgdGhpcyBpbiBhcyBhIHdnIGRvY3VtZW50IHNvIHdlIGNhbiBhZGRyZXNzIHRoZXNlIHVz ZSBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5qYW1lcyB3b29keWF0dDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdWx5IDE4LCAyMDE3IDI6MTIgUE08YnI+DQo8Yj5Ubzo8L2I+IDZNQU4gV29ya2luZyBH cm91cCAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW4gY29uc2lk ZXJhdGlvbiBvZiBJLUQudGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgNk1BTiw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBleGhhdXN0ZWQgb3VyIGF2 YWlsYWJsZSB0aW1lIGRpc2N1c3NpbmcgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10ZW1wbGluLTZtYW4tcmlvLXJlZGlyZWN0Ij5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdDwvYT4mZ3Q7IGluIHRo ZSBzZXNzaW9uIHllc3RlcmRheSwgYW5kIHNpbmNlIHRoaXMgZHJhZnQgc2VlbXMgdG8gYm90aA0K IEZyZWQgYW5kIG1lIHRvIGJlIHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLCBJ4oCZ ZCBsaWtlIHRvIHByb21wdCBmdXJ0aGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgdG93YXJkIHRo YXQgZW5kLiBTb21lIHBhcnRpY2lwYW50cyB3b3VsZCBsaWtlIGZ1cnRoZXIgY2xhcmlmaWNhdGlv bnMgYWJvdXQgdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhlIHRlY2huaWNhbCBjaG9pY2VzIHdlIG1h ZGUgaW4gdGhpcyBkcmFmdCwgYW5kIEkgaG9wZSB3ZQ0KIGNhbiBkbyB0aGF0IGhlcmUgb24gdGhl IGxpc3QuIEnigJltIGdvaW5nIHRvIHVzZSBhIFEmYW1wO0EgZm9ybWF0IHRvIHByZXNlbnQgdmFy aW91cyBwYXJhcGhyYXNlZCB2ZXJzaW9ucyBvZiB0aGUgcXVlc3Rpb25zIHdl4oCZdmUgbm90ZWQg aW4gdGFsa2luZyB3aXRob3V0IG90aGVyIHBhcnRpY2lwYW50cywgYW5kIHRyeSB0byBwcm92aWRl IG1vcmUgc2F0aXNmeWluZyBhbnN3ZXJzIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1ZXN0aW9uOiBXaGF0IGlzIHRoaXMgZHJhZnQg KnJlYWxseSogYWJvdXQ/IEnigJltIGp1c3QgYWxsIGNvbmZ1c2VkIGFib3V0IGl0cyBiYXNpYyBw cm9ibGVtIHN0YXRlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5zd2VyOiBNb3N0IHBvcHVsYXIgaG9zdCBJUHY2IGltcGxlbWVudGF0 aW9ucywgZS5nLiBMaW51eCwgRGFyd2luLCBXaW5kb3dzLCBldCBjZXRlcmEsIGhhdmUgaG9zdCBy b3V0ZSB0YWJsZXMgY2FwYWJsZSBvZiByZXByZXNlbnRpbmcgcm91dGVzIG1vcmUgc3BlY2lmaWMg dGhhbiBhIHNpbXBsZSBkZWZhdWx0IHJvdXRlLCBidXQgUkZDIDQxOTEgaGFzbuKAmXQgYmVlbiB3 aWRlbHkgYWRvcHRlZCBpbiBkZWZhdWx0DQogY29uZmlndXJhdGlvbnPigJQgc28sIHRoZSAmcXVv dDtUeXBlIEPigJ0gaG9zdHMgaXQgZGVmaW5lcywgd2hpY2ggcHJvY2VzcyBSSU8gb3B0aW9ucyBp biBSQSBtZXNzYWdlcywgYXJlIG5vdCBjb21tb25seSBkZXBsb3llZCBpbiBnZW5lcmFsIHB1cnBv c2UgaG9zdHMuIEkgbWVhbiwgeWVzLCB5b3UgY2FuIHR1cm4gaXQgb24gd2l0aCBhIHN5c2N0bCB2 YXJpYWJsZSBvciBzb21lIHN1Y2ggYWR2YW5jZWQgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIsIGJ1 dCBvdXQgb2YNCiB0aGUgYm94PyBObywgaXTigJlzIG5vdCBlbmFibGVkLiBUaGlzIGRyYWZ0IGlz ICpyZWFsbHkqIGFsbCBhYm91dCByZXZpc2luZyBSRkMgNDE5MeKAlCBpbiBhIGNvbXBsZXRlbHkg YmFja3dhcmQgY29tcGF0aWJsZSB3YXnigJQgdG8gbWFrZSBhdXRvbWF0aWNhbGx5IGFuZCBkeW5h bWljYWxseSB1cGRhdGluZyBob3N0IHJvdXRlIHRhYmxlcyB3aXRoIGluZm9ybWF0aW9uIGZyb20g dGhlIG5ldHdvcmsgbW9yZSBhcHByb3ByaWF0ZSBmb3Igd2lkZXNwcmVhZCBkZXBsb3ltZW50DQog aW4gZ2VuZXJhbCBwdXJwb3NlIGhvc3RzLiBJbiBvdGhlciB3b3Jkcywgd2UgaG9wZSBMaW51eCwg RnJlZUJTRCwgV2luZG93cyBhbmQgdGhlIGxpa2Ugd2lsbCBhZG9wdCB0aGlzLCBhbmQgdHVybiBp dCBvbiBieSBkZWZhdWx0IG91dCBvZiB0aGUgYm94LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVzdGlvbjogU28gd2h5IGlzbuKAmXQgUkZD IDQxOTEgZ29vZCBlbm91Z2ggYXMgaXQgaXM/IFdoeSBkbyB3ZSBuZWVkIHRvIHJldmlzZSBpdD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5z d2VyOiBPbmUgcmVhc29uIGhvc3QgaW1wbGVtZW50YXRpb25zIGFyZSBub3QgVHlwZSBDIGluIGRl ZmF1bHQgY29uZmlndXJhdGlvbnMgaXMgdGhlIGNvbmNlcm4gYWJvdXQg4oCccm9ndWUgYWR2ZXJ0 aXNlcnPigJ0gcG9pc29uaW5nIGhvc3Qgcm91dGUgdGFibGVzIHRoZW4gdXNpbmcgdGhhdCBhcyBh IHBsYXRmb3JtIHRvIG1vdW50IGF0dGFja3Mgb24gdGhlIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBp biB2YXJpb3VzDQoga2luZHMgb2YgY3J5cHRvZ3JhcGhpYyBwcm90b2NvbHMuIFRoZSBwZXJjZXB0 aW9uIChhcmd1YWJseSBhIG1pc3BlcmNlcHRpb24sIGJ1dCBsZXTigJlzIGxlYXZlIHRoYXQgYXNp ZGUpIGlzIHRoYXQgaXTigJlzIG5vdCBhbHdheXMgc2FmZSBpbiBnZW5lcmFsIHB1cnBvc2UgaG9z dHMgdG8gcHJvY2VzcyBSSU8gb3B0aW9ucyBpbiBSQSBtZXNzYWdlcy4gT3VyIGRyYWZ0IGludHJv ZHVjZXMgbmV3IGZlYXR1cmVzIHRvIHRoZSBleGlzdGluZyBwcm90b2NvbA0KIHRvIG5hcnJvdyB0 aGUgYXR0YWNrIHN1cmZhY2Ugb24gaG9zdHMgdGhhdCBwcm9jZXNzIFJJTyBvcHRpb25zIHNvIHRo YXQgc2ltcGxlIFJBIGd1YXJkcyBjYW4gYmUgZGVwbG95ZWQgb24gbGlua3MgdG8gYmxvY2sgcm9n dWUgYWR2ZXJ0aXNlcnMgYW5kIGhvc3RzIHdpbGwgc3RpbGwgb3B0aW1pemUgdHJhbnNtaXNzaW9u IGZvciBzZW5kaW5nIHRvIHRoZSBiZXN0IHJvdXRlciBmb3Igc3BlY2lmaWMgZGVzdGluYXRpb25z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5R dWVzdGlvbjogV2h5IGV2ZW4gZG8gdGhpcyB3aXRoIElDTVB2NiBuZWlnaGJvciBkaXNjb3Zlcnkg YXQgYWxsPyBDb3VsZG7igJl0IHlvdSBqdXN0IHByb3Zpc2lvbiBob3N0IHJvdXRlIHRhYmxlcyB3 aXRoIHN0YXRlZnVsIERIQ1B2NiBvcHRpb25zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnN3ZXI6IFRoYXTigJlzIGFuICpleGNlbGxlbnQq IHF1ZXN0aW9uLCBiZWNhdXNlIGl0IGlsbHVzdHJhdGVzIHRoZSBzaXR1YXRpb24gdmVyeSB3ZWxs ISBUaGUgc2ltcGxlIGFuc3dlciBpcyDigJxmb3IgYWxsIHRoZSBzYW1lIHJlYXNvbnMgd2UgZG9u 4oCZdCBjb25maWd1cmUgaG9zdHMgd2l0aCBEZWZhdWx0IFJvdXRlciBhZGRyZXNzZXMgdXNpbmcg REhDUHY2LOKAnSB3aGlsZSB0aGUgY29tcGxldGUgYW5zd2VyIGlzIHRoYXQNCiBob3N0IHJvdXRp bmcgdGFibGVzIG9mdGVuIG5lZWQgdG8gYmUgZHluYW1pY2FsbHkgdXBkYXRlZCBpbiByZXNwb25z ZSB0byBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgZXZlbnRzLCBhbmQgdGhhdCB3b3VsZCBtZWFu IGEgdGlnaHQgY291cGxpbmcgYmV0d2VlbiB0aGUgREhDUHY2IHNlcnZlciBhbmQgdGhlIGR5bmFt aWMgcm91dGluZyBwcm90b2NvbCBhZ2VudCBzbyB0aGF0IERIQ1B2NiBSZWNvbmZpZ3VyZSBtZXNz YWdlcyBjYW4gYmUgc2VudCB0bw0KIHByb21wdCBob3N0cyB0byBtYWtlIEluZm9ybWF0aW9uLXJl cXVlc3QgbWVzc2FnZXMgZm9yIHJvdXRlIHRhYmxlIHVwZGF0ZXMgaW4gYSB0aW1lbHkgbWFubmVy LiBBbmQgdGhlcmUgaXMgdGhlIHdob2xlIGZhdGUtc2hhcmluZyB0aGluZy4gUGx1cywgYSBjb3Vw bGUgb3RoZXIgcG9pbnRzOiBhKSB0aGUgSUNNUHY2IG5laWdoYm9yIGFuZCByb3V0ZXIgZGlzY292 ZXJ5IHByb3RvY29scyBhcmUgdGhlIG5hdHVyYWwgcGxhY2UgaW4gdGhlIElQdjYgYXJjaGl0ZWN0 dXJlDQogZm9yIGRvaW5nIHRoaXMgc3R1ZmY7IGFuZCBiKSBpdCBoYXMgc29tZSBhdHRyYWN0aXZl IHF1YWxpdGllcyBpbiB0eXBpY2FsIGhvc3QgaW1wbGVtZW50YXRpb25zLCB3aGljaCBoYW5kbGUg SUNNUHY2IGVudGlyZWx5IGluc2lkZSB0aGUga2VybmVsLCB3aGVyZWFzIERIQ1B2NiBhbmQgdmFy aW91cyBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSB1c3VhbGx5IGltcGxlbWVudGVkIGFz IGRhZW1vbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlF1ZXN0aW9uOiBJbiB0aGUgZHJhZnQsIEZpZ3VyZSAxOiAmcXVvdDtDbGFzc2ljYWwg UmVkaXJlY3Rpb24gU2NlbmFyaW/igJ0gaXMgY29uZnVzaW5nLiBJcyB0aGUgVGFyZ2V0IGEgcm91 dGVyIHRvbz8gV2hhdCBraW5kIG9mIG5vZGUgaXMgdGhlIFNvdXJjZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5zd2VyOiBUaGUgZHJhZnQg dXNlcyBTb3VyY2UgYW5kIFRhcmdldCBoZXJlIGJlY2F1c2UgaXTigJlzIHRhbGtpbmcgYWJvdXQg dGhlIG5hbWVzIG9mIHRoZSBmaWVsZHMgaW4gdGhlIE5EIFJlZGlyZWN0IHBhY2tldCB3aGVyZSB0 aGUgSVB2NiBhZGRyZXNzIG9mIHRoZSByZWxldmFudCBpbnRlcmZhY2Ugb24gdGhlIGNvcnJlc3Bv bmRpbmcgbm9kZXMgc2hvd24gaW4gdGhlIGRpYWdyYW0uIFRoZSBub2RlIGxhYmVsZWQNCiBUYXJn ZXQgaXMgYSBnYXRld2F54oCUIHdpdGggb25lIGludGVyZmFjZSBvbiB0aGUgbGluayB3aXRoIHRo ZSBSb3V0ZXIgKHdoaWNoIHNlbmRzIHRoZSBORCBSZWRpcmVjdCB0byBTb3VyY2UgZm9yIFRhcmdl dCksIGFuZCBhbm90aGVyIGludGVyZmFjZSBvbiB0aGUgbGluayB3aXRoIHRoZSBob3N0cyBIMSwg SDIsIEgzLCBldCBjZXRlcmEuIFRoZSBnYXRld2F5IG5lZWQgbm90IGJlIGEgZHluYW1pYyByb3V0 ZXIsIGkuZS4gYSBnYXRld2F5IHRoYXQgdXNlcw0KIGEgcm91dGluZyBwcm90b2NvbCBsaWtlIFJJ UCwgT1NQRiwgSVMtSVMgb3IgQmFiZWwuIEl0IGNvdWxkIGJlIGEgc2ltcGxlIGdhdGV3YXkgdGhh dCBvYnRhaW5zIGl0cyBwcmVmaXggZGVsZWdhdGlvbiBmcm9tIFJvdXRlciB3aXRoIERIQ1B2Ni1Q RCwgYW5kIGl04oCZcyBhbiBpbXBvcnRhbnQgcG9pbnQgdGhhdCB0aGUgU291cmNlIHRoYXQgcHJv Y2Vzc2VzIFJJTyBlbGVtZW50cyBkb2VzbuKAmXQgaGF2ZSBhbnkgbmVlZCB0byBrbm93IGhvdyB0 aGUgZ2F0ZXdheQ0KIG9idGFpbmVkIHRoZSBwcmVmaXggdG8gd2hpY2ggaXQgZm9yd2FyZHMgcGFj a2V0cywgb3IgaG93IHRoZSByb3V0aW5nIGRvbWFpbiBpcyBjb250cm9sbGVkIGFuZCBtYW5hZ2Vk LiBJbiB0aGUgc2ltcGxlIGNhc2UsIHRoZSBTb3VyY2Ugbm9kZSBpcyBqdXN0IGEgaG9zdCwgYW5k IGl0IG5laXRoZXIgbmVlZHMgbm9yIOKAnHdhbnRz4oCdIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBk eW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgdXNlZCBieSB0aGUgUm91dGVyIGFuZA0KIHRoZSBUYXJn ZXQgbm9kZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlF1ZXN0aW9uOiBXaHkgYXJlIHlvdSB1c2luZyBOUy9OQSBmb3IgdGhlIFJJTyBjb25m aXJtYXRpb24gbG9ja3N0ZXA/IFdoeSBub3QgdXNlIFJTL1JBIGluc3RlYWQ/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuc3dlcjogSW4gZmFj dCwgdGhlIGRyYWZ0IGhhcyBhIHdob2xlIHNlY3Rpb24gYWJvdXQgdGhhdCwgwqc0LjIuNiDigJxX aHkgTlMvTkE/4oCdIGFuZCBwYXJhcGhyYXNpbmcgaGVyZTogbWFpbmx5IGJlY2F1c2UsIHRvIHNl bmQgUkEgbWVzc2FnZXMgZW50YWlscyBkZWxheSBhbmQgcmF0ZSBsaW1pdGluZyB0aGF0IGRvIG5v dCBhcHBseSB3aGVuIHNlbmRpbmcgTkEgbWVzc2FnZXMuIEFsc28sIFJBIG1lc3NhZ2VzIGFyZQ0K IHR5cGljYWxseSBtdWx0aWNhc3QsIHdoaWNoIGlzIGxlc3MgcmVsaWFibGUgb24gbWFueSB3aXJl bGVzcyBsaW5rIHR5cGVzLCBidXQgdGhlc2UgaW50ZXJhY3Rpb25zIGFyZSBiZXR0ZXIgZG9uZSB3 aXRoIHVuaWNhc3QgZnJvbSBUYXJnZXQgZGlyZWN0bHkgdG8gU291cmNlIHdpdGhvdXQgYW55IGRl bGF5cy4gRmluYWxseSwgaWYgc2ltcGxlIFJBIGd1YXJkcyBhcmUgZGVwbG95ZWQgd2l0aG91dCB3 aGl0ZWxpc3RpbmcgYWxsIHRoZSBwb3RlbnRpYWwNCiB0YXJnZXRzIHRoYXQgbWF5IHJlY2VpdmUg REhDUHY2LVBEIGRlbGVnYXRpb25zLCB0aGVuIHRob3NlIFJBIG1lc3NhZ2VzIHdpbGwgYmUgZmls dGVyZWQgb3V0IGFuZCB0aGUgc3lzdGVtIHdvbuKAmXQgd29yay4gQmV0dGVyIHRvIHVzZSBOUy9O QSBpbnRlcmNoYW5nZXMgaGVyZSwgYW5kIGtlZXAgdGhlIHN5c3RlbSBzaW1wbGUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1ZXN0aW9uOiBP a2F5LCB0aGlzIG1ha2VzIGEgbG90IG1vcmUgc2Vuc2Ugbm93IHRoYXQgeW914oCZdmUgZXhwbGFp bmVkIHRoaW5ncyBtb3JlIGNsZWFybHkhIENhbiB5b3UgdXBkYXRlIHRoZSBkcmFmdCB3aXRoIGFs bCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbnN3ZXI6IFllcyEgTGV04oCZcyBhZG9wdCB0aGUgZHJhZnQgYXMgYSB3b3JraW5nIGdy b3VwIGl0ZW0sIHRoZW4gd2UgY2FuIGRlYmF0ZSB0aGUgYmVzdCB3YXkgdG8gY2xhcmlmeSB0aGUg dGV4dCBzbyB0aGF0IGl0IGNvbnZleXMgYWxsIHRoaXMgYXMgY2xlYXJseSBhcyBwb3NzaWJsZSEg Q2FuIHdlIHBsZWFzZSBhZG9wdCB0aGUgZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0/IFRo YXQgd291bGQgYmUgZXhjZWxsZW50Lg0KIExldOKAmXMgZG8gdGhhdCByaWdodCBhd2F5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS1qYW1lcyB3b29keWF0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpod0Bnb29nbGUu Y29tIj5qaHdAZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4a50273fd30849c8836ebc1dda0076d3XCH150608nwnosboeingcom_-- From nobody Wed Jul 19 01:55:30 2017 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 2D232131C35 for ; Wed, 19 Jul 2017 01:55: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, RP_MATCHES_RCVD=-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 ML59-tmXfI_z for ; Wed, 19 Jul 2017 01:55:27 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF94131C3C for ; Wed, 19 Jul 2017 01:55:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id BC6001BC37 for ; Wed, 19 Jul 2017 08:55:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: rationale for the default of DupAddrDetectTransmits From: Simon Hobson In-Reply-To: Date: Wed, 19 Jul 2017 09:55:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 08:55:29 -0000 Mark Smith wrote: > In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on > a link before IPv4 DAD (and DHCPv4) became available. I'd much rather > reliable DAD and failure of DAD to be considered fatal. Yes, address duplicates are "interesting" aren't they - especially if = it's the default router address :-( At the risk of opening another tin or worms, shouldn't DAD be an ongoing = process ? Ie, rather than a simple "fire off a packet, if you get = nothing back then use the address", it should do that initially, but = keep looking out for evidence that the address is in use and discontinue = use if it detects a conflict ? Introduces another means of DoS - but I think if any node is in a = position to trigger such an ongoing DAD collision event, then it's = already in a position to cause problems (such as by firing off = unsolicited ND packets ?) From nobody Wed Jul 19 02:04:35 2017 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 ACDB3131C49 for ; Wed, 19 Jul 2017 02:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FVQ7XshiZnpG for ; Wed, 19 Jul 2017 02:04:20 -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 C714C131C3C for ; Wed, 19 Jul 2017 02:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4678; q=dns/txt; s=iport; t=1500455059; x=1501664659; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XIo7yRh4lHKmbtR/Yvga1clHREp76bELZ3Nd8onC84M=; b=hKOl8lAMq7QvnRiYImSdkgyisBPVNTOjNwMVIRsMMGl9j+zJlx76EBqx qf/P8nfGvAgjVs1c6acs0otAUaZEg8KEUTjT2AxWJ37mbJe9cWgCowahQ f+tUL7oAtYuQIQdzLrvUkNSRsLOlKxiAsMSLXPernuZisMXh4shSFLW7E A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AAA+IG9Z/5tdJa1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRSOC5oOiCo5IIRTghEhAQqFGwKDWj8YAQIBAQEBAQEBayiFGQI?= =?us-ascii?q?BAwEBbAsQAgEIBAoxByEGCxQRAgQOBYlLTAMVELEOhzQNg0YBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYIydoNNggyCeYJXhVaCMQWJXZUhOwKPJ4Rwki+MDIlPAR8?= =?us-ascii?q?4gQp1FUkSAYcDdohTAQEB?= X-IronPort-AV: E=Sophos;i="5.40,380,1496102400"; d="scan'208,217";a="457858257" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 09:04:03 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6J943Sl017759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Jul 2017 09:04:03 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 04:04:03 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 04:04:03 -0500 From: "Rajiv Asati (rajiva)" To: Simon Hobson CC: 6man WG Subject: Re: rationale for the default of DupAddrDetectTransmits Thread-Topic: rationale for the default of DupAddrDetectTransmits Thread-Index: AQHTAGzN3f/Qr4/JqEmv/RDqL8w/LaJa2xXz Date: Wed, 19 Jul 2017 09:04:03 +0000 Message-ID: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> , <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> In-Reply-To: <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> 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_BD3125B5BCFE4EC3991DBE5966AF6546ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:04:22 -0000 --_000_BD3125B5BCFE4EC3991DBE5966AF6546ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable should do that initially, but keep looking out for evidence that the addres= s is in use and discontinue use if it detects a conflict ? Nope. :) if every node performs the check and uses the assumed address only= if check passed, then no conflict afterwards. Cheers, Rajiv On Jul 19, 2017, at 10:55 AM, Simon Hobson > wrote: Mark Smith > wrote: In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on a link before IPv4 DAD (and DHCPv4) became available. I'd much rather reliable DAD and failure of DAD to be considered fatal. Yes, address duplicates are "interesting" aren't they - especially if it's = the default router address :-( At the risk of opening another tin or worms, shouldn't DAD be an ongoing pr= ocess ? Ie, rather than a simple "fire off a packet, if you get nothing bac= k then use the address", it should do that initially, but keep looking out = for evidence that the address is in use and discontinue use if it detects a= conflict ? Introduces another means of DoS - but I think if any node is in a position = to trigger such an ongoing DAD collision event, then it's already in a posi= tion to cause problems (such as by firing off unsolicited ND packets ?) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BD3125B5BCFE4EC3991DBE5966AF6546ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

should do that initially, but keep looking= out for evidence that the address is in use and discontinue use if it dete= cts a conflict ?

Nope. :) if every node performs the check and uses the assumed address only= if check passed, then no conflict afterwards. 

Cheers,
Rajiv  

On Jul 19, 2017, at 10:55 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:

Mark Smith <markzzz= smith@gmail.com> wrote:

In the distant past, I've troubleshooted 5 = duplicate IPv4 addresses on
a link before IPv4 DAD (and DHCPv4) became = available. I'd much rather
reliable DAD and failure of DAD to be consi= dered fatal.

Yes, address duplicates are "interesting" aren't they - esp= ecially if it's the default router address :-(

At the risk of opening another tin or worms, shouldn't DAD be an ongo= ing process ? Ie, rather than a simple "fire off a packet, if you get = nothing back then use the address", it should do that initially, but k= eep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Introduces another means of DoS - but I think if any node is in a pos= ition to trigger such an ongoing DAD collision event, then it's already in = a position to cause problems (such as by firing off unsolicited ND packets = ?)

--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
--_000_BD3125B5BCFE4EC3991DBE5966AF6546ciscocom_-- From nobody Wed Jul 19 02:18:55 2017 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 8C389131C4C for ; Wed, 19 Jul 2017 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 NFxwLbjp-pyG for ; Wed, 19 Jul 2017 02:18:51 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125B9131A85 for ; Wed, 19 Jul 2017 02:18:51 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id r125so7152534vkf.1 for ; Wed, 19 Jul 2017 02:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WcglfqT12JdauabuGdC5tkhjaunsNXJXqe38Uwgmp1M=; b=MYe4uFbGe+KjnTH6cHC8kNE/eWU5uVrG4vqceFx3U8iMv5yJwiLgrNVJ/SZGXyl1xT CGK7JbZn6zH3LxA0M2EcYwNrVCxEhVlEbsLsm4IkYGfUytCMumlJ+VeM8gt3J0Dzt1j3 jX4k10BkGRQC5inm9BseKEvFN5+JUkgx3MgIw5wuTEi0Rs7qpAMl/iZawd0OjZzrTT1u bYrDZ6PamN+lDc5x3g9NvlVcuIIKkvMd1rh1wHe01JCvLaZp8boj9Lph2crzRJyacZYE jxllyV1Ibjx8rgbRo4w8JIzfqfXINbo903ssgSL5247gSp2adroc/eaCDcE9VK/j3spc cNGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WcglfqT12JdauabuGdC5tkhjaunsNXJXqe38Uwgmp1M=; b=HNHPwlUusMvzyN2jsml6rOaYF0X2n3Dw8RT3dm0n22Jx0/467CmuC3e+hrZcHc+JBN OJ1KaWKYSpH33nTNfu60DpCDw+XLilqeEYlRIbItA5t4bbLPBHf2C+l/RKy666adPo42 2IVchiIQB8NgIeyHGbAbLzEWtLYGAYRcA5m035Qnpv6KzWEkKjAqjxrifT47oPOjxEsG ymJl1KPKzSlL5hFvQPZ9nl/1IC/CkdgtFX02IX9sEySCr5pCYDkT2ZnkY5dpDDtknipM KD5Qzg8bUVIQHStFfDbYWwXka68HdCO7dujuXg/NssuTtJb22Yn2MHDbIJZpxelFX5Bp cnug== X-Gm-Message-State: AIVw112P6Sptq81ODH1rL/Ikc+i1Pl79GpOtvWRxJxf6F+uYzcRyRA9f 8/g7CrGKMIM3P60xmaOTmGdmDH27Uw== X-Received: by 10.31.238.196 with SMTP id m187mr1041379vkh.96.1500455930148; Wed, 19 Jul 2017 02:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Wed, 19 Jul 2017 02:18:19 -0700 (PDT) In-Reply-To: <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> From: Mark Smith Date: Wed, 19 Jul 2017 19:18:19 +1000 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Simon Hobson Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:18:53 -0000 On 19 July 2017 at 18:55, Simon Hobson wrote: > Mark Smith wrote: > >> In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on >> a link before IPv4 DAD (and DHCPv4) became available. I'd much rather >> reliable DAD and failure of DAD to be considered fatal. > > Yes, address duplicates are "interesting" aren't they - especially if it's the default router address :-( > > At the risk of opening another tin or worms, shouldn't DAD be an ongoing process ? > Ie, rather than a simple "fire off a packet, if you get nothing back then use the address", it should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ? > It shouldn't be necessary. The normal state is no duplicates, so why have all devices that have known unique addresses continually check to see if duplicates have occurred? A duplicate can only occur when a node tries to bring up a new address on the link, and that is the time for that node to check to see if the new address is a duplicate. If the new address is a duplicate of an existing address, the existing address user gets to keep using it, and the new node has to pick another address. Ongoing DAD by existing nodes could overcome the reliability issues being discussed, however it is really better to have the new entrant try harder. It's a once off period of checking to ensure and get the set of addresses to being unique verses an ongoing period of checking that has no value once the set of addresses are unique. > Introduces another means of DoS - but I think if any node is in a position to trigger such an ongoing DAD collision event, then it's already in a position to cause problems (such as by firing off unsolicited ND packets ?) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 19 02:24:45 2017 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 3460B131C50 for ; Wed, 19 Jul 2017 02:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 LFTGuaVIGZpi for ; Wed, 19 Jul 2017 02:24:43 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 BBF20131A7A for ; Wed, 19 Jul 2017 02:24:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6J9OeKP032302 for ; Wed, 19 Jul 2017 11:24:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 995302066CE for ; Wed, 19 Jul 2017 11:24: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 8489D205AFF for ; Wed, 19 Jul 2017 11:24:40 +0200 (CEST) Received: from [132.166.84.51] ([132.166.84.51]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6J9OdOw008401 for ; Wed, 19 Jul 2017 11:24:40 +0200 Subject: Re: In consideration of I-D.templin-6man-rio-redirect To: ipv6@ietf.org References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> From: Alexandre Petrescu Message-ID: <16b18ff0-b94d-549b-41c0-816a31c61380@gmail.com> Date: Wed, 19 Jul 2017 11:24:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:24:44 -0000 [...] > Question: Why are you using NS/NA for the RIO confirmation lockstep? > Why not use RS/RA instead? I subscribe to this question. Especially if the 'Target' in the figure is a Router, and especially if we talk about Target-to-Target communication. In IPWAVE WG we develop a problem statement about this, for vehicle to vehicle communications. There are also some I-Ds with solutions doing this with RA extensions. Alex From nobody Wed Jul 19 02:36:57 2017 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 EA0A3131C62 for ; Wed, 19 Jul 2017 02:36:55 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ns6Lk1OXJowY for ; Wed, 19 Jul 2017 02:36:54 -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 5BF3E131C45 for ; Wed, 19 Jul 2017 02:36:54 -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 v6J9arR6045889; Wed, 19 Jul 2017 02:36:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6J9arSf045885 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 02:36:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 02:36:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 02:36:52 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: In consideration of I-D.templin-6man-rio-redirect Thread-Topic: In consideration of I-D.templin-6man-rio-redirect Thread-Index: AQHTAHDYiPckzv4gME6Aj7m1B2sutqJa4Zmg Date: Wed, 19 Jul 2017 09:36:52 +0000 Message-ID: References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> <16b18ff0-b94d-549b-41c0-816a31c61380@gmail.com> In-Reply-To: <16b18ff0-b94d-549b-41c0-816a31c61380@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:36:56 -0000 Hi Alex, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Wednesday, July 19, 2017 2:25 AM > To: ipv6@ietf.org > Subject: Re: In consideration of I-D.templin-6man-rio-redirect >=20 >=20 > [...] > > Question: Why are you using NS/NA for the RIO confirmation lockstep? > > Why not use RS/RA instead? >=20 > I subscribe to this question. Especially if the 'Target' in the figure > is a Router, and especially if we talk about Target-to-Target communicati= on. Target is a node that receives a Prefix Delegation. The node can then act as either a host that uses the prefix for its own multi-addressing purposes or as a router that forwards packets on behalf of nodes on its downstream attached networks. Our draft refers to these nodes as "Type D" hosts. > In IPWAVE WG we develop a problem statement about this, for vehicle to > vehicle communications. This is for peer-to-peer communications so that two peer nodes on the link can communicate directly without having to go through a default router. The peer-to-peer communications are established through an NS/NA exchange which may be initially triggered by a Redirect.=20 > There are also some I-Ds with solutions doing this with RA extensions. Our concept follows directly from RFC6706. But, we recognize the need for involving RIOs in other IPv6 ND messages than just Redirects. We do not see a need for any RA extensions. Thanks - Fred > Alex >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 19 02:38:15 2017 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 61B8B131C5E for ; Wed, 19 Jul 2017 02:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RZgx6n62QUMS for ; Wed, 19 Jul 2017 02:38:11 -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 83D0A131C70 for ; Wed, 19 Jul 2017 02:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6239; q=dns/txt; s=iport; t=1500457090; x=1501666690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JLBfaPbCZGkP8zYMc/lmS285jwatDQ2BNwLzjNvUNG4=; b=CRyh5fBtb7D5MPdOQOF3Tbh5MAGdR8FqMVr/PtIgK13/EoscynOvbDdH jfW2rLFy7jiC5Gfq4gNfmDzhAwKCaZ4YfS7IJfIu4vA8VjT62geo8aafn rrwibBdVWQ1WvLApRmXhq0/9xTXGellDE/a9xlroC0amWTFcieg39AkDM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAQATJ29Z/5xdJa1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgQETjguRPohQiCo5IIRTghEhAQqFGwKDWj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQIBAwEBbAsQAgEIPwchBgsUEQIEDgWJS0wDFRCwe4c0DYNGAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWCMnaFWQuCboJXhVaCMQWJXZUhOwKPJ4Rwki+MDIlPAR8?= =?us-ascii?q?4gQp1FUkSAYcDdohTAQEB?= X-IronPort-AV: E=Sophos;i="5.40,380,1496102400"; d="scan'208,217";a="269956581" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 09:38:09 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6J9c9vI030549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Jul 2017 09:38:09 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 04:38:08 -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; Wed, 19 Jul 2017 04:38:08 -0500 From: "Bernie Volz (volz)" To: "Rajiv Asati (rajiva)" CC: Simon Hobson , 6man WG Subject: Re: rationale for the default of DupAddrDetectTransmits Thread-Topic: rationale for the default of DupAddrDetectTransmits Thread-Index: AQHS/ywxwHOXgs6fj0Cp7xekQwnE8aJa20MJgABWJYD//7W15Q== Date: Wed, 19 Jul 2017 09:38:08 +0000 Message-ID: <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> , <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk>, 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: multipart/alternative; boundary="_000_5A88D5B305054DA8AC898668EEE7665Eciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:38:13 -0000 --_000_5A88D5B305054DA8AC898668EEE7665Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Packets get dropped or a node maybe "sleeping". There are ongoing checks based on normal ND traffic though so no explicit D= AD needed. - Bernie (from iPhone) On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) > wrote: should do that initially, but keep looking out for evidence that the addres= s is in use and discontinue use if it detects a conflict ? Nope. :) if every node performs the check and uses the assumed address only= if check passed, then no conflict afterwards. Cheers, Rajiv On Jul 19, 2017, at 10:55 AM, Simon Hobson > wrote: Mark Smith > wrote: In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on a link before IPv4 DAD (and DHCPv4) became available. I'd much rather reliable DAD and failure of DAD to be considered fatal. Yes, address duplicates are "interesting" aren't they - especially if it's = the default router address :-( At the risk of opening another tin or worms, shouldn't DAD be an ongoing pr= ocess ? Ie, rather than a simple "fire off a packet, if you get nothing bac= k then use the address", it should do that initially, but keep looking out = for evidence that the address is in use and discontinue use if it detects a= conflict ? Introduces another means of DoS - but I think if any node is in a position = to trigger such an ongoing DAD collision event, then it's already in a posi= tion to cause problems (such as by firing off unsolicited ND packets ?) -------------------------------------------------------------------- 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 -------------------------------------------------------------------- --_000_5A88D5B305054DA8AC898668EEE7665Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Packets get dropped or a node maybe "sleeping".

There are ongoing checks based on normal ND = traffic though so no explicit DAD needed.

- Bernie (from iPhone)

On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:


should do that initially, but keep looking= out for evidence that the address is in use and discontinue use if it dete= cts a conflict ?

Nope. :) if every node performs the check and uses the assumed address only= if check passed, then no conflict afterwards. 

Cheers,
Rajiv  

On Jul 19, 2017, at 10:55 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:

Mark Smith <markzzz= smith@gmail.com> wrote:

In the distant past, I've troubleshooted 5 = duplicate IPv4 addresses on
a link before IPv4 DAD (and DHCPv4) became = available. I'd much rather
reliable DAD and failure of DAD to be consi= dered fatal.

Yes, address duplicates are "interesting" aren't they - esp= ecially if it's the default router address :-(

At the risk of opening another tin or worms, shouldn't DAD be an ongo= ing process ? Ie, rather than a simple "fire off a packet, if you get = nothing back then use the address", it should do that initially, but k= eep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Introduces another means of DoS - but I think if any node is in a pos= ition to trigger such an ongoing DAD collision event, then it's already in = a position to cause problems (such as by firing off unsolicited ND packets = ?)

--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
----------------------------------------------------------------= ----
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
--_000_5A88D5B305054DA8AC898668EEE7665Eciscocom_-- From nobody Wed Jul 19 02:50:09 2017 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 6FDD2131C74 for ; Wed, 19 Jul 2017 02:50:08 -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, RP_MATCHES_RCVD=-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 FxVL5pBh8I6h for ; Wed, 19 Jul 2017 02:50:07 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12640126C0F for ; Wed, 19 Jul 2017 02:50:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 311281BC37 for ; Wed, 19 Jul 2017 09:49:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: rationale for the default of DupAddrDetectTransmits From: Simon Hobson In-Reply-To: Date: Wed, 19 Jul 2017 10:49:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1011CC-6068-4330-8533-B67AF59C6331@thehobsons.co.uk> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:50:08 -0000 Mark Smith wrote: >> At the risk of opening another tin or worms, shouldn't DAD be an = ongoing process ? >> Ie, rather than a simple "fire off a packet, if you get nothing back = then use the address", it should do that initially, but keep looking out = for evidence that the address is in use and discontinue use if it = detects a conflict ? >=20 > It shouldn't be necessary. >=20 > The normal state is no duplicates, so why have all devices that have > known unique addresses continually check to see if duplicates have > occurred? >=20 > A duplicate can only occur when a node tries to bring up a new address > on the link, and that is the time for that node to check to see if the > new address is a duplicate. If the new address is a duplicate of an > existing address, the existing address user gets to keep using it, and > the new node has to pick another address. >=20 > Ongoing DAD by existing nodes could overcome the reliability issues > being discussed, however it is really better to have the new entrant > try harder. It's a once off period of checking to ensure and get the > set of addresses to being unique verses an ongoing period of checking > that has no value once the set of addresses are unique. I probably didn't write that very well. Part of this discussion arose from observations that the initial DAD = could fail in a statistically significant number of cases because the = packet(s) got lost - filtering/rate limiting in the wireless network, = the network switch has spanning tree and the port is still not in = forwarding mode, ... So it's possible for a node to obtain/generate an address, perform = initial DAD, and *NOT* detect a duplicate - so configuring an address on = an interface which is already in use. It's not true to say that "A = duplicate can only occur when a node tries to bring up a new address on = the link". You can "try harder", but unless "try harder" means keep = trying ad infinitum then you still don't have a **guarantee** on = anything but a perfectly lossless/error-free network. So should "try = harder" mean trying several times over a few seconds ? Or should it mean = trying multiple times over at least 16 seconds (default forwarding delay = is 15 seconds for spanning tree), or even longer since the network admin = may have set the delay to a larger value ? You could argue that this is a network problem, but in the real world, = we do have networks which aren't 100% reliable. When I wrote "an ongoing process" I wasn't thinking of an active process = of sending discovery packets, but a passive process of monitoring for = indications of another host using the same address. Eg, if the network = stack sees a packet on the wire with one of it's own addresses as the = source address, but that packet didn't come from this node (different = hardware address for example) then that's an indication that there is a = duplicate. The problem then is which node then has the right to carry on using that = address ! From nobody Wed Jul 19 02:58:12 2017 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 ADB1B131C49 for ; Wed, 19 Jul 2017 02:58:10 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1XkgxmLE5dEP for ; Wed, 19 Jul 2017 02:58:09 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B81E126C0F for ; Wed, 19 Jul 2017 02:58:09 -0700 (PDT) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 9FEDC2D4F8B; Wed, 19 Jul 2017 09:58:06 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-D1EF6EDA-184F-4236-8F49-F9468BAC3349 Mime-Version: 1.0 (1.0) Subject: Re: rationale for the default of DupAddrDetectTransmits From: Ole Troan X-Mailer: iPhone Mail (14G57) In-Reply-To: <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> Date: Wed, 19 Jul 2017 11:58:04 +0200 Cc: "Rajiv Asati (rajiva)" , 6man WG Content-Transfer-Encoding: 7bit Message-Id: <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> To: "Bernie Volz (volz)" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:58:11 -0000 --Apple-Mail-D1EF6EDA-184F-4236-8F49-F9468BAC3349 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Bernie, > On 19 Jul 2017, at 11:38, Bernie Volz (volz) wrote: >=20 > Packets get dropped or a node maybe "sleeping". >=20 > There are ongoing checks based on normal ND traffic though so no explicit D= AD needed. No, there is no collision detection as part of normal ND. Links might merge and split. See the previous links for an enumeration of DA= D failure cases.=20 We need an equivalent of IPv4's ACD.=20 Ole >=20 > - Bernie (from iPhone) >=20 > On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) wrot= e: >=20 >>=20 >>> should do that initially, but keep looking out for evidence that the add= ress is in use and discontinue use if it detects a conflict ? >>=20 >> Nope. :) if every node performs the check and uses the assumed address on= ly if check passed, then no conflict afterwards.=20 >>=20 >> Cheers, >> Rajiv =20 >>=20 >> On Jul 19, 2017, at 10:55 AM, Simon Hobson wrote= : >>=20 >>> Mark Smith wrote: >>>=20 >>>> In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on >>>> a link before IPv4 DAD (and DHCPv4) became available. I'd much rather >>>> reliable DAD and failure of DAD to be considered fatal. >>>=20 >>> Yes, address duplicates are "interesting" aren't they - especially if it= 's the default router address :-( >>>=20 >>> At the risk of opening another tin or worms, shouldn't DAD be an ongoing= process ? Ie, rather than a simple "fire off a packet, if you get nothing b= ack then use the address", it should do that initially, but keep looking out= for evidence that the address is in use and discontinue use if it detects a= conflict ? >>>=20 >>> Introduces another means of DoS - but I think if any node is in a positi= on to trigger such an ongoing DAD collision event, then it's already in a po= sition to cause problems (such as by firing off unsolicited ND packets ?) >>>=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 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-D1EF6EDA-184F-4236-8F49-F9468BAC3349 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Bernie,

On 19 Jul 2017, at 11:38, Bernie Volz (volz) <volz@cisco.com> wrote:

Packets get dropped or a node maybe "sleeping".

There are ongoing checks based on normal ND traffic though so no explicit DAD needed.

No, there is no collision detection as part of normal ND.

Links might merge and split. See the previous links for an enumeration of DAD failure cases. 

We need an equivalent of IPv4's ACD. 

Ole



- Bernie (from iPhone)

On Jul 19, 2017, at 11:05 AM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:


should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Nope. :) if every node performs the check and uses the assumed address only if check passed, then no conflict afterwards. 

Cheers,
Rajiv  

On Jul 19, 2017, at 10:55 AM, Simon Hobson <linux@thehobsons.co.uk> wrote:

Mark Smith <markzzzsmith@gmail.com> wrote:

In the distant past, I've troubleshooted 5 duplicate IPv4 addresses on
a link before IPv4 DAD (and DHCPv4) became available. I'd much rather
reliable DAD and failure of DAD to be considered fatal.

Yes, address duplicates are "interesting" aren't they - especially if it's the default router address :-(

At the risk of opening another tin or worms, shouldn't DAD be an ongoing process ? Ie, rather than a simple "fire off a packet, if you get nothing back then use the address", it should do that initially, but keep looking out for evidence that the address is in use and discontinue use if it detects a conflict ?

Introduces another means of DoS - but I think if any node is in a position to trigger such an ongoing DAD collision event, then it's already in a position to cause problems (such as by firing off unsolicited ND packets ?)

--------------------------------------------------------------------
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
--------------------------------------------------------------------
--Apple-Mail-D1EF6EDA-184F-4236-8F49-F9468BAC3349-- From nobody Wed Jul 19 03:26:24 2017 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 08DB1131C81 for ; Wed, 19 Jul 2017 03:26:23 -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 nTozFv0UPHXI for ; Wed, 19 Jul 2017 03:26:21 -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 BA1E5131C60 for ; Wed, 19 Jul 2017 03:26:21 -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 v6JAQK01024272; Wed, 19 Jul 2017 03:26:20 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6JAQDAP024239 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Jul 2017 03:26:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 03:26:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 03:26:12 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QA== Date: Wed, 19 Jul 2017 10:26:12 +0000 Message-ID: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:26:23 -0000 Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Deleg= ating Router. Recent discussions and drafts have suggested that the "Requesting Router" c= ould be a simple host that receives a Prefix Delegation (of whatever prefix length) f= or its own multi-addressing purposes. Meaning, that the host configures addresses from= the prefix and assigns them, e.g., to a loopback interface so that its local ap= plications can each use a different address if desired. But, whether the node uses the delegated prefix for multi-addressing (as a = host would) or for assignment to downstream links (as a router would), it still = has the same appearance from the outside world. So, from the outside world, the nod= e would appear as a multi-addressing host even if it is acting as a router on= its downstream links. The only time it would look like a router is if it engage= d in a dynamic routing protocol on the interface over which it received the prefix= . Any thoughts? Thanks - Fred From nobody Wed Jul 19 03:58:41 2017 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 A13D812EA7C for ; Wed, 19 Jul 2017 03:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8mSHJHOI814 for ; Wed, 19 Jul 2017 03:58:38 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C42B12714F for <6man@ietf.org>; Wed, 19 Jul 2017 03:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500461916; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=mlylVVopCP0UQEC/4tvoDOaOIChu6KKo7ZHH4wPix8o=; b=gZRuLMZC7cEeRii4GGuq1dpm7zL868IMVYpo3gUJP78yOQCU920+I/wxhTOfj/96z467njzyLz7fzE9vB0QrGHbi2XPjUvkZj0PhAX54SWMQkwBEe7xfW2kNzif+rVYqPP5RsDZRPePyxVa+FtvmBtoWk5RAw1XOsZ43reziKVA= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0175.outbound.protection.outlook.com [213.199.154.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-59-BzsnIaosOPSPuT4hNvFM5w-1; Wed, 19 Jul 2017 11:58:34 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB451.eurprd07.prod.outlook.com (10.242.113.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 10:58:33 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 10:58:33 +0000 From: Tim Chown To: Fernando Gont CC: "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Topic: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Index: AQHS/9WLcUlWmq4/K0ml7V6v7zatO6Ja/D+A Date: Wed, 19 Jul 2017 10:58:33 +0000 Message-ID: <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> In-Reply-To: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:370:128:f4f2:7c6d:6820:d763] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB451; 20:xfCZHiRVmXEGtGGovUhOfFOimNHZ8WUQKm6Z1eSwY8WAlk2VJtSCgKaFEyJElmO/6spZ7fgNPH+UydWIBT5322yF7yOAoW9Dbsj/jkUQXSF+WfQ/uBCfqUvJKi0cUBliqSUgbaf3vRYICAn39uY8J9fKP2YB8APJIlpzXbZadjo= x-ms-office365-filtering-correlation-id: 0309803b-9094-4a33-912d-08d4ce951962 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB451; x-ms-traffictypediagnostic: AM3PR07MB451: x-exchange-antispam-report-test: UriScan:(236129657087228)(192374486261705)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB451; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB451; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39840400002)(24454002)(14454004)(110136004)(38730400002)(2950100002)(42882006)(6512007)(6916009)(229853002)(2900100001)(102836003)(305945005)(5250100002)(53546010)(561944003)(53936002)(189998001)(6116002)(4326008)(33656002)(6486002)(6436002)(36756003)(76176999)(6506006)(50986999)(25786009)(99286003)(57306001)(6246003)(5660300001)(83716003)(50226002)(72206003)(8936002)(230783001)(74482002)(82746002)(86362001)(478600001)(2906002)(7736002)(81166006)(3660700001)(3280700002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB451; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6029B4A12F75234D8F1B80E28964E7CF@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 10:58:33.6861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB451 X-MC-Unique: BzsnIaosOPSPuT4hNvFM5w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:58:40 -0000 PiBPbiAxOCBKdWwgMjAxNywgYXQgMTU6NTIsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBGb2xrcywNCj4gDQo+IEFtb25nIHRoZSBsaXN0IG9mIFJG Q3MgdG8gYmUgcHJvZ3Jlc3NlZCB0byBmdWxsIHN0ZCBpcy93YXMgUkZDNDk0MQ0KPiAoIlByaXZh Y3kgRXh0ZW5zaW9ucyBmb3IgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gaW4g SVB2NiIpLg0KPiANCj4gQXMgaXQgc3RhbmRzLCBSRkM0OTQxIGhhcyBhIG51bWJlciBvZiBpc3N1 ZXM6DQo+IA0KPiAqIFVzaW5nIHRoZSBzYW1lIElJRCBmb3IgbXVsdGlwbGUgcHJlZml4ZXMNCj4g KiBOb3QgY2hhbmdpbmcgdGhlIElJRCB1cG9uICJzZWN1cml0eSBldmVudHMiIChpbmNsdWRpbmcg ZS5nLiwgY2hhbmdlIGluDQo+IHRoZSB1bmRlcmx5aW5nIE1BQyBhZGRyZXNzKQ0KPiAqIFVzaW5n IE1ENSBhcyBvcHBvc2VkIHRvIHNvbWV0aGluZyBiZXR0ZXINCj4gKiBSZXF1aXJpbmcgdGhlIHVz ZSBvZiB0ZW1wb3JhcnkgYWRkcmVzc2VzIGFsb25nIHN0YWJsZSBhZGRyZXNzZXMNCj4gKHByZXZl bnRpbmcgdXNlIG9mIHRlbXBvcmFyeS1vbmx5LCBmb3Igbm9kZXMgdGhhdCBmZWVsIGxpa2UpDQo+ ICogTm90IHRyZWF0aW5nIElJRHMgYXMgb3BhcXVlIHZhbHVlcyAoc2VlIFJGQzcxMzYpICB3aGVu IGdlbmVyYXRpbmcgdGhlDQo+IHJhbmRvbWl6ZWQgSUlEcyAoc2VlIHN0ZXAgMyBpbiBzZWN0aW9u IDMuMi4xIG9mIFJGQzQ5NDEpDQo+ICogTWFuZGF0aW5nIG9uZSBzcGVjaWZpYyBhbGdvcml0aG0s IHdoZW4gdGhlIHNhbWUgZ29hbHMvcHJvcGVydGllcyBjYW4NCj4gYmUgYWNoaWV2ZWQgd2l0aCBt dWx0aXBsZSBhbGdvcml0aG1zIChzZWUgc2VjdGlvbiA0IG9mDQo+IGRyYWZ0LWdvbnQtNm1hbi1u b24tc3RhYmxlLWlpZHMtMDEpDQo+IA0KPiANCj4gQmFzZWQgb24gdGhlIGFib3ZlLCBJIHBlcnNv bmFsbHkgZG9uJ3QgdGhpbmsgdGhhdCBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvDQo+IHByb2dyZXNz IFJGQzQ5NDEgdG8gSW50ZXJuZXQgU3RhbmRhcmQsIGJ1dCByYXRoZXIgdGhpbmsgdGhhdCB3ZSBz aG91bGQNCj4gd29yayBvbiAgYSByZXBsYWNlbWVudCBvZiBpdCAtLSBvdXIgcHJvcG9zYWwgYmVp bmcNCj4gZHJhZnQtZ29udC02bWFuLW5vbi1zdGFibGUtaWlkcy0wMS4NCj4gDQo+IFRob3VnaHRz Pw0KDQpDZXJ0YWlubHkgYW55IHVwZGF0ZSBvbiA0OTQxIG5lZWRzIHRvIGJlIGRvbmUgaW4gdGhl IGxpZ2h0IG9mIGEgZmV3IGRlZmljaWVuY2llcyB0aGF0IGhhdmUgZW1lcmdlZCBvdmVyIHRoZSB5 ZWFycywgYW5kIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkM3MjE3Lg0KDQpJIHRoaW5rIGl04oCZcyBz dGlsbCBwb3NzaWJsZSB0byBkbyBhIC1iaXMgb2ZmIDQ5NDEuDQoNClRpbSA= From nobody Wed Jul 19 04:18:58 2017 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 0E735131CB3 for ; Wed, 19 Jul 2017 04:18:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XNma7rLIvmtA for ; Wed, 19 Jul 2017 04:18:54 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 DFDA612EBFA for ; Wed, 19 Jul 2017 04:18:53 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 33so720689wrz.4 for ; Wed, 19 Jul 2017 04:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=OAd996iS+TBGUlZsFZnt/MUYJkyqAYiz7dR4u3DCb2k=; b=k6xszCVv+rNrnj5iTLfZ+htPCFDXYqznmM55w1GgZhgFMs7uiUqbM0GmTctIax5l7K /NGAjDFDGnugJDjiKq1OxwMv9aLIiwM0MxCvKmwvrmTsxlc8g5n6mxbxKZhAeW88eMQp gED9OXHWiW8kRxf1XcXxyJmFgI5zJAm9zG/zc5GtnzgCu4XSluN3yJIXihH7XzEa9Edf PerzpU1JWP/XaY/po2RxUbdAc8s4DlEMF7fa4an7xfd4Q05gWiJhV6PDiHD/mdMwqmkn TdBNc5HYiddaYbq43W/LO/Gj06LckJc5YLCGMupCEYmmNTDHu6OsOVGTUwru+sYtTKU1 onOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=OAd996iS+TBGUlZsFZnt/MUYJkyqAYiz7dR4u3DCb2k=; b=d64CmciTOBRA+D2vNHRIhsrlKXD9mOzV6p0zleF/TyITA3kaSZQTa1DgixKmiDGxXu ccBL/vHi4DqsrTAi4DrIUNouTXJdhNGkhsloDXyj914BQ5R1pCA7N5rwrwk/xO06XvBt y51924CBoFUqNcFrYio4/WfAeCk6e3syepkgAkjHJrnAzNSZMRfbmJkGvXNsQWgmzdA6 eMfaUn8npmQYmvUa8mA4KyfPdD4RIXo7igFOrZ4OBY3l7waOWMk9M8/psHn66TPXRcRp eb6PXw5oLvdQmKgOXt6D+jAbwAJiYvTj1hbLaz8YqPfXQK8Cjb/I83f8DXlw13j/dYRJ 0/tg== X-Gm-Message-State: AIVw111JosR/9RP2KxA9qotosO1qs4vNoAmc6lY9LEmZNufZFWSsxVvR 33cGRtS1wEI8QqnKOFygSQ== X-Received: by 10.223.164.94 with SMTP id e30mr4150697wra.129.1500463132038; Wed, 19 Jul 2017 04:18:52 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:c4a3:3113:6a2c:a8de? ([2001:67c:370:1998:c4a3:3113:6a2c:a8de]) by smtp.gmail.com with ESMTPSA id d26sm156804wra.92.2017.07.19.04.18.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 04:18:51 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_7AD8ABDB-0D23-4A77-B9B1-925ECE031A5D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: In consideration of I-D.templin-6man-rio-redirect Date: Wed, 19 Jul 2017 13:18:50 +0200 References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> <4a50273fd30849c8836ebc1dda0076d3@XCH15-06-08.nw.nos.boeing.com> To: IPv6 List In-Reply-To: Message-Id: <8009DD43-FB28-41E7-8439-EC7F559E0181@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:18:56 -0000 --Apple-Mail=_7AD8ABDB-0D23-4A77-B9B1-925ECE031A5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 19, 2017, at 11:05, Bernie Volz (volz) wrote: >=20 > Couldn't the LAN case be solved by sending a PIO with shorter prefix = length covering the address space with on-link set but SLAAC disabled? That could work, but it would entail a NS/NS exchange and ND cache = entries at the Source for every address in use that is delegated to the = Target. Another similar method could work using the existing ND Redirect = messages, which would have the same effect: inserting ND cache entries = for each address. You should think of our proposal as an optimization that lifts all those = ND cache entries up into the host route table for whole prefixes at a = time. --james woodyatt > --Apple-Mail=_7AD8ABDB-0D23-4A77-B9B1-925ECE031A5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jul 19, 2017, at 11:05, Bernie Volz (volz) <volz@cisco.com> = wrote:

Couldn't the LAN case be solved by sending a PIO with shorter = prefix length covering the address space with on-link set but SLAAC = disabled?

That could = work, but it would entail a NS/NS exchange and ND cache entries at the = Source for every address in use that is delegated to the Target. Another = similar method could work using the existing ND Redirect messages, which = would have the same effect: inserting ND cache entries for each = address.

You should think of our = proposal as an optimization that lifts all those ND cache entries up = into the host route table for whole prefixes at a time.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_7AD8ABDB-0D23-4A77-B9B1-925ECE031A5D-- From nobody Wed Jul 19 04:33:47 2017 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 AA15513178B for ; Wed, 19 Jul 2017 04:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DcqZKlXo-UQa for ; Wed, 19 Jul 2017 04:33:44 -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 67BE11300BB for <6man@ietf.org>; Wed, 19 Jul 2017 04:33:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6JBH9nN037512; Wed, 19 Jul 2017 13:17:09 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707191117.v6JBH9nN037512@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont cc: "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids In-reply-to: Your message of Tue, 18 Jul 2017 17:52:50 +0300. <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> Date: Wed, 19 Jul 2017 13:17:09 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:33:46 -0000 > Among the list of RFCs to be progressed to full std is/was RFC4941 > ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). => I even published a document explaining what I thought about the whole idea (and I didn't change my mind). > As it stands, RFC4941 has a number of issues: > * Using MD5 as opposed to something better => for this use MD5 is not bad. Just consider it as a not crypto hash. Now RFC4941bis is currently heavily deployed so it is far too soon to try to obsolete it. When I went to the mic at a previous IETF meeting some years ago to ask the IPv6 specs to be raise to full standard with at first the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left at the border of the road I shan't be sad... Regards Francis.Dupont@fdupont.fr From nobody Wed Jul 19 04:34:58 2017 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 A9FC6131CC2 for ; Wed, 19 Jul 2017 04:34:49 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 o6ipMEZ8eVdc for ; Wed, 19 Jul 2017 04:34:39 -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 25BCF131CC3 for ; Wed, 19 Jul 2017 04:34:37 -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 v6JBYagO046406; Wed, 19 Jul 2017 04:34:36 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6JBYTTP046360 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Jul 2017 04:34:30 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 04:34:29 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 04:34:29 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: RE: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QAACdcww Date: Wed, 19 Jul 2017 11:34:28 +0000 Message-ID: References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:34:50 -0000 To add to this, these types of nodes must not send RAs on the link over whi= ch they received the prefix delegation - only routers that are authoritative for th= e link should send RAs. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Wednesday, July 19, 2017 3:26 AM > To: ipv6@ietf.org > Subject: Prefix Delegation and hosts >=20 > Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Del= egating Router. > Recent discussions and drafts have suggested that the "Requesting Router"= could be a > simple host that receives a Prefix Delegation (of whatever prefix length)= for its own > multi-addressing purposes. Meaning, that the host configures addresses fr= om the > prefix and assigns them, e.g., to a loopback interface so that its local = applications can > each use a different address if desired. >=20 > But, whether the node uses the delegated prefix for multi-addressing (as = a host > would) or for assignment to downstream links (as a router would), it stil= l has the > same appearance from the outside world. So, from the outside world, the n= ode > would appear as a multi-addressing host even if it is acting as a router = on its > downstream links. The only time it would look like a router is if it enga= ged in a > dynamic routing protocol on the interface over which it received the pref= ix. >=20 > Any thoughts? >=20 > Thanks - Fred >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 19 04:38:23 2017 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 60905131C4B for ; Wed, 19 Jul 2017 04:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, URIBL_BLOCKED=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 5sZdtjRjc4OM for ; Wed, 19 Jul 2017 04:38:19 -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 BEAEE13178B for ; Wed, 19 Jul 2017 04:38:19 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id c74so764530iod.4 for ; Wed, 19 Jul 2017 04:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N0aYeYPgpWNzXJjUNmJRZ/U/iWV0FEKtCB3wHvReVhM=; b=fl/dmEJb8QiTALTk1lhNrkwEqqkU2P98oYA+RbvtfTaQLc7yvRTRa+ya8cUgCOZKm+ bSXZm/8BGucdiecD+j6Ty76WkBpGOjBzB6SrmtF+VqhuCM5Px4Qn3tHXLisHqWkvLem5 QCeGmuaQQKVXpzQpr1ho0OOQAG9evQ4LvTEfpAirIwD36hQSRdqro0uK0a9qtII1/yX8 wbm3qo3VY+XOqAr8G1Rb5OiZIOMXqseXVBduJ9PLMMJRKkqsnt91N1idiR9Qq4V0OBx6 bwQHtmYuefpt5zBQDOaPOTfjkbG+fhqjw9LnavnehlH2KZlt67yOOJ5eyiS9ige4pwpt cTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N0aYeYPgpWNzXJjUNmJRZ/U/iWV0FEKtCB3wHvReVhM=; b=DETJrTxh3GQeuNi0FqVMkkTdD84oRa6sHVKiVlhs3zfFukBYiyOylF+jI858ZI5EfF O9vg+Q6bnoOmyziw0A7Bfsp7BArYTN08/rR2zpCkmgebmUUS6t46WbchpbGIdBckGVWC LUj8wRaegjle2MEIghCuFkZJjWC/P5VeFyhXG5H/p0jq4vsC+UDSBkAA/RyAxwciOZwa gfueChL2G7m3FIa0p24DKm3ZG9FgLhx5ZpCMRrQOkJqHthmXXAjfgx1xilDRLCK+/Onz 2To7Puo2fq225O2xLgtutblIizRYWnI1kkh++Fb72v33nlot3RPIsJDlpc6nh9nCeDNU QeOQ== X-Gm-Message-State: AIVw110cuYQIlQYAZxV4FgxH4uSnvLsSBvI1K4Vv4vo4vdWDN9NlvDjh DMEugZyjf8qL++2kl6+vgMc+x21MwA== X-Received: by 10.107.168.164 with SMTP id e36mr1694201ioj.40.1500464299156; Wed, 19 Jul 2017 04:38:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.173.162 with HTTP; Wed, 19 Jul 2017 04:38:18 -0700 (PDT) In-Reply-To: <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> From: Sowmini Varadhan Date: Wed, 19 Jul 2017 07:38:18 -0400 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Ole Troan , Sowmini Varadhan Cc: "Bernie Volz (volz)" , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:38:21 -0000 This was actually brought up some IETFs ago, see https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01 Solaris 11 actually uses a common ACD engine for both IPv4 and IPv6. I believe (?) Microsoft also does the same, perhaps someone from MS can confirm. If there's an interest in this, I'd be happy to provide more details about the Solaris implementation. On Wed, Jul 19, 2017 at 5:58 AM, Ole Troan wrote: > Bernie, > > On 19 Jul 2017, at 11:38, Bernie Volz (volz) wrote: > > Packets get dropped or a node maybe "sleeping". > > There are ongoing checks based on normal ND traffic though so no explicit > DAD needed. > > > No, there is no collision detection as part of normal ND. > > Links might merge and split. See the previous links for an enumeration of > DAD failure cases. > > We need an equivalent of IPv4's ACD. > > Ole From nobody Wed Jul 19 05:07:02 2017 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 D9788131CB4 for ; Wed, 19 Jul 2017 05:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 JWvZpncuidPD for ; Wed, 19 Jul 2017 05:06:59 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2CE1317A9 for ; Wed, 19 Jul 2017 05:06:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id a12so19053193ywh.3 for ; Wed, 19 Jul 2017 05:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DCmMLCzpsuzjdJCz/1Bm4BnjVwRwAtjJxSKZA20KSQ=; b=dgJGREWPWMS7gnUen+nWdlYPKhMXZk7/WQb5dvHl3DQgvg0WjNF22cSDX3Ml8b9zG4 Fad05ARbSixLmovD7RRcW8AFALtG4AO7eDFH4bGSW39at89nKly2zZgy/ziaZPNYKxFX A4NzNJQNyblWTd6afZ9HYKu03clAKfwyy2ymlaMLkLpUqNAlJPfXGHLmwE31dUWCmqlK vVnwGPahB1YBF+xBJEdKZ05D9BL6YxZUmTkvagbMneq3eLry4UxHc6DrqCNmkm/XSF6d mbwkrkiNJF+E4YWBFcAawApc8dHom8SMzFXbQFv1R/O+y7GfDbWMfjgqERxAM17nXi5L GOzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DCmMLCzpsuzjdJCz/1Bm4BnjVwRwAtjJxSKZA20KSQ=; b=IyMDy9L/bhzegP3jR5y+HYG5q07T08s4dlpXBuz+VBhdMs9rA3/UxjhUSUPw3HtE0y zfYCesnGFm3KYZPGbccFldbe5ouyAvxTJrPk/tDG1g6VQcCSOEjICu8uj0mtekH/2o/N bBxCa24NwOAETYPTQv/E+A7nltc1EuYmxk01DMHLsojwMgJ7SReH4xoTXZunDHBaioSt XeLy/hXe8erh5wRMUEmnVvFmc9vtpY2TA64MTUv22oS4jrNL3Q2Wc4axdmTGTml3LiHv TeL933HmEMyVDJWnjyoehYediOCDVxO11uxOZXdu1MOH8fk/wnFaaNM9MyyuYy25uTAM 3cNg== X-Gm-Message-State: AIVw113+hIJjyyHsKeqwMrRsfMO9wg19LzOESohql9lBcvRtL/rNSI1o U1J2iVqABmejODg8ItJqHlwUlhtvkXlpKY4= X-Received: by 10.13.249.65 with SMTP id j62mr1880335ywf.141.1500466018447; Wed, 19 Jul 2017 05:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.35.69 with HTTP; Wed, 19 Jul 2017 05:06:37 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> From: Erik Kline Date: Wed, 19 Jul 2017 14:06:37 +0200 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Sowmini Varadhan Cc: Ole Troan , Sowmini Varadhan , 6man WG , "Bernie Volz (volz)" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07e3701059f20554aa78ef" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:07:01 -0000 --94eb2c07e3701059f20554aa78ef Content-Type: text/plain; charset="UTF-8" > If there's an interest in this, I'd be happy to provide more details > about the Solaris implementation. If it's appropriate to share with the group, I think it'd be interesting. --94eb2c07e3701059f20554aa78ef Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQggyyisGsYGz68XfNE6vXozERn3j9MYTpD eD9i7CKJK/wwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzE5 MTIwNjU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGOiHJJxrlZL1zRHGj604bOko44JKth2XrPhur/1Dh2HysgyGD/7 KqY7LCaLq9qRHIuYqNgN8JAZ9bBBPFrSD18as19P50xRa9OiC6NsJVRvk80KTExp2xbvozBSvTxQ PjnA9edx8LjtmC8LnjFa2LraLJIcWUmcjiW0rd4GHsk7F4jpBiLItgZKnZ+Ilqqm+LkPRsRhB20g YPzSJNsp3iK9sdVwBMXDozBzuwoasb+FgZtcKCKmSyO8mFadETIjH9MVoOes175r4Snuf00oUMT7 8NpBqeCsZG3NpqCNtGWxNY5Pt8kJ0d9Plp8vLFwvS0/Eq2jY+au0kPJraq/p/0U= --94eb2c07e3701059f20554aa78ef-- From nobody Wed Jul 19 05:19:56 2017 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 07B6D131CE0 for ; Wed, 19 Jul 2017 05:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 f97BfGJCoP_h for ; Wed, 19 Jul 2017 05:19:54 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C02131CE4 for ; Wed, 19 Jul 2017 05:19:54 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6JCJlpK005047 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jul 2017 12:19:48 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6JCJln6022549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jul 2017 12:19:47 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6JCJl8u031152; Wed, 19 Jul 2017 12:19:47 GMT Received: from oracle.com (/31.133.131.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jul 2017 05:19:46 -0700 Date: Wed, 19 Jul 2017 08:19:40 -0400 From: Sowmini Varadhan To: Erik Kline Cc: Sowmini Varadhan , Ole Troan , 6man WG , "Bernie Volz (volz)" Subject: Re: rationale for the default of DupAddrDetectTransmits Message-ID: <20170719121940.GA10022@oracle.com> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> 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) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:19:55 -0000 On (07/19/17 14:06), Erik Kline wrote: > > > If there's an interest in this, I'd be happy to provide more details > > about the Solaris implementation. > > If it's appropriate to share with the group, I think it'd be interesting. ok, let me dig up some of my notes about the details of this, and I'll get back on this thread. --Sowmini From nobody Wed Jul 19 05:24:14 2017 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 CF8FD131B2F for ; Wed, 19 Jul 2017 05:24:11 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 L2rc3GY4-gpy for ; Wed, 19 Jul 2017 05:24:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8F2131B13 for ; Wed, 19 Jul 2017 05:24:10 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 49A531F8F6; Wed, 19 Jul 2017 12:24:09 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2700C1CCB; Wed, 19 Jul 2017 14:24:01 +0200 (CEST) From: Michael Richardson To: "Templin\, Fred L" cc: "ipv6\@ietf.org" Subject: Re: Prefix Delegation and hosts In-reply-to: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> Comments: In-reply-to "Templin, Fred L" message dated "Wed, 19 Jul 2017 10:26:12 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 19 Jul 2017 14:24:01 +0200 Message-ID: <18448.1500467041@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:24:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > But, whether the node uses the delegated prefix for multi-addressing > (as a host would) or for assignment to downstream links (as a router > would), it still has the same appearance from the outside world. So, > from the outside world, the node would appear as a multi-addressing > host even if it is acting as a router on its downstream links. The on= ly > time it would look like a router is if it engaged in a dynamic routing > protocol on the interface over which it received the prefix. > Any thoughts? I should tell my 5G provider that I need the prefix because I run VMs on my phone (work, home, kid gaming), and that it has nothing to do with tethering.=20=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZb09gAAoJEJVM4Vb9/EKQLScH/jh+adw8eVIpZqOHt6YZmuol 2TkgcW+/tt7/C/+XWlqwqE+dq55oOatbIEZD+iVsQ3+bcWNkbAFk+03HNoCsF0i8 b2/2nSoK4e8+0RubObFMotvJKTI2n2vQeM3wZmXLt6DQCXoXIikrAVv9CFuHhabp TmP8CcE3sPYnecLICYnSw/1yad2kmeo2OpM/Gh2xokd7OM6RMrbOJQ5TfMQ/wZ0y z3E2NFAPJj0aAUdIq6MZbLKAk1cWqqi7X4G3IR4sD3Kb2OcIuANAu4ckIrySmqt0 cs6Sh2yyNEN80LOhqufClkT+6NAGGUbw64/9IGzj4OED0SCgoGajYPOQ54uUUik= =jnoK -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 19 05:48:12 2017 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 3D157131CFA for ; Wed, 19 Jul 2017 05:48:11 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 a2L0_c-eaW5V for ; Wed, 19 Jul 2017 05:48:09 -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 C69A51288B8 for ; Wed, 19 Jul 2017 05:48:09 -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 v6JCm85l036699; Wed, 19 Jul 2017 05:48:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6JCm4fU036655 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 05:48:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 05:48:03 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 05:48:03 -0700 From: "Templin, Fred L" To: Michael Richardson CC: "ipv6@ietf.org" Subject: RE: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QAAS7xCAAA3nseA= Date: Wed, 19 Jul 2017 12:48:03 +0000 Message-ID: <90d7bd34624946de86e88a963e868953@XCH15-06-08.nw.nos.boeing.com> References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <18448.1500467041@dooku.sandelman.ca> In-Reply-To: <18448.1500467041@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:48:11 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Wednesday, July 19, 2017 5:24 AM > To: Templin, Fred L > Cc: ipv6@ietf.org > Subject: Re: Prefix Delegation and hosts >=20 >=20 > Templin, Fred L wrote: > > But, whether the node uses the delegated prefix for multi-addressin= g > > (as a host would) or for assignment to downstream links (as a route= r > > would), it still has the same appearance from the outside world. So= , > > from the outside world, the node would appear as a multi-addressing > > host even if it is acting as a router on its downstream links. The = only > > time it would look like a router is if it engaged in a dynamic rout= ing > > protocol on the interface over which it received the prefix. >=20 > > Any thoughts? >=20 > I should tell my 5G provider that I need the prefix because I run VMs > on my phone (work, home, kid gaming), and that it has nothing to do with > tethering. Yes, exactly. And, if the provider won't give you a prefix because they fea= r tethering all you need to do is turn your phone into a NAT. Thanks - Fred =20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 From nobody Wed Jul 19 05:58:03 2017 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 958F3131C71 for ; Wed, 19 Jul 2017 05:58:01 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 lII_iXNzB_ua for ; Wed, 19 Jul 2017 05:57:59 -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 8F77D12EBF7 for <6man@ietf.org>; Wed, 19 Jul 2017 05:57:59 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:e5ff:e555:a323:80b4] (unknown [IPv6:2001:67c:370:128:e5ff:e555:a323:80b4]) (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 D65A18254C; Wed, 19 Jul 2017 14:59:27 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Tim Chown Cc: "6man@ietf.org" <6man@ietf.org> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> From: Fernando Gont Message-ID: Date: Wed, 19 Jul 2017 15:57:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:58:02 -0000 On 07/19/2017 01:58 PM, Tim Chown wrote: >> On 18 Jul 2017, at 15:52, Fernando Gont >> wrote: >> >> Folks, >> >> Among the list of RFCs to be progressed to full std is/was RFC4941 >> ("Privacy Extensions for Stateless Address Autoconfiguration in >> IPv6"). >> >> As it stands, RFC4941 has a number of issues: >> >> * Using the same IID for multiple prefixes * Not changing the IID >> upon "security events" (including e.g., change in the underlying >> MAC address) * Using MD5 as opposed to something better * Requiring >> the use of temporary addresses along stable addresses (preventing >> use of temporary-only, for nodes that feel like) * Not treating >> IIDs as opaque values (see RFC7136) when generating the randomized >> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one >> specific algorithm, when the same goals/properties can be achieved >> with multiple algorithms (see section 4 of >> draft-gont-6man-non-stable-iids-01) >> >> >> Based on the above, I personally don't think that it would make >> sense to progress RFC4941 to Internet Standard, but rather think >> that we should work on a replacement of it -- our proposal being >> draft-gont-6man-non-stable-iids-01. >> >> Thoughts? > > Certainly any update on 4941 needs to be done in the light of a few > deficiencies that have emerged over the years, and the publication of > RFC7217. > > I think it’s still possible to do a -bis off 4941. My questions would be: 1) Can you actually address the aforementioned deficiencies without significant changes to RFC4941? -- It would seem to me that in order to address them, rfc4941bis would not be a bis document anymore. 2) If you were to address such deficiencies, could the bis document be progressed to Internet Standard? -- My assessment of this question is: No. If RFC4941 would take significant work, and the end result would actually be significantly different from what's in RFC4941, then I'm not sure that'd be different than starting from the I-D we already have... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 19 06:44:54 2017 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 80588131C7E for ; Wed, 19 Jul 2017 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bWIuXodTHNQ for ; Wed, 19 Jul 2017 06:44:51 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 F092A131D28 for ; Wed, 19 Jul 2017 06:44:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 32A9D9BE for ; Wed, 19 Jul 2017 13:44:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crM0Hf4Hdf_f for ; Wed, 19 Jul 2017 08:44:49 -0500 (CDT) Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 0BE6675B for ; Wed, 19 Jul 2017 08:44:48 -0500 (CDT) Received: by mail-io0-f200.google.com with SMTP id m88so929409iod.0 for ; Wed, 19 Jul 2017 06:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F8eqUKdA3RVoDKU25h4NMaC4VQbNuj6shyvFZomQUsk=; b=EgDwqSocd9+X627CMAVk6Yqk/1AooJM46lzKrX1COZ3jAycwXXG/hqcbUu8WgQgZEQ cCY0B6l0OLxWSzqH25Y7vax/CBdIyS89OZvFTFwgAfaaE2SzVkh0ApBtvSeeVz8Wu4jm 7TrEpR7EPnsoHXhb8yOWR7Z0iJfY0uPS3vgAW4ZTbZTEQxTeAXp4/lJwYJsHO40kzOWs WPmeVUoh14Cv3bLd+X1YHwR9aDCzMTPRguR2WnHX2PkZvdpQmUhQzVR0We/47ZkbsPGH Cgyisfk90JOQU+cDaVd/agmHJr0B3uBlIG2YCXtaRGBkuZlpa7ePnGpg9wFb3GtVldrf fc7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F8eqUKdA3RVoDKU25h4NMaC4VQbNuj6shyvFZomQUsk=; b=VOml75AqYyoXsafGw7VJhHDvpopRJQ2gtTPHoFm31rEumO6dykd16eMTT7kybYN4// JsF9uIoAeGhBrlPhh9bmfyDKSViCTchWiAd0/pyai42vlyBVeAYb24rGZDw6SuOOAqnA xU8e2m+JDSzf5cTSHckkCB/hnb1M8op/brkRuafje+PrdkxLkKvknO/0lP5Il8LCSVyf 6ddo+9c3KgIC72q5LwYIhWflBzwmmV+eDeyG0idr1B0T7NET2Z+7l39FdK4tP9hgFw0F CAGeBBRk/SV4CVcnXLzPWHxBtIsMjPXo4pMV6pPTfUFegMXpu6dkk7f3HPajGrJ++rUK Y7Eg== X-Gm-Message-State: AIVw112xyY9vfq9fDU+NZSytLjRqeJJ+69pKTMnxQfRkO4zmjJmtVUrx 02Soi+K6ZABLy69tv/izwuXGjXNkPgQCDz9SFXsdmRO6hgwnlG3kRey+ZD3OFrUecLIkwBEB+24 = X-Received: by 10.107.138.151 with SMTP id c23mr128050ioj.268.1500471883431; Wed, 19 Jul 2017 06:44:43 -0700 (PDT) X-Received: by 10.107.138.151 with SMTP id c23mr127806ioj.268.1500471878354; Wed, 19 Jul 2017 06:44:38 -0700 (PDT) Received: from [172.19.131.142] ([12.130.118.25]) by smtp.gmail.com with ESMTPSA id i133sm32276ioi.31.2017.07.19.06.44.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 06:44:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EDF4C8DD-7D4E-4584-A1C5-44F1B2B554C8 Mime-Version: 1.0 (1.0) Subject: Re: From: David Farmer X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 19 Jul 2017 08:44:30 -0500 Cc: james woodyatt , IPv6 List Content-Transfer-Encoding: 7bit Message-Id: <84C45918-42F4-4E5C-B1B3-A912E35AF4C7@umn.edu> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> To: Lorenzo Colitti Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:44:52 -0000 --Apple-Mail-EDF4C8DD-7D4E-4584-A1C5-44F1B2B554C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Jul 19, 2017, at 02:26, Lorenzo Colitti wrote: >=20 >> On Wed, Jul 19, 2017 at 8:22 AM, james woodyatt wrote: >> If have yet to find where RFC 4291 clearly names the part of an IPv6 addr= ess that follows a *routing* prefix apart from a *subnet* prefix. >=20 > There is no name for this concept because it doesn't make sense. >=20 > The zero or more on-link prefixes on a link are entirely separate from any= IP addresses the host might have on that link. >=20 > Any address the host has on that interface might be covered by zero on-lin= k prefixes, one on-link prefix, or more than one. Similarly, any on-link pre= fix may cover zero or more addresses that the host has on that interface. If there is truly a distinction in IPv6 between a subnet prefix that is pair= with an IID and a routing/on-link prefix, purportedly without an IID, that i= s an important architectural distinction that needs to be much more clearly e= xplained in RFC4291bis. =20 In the current text, this point is either way too subtle or missing all toge= ther. In fact I believe at least the diagrams in section 2.4, mislead casual= readers to the exact opposite conclusion, maybe even some careful readers t= oo. :) I think it is important to the understanding of the IPv6 Addressing Architec= ture that this gets clarified prior to moving to Internet Standard, otherwis= e I suspect there will be continued misunderstanding of this distinction. David Farmer= --Apple-Mail-EDF4C8DD-7D4E-4584-A1C5-44F1B2B554C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



Sent from m= y iPhone
On Jul 19, 2017, at 02:26, Lorenzo Colitti <lorenzo@google.com> wrote:

On Wed, Jul 19, 2017 at 8:22 AM, james woodyatt <jhw@google= .com> wrote:
If have yet to find where RFC 4291 clearly nam= es the part of an IPv6 address that follows a *routing* prefix apart from a *= subnet* prefix.

There is n= o name for this concept because it doesn't make sense.

<= div>The zero or more on-link prefixes on a link are entirely separate from a= ny IP addresses the host might have on that link.

A= ny address the host has on that interface might be covered by zero on-link p= refixes, one on-link prefix, or more than one. Similarly, any on-link prefix= may cover zero or more addresses that the host has on that interface.
=

If there is truly a distinctio= n in IPv6 between a subnet prefix that is pair with an IID and a routing/on-= link prefix, purportedly without an IID, that is an important architectural d= istinction that needs to be much more clearly explained in RFC4291bis.  = ;

In the current text, this point is either way too= subtle or missing all together. In fact I believe at least the diagrams in s= ection 2.4, mislead casual readers to the exact opposite conclusion, maybe e= ven some careful readers too. :)

I think it is impo= rtant to the understanding of the IPv6 Addressing Architecture that this get= s clarified prior to moving to Internet Standard, otherwise I suspect there w= ill be continued misunderstanding of this distinction.

<= div>David Farmer
= --Apple-Mail-EDF4C8DD-7D4E-4584-A1C5-44F1B2B554C8-- From nobody Wed Jul 19 06:51:57 2017 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 6379012F268 for ; Wed, 19 Jul 2017 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 pUmv_3GOZ9km for ; Wed, 19 Jul 2017 06:51:54 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD1C131D17 for ; Wed, 19 Jul 2017 06:51:54 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6JDpmqR002319 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2017 14:51:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <596F63F4.9010501@foobar.org> Date: Wed, 19 Jul 2017 14:51:48 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: David Farmer CC: IPv6 List , Bob Hinden Subject: Re: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 13:51:56 -0000 David Farmer wrote: > 2. The fact that some components of IPv6 are architecturally based on > 64bit IIDs doesn't mean that operationally IIDs are always required to > be 64 bits. this is certainly implied by the current text in -09. > Rather than implying that operationally IID are required to > be 64bits, how about simply stating that operationally 64 bit IIDs are > recommended. This eliminates the need to enumerate all the exceptions, > which probably isn't something an architectural document should be doing. This would be a good way of dealing with this issue and you're correct to state that enumerating exceptions is something that ought to be avoided in architectural documents. Nick From nobody Wed Jul 19 07:08:52 2017 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 B41B112F268 for ; Wed, 19 Jul 2017 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 VcLQTGM4cNM8 for ; Wed, 19 Jul 2017 07:08:49 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 12F64131473 for ; Wed, 19 Jul 2017 07:08:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6JE8lRQ026583 for ; Wed, 19 Jul 2017 16:08:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 44253206A07 for ; Wed, 19 Jul 2017 16:08:47 +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 3B7A9206A1B for ; Wed, 19 Jul 2017 16:08:47 +0200 (CEST) Received: from [132.166.84.52] ([132.166.84.52]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6JE8kWU015795 for ; Wed, 19 Jul 2017 16:08:47 +0200 Subject: Re: Prefix Delegation and hosts To: ipv6@ietf.org References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Wed, 19 Jul 2017 16:08:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:08:51 -0000 Le 19/07/2017 à 12:26, Templin, Fred L a écrit : > Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router. > Recent discussions and drafts have suggested that the "Requesting Router" could be a > simple host that receives a Prefix Delegation (of whatever prefix length) for its own > multi-addressing purposes. Meaning, that the host configures addresses from the > prefix and assigns them, e.g., to a loopback interface so that its local applications can > each use a different address if desired. The host-that-became-router can also not assign any address from the delegated prefix on any of its interfaces, use its LLs, and forward IP packets. > But, whether the node uses the delegated prefix for multi-addressing (as a host > would) or for assignment to downstream links (as a router would), it still has the > same appearance from the outside world. So, from the outside world, the node > would appear as a multi-addressing host even if it is acting as a router on its > downstream links. The only time it would look like a router is if it engaged in a > dynamic routing protocol on the interface over which it received the prefix. I agree. It would like like Router to the outside world if it ran a routing protocol and if it joined the All-Routers multicast address. Alex > > Any thoughts? > > Thanks - Fred > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jul 19 08:59:23 2017 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 D0E04127B60 for ; Wed, 19 Jul 2017 08:59:21 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 grt0cBeNPUqK for ; Wed, 19 Jul 2017 08:59:20 -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 6CB38127601 for ; Wed, 19 Jul 2017 08:59:20 -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 v6JFxI12029624; Wed, 19 Jul 2017 08:59:19 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6JFxEJZ029597 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 08:59:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 08:59:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 08:59:13 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QAAWl5kAAAr24cA= Date: Wed, 19 Jul 2017 15:59:13 +0000 Message-ID: <12e091f8fd6f4104adf62afb8df653b4@XCH15-06-08.nw.nos.boeing.com> References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 15:59:22 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFtt YWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJl c2N1DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyA3OjA5IEFNDQo+IFRvOiBpcHY2 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBQcmVmaXggRGVsZWdhdGlvbiBhbmQgaG9zdHMNCj4g DQo+IA0KPiANCj4gTGUgMTkvMDcvMjAxNyDDoCAxMjoyNiwgVGVtcGxpbiwgRnJlZCBMIGEgw6lj cml0IDoNCj4gPiBDbGFzc2ljYWwgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIGludm9sdmVzIGEg UmVxdWVzdGluZyBSb3V0ZXIgYW5kIGEgRGVsZWdhdGluZyBSb3V0ZXIuDQo+ID4gUmVjZW50IGRp c2N1c3Npb25zIGFuZCBkcmFmdHMgaGF2ZSBzdWdnZXN0ZWQgdGhhdCB0aGUgIlJlcXVlc3Rpbmcg Um91dGVyIiBjb3VsZCBiZSBhDQo+ID4gc2ltcGxlIGhvc3QgdGhhdCByZWNlaXZlcyBhIFByZWZp eCBEZWxlZ2F0aW9uIChvZiB3aGF0ZXZlciBwcmVmaXggbGVuZ3RoKSBmb3IgaXRzIG93bg0KPiA+ IG11bHRpLWFkZHJlc3NpbmcgcHVycG9zZXMuIE1lYW5pbmcsIHRoYXQgdGhlIGhvc3QgY29uZmln dXJlcyBhZGRyZXNzZXMgZnJvbSB0aGUNCj4gPiBwcmVmaXggYW5kIGFzc2lnbnMgdGhlbSwgZS5n LiwgdG8gYSBsb29wYmFjayBpbnRlcmZhY2Ugc28gdGhhdCBpdHMgbG9jYWwgYXBwbGljYXRpb25z IGNhbg0KPiA+IGVhY2ggdXNlIGEgZGlmZmVyZW50IGFkZHJlc3MgaWYgZGVzaXJlZC4NCj4gDQo+ IFRoZSBob3N0LXRoYXQtYmVjYW1lLXJvdXRlciBjYW4gYWxzbyBub3QgYXNzaWduIGFueSBhZGRy ZXNzIGZyb20gdGhlDQo+IGRlbGVnYXRlZCBwcmVmaXggb24gYW55IG9mIGl0cyBpbnRlcmZhY2Vz LCB1c2UgaXRzIExMcywgYW5kIGZvcndhcmQgSVANCj4gcGFja2V0cy4NCg0KSSBhZ3JlZSBpdCBj YW4gYmUgTEwtb25seSBvbiBpdHMgaW50ZXJmYWNlIG92ZXIgd2hpY2ggaXQgcmVjZWl2ZXMgdGhl IFBELA0KYnV0IGl0IG5lZWRzIHRvIGhhdmUgYXQgbGVhc3Qgb25lIEdVQSBhc3NpZ25lZCBvbiAq c29tZSogaW50ZXJmYWNlDQpzbyBpdCBoYXMgYSBzb3VyY2UgYWRkcmVzcyBmb3Igc2VuZGluZyBJ Q01Qcy4NCg0KPiA+IEJ1dCwgd2hldGhlciB0aGUgbm9kZSB1c2VzIHRoZSBkZWxlZ2F0ZWQgcHJl Zml4IGZvciBtdWx0aS1hZGRyZXNzaW5nIChhcyBhIGhvc3QNCj4gPiB3b3VsZCkgb3IgZm9yIGFz c2lnbm1lbnQgdG8gZG93bnN0cmVhbSBsaW5rcyAoYXMgYSByb3V0ZXIgd291bGQpLCBpdCBzdGls bCBoYXMgdGhlDQo+ID4gc2FtZSBhcHBlYXJhbmNlIGZyb20gdGhlIG91dHNpZGUgd29ybGQuIFNv LCBmcm9tIHRoZSBvdXRzaWRlIHdvcmxkLCB0aGUgbm9kZQ0KPiA+IHdvdWxkIGFwcGVhciBhcyBh IG11bHRpLWFkZHJlc3NpbmcgaG9zdCBldmVuIGlmIGl0IGlzIGFjdGluZyBhcyBhIHJvdXRlciBv biBpdHMNCj4gPiBkb3duc3RyZWFtIGxpbmtzLiBUaGUgb25seSB0aW1lIGl0IHdvdWxkIGxvb2sg bGlrZSBhIHJvdXRlciBpcyBpZiBpdCBlbmdhZ2VkIGluIGENCj4gPiBkeW5hbWljIHJvdXRpbmcg cHJvdG9jb2wgb24gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIGl0IHJlY2VpdmVkIHRoZSBwcmVm aXguDQo+IA0KPiBJIGFncmVlLiAgSXQgd291bGQgbGlrZSBsaWtlIFJvdXRlciB0byB0aGUgb3V0 c2lkZSB3b3JsZCBpZiBpdCByYW4gYQ0KPiByb3V0aW5nIHByb3RvY29sIGFuZCBpZiBpdCBqb2lu ZWQgdGhlIEFsbC1Sb3V0ZXJzIG11bHRpY2FzdCBhZGRyZXNzLg0KDQpZZXMsIHlvdSBhcmUgcmln aHQuIFRoZXNlIHRoaW5ncyBtdXN0IG5vdCByZWNlaXZlIGFuZCByZXNwb25kIHRvIG11bHRpY2Fz dA0KUlNzIHNlbnQgYnkgaG9zdHMgb24gdGhlIGxpbmsgdGhhdCBhcmUgdHJ5aW5nIHRvIGNvbnRh Y3Qgcm91dGVycyB0aGF0IGFyZQ0KYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIGxpbmsuDQoNClRoYW5r cyAtIEZyZWQNCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4gQW55IHRob3VnaHRzPw0KPiA+DQo+ID4g VGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJRVRGIElQdjYgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPiBpcHY2QGlldGYub3JnDQo+ID4gQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg== From nobody Wed Jul 19 09:00:35 2017 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 449BD131686 for ; Wed, 19 Jul 2017 09:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbK8B5D-Sr_6 for ; Wed, 19 Jul 2017 09:00:31 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05F81317CA for <6man@ietf.org>; Wed, 19 Jul 2017 09:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500480029; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=5CxAZPH8I885xxVtZeAVKSs2NY/OCPLui4lHgL3wCh0=; b=Iy60pRpPVRfETJle+bSPbA2Ch8lM8/zY5vJ4F0OM8SFzipicHT+JH6oxYSwc3kg5MKJSXSAXgrfQ7gcniNmzJwrOnz8VBhK3p59AWjVROCYJ2ko1Rp0x29U3TF9fP/hkzXqbk9wNuVbsKj6TFgIcw+lGP6h8Ee8xWHu2K3DU3OU= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0143.outbound.protection.outlook.com [213.199.180.143]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-X2umePG8M_mRbeYkMaf6sA-1; Wed, 19 Jul 2017 17:00:24 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1108.eurprd07.prod.outlook.com (10.163.187.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 16:00:23 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 16:00:23 +0000 From: Tim Chown To: Fernando Gont CC: "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Topic: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Index: AQHS/9WLcUlWmq4/K0ml7V6v7zatO6Ja/D+AgAAhKwCAADMrAA== Date: Wed, 19 Jul 2017 16:00:23 +0000 Message-ID: References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> 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.3273) x-originating-ip: [2001:67c:370:128:6008:774b:6cf7:5e21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1108; 20:i6mhKl2ETAV7i+TAMxnX2a0A1hQstHrJHBvYhEMrNuT4TxMemh5XfstYrCqOP5IEsWFjFIRkA9x7qaIqpEPqKLjsEMdJArCLGgJVlWVpmuSa3PTVHDHq0fgXphveZCl+K83RUwfZ45AxBxx/YXaAeBjzoUmjxCWPiYceIFRXcVA= x-ms-office365-filtering-correlation-id: a6a21032-88bc-444b-a8ef-08d4cebf4393 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1108; x-ms-traffictypediagnostic: AM3PR07MB1108: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1108; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1108; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39840400002)(39410400002)(377454003)(24454002)(53546010)(6506006)(81166006)(6916009)(8676002)(8936002)(76176999)(50986999)(33656002)(2900100001)(3660700001)(72206003)(478600001)(36756003)(50226002)(4326008)(6436002)(561944003)(25786009)(305945005)(3280700002)(86362001)(82746002)(2906002)(230783001)(7736002)(14454004)(74482002)(6246003)(189998001)(6116002)(38730400002)(110136004)(102836003)(5660300001)(2950100002)(6486002)(42882006)(229853002)(6512007)(83716003)(57306001)(53936002)(99286003)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1108; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6F600026EBCBFC43845B974A4FCFF714@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 16:00:23.1826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1108 X-MC-Unique: X2umePG8M_mRbeYkMaf6sA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 16:00:34 -0000 PiBPbiAxOSBKdWwgMjAxNywgYXQgMTM6NTcsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNy8xOS8yMDE3IDAxOjU4IFBNLCBUaW0gQ2hvd24g d3JvdGU6DQo+Pj4gT24gMTggSnVsIDIwMTcsIGF0IDE1OjUyLCBGZXJuYW5kbyBHb250IDxmZ29u dEBzaTZuZXR3b3Jrcy5jb20+DQo+Pj4gd3JvdGU6DQo+Pj4gDQo+Pj4gRm9sa3MsDQo+Pj4gDQo+ Pj4gQW1vbmcgdGhlIGxpc3Qgb2YgUkZDcyB0byBiZSBwcm9ncmVzc2VkIHRvIGZ1bGwgc3RkIGlz L3dhcyBSRkM0OTQxIA0KPj4+ICgiUHJpdmFjeSBFeHRlbnNpb25zIGZvciBTdGF0ZWxlc3MgQWRk cmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbg0KPj4+IElQdjYiKS4NCj4+PiANCj4+PiBBcyBpdCBz dGFuZHMsIFJGQzQ5NDEgaGFzIGEgbnVtYmVyIG9mIGlzc3VlczoNCj4+PiANCj4+PiAqIFVzaW5n IHRoZSBzYW1lIElJRCBmb3IgbXVsdGlwbGUgcHJlZml4ZXMgKiBOb3QgY2hhbmdpbmcgdGhlIElJ RA0KPj4+IHVwb24gInNlY3VyaXR5IGV2ZW50cyIgKGluY2x1ZGluZyBlLmcuLCBjaGFuZ2UgaW4g dGhlIHVuZGVybHlpbmcNCj4+PiBNQUMgYWRkcmVzcykgKiBVc2luZyBNRDUgYXMgb3Bwb3NlZCB0 byBzb21ldGhpbmcgYmV0dGVyICogUmVxdWlyaW5nDQo+Pj4gdGhlIHVzZSBvZiB0ZW1wb3Jhcnkg YWRkcmVzc2VzIGFsb25nIHN0YWJsZSBhZGRyZXNzZXMgKHByZXZlbnRpbmcNCj4+PiB1c2Ugb2Yg dGVtcG9yYXJ5LW9ubHksIGZvciBub2RlcyB0aGF0IGZlZWwgbGlrZSkgKiBOb3QgdHJlYXRpbmcN Cj4+PiBJSURzIGFzIG9wYXF1ZSB2YWx1ZXMgKHNlZSBSRkM3MTM2KSAgd2hlbiBnZW5lcmF0aW5n IHRoZSByYW5kb21pemVkDQo+Pj4gSUlEcyAoc2VlIHN0ZXAgMyBpbiBzZWN0aW9uIDMuMi4xIG9m IFJGQzQ5NDEpICogTWFuZGF0aW5nIG9uZQ0KPj4+IHNwZWNpZmljIGFsZ29yaXRobSwgd2hlbiB0 aGUgc2FtZSBnb2Fscy9wcm9wZXJ0aWVzIGNhbiBiZSBhY2hpZXZlZA0KPj4+IHdpdGggbXVsdGlw bGUgYWxnb3JpdGhtcyAoc2VlIHNlY3Rpb24gNCBvZiANCj4+PiBkcmFmdC1nb250LTZtYW4tbm9u LXN0YWJsZS1paWRzLTAxKQ0KPj4+IA0KPj4+IA0KPj4+IEJhc2VkIG9uIHRoZSBhYm92ZSwgSSBw ZXJzb25hbGx5IGRvbid0IHRoaW5rIHRoYXQgaXQgd291bGQgbWFrZQ0KPj4+IHNlbnNlIHRvIHBy b2dyZXNzIFJGQzQ5NDEgdG8gSW50ZXJuZXQgU3RhbmRhcmQsIGJ1dCByYXRoZXIgdGhpbmsNCj4+ PiB0aGF0IHdlIHNob3VsZCB3b3JrIG9uICBhIHJlcGxhY2VtZW50IG9mIGl0IC0tIG91ciBwcm9w b3NhbCBiZWluZyANCj4+PiBkcmFmdC1nb250LTZtYW4tbm9uLXN0YWJsZS1paWRzLTAxLg0KPj4+ IA0KPj4+IFRob3VnaHRzPw0KPj4gDQo+PiBDZXJ0YWlubHkgYW55IHVwZGF0ZSBvbiA0OTQxIG5l ZWRzIHRvIGJlIGRvbmUgaW4gdGhlIGxpZ2h0IG9mIGEgZmV3DQo+PiBkZWZpY2llbmNpZXMgdGhh dCBoYXZlIGVtZXJnZWQgb3ZlciB0aGUgeWVhcnMsIGFuZCB0aGUgcHVibGljYXRpb24gb2YNCj4+ IFJGQzcyMTcuDQo+PiANCj4+IEkgdGhpbmsgaXTigJlzIHN0aWxsIHBvc3NpYmxlIHRvIGRvIGEg LWJpcyBvZmYgNDk0MS4NCj4gDQo+IE15IHF1ZXN0aW9ucyB3b3VsZCBiZToNCj4gDQo+IDEpIENh biB5b3UgYWN0dWFsbHkgYWRkcmVzcyB0aGUgYWZvcmVtZW50aW9uZWQgZGVmaWNpZW5jaWVzIHdp dGhvdXQNCj4gc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBSRkM0OTQxPyAtLSBJdCB3b3VsZCBzZWVt IHRvIG1lIHRoYXQgaW4gb3JkZXIgdG8NCj4gYWRkcmVzcyB0aGVtLCByZmM0OTQxYmlzIHdvdWxk IG5vdCBiZSBhIGJpcyBkb2N1bWVudCBhbnltb3JlLg0KPiANCj4gMikgSWYgeW91IHdlcmUgdG8g YWRkcmVzcyBzdWNoIGRlZmljaWVuY2llcywgY291bGQgdGhlIGJpcyBkb2N1bWVudCBiZQ0KPiBw cm9ncmVzc2VkIHRvIEludGVybmV0IFN0YW5kYXJkPyAtLSBNeSBhc3Nlc3NtZW50IG9mIHRoaXMg cXVlc3Rpb24gaXM6IE5vLg0KPiANCj4gSWYgUkZDNDk0MSB3b3VsZCB0YWtlIHNpZ25pZmljYW50 IHdvcmssIGFuZCB0aGUgZW5kIHJlc3VsdCB3b3VsZA0KPiBhY3R1YWxseSBiZSBzaWduaWZpY2Fu dGx5IGRpZmZlcmVudCBmcm9tIHdoYXQncyBpbiBSRkM0OTQxLCB0aGVuIEknbSBub3QNCj4gc3Vy ZSB0aGF0J2QgYmUgZGlmZmVyZW50IHRoYW4gc3RhcnRpbmcgZnJvbSB0aGUgSS1EIHdlIGFscmVh ZHkgaGF2ZS4uLg0KDQpKdXN0IHRvIGJlIGNsZWFyLCBJIGxpa2UgdGhlIG1hdGVyaWFsIGluIHlv dXIgbmV3IGRyYWZ0Lg0KDQpUaGF0IHNhaWQsIGl0IHNlZW1zIHlvdSBjb3VsZCBkbyBhIHNpbWls YXIgc3R5bGUgb2YgdXBkYXRlIGZyb20gMzA0MSB0byA0OTQxLCB3aXRoIGEgc2ltaWxhciBzdHJ1 Y3R1cmU7IHRoZSBjb250ZW50IGlzIHRoZXJlIGluIHlvdXIgZHJhZnQsIGl0IOKAnGp1c3QiIG5l ZWRzIHRvIGJlIG1lcmdlZCBpbi4NCg0KVGhhdCB3b3VsZCBtZWFuIG9ic29sZXRpbmcgNDk0MSwg anVzdCBhcyA0OTQxIG9ic29sZXRlZCAzMDQxLiAgU28geW91IHdvdWxkIGluY2x1ZGUgdGhlIGRl dGFpbHMgaW4gNDk0MSB0aGF0IHdvdWxkIGNhcnJ5IGZvcndhcmQuDQoNClRpbQ== From nobody Wed Jul 19 16:47:53 2017 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 AB5DC126CD6 for ; Wed, 19 Jul 2017 16:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 yd97YoKSF2xn for ; Wed, 19 Jul 2017 16:47:50 -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 E9CFD126BF3 for ; Wed, 19 Jul 2017 16:47:49 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id y126so6639100qke.4 for ; Wed, 19 Jul 2017 16:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=66BBhT8tgOwpOm95lflDRZ/PycTR0bqZEqWxwUGzNJc=; b=nOx3B/7cC0OXKs4qSf7eIohDPdTHGd1Yx/fVqWcHHMv8LKXgPAo4r8oINWNCBv7K2L 9h82dHJ+wyiaukhGXeI10FmnRRHjG5U7cWJmwbdCXNbKtuxSUkKDMpm6jCo1GAgiRssR iWe20JWpfMkNGU9KRvEmA+rH0eclsNRm61ppxrnCATEO9FJ+ccK6wGX+B8g9/GztLvq+ upTJNP6wiK5oiOb8T5GsQs5K6nJLx9y/t6cWOZKhaNZtoeWEFHym8f7vlbz6Z+FJn7lo HVQ0q8IMyHi43GrKMnXuPPDBAuAp2XD01e42kyoUhEQoSi1LxnxCg7OOOdWAoJha5pNi U5bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=66BBhT8tgOwpOm95lflDRZ/PycTR0bqZEqWxwUGzNJc=; b=EtTgj25EzZKaGimWXFCKO0OxRhXwUvPgTYodFChBOaosIkCPAe15yGiZXRRjhS6Uys 7v16XwyTTv3cb2RRRysx5cy0057SWj5bS8R6y0cGtjxaftbPQePT6VPUYxIEQH1GBfc+ mUtW8DEdNnkRdyj+Jmu8bZks2htR625swhcFT6ZCHaUa6Stwdr7d0jC4l1pNdaB5CXRc cI8XxaYUDddkbJFVoMERio2RGQvTjGvKftNoQXgwPUx22dGItG6HeOgemeKeVM9rfMHt b4Sssmdi2Ct379uXsZI097AG3rpJHVulSFXgNUrVWRGMidaRM+577BAeStu6h3BOmzCJ dWUQ== X-Gm-Message-State: AIVw110Vv3m3Oud0Xc8U65+cKGkiT6sFu97NFU7qSdlt/g399GHRnWLW aij7rn4NRWuQBuDLHPCGmLS2j4xdVA== X-Received: by 10.55.40.194 with SMTP id o63mr2322403qko.310.1500508068986; Wed, 19 Jul 2017 16:47:48 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Wed, 19 Jul 2017 16:47:48 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 19 Jul 2017 16:47:48 -0700 X-Google-Sender-Auth: 3r76CGmGfjNXbNPt7-9NOJackdA Message-ID: Subject: Re: To: David Farmer Cc: Lorenzo Colitti , IPv6 List , Bob Hinden Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 23:47:52 -0000 At Mon, 17 Jul 2017 16:42:23 -0500, David Farmer wrote: > So, I would propose the following for RFC4291bis; > > Several components of IPv6 are architecturally based on a requirement that > Interface Identifiers are 64 bit long except if the first three bits of the > address are 000. The rationale for using 64 bit Interface Identifiers can > be found in [RFC7421]. However, other components of IPv6 are > architecturally based > on Interface Identifiers of any length, most importantly Neighbor Discovery > [RFC4861]. Neither of these two architectures override or invalidate the > other. Accordingly, 64 bit Interface Identifiers are recommended for > operational use. I don't see how RFC4861 is related to IID. This seems to be based on the common confusion on the difference between on-link prefixes and address assignment prefixes (RFC4861 refers to "interface identifier" only in a handful of phrases, none of which seems to be relevant to this topic). But I guess you are one of the few people who actually understand this point quite well, so this is probably an editorial problem. Maybe you're trying to answer the question like the one Brian asked: "if we manually configure an IPv6 address and gets an RA PIO with L=1 and A=0 whose and the prefix length being 80 bits that (happens to) match the configured address, then what would we call the rightmost 48 bits of the address? Is it the 'interface identifier'"? I agree that's a valid question, but it's too subtle to explain by such a brief explanation like the above one. It's really subtle and if we want to answer the question in rfc4291bis, much verbose text will be necessary. But, even if we address this point, I don't see any possibility in making "64" a mere "recommendation" in the context rfc4291bis. Let's be realistic - it simply won't be accepted by one of the "camp"s that want to keep the current requirement on this point as much as possible. If the proposal only clarifies the question like the above one without trying to tweak the most contentious points, that may make sense and as a fan of clarity I might actually support it. But as I said above it will result in much more verbose text and it will have its own drawback - for example I thought Bob didn't want to talk about too much on how to generate addresses or refer to other specs that do not directly related to the addressing architecture (ND, SLAAC, DHCPv6 etc). So, to me, the time for tweaking the text is over. IMO we should now just see if we can form a rough consensus on some basic point (e.g., explicitly excluding the manually configured addresses for the 64-bit requirement) and move on or drop the effort. The result will still leave questions (such as the above one) and contain some awkward content (like the listed exceptions in the architecture), and I'd be sad about that, but that's probably an inconvenient truth when what's needed to make progress is compromise rather than technical purity. -- JINMEI, Tatuya From nobody Wed Jul 19 19:01:36 2017 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 7365D12EACC for ; Wed, 19 Jul 2017 19:01:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 K09Lgvp3bWQ2 for ; Wed, 19 Jul 2017 19:01:34 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 28BF2126C2F for ; Wed, 19 Jul 2017 19:01:34 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id s70so6547618pfs.0 for ; Wed, 19 Jul 2017 19:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3yce3H/0p+2WzUHx/4Jk5kxq06bRfZw3iLqc16mSxDk=; b=SodDkUyZLHxsAXQ9VWDsEpaLJgDdkvPwC/kaQpCQmtJdO2xKGrzs4Bgj6AHY0FUGLj uQ8uB4nefS0FSwrHGZxFHQ2TKaqC7L6TWWf6lw7cZVJYj/bscYm0ot4Zcvf4Txzz1ez5 ne028FDxUvCx6sa8+8vDHwsJ9zNh7IJfYp3NkaMJTWEGZIlMWNT56VN2QhN0BCi/Pa0H o8T7SKeL9PSqikTewZGJ5UJ89sacqjh7Z/hhIE7UhQDPxdOLjeRfCfRtXUruZ9iGbCzD SmpFMjjQonyx3ZktN/hjXmFonDiNFXz//Ipq4gusyp7wmuf5KCkw472MLTiepgtalyel ta3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3yce3H/0p+2WzUHx/4Jk5kxq06bRfZw3iLqc16mSxDk=; b=ApQ4mVSHjjymayr17V25nhw6kNasJRDhRfFYakSCq5tTO0saPvjYJ27G3R2xP8NOlE 5DTLULuGmW2M2+DfRIvn+Gjx+1H9qW1HJ70kwxpBVClf8vMaNmcVpmD8gju5/Phhh8eT FI+hgwcBO6TT6PwOEBN+07eQTH1NcUrYVf5r1fgNH4tTsXvuQHwaNNzIx+wR4fTk0rzd HcLq0lXJywbtZqsh6yY8UrRpbS+Taees6KtCd2Ov7Iz5nOFZ7iBnU9qnwE7klLByBEs1 bLCsO1YI3fxOmIQzqyC8A1ED2B4R3sWy3EOv9zWFCSehtcfb7ijaoodSvoGddNsRdtE8 fAHA== X-Gm-Message-State: AIVw110xZ6MV/HifIiMxnGDJDY9+uhkJlKxChi16gQ/jDLgyt3yHfDbz VcY+NfOxVgrP/vLd X-Received: by 10.99.44.138 with SMTP id s132mr2145053pgs.318.1500516093628; Wed, 19 Jul 2017 19:01:33 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 85sm1732444pfr.90.2017.07.19.19.01.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 19:01:33 -0700 (PDT) Subject: Re: To: Nick Hilliard , David Farmer Cc: Bob Hinden , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Jul 2017 14:01:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <596F63F4.9010501@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 02:01:35 -0000 On 20/07/2017 01:51, Nick Hilliard wrote: > David Farmer wrote: >> 2. The fact that some components of IPv6 are architecturally based on >> 64bit IIDs doesn't mean that operationally IIDs are always required to >> be 64 bits. > > this is certainly implied by the current text in -09. > >> Rather than implying that operationally IID are required to >> be 64bits, how about simply stating that operationally 64 bit IIDs are >> recommended. This eliminates the need to enumerate all the exceptions, >> which probably isn't something an architectural document should be doing. > > This would be a good way of dealing with this issue and you're correct > to state that enumerating exceptions is something that ought to be > avoided in architectural documents. But what is needed is clarity in definitions, which is why I've been asking what the low order bits in an IPv6 address are called in cases where people claim they are not called an IID. (My answer fwiw is that they are always called an IID, because once you're on the final link, those bits serve only to deliver the packet to the intended interface, so they must uniquely identify that interface.) Brian Brian From nobody Wed Jul 19 19:14:23 2017 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 9121312EC3B for ; Wed, 19 Jul 2017 19:14:22 -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 fPqsvIlBtFe3 for ; Wed, 19 Jul 2017 19:14:21 -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 E4B4B126C2F for ; Wed, 19 Jul 2017 19:14:20 -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 v6K2EJKj039679; Wed, 19 Jul 2017 19:14:19 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6K2EDhY039667 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 19:14:13 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 19:14:12 -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.1263.000; Wed, 19 Jul 2017 19:14:12 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHTAJYqd3esQDb6ikC6XZkOC9tAJKJcbGeA//+LAwA= Date: Thu, 20 Jul 2017 02:14:11 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 02:14:22 -0000 From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > But what is needed is clarity in definitions, which is why > I've been asking what the low order bits in an IPv6 address > are called in cases where people claim they are not called an > IID. > > (My answer fwiw is that they are always called an IID, because > once you're on the final link, those bits serve only to deliver > the packet to the intended interface, so they must uniquely > identify that interface.) That's certainly my answer too. But more to the point, I don't understand w= hat other answer could be valid, or said another way, why ask the question? RFC 4291 wasn't ambiguous about this, was it? | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ That isn't limited to 64 bits? It 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. We've been over the broadening of the exceptions in 4291-bis, but even as w= ritten, the IID isn't constrained to being just 64 bits. Bert From nobody Wed Jul 19 19:37:34 2017 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 CC2B112741D for ; Wed, 19 Jul 2017 19:37:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VvLAvOh4hb4N for ; Wed, 19 Jul 2017 19:37:31 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 6AB0F126C2F for ; Wed, 19 Jul 2017 19:37:31 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id q85so6820765pfq.1 for ; Wed, 19 Jul 2017 19:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4a7UzDEYkSpvRlqHGEzcYft/hLS1VBcYJDiXIC0zy2k=; b=CjRnpsktzE5LK0V8B3jYQXZeF8ypiex5jtWUkQL/fevGpSnfHaGx5ETlnjQL6JzNvA aVtsrPIrS8S/pbqb7VCia8GX7lcUxu81k9EMzNaRxRzH4g94m1oMA0KFbq3cgcU5oehS T2i8kJZkKEM2+XJyAduYHwpblaUn81VV5RGPe2EzHSVP9/dXFI7pUARfiKzmW5yHIsOZ XrgtJt5ufkoaWlU8bZsMi20CUhBD+AuO22MUaUqo42x4W6XGDDkkof9L98z3hWojcIJ2 P113TtawP1QhcbF13HhTLR7mJtombrRpEzo27TBu8AAucpC+wnKTDgR6mZ0hOuLtdALN XtNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4a7UzDEYkSpvRlqHGEzcYft/hLS1VBcYJDiXIC0zy2k=; b=X8ZGxNnelUDj5Oky2+oiPwwhg/jlce3otyDEHviXvbQT8WndQkTvSvFo4u0Hs3q6OK 8uk6dG5KKJj2hJuN2SUIQLcRdajYfIPxdnNgm3J2VUeWXiPWJu7qlWB95jCPbUjziirO YJ2MIuIRufequfQYBP9dSHlXqorJVb6j23KpAX0wUtFpF4SlkE2wIht6IjFjlrrY4xOW f8Lr5RXTSDyWEJ0A+ExM5q0bJOHSeyIMcZP9AwiK85EVrgp1mXF57gYxgR16SxQ4G3Av Ar3/qyBIxScQJPCkScHk9Le8Gfy+VPaADwE2Q9v+/b2qoOXDRhDq1e70K9pDwS+doArb CkXw== X-Gm-Message-State: AIVw113t/rvmlaVYD6JrJWbNOG8oBmNvvR3WF6xk+hAHNDqpTV3QlMoi ajSkQiashCnbji2N X-Received: by 10.99.97.209 with SMTP id v200mr2218482pgb.346.1500518250649; Wed, 19 Jul 2017 19:37:30 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n80sm1819347pfj.118.2017.07.19.19.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 19:37:29 -0700 (PDT) Subject: Re: Prefix Delegation and hosts To: "Templin, Fred L" , "ipv6@ietf.org" References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> Date: Thu, 20 Jul 2017 14:37:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 02:37:33 -0000 On 19/07/2017 22:26, Templin, Fred L wrote: > Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router. > Recent discussions and drafts have suggested that the "Requesting Router" could be a > simple host that receives a Prefix Delegation (of whatever prefix length) for its own > multi-addressing purposes. Meaning, that the host configures addresses from the > prefix and assigns them, e.g., to a loopback interface so that its local applications can > each use a different address if desired. > > But, whether the node uses the delegated prefix for multi-addressing (as a host > would) or for assignment to downstream links (as a router would), it still has the > same appearance from the outside world. So, from the outside world, the node > would appear as a multi-addressing host even if it is acting as a router on its > downstream links. The only time it would look like a router is if it engaged in a > dynamic routing protocol on the interface over which it received the prefix. Formally, a router is "a node that forwards IPv6 packets not explicitly addressed to itself. (See Note below.)" [RFC8200]. I recommend reading the note as well. But what it amounts to is: it's no business of the delegating router what the requesting router chooses to do with the delegated prefix, as long as it obeys RFC8200. If it gets a /64 and and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody upstream will know (or care). Of course, SLAAC won't work for the friends, but nobody upstream will know that either. (It should be a small matter of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that will show up in running code sometime.) Brian From nobody Wed Jul 19 19:40:54 2017 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 372FD12741D for ; Wed, 19 Jul 2017 19:40:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4zPRQ5qwzlbG for ; Wed, 19 Jul 2017 19:40:51 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3805126C2F for ; Wed, 19 Jul 2017 19:40:51 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 123so8176602pgj.1 for ; Wed, 19 Jul 2017 19:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rufLypdSwcu58GyvdbAgE3ijmX4dGjxCm3/XaKbSEf8=; b=NBZ9lQ571elsml/6v7mfCkYWzUr8dZ3Fy1HYNrRrei/aqV8oqBz8T6T2QdgxsGGYyT lD/QNX8tb1Q2djeu4rXnW87QKWg4PVsgIz4IvbdlvWbQXzW2xaItFXCM32kOnqye+vPB cdPzUxTol6pxyiH43RsQ/vzq1ekqLfQ6rb517TVixP7NLSVt0DgetKVzBGMMW3dIGhkf TyrYq43yANF/MMSXyXe9izCPHypjN34T+V+zKzYiNrYOrPjvfXb4oriRqO/a0iLz6wz2 6bJaweD2ijBs6i8thvTIJ9cT/RorK6Hq2HduNxgugJzzmp0WSzg+D7b36kcXARjuZ1vH GN3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rufLypdSwcu58GyvdbAgE3ijmX4dGjxCm3/XaKbSEf8=; b=cUJbheaYiawkjbdkOUsmcQ7bSvRP0ltvd63Zv6nPrNYQsrVkWl4kBoIueMwWumKKav SNU4K3tmxu3ph49qrTc81WzUYSIbUnkzU9fPZhVIX7/rW7y+4ogD+ix3ovWpGtZQ2DFm eMR0JrUxyNNw13i5201tCTvTX2G0vKfMTwn2GegII4YwjX3TKnkxODTXgPMSmUU77dbY KglosO8CRLtVqal1h3+FthatJITpe9yEJFIKuC248D4u9t4X5tXK1oOc3bjgBP8Dy0Zj 3JcY7ZicLMX3SSyxwI97NJFugGG9tS9zWUa58mPk4xddqht8sXeI0Ix+afo8u2i+zsGs VPdQ== X-Gm-Message-State: AIVw113SxbB7gM3/bVgdXhPRDXw6i/8VDkwpGsoWwe6HY6U2j9kXYtnL PSC84NIz1H7vSYcY X-Received: by 10.98.15.143 with SMTP id 15mr2210314pfp.203.1500518451139; Wed, 19 Jul 2017 19:40:51 -0700 (PDT) Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u184sm1807382pfb.37.2017.07.19.19.40.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 19:40:50 -0700 (PDT) Subject: Re: To: "Manfredi, Albert E" Cc: IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> Date: Thu, 20 Jul 2017 14:40:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 02:40:53 -0000 On 20/07/2017 14:14, Manfredi, Albert E wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >> But what is needed is clarity in definitions, which is why >> I've been asking what the low order bits in an IPv6 address >> are called in cases where people claim they are not called an >> IID. >> >> (My answer fwiw is that they are always called an IID, because >> once you're on the final link, those bits serve only to deliver >> the packet to the intended interface, so they must uniquely >> identify that interface.) > > That's certainly my answer too. But more to the point, I don't understand what other answer could be valid, or said another way, why ask the question? a) Because of the several subtly different meanings of 'prefix' in IPv6. b) Because some people seem to be limiting their use of 'IID' to the SLAAC meaning of 'prefix'. Brian > > RFC 4291 wasn't ambiguous about this, was it? > > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ > > That isn't limited to 64 bits? It 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. > > We've been over the broadening of the exceptions in 4291-bis, but even as written, the IID isn't constrained to being just 64 bits. > > Bert > > > From nobody Wed Jul 19 20:36:26 2017 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 3E6E7127010 for ; Wed, 19 Jul 2017 20:36:26 -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 mkzSHABKkQmf for ; Wed, 19 Jul 2017 20:36:25 -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 EC0E1126C23 for ; Wed, 19 Jul 2017 20:36:24 -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 v6K3aOD4055753; Wed, 19 Jul 2017 20:36:24 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6K3aNPI055742 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Jul 2017 20:36:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 20:36:22 -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.1263.000; Wed, 19 Jul 2017 20:36:22 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHTAJYqd3esQDb6ikC6XZkOC9tAJKJcbGeA//+LAwCAAH/4gP//kxnA Date: Thu, 20 Jul 2017 03:36:21 +0000 Message-ID: <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> In-Reply-To: <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 03:36:26 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAx OSwgMjAxNyAyMjo0MQ0KDQo+PiB3aHkgYXNrIHRoZSBxdWVzdGlvbj8NCj4NCj4gYSkgQmVjYXVz ZSBvZiB0aGUgc2V2ZXJhbCBzdWJ0bHkgZGlmZmVyZW50IG1lYW5pbmdzIG9mICdwcmVmaXgnIGlu IElQdjYuDQoNClNvbWUgcHJlZml4ZXMgY2FuIGJlIG9uLWxpbmssIHdoaWxlIG90aGVycyBhcmUg bm90LiBPa2F5LCBidXQgdGhpcyBpcyBhIHF1ZXN0aW9uIG9mIGFkZHJlc3MgYXJjaGl0ZWN0dXJl LCBhbmQgd2hhdGV2ZXIgcHJlZml4IGJpdHMgZXhpc3QgaW4gdGhhdCAxMjgtYml0IGFkZHJlc3Ms IHRoZSByZW1haW5pbmcgYml0cyBhcmUgYnkgZGVmaW5pdGlvbiBJSUQuDQoNCg0KICAgfCAgICAg ICAgICBuIGJpdHMgICAgICAgICAgICAgICB8ICAgICAgICAgICAxMjgtbiBiaXRzICAgICAgICAg ICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgICAgICBzdWJuZXQgcHJlZml4ICAgICAgICAgICB8 ICAgICAgICAgICBpbnRlcmZhY2UgSUQgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQo+IGIp IEJlY2F1c2Ugc29tZSBwZW9wbGUgc2VlbSB0byBiZSBsaW1pdGluZyB0aGVpciB1c2Ugb2YgJ0lJ RCcgdG8gdGhlIFNMQUFDDQo+IG1lYW5pbmcgb2YgJ3ByZWZpeCcuDQoNCkkgc2VlIG9ubHkgYSBz bWFsbCBhbWJpZ3VpdHkgaW4gdGhpcyByZWdhcmQuIEZyb20gUkZDIDQ4NjI6DQoNCiAgIGludGVy ZmFjZSBpZGVudGlmaWVyIC0gIGEgbGluay1kZXBlbmRlbnQgaWRlbnRpZmllciBmb3IgYW4gaW50 ZXJmYWNlDQogICAgICB0aGF0IGlzIChhdCBsZWFzdCkgdW5pcXVlIHBlciBsaW5rIFtSRkM0Mjkx XS4gIFN0YXRlbGVzcyBhZGRyZXNzDQogICAgICBhdXRvY29uZmlndXJhdGlvbiBjb21iaW5lcyBh biBpbnRlcmZhY2UgaWRlbnRpZmllciB3aXRoIGEgcHJlZml4DQogICAgICB0byBmb3JtIGFuIGFk ZHJlc3MuICBGcm9tIGFkZHJlc3MgYXV0b2NvbmZpZ3VyYXRpb24ncyBwZXJzcGVjdGl2ZSwNCiAg ICAgIGFuIGludGVyZmFjZSBpZGVudGlmaWVyIGlzIGEgYml0IHN0cmluZyBvZiBrbm93biBsZW5n dGguICBUaGUNCiAgICAgIGV4YWN0IGxlbmd0aCBvZiBhbiBpbnRlcmZhY2UgaWRlbnRpZmllciBh bmQgdGhlIHdheSBpdCBpcyBjcmVhdGVkDQogICAgICBpcyBkZWZpbmVkIGluIGEgc2VwYXJhdGUg bGluay10eXBlIHNwZWNpZmljIGRvY3VtZW50IHRoYXQgY292ZXJzDQogICAgICBpc3N1ZXMgcmVs YXRlZCB0byB0aGUgdHJhbnNtaXNzaW9uIG9mIElQIG92ZXIgYSBwYXJ0aWN1bGFyIGxpbmsNCiAg ICAgIHR5cGUgKGUuZy4sIFtSRkMyNDY0XSkuICBOb3RlIHRoYXQgdGhlIGFkZHJlc3MgYXJjaGl0 ZWN0dXJlDQogICAgICBbUkZDNDI5MV0gYWxzbyBkZWZpbmVzIHRoZSBsZW5ndGggb2YgdGhlIGlu dGVyZmFjZSBpZGVudGlmaWVycyBmb3INCiAgICAgIHNvbWUgc2V0IG9mIGFkZHJlc3NlcywgYnV0 IHRoZSB0d28gc2V0cyBvZiBkZWZpbml0aW9ucyBtdXN0IGJlDQogICAgICBjb25zaXN0ZW50LiAg SW4gbWFueSBjYXNlcywgdGhlIGlkZW50aWZpZXIgd2lsbCBiZSBkZXJpdmVkIGZyb20NCiAgICAg IHRoZSBpbnRlcmZhY2UncyBsaW5rLWxheWVyIGFkZHJlc3MuDQoNClRoaXMgZGVmaW5pdGlvbiBk b2VzIG5vdCBsaW1pdCB0aGUgSUlEIHRvIDY0IGJpdHMgZWl0aGVyLCBnaXZpbmcgUkZDIDI0NjQg b25seSBhcyBhbiBleGFtcGxlLCBhbmQgc2F5aW5nIG9ubHkgdGhhdCAiaW4gbWFueSBjYXNlcywi IHRoZSBJSUQgaXMgZGVyaXZlZCBmcm9tIHRoZSBsaW5rIGxheWVyIGFkZHJlc3MuIFdpdGhvdXQg c3BlY2lmeWluZyBob3cgbG9uZyB0aGF0IG1pZ2h0IGJlLiBBbmQgaXQgcmVmZXJzIGJhY2sgdG8g UkZDIDQyOTEsIHdoaWNoIGRvZXMgbm90IGxpbWl0IElJRCB0byA2NCBiaXRzLg0KDQpUaGUgYW1i aWd1aXR5IGlzIHRoaXM6DQoNCiAgICAgIGEgbGluay1kZXBlbmRlbnQgaWRlbnRpZmllciBmb3Ig YW4gaW50ZXJmYWNlDQogICAgICB0aGF0IGlzIChhdCBsZWFzdCkgdW5pcXVlIHBlciBsaW5rIFtS RkM0MjkxXS4NCg0KSU1PLCB0aGF0IHNob3VsZCBub3cgYmUgc3RhdGVkIGFzICJ1bmlxdWUgcGVy IHN1Ym5ldCBwcmVmaXgsIiBhcyBjbGVhcmx5IHN0YXRlZCBpbiAyLjUuMSBvZiBSRkMgNDI5MS4g SSB0aGluayB3ZSBtZW50aW9uZWQgdGhpcyBpbiBkaXNjdXNzaW9uIHJlY2VudGx5LiBTdGlsbCwg dGhpcyBkb2Vzbid0IGNoYW5nZSB0aGUgbWFpbiBwb2ludCwgdGhhdCBJSURzIHNob3VsZCBub3Qg YmUgY29uc3RyYWluZWQgdG8gYWx3YXlzIDY0IGJpdHMsIHVubGVzcyBmb3JtZWQgdXNpbmcgU0xB QUMsIGFzIGEgc2VsZi1pbXBvc2VkLCBhcnRpZmljaWFsIGxpbWl0YXRpb24uIChXaGljaCBhcyB5 b3UgcG9pbnRlZCBvdXQsIHNvbWUgY2xldmVyIGhhY2sgY2FuIGNoYW5nZSBpbiBkdWUgY291cnNl LikNCg0KQmVydA0KDQo= From nobody Thu Jul 20 01:21:34 2017 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 2479312FB9C for ; Thu, 20 Jul 2017 01:21:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fici7QZvYa5M for ; Thu, 20 Jul 2017 01:21:27 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::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 0F9B1129AA0 for <6man@ietf.org>; Thu, 20 Jul 2017 01:21:27 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id 12so1751121wrb.4 for <6man@ietf.org>; Thu, 20 Jul 2017 01:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Dte6P3G57MVZe8ScNka0VMQ7dJTqreGJURshtgGb7iM=; b=lXEvy0Xakl1T2oOWbyAWa71LMbB/qGwTScH8XLCcZUOD20Z2hCdSuOma80Ac2j3ja2 XQrPnF4JwYCMMAbLyqa9sfUtzeE3swFnr2vwaVhrGSfiuBrRB5M65rHnODew66GpHtlx gcFnWE6T5Q2s6bKKlXksb+kLpsRhetqUKZOQqNk22SsFZJBNQmOBom8Akw3jMYUSlOnA PqmcEvfAnVKVjSHhxE9P5NTzNanIsqJhtiyOwBA4P5kIQfyN3Y8Rjpt8qVlS4FMI7v6r 0NVnb5zGEYwZsPaEVQPAv/DsVpHcXl/CBQlPLTY7+AMCtX5+IkeV12QQlQ24Ku230idS T9Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Dte6P3G57MVZe8ScNka0VMQ7dJTqreGJURshtgGb7iM=; b=bHE91neITkBfzHtDwYP1NwHN8tyMmPvFun8GO+zaDz72bGBW30kKhWghsh/dmc6OC/ 4TVM1XNrtNTpsrqzaIDXw7EWwYjxDhQhM8LJJ1WYbQGC9oNn1fJqQYwTke6TCz8c4guR TyFguEP6dcRkMcWU7W2NoZIfIUuaBrjUNaDQZntHemg390btCM4KCglyQmjyoO36Oxus wfvrAecXBcU5eGQTPbsXixEOhY6W6L/PoHeMCCK4X8w+qJL9giJUid2KNuFCRGjH9PjO 9N+/ZgTj84GcB6C6N0aLuHQXJa+R/ReInMPUbqj8kpsf3c9JNw4q31PS41qfLrOvkG4F FxVA== X-Gm-Message-State: AIVw113V8g5ATRR5QUfwY7vr8bX7aBy41G7s9qe2w5dH2wyk9osyY/2q c9B+lRM3IZdD0Q== X-Received: by 10.223.171.3 with SMTP id q3mr6181833wrc.12.1500538885544; Thu, 20 Jul 2017 01:21:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:e55e:d3be:d288:1bd4? ([2001:67c:370:128:e55e:d3be:d288:1bd4]) by smtp.gmail.com with ESMTPSA id w136sm1338475wmd.45.2017.07.20.01.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 01:21:25 -0700 (PDT) From: Suresh Krishnan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2F4A7A4F-B0BD-48AB-8866-F0F3D11EE065" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids Date: Thu, 20 Jul 2017 10:21:23 +0200 In-Reply-To: Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org> To: Tim Chown References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:21:29 -0000 --Apple-Mail=_2F4A7A4F-B0BD-48AB-8866-F0F3D11EE065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tim, > On Jul 19, 2017, at 6:00 PM, Tim Chown wrote: >=20 >> On 19 Jul 2017, at 13:57, Fernando Gont = wrote: >>=20 >> On 07/19/2017 01:58 PM, Tim Chown wrote: >>>> On 18 Jul 2017, at 15:52, Fernando Gont >>>> wrote: >>>>=20 >>>> Folks, >>>>=20 >>>> Among the list of RFCs to be progressed to full std is/was RFC4941=20= >>>> ("Privacy Extensions for Stateless Address Autoconfiguration in >>>> IPv6"). >>>>=20 >>>> As it stands, RFC4941 has a number of issues: >>>>=20 >>>> * Using the same IID for multiple prefixes * Not changing the IID >>>> upon "security events" (including e.g., change in the underlying >>>> MAC address) * Using MD5 as opposed to something better * Requiring >>>> the use of temporary addresses along stable addresses (preventing >>>> use of temporary-only, for nodes that feel like) * Not treating >>>> IIDs as opaque values (see RFC7136) when generating the randomized >>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one >>>> specific algorithm, when the same goals/properties can be achieved >>>> with multiple algorithms (see section 4 of=20 >>>> draft-gont-6man-non-stable-iids-01) >>>>=20 >>>>=20 >>>> Based on the above, I personally don't think that it would make >>>> sense to progress RFC4941 to Internet Standard, but rather think >>>> that we should work on a replacement of it -- our proposal being=20= >>>> draft-gont-6man-non-stable-iids-01. >>>>=20 >>>> Thoughts? >>>=20 >>> Certainly any update on 4941 needs to be done in the light of a few >>> deficiencies that have emerged over the years, and the publication = of >>> RFC7217. >>>=20 >>> I think it=E2=80=99s still possible to do a -bis off 4941. >>=20 >> My questions would be: >>=20 >> 1) Can you actually address the aforementioned deficiencies without >> significant changes to RFC4941? -- It would seem to me that in order = to >> address them, rfc4941bis would not be a bis document anymore. >>=20 >> 2) If you were to address such deficiencies, could the bis document = be >> progressed to Internet Standard? -- My assessment of this question = is: No. >>=20 >> If RFC4941 would take significant work, and the end result would >> actually be significantly different from what's in RFC4941, then I'm = not >> sure that'd be different than starting from the I-D we already = have... >=20 > Just to be clear, I like the material in your new draft. >=20 > That said, it seems you could do a similar style of update from 3041 = to 4941, with a similar structure; the content is there in your draft, = it =E2=80=9Cjust" needs to be merged in. >=20 > That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you = would include the details in 4941 that would carry forward. . I agree. If we are planning a drop in replacement to = RFC4941 creating a bis document from there is the right thing to do. Thanks Suresh --Apple-Mail=_2F4A7A4F-B0BD-48AB-8866-F0F3D11EE065 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tim,

On Jul 19, 2017, at 6:00 PM, = Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

On 19 Jul 2017, at 13:57, = Fernando Gont <fgont@si6networks.com> wrote:

On 07/19/2017 01:58 PM, Tim Chown wrote:
On 18 Jul 2017, at 15:52, Fernando Gont <fgont@si6networks.com>
wrote:

Folks,

Among the = list of RFCs to be progressed to full std is/was RFC4941 
("Privacy = Extensions for Stateless Address Autoconfiguration in
IPv6").

As it stands, RFC4941 = has a number of issues:

* Using the same = IID for multiple prefixes * Not changing the IID
upon = "security events" (including e.g., change in the underlying
MAC address) * Using MD5 as opposed to something better * = Requiring
the use of temporary addresses along stable = addresses (preventing
use of temporary-only, for nodes = that feel like) * Not treating
IIDs as opaque values (see = RFC7136)  when generating the randomized
IIDs (see = step 3 in section 3.2.1 of RFC4941) * Mandating one
specific= algorithm, when the same goals/properties can be achieved
with multiple algorithms (see section 4 of 
draft-gont-6man-non-stable-iids-01)


Based on the above, I personally don't think = that it would make
sense to progress RFC4941 to Internet = Standard, but rather think
that we should work on  a = replacement of it -- our proposal being 
draft-gont-6man-non-stable-iids-01.

Thoughts?

Certainly = any update on 4941 needs to be done in the light of a few
deficiencies that have emerged over the years, and the = publication of
RFC7217.

I = think it=E2=80=99s still possible to do a -bis off 4941.

My questions would be:

1) Can you actually address the aforementioned = deficiencies without
significant changes to RFC4941? -- It = would seem to me that in order to
address them, rfc4941bis = would not be a bis document anymore.

2) If = you were to address such deficiencies, could the bis document be
progressed to Internet Standard? -- My assessment of this = question is: No.

If RFC4941 would take = significant work, and the end result would
actually be = significantly different from what's in RFC4941, then I'm not
sure that'd be different than starting from the I-D we = already have...

Just to be clear, I like the = material in your new draft.

That said, it seems you could do a similar style = of update from 3041 to 4941, with a similar structure; the content is = there in your draft, it =E2=80=9Cjust" needs to be merged in.
That would mean obsoleting 4941, just as 4941 = obsoleted 3041.  So you would include the details in 4941 that = would carry forward.

<AD= hat off>. I agree. If we are planning a drop in replacement to = RFC4941 creating a bis document from there is the right thing to = do.

Thanks
Suresh

= --Apple-Mail=_2F4A7A4F-B0BD-48AB-8866-F0F3D11EE065-- From nobody Thu Jul 20 04:03:29 2017 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 2AA5E131687 for ; Thu, 20 Jul 2017 04:03:28 -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 3Ids-4tnx8Bc for ; Thu, 20 Jul 2017 04:03:25 -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 4B1A7129AD1 for <6man@ietf.org>; Thu, 20 Jul 2017 04:03:24 -0700 (PDT) Received: from [192.168.0.25] (unknown [46.13.174.201]) (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 5A1FD80D4D; Thu, 20 Jul 2017 13:04:49 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Suresh Krishnan , Tim Chown Cc: "6man@ietf.org" <6man@ietf.org> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> From: Fernando Gont Message-ID: <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> Date: Thu, 20 Jul 2017 14:03:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:03:28 -0000 On 07/20/2017 11:21 AM, Suresh Krishnan wrote: > Hi Tim, > >> On Jul 19, 2017, at 6:00 PM, Tim Chown > > wrote: >> >>> On 19 Jul 2017, at 13:57, Fernando Gont >> > wrote: >>> >>> On 07/19/2017 01:58 PM, Tim Chown wrote: >>>>> On 18 Jul 2017, at 15:52, Fernando Gont >>>> > >>>>> wrote: >>>>> >>>>> Folks, >>>>> >>>>> Among the list of RFCs to be progressed to full std is/was RFC4941 >>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in >>>>> IPv6"). >>>>> >>>>> As it stands, RFC4941 has a number of issues: >>>>> >>>>> * Using the same IID for multiple prefixes * Not changing the IID >>>>> upon "security events" (including e.g., change in the underlying >>>>> MAC address) * Using MD5 as opposed to something better * Requiring >>>>> the use of temporary addresses along stable addresses (preventing >>>>> use of temporary-only, for nodes that feel like) * Not treating >>>>> IIDs as opaque values (see RFC7136) when generating the randomized >>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one >>>>> specific algorithm, when the same goals/properties can be achieved >>>>> with multiple algorithms (see section 4 of >>>>> draft-gont-6man-non-stable-iids-01) >>>>> >>>>> >>>>> Based on the above, I personally don't think that it would make >>>>> sense to progress RFC4941 to Internet Standard, but rather think >>>>> that we should work on a replacement of it -- our proposal being >>>>> draft-gont-6man-non-stable-iids-01. >>>>> >>>>> Thoughts? >>>> >>>> Certainly any update on 4941 needs to be done in the light of a few >>>> deficiencies that have emerged over the years, and the publication of >>>> RFC7217. >>>> >>>> I think it’s still possible to do a -bis off 4941. >>> >>> My questions would be: >>> >>> 1) Can you actually address the aforementioned deficiencies without >>> significant changes to RFC4941? -- It would seem to me that in order to >>> address them, rfc4941bis would not be a bis document anymore. >>> >>> 2) If you were to address such deficiencies, could the bis document be >>> progressed to Internet Standard? -- My assessment of this question >>> is: No. >>> >>> If RFC4941 would take significant work, and the end result would >>> actually be significantly different from what's in RFC4941, then I'm not >>> sure that'd be different than starting from the I-D we already have... >> >> Just to be clear, I like the material in your new draft. >> >> That said, it seems you could do a similar style of update from 3041 >> to 4941, with a similar structure; the content is there in your draft, >> it “just" needs to be merged in. >> >> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you >> would include the details in 4941 that would carry forward. > > . I agree. If we are planning a drop in replacement to > RFC4941 creating a bis document from there is the right thing to do. Can you explain your rationale? (along with answering the two questions I posed to Tim). RFC4941 can be summarized as consisting of two parts: 1) A discussion of privacy implications of Identifiers, and of IIDs in particular 2) Specification of an algorithm to generate the IID "1)" was much needed when RFC3041 was published, and then carried to RFC4941 (when it was probably still needed). Nowadays, the security and privacy properties of IPv6 addresses are discussed more thoroughly (and in more dimensions) in RFC7721. And the discussion of identifiers in documents such as RFC6973 and draft-gont-predictable-numeric-ids (besides the fact that one can always refer back to RFC3041 or even RFC4941 for such discussion, in the same way we referenced RFC3041 in RFC7721). When it comes to "2)", if you really want to address the issues found in RFC4941, essentially you need to replace the algorithm with something else. One may tweak a few things here and there (e.g., the update we propose in our I-D), but still there are drawbacks in RFC4941 that cannot be addressed without fundamentally changing the algorithm (for instance, RFC4941 has notable drawbacks when compared to simply generating the IID as a random number that is not tied to previously selected IIDs). If one were to do rfc4941bis, such document could not be progressed to STD. And since there are better and/or alternative approaches for generating temporary addresses, I'm not sure what would be the benefit here. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 20 04:16:11 2017 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 88A1712EAF0 for ; Thu, 20 Jul 2017 04:16:09 -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 GJZvaEzdwuIZ for ; Thu, 20 Jul 2017 04:16:08 -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 DF59E131687 for <6man@ietf.org>; Thu, 20 Jul 2017 04:16:01 -0700 (PDT) Received: from [192.168.0.25] (unknown [46.13.174.201]) (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 03C2D80D4E; Thu, 20 Jul 2017 13:17:30 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Francis Dupont Cc: "6man@ietf.org" <6man@ietf.org> References: <201707191117.v6JBH9nN037512@givry.fdupont.fr> From: Fernando Gont Message-ID: Date: Thu, 20 Jul 2017 14:16:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201707191117.v6JBH9nN037512@givry.fdupont.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:16:10 -0000 Hello, Francis, On 07/19/2017 02:17 PM, Francis Dupont wrote: >> Among the list of RFCs to be progressed to full std is/was RFC4941 >> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). > > => I even published a document explaining what I thought about the > whole idea (and I didn't change my mind). COuld you please provide a reference? >> As it stands, RFC4941 has a number of issues: >> * Using MD5 as opposed to something better > > => for this use MD5 is not bad. Just consider it as a not crypto hash. > > Now RFC4941bis is currently heavily deployed so it is far too soon > to try to obsolete it. I'm not necessarily thinking about obsoleting it. This is, say, an open question. I do think that you cannot move RFC4941 to STD, though. > When I went to the mic at a previous IETF meeting some years ago > to ask the IPv6 specs to be raise to full standard with at first > the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left > at the border of the road I shan't be sad... I don't think RFC4941 meet the criteria for elevating a document to STD, though. 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 20 04:29:30 2017 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 6922F12EC30 for ; Thu, 20 Jul 2017 04:29:28 -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, RP_MATCHES_RCVD=-0.001, 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 S0-2wkx5CEvO for ; Thu, 20 Jul 2017 04:29:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 EF930131A86 for ; Thu, 20 Jul 2017 04:29:26 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6KBTMPk030362 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jul 2017 11:29:23 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6KBTM7F009317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jul 2017 11:29:22 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v6KBTLum013691; Thu, 20 Jul 2017 11:29:21 GMT Received: from oracle.com (/31.133.149.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jul 2017 04:29:21 -0700 Date: Thu, 20 Jul 2017 07:29:13 -0400 From: Sowmini Varadhan To: Erik Kline Cc: Sowmini Varadhan , Ole Troan , 6man WG , "Bernie Volz (volz)" Subject: Re: rationale for the default of DupAddrDetectTransmits Message-ID: <20170720112913.GA15018@oracle.com> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> <5A88D5B3-0505-4DA8-AC89-8668EEE7665E@cisco.com> <9C251A7A-EFE7-4DE2-83DB-50B9C0593C19@employees.org> 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) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:29:28 -0000 On (07/19/17 14:06), Erik Kline wrote: > > > If there's an interest in this, I'd be happy to provide more details > > about the Solaris implementation. > > If it's appropriate to share with the group, I think it'd be interesting. here it is: > From internet-drafts@ietf.org Thu Jul 20 07:17:24 2017 > > A new version of I-D, draft-varadhan-continuous-dad-00.txt > has been successfully submitted by Sowmini Varadhan and posted to the > IETF repository. > > Name: draft-varadhan-continuous-dad > Revision: 00 > Title: Continuous DAD implementation in Solaris > Document date: 2017-07-20 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/id/draft-varadhan-continuous-dad-00.txt > Status: https://datatracker.ietf.org/doc/draft-varadhan-continuous-dad/ > Htmlized: https://tools.ietf.org/html/draft-varadhan-continuous-dad-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-varadhan-continuous-dad-00 > > > Abstract: > This describes an implementation of IPv6 Duplicate Address Detection > (DAD) in Solaris that merges concepts from RFC 5227 to address some > of the known issues around DAD robustness and efficiency. > > > 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 > > > From nobody Thu Jul 20 04:35:04 2017 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 0E01712969E for ; Thu, 20 Jul 2017 04:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, 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=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZnmslkU2rNa for ; Thu, 20 Jul 2017 04:34:55 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD20E12EC30 for <6man@ietf.org>; Thu, 20 Jul 2017 04:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500550493; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=L5X3OMMrFjjXSzW+Fp8dO85eRcHLHHQc+lq5Ua9qnwA=; b=LhtaJ7cGL0NtYTPdDWI2T0z9K/TUfuPjRtOxRBfkTv2JfBc75CIDhGTMoEDBqxBLCSNADZ+ljgBjB+YHq9GJD4pNcLL0MF/qHU5JKivuvULzbEpKkuXUmMsHHGK6xxcC9K8LrcXATef+lo1ZCo50Z/iNEPOljZ3iHWvJOtOZIeI= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0176.outbound.protection.outlook.com [213.199.154.176]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-133-KEjL1uwNPRGbxc-0yxiIhg-1; Thu, 20 Jul 2017 12:34:50 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB308.eurprd07.prod.outlook.com (10.242.108.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 11:34:49 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 11:34:49 +0000 From: Tim Chown To: Fernando Gont CC: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Topic: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Index: AQHS/9WLcUlWmq4/K0ml7V6v7zatO6Ja/D+AgAAhKwCAADMrAIABEhiAgAAtRgCAAAjCAA== Date: Thu, 20 Jul 2017 11:34:49 +0000 Message-ID: <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> In-Reply-To: <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:370:128:594a:346a:ddcf:6fa7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB308; 20:5jLCyiqmOv0x9Gx+cQT4mqHDE0wHUmkxaLKjQQgGI6z8Mv1gL62/7gY/H/JFhnKBjgfOVnv2xHqkntVUTeoilluQdAk2E3LY/1eK8OtUppzNjOwPKQ8BDg93wbQvutPc8kbbciDj1+Sn96rYjAcTYTusgantw3b+RoKLpvs2wWE= x-ms-office365-filtering-correlation-id: 7ce5206b-801e-4617-fce1-08d4cf63549b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB308; x-ms-traffictypediagnostic: AM3PR07MB308: x-exchange-antispam-report-test: UriScan:(274715658323672)(278178393323532)(236129657087228)(192374486261705)(788757137089)(48057245064654)(148574349560750)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB308; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(24454002)(377454003)(33656002)(3280700002)(561944003)(2906002)(82746002)(2900100001)(36756003)(478600001)(5250100002)(230783001)(93886004)(189998001)(74482002)(50226002)(8936002)(8676002)(81166006)(57306001)(7736002)(6512007)(54906002)(99286003)(39060400002)(6436002)(6116002)(102836003)(229853002)(86362001)(110136004)(6916009)(2950100002)(305945005)(42882006)(50986999)(6246003)(72206003)(53936002)(76176999)(83716003)(6506006)(38730400002)(3660700001)(25786009)(14454004)(53546010)(4326008)(5660300001)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB308; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 11:34:49.3053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB308 X-MC-Unique: KEjL1uwNPRGbxc-0yxiIhg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:35:03 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTI6MDMsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNy8yMC8yMDE3IDExOjIxIEFNLCBTdXJlc2ggS3Jp c2huYW4gd3JvdGU6DQo+PiBIaSBUaW0sDQo+PiANCj4+PiBPbiBKdWwgMTksIDIwMTcsIGF0IDY6 MDAgUE0sIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWsNCj4+PiA8bWFpbHRvOlRpbS5D aG93bkBqaXNjLmFjLnVrPj4gd3JvdGU6DQo+Pj4gDQo+Pj4+IE9uIDE5IEp1bCAyMDE3LCBhdCAx Mzo1NywgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tDQo+Pj4+IDxtYWlsdG86 ZmdvbnRAc2k2bmV0d29ya3MuY29tPj4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBPbiAwNy8xOS8yMDE3 IDAxOjU4IFBNLCBUaW0gQ2hvd24gd3JvdGU6DQo+Pj4+Pj4gT24gMTggSnVsIDIwMTcsIGF0IDE1 OjUyLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj4+Pj4+PiA8bWFpbHRv OmZnb250QHNpNm5ldHdvcmtzLmNvbT4+DQo+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4g Rm9sa3MsDQo+Pj4+Pj4gDQo+Pj4+Pj4gQW1vbmcgdGhlIGxpc3Qgb2YgUkZDcyB0byBiZSBwcm9n cmVzc2VkIHRvIGZ1bGwgc3RkIGlzL3dhcyBSRkM0OTQxIA0KPj4+Pj4+ICgiUHJpdmFjeSBFeHRl bnNpb25zIGZvciBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbg0KPj4+Pj4+ IElQdjYiKS4NCj4+Pj4+PiANCj4+Pj4+PiBBcyBpdCBzdGFuZHMsIFJGQzQ5NDEgaGFzIGEgbnVt YmVyIG9mIGlzc3VlczoNCj4+Pj4+PiANCj4+Pj4+PiAqIFVzaW5nIHRoZSBzYW1lIElJRCBmb3Ig bXVsdGlwbGUgcHJlZml4ZXMgKiBOb3QgY2hhbmdpbmcgdGhlIElJRA0KPj4+Pj4+IHVwb24gInNl Y3VyaXR5IGV2ZW50cyIgKGluY2x1ZGluZyBlLmcuLCBjaGFuZ2UgaW4gdGhlIHVuZGVybHlpbmcN Cj4+Pj4+PiBNQUMgYWRkcmVzcykgKiBVc2luZyBNRDUgYXMgb3Bwb3NlZCB0byBzb21ldGhpbmcg YmV0dGVyICogUmVxdWlyaW5nDQo+Pj4+Pj4gdGhlIHVzZSBvZiB0ZW1wb3JhcnkgYWRkcmVzc2Vz IGFsb25nIHN0YWJsZSBhZGRyZXNzZXMgKHByZXZlbnRpbmcNCj4+Pj4+PiB1c2Ugb2YgdGVtcG9y YXJ5LW9ubHksIGZvciBub2RlcyB0aGF0IGZlZWwgbGlrZSkgKiBOb3QgdHJlYXRpbmcNCj4+Pj4+ PiBJSURzIGFzIG9wYXF1ZSB2YWx1ZXMgKHNlZSBSRkM3MTM2KSAgd2hlbiBnZW5lcmF0aW5nIHRo ZSByYW5kb21pemVkDQo+Pj4+Pj4gSUlEcyAoc2VlIHN0ZXAgMyBpbiBzZWN0aW9uIDMuMi4xIG9m IFJGQzQ5NDEpICogTWFuZGF0aW5nIG9uZQ0KPj4+Pj4+IHNwZWNpZmljIGFsZ29yaXRobSwgd2hl biB0aGUgc2FtZSBnb2Fscy9wcm9wZXJ0aWVzIGNhbiBiZSBhY2hpZXZlZA0KPj4+Pj4+IHdpdGgg bXVsdGlwbGUgYWxnb3JpdGhtcyAoc2VlIHNlY3Rpb24gNCBvZiANCj4+Pj4+PiBkcmFmdC1nb250 LTZtYW4tbm9uLXN0YWJsZS1paWRzLTAxKQ0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEJhc2Vk IG9uIHRoZSBhYm92ZSwgSSBwZXJzb25hbGx5IGRvbid0IHRoaW5rIHRoYXQgaXQgd291bGQgbWFr ZQ0KPj4+Pj4+IHNlbnNlIHRvIHByb2dyZXNzIFJGQzQ5NDEgdG8gSW50ZXJuZXQgU3RhbmRhcmQs IGJ1dCByYXRoZXIgdGhpbmsNCj4+Pj4+PiB0aGF0IHdlIHNob3VsZCB3b3JrIG9uICBhIHJlcGxh Y2VtZW50IG9mIGl0IC0tIG91ciBwcm9wb3NhbCBiZWluZyANCj4+Pj4+PiBkcmFmdC1nb250LTZt YW4tbm9uLXN0YWJsZS1paWRzLTAxLg0KPj4+Pj4+IA0KPj4+Pj4+IFRob3VnaHRzPw0KPj4+Pj4g DQo+Pj4+PiBDZXJ0YWlubHkgYW55IHVwZGF0ZSBvbiA0OTQxIG5lZWRzIHRvIGJlIGRvbmUgaW4g dGhlIGxpZ2h0IG9mIGEgZmV3DQo+Pj4+PiBkZWZpY2llbmNpZXMgdGhhdCBoYXZlIGVtZXJnZWQg b3ZlciB0aGUgeWVhcnMsIGFuZCB0aGUgcHVibGljYXRpb24gb2YNCj4+Pj4+IFJGQzcyMTcuDQo+ Pj4+PiANCj4+Pj4+IEkgdGhpbmsgaXTigJlzIHN0aWxsIHBvc3NpYmxlIHRvIGRvIGEgLWJpcyBv ZmYgNDk0MS4NCj4+Pj4gDQo+Pj4+IE15IHF1ZXN0aW9ucyB3b3VsZCBiZToNCj4+Pj4gDQo+Pj4+ IDEpIENhbiB5b3UgYWN0dWFsbHkgYWRkcmVzcyB0aGUgYWZvcmVtZW50aW9uZWQgZGVmaWNpZW5j aWVzIHdpdGhvdXQNCj4+Pj4gc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBSRkM0OTQxPyAtLSBJdCB3 b3VsZCBzZWVtIHRvIG1lIHRoYXQgaW4gb3JkZXIgdG8NCj4+Pj4gYWRkcmVzcyB0aGVtLCByZmM0 OTQxYmlzIHdvdWxkIG5vdCBiZSBhIGJpcyBkb2N1bWVudCBhbnltb3JlLg0KPj4+PiANCj4+Pj4g MikgSWYgeW91IHdlcmUgdG8gYWRkcmVzcyBzdWNoIGRlZmljaWVuY2llcywgY291bGQgdGhlIGJp cyBkb2N1bWVudCBiZQ0KPj4+PiBwcm9ncmVzc2VkIHRvIEludGVybmV0IFN0YW5kYXJkPyAtLSBN eSBhc3Nlc3NtZW50IG9mIHRoaXMgcXVlc3Rpb24NCj4+Pj4gaXM6IE5vLg0KPj4+PiANCj4+Pj4g SWYgUkZDNDk0MSB3b3VsZCB0YWtlIHNpZ25pZmljYW50IHdvcmssIGFuZCB0aGUgZW5kIHJlc3Vs dCB3b3VsZA0KPj4+PiBhY3R1YWxseSBiZSBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBmcm9tIHdo YXQncyBpbiBSRkM0OTQxLCB0aGVuIEknbSBub3QNCj4+Pj4gc3VyZSB0aGF0J2QgYmUgZGlmZmVy ZW50IHRoYW4gc3RhcnRpbmcgZnJvbSB0aGUgSS1EIHdlIGFscmVhZHkgaGF2ZS4uLg0KPj4+IA0K Pj4+IEp1c3QgdG8gYmUgY2xlYXIsIEkgbGlrZSB0aGUgbWF0ZXJpYWwgaW4geW91ciBuZXcgZHJh ZnQuDQo+Pj4gDQo+Pj4gVGhhdCBzYWlkLCBpdCBzZWVtcyB5b3UgY291bGQgZG8gYSBzaW1pbGFy IHN0eWxlIG9mIHVwZGF0ZSBmcm9tIDMwNDENCj4+PiB0byA0OTQxLCB3aXRoIGEgc2ltaWxhciBz dHJ1Y3R1cmU7IHRoZSBjb250ZW50IGlzIHRoZXJlIGluIHlvdXIgZHJhZnQsDQo+Pj4gaXQg4oCc anVzdCIgbmVlZHMgdG8gYmUgbWVyZ2VkIGluLg0KPj4+IA0KPj4+IFRoYXQgd291bGQgbWVhbiBv YnNvbGV0aW5nIDQ5NDEsIGp1c3QgYXMgNDk0MSBvYnNvbGV0ZWQgMzA0MS4gIFNvIHlvdQ0KPj4+ IHdvdWxkIGluY2x1ZGUgdGhlIGRldGFpbHMgaW4gNDk0MSB0aGF0IHdvdWxkIGNhcnJ5IGZvcndh cmQuDQo+PiANCj4+IDxBRCBoYXQgb2ZmPi4gSSBhZ3JlZS4gSWYgd2UgYXJlIHBsYW5uaW5nIGEg ZHJvcCBpbiByZXBsYWNlbWVudCB0bw0KPj4gUkZDNDk0MSBjcmVhdGluZyBhIGJpcyBkb2N1bWVu dCBmcm9tIHRoZXJlIGlzIHRoZSByaWdodCB0aGluZyB0byBkby4NCj4gDQo+IENhbiB5b3UgZXhw bGFpbiB5b3VyIHJhdGlvbmFsZT8gKGFsb25nIHdpdGggYW5zd2VyaW5nIHRoZSB0d28gcXVlc3Rp b25zDQo+IEkgcG9zZWQgdG8gVGltKS4NCj4gDQo+IFJGQzQ5NDEgY2FuIGJlIHN1bW1hcml6ZWQg YXMgY29uc2lzdGluZyBvZiB0d28gcGFydHM6DQo+IA0KPiAxKSBBIGRpc2N1c3Npb24gb2YgcHJp dmFjeSBpbXBsaWNhdGlvbnMgb2YgSWRlbnRpZmllcnMsIGFuZCBvZiBJSURzIGluDQo+IHBhcnRp Y3VsYXINCj4gDQo+IDIpIFNwZWNpZmljYXRpb24gb2YgYW4gYWxnb3JpdGhtIHRvIGdlbmVyYXRl IHRoZSBJSUQNCj4gDQo+IA0KPiAiMSkiIHdhcyBtdWNoIG5lZWRlZCB3aGVuIFJGQzMwNDEgd2Fz IHB1Ymxpc2hlZCwgYW5kIHRoZW4gY2FycmllZCB0bw0KPiBSRkM0OTQxICh3aGVuIGl0IHdhcyBw cm9iYWJseSBzdGlsbCBuZWVkZWQpLiBOb3dhZGF5cywgdGhlIHNlY3VyaXR5IGFuZA0KPiBwcml2 YWN5IHByb3BlcnRpZXMgb2YgSVB2NiBhZGRyZXNzZXMgYXJlIGRpc2N1c3NlZCBtb3JlIHRob3Jv dWdobHkgKGFuZA0KPiBpbiBtb3JlIGRpbWVuc2lvbnMpIGluIFJGQzc3MjEuICBBbmQgdGhlIGRp c2N1c3Npb24gb2YgaWRlbnRpZmllcnMgaW4NCj4gZG9jdW1lbnRzIHN1Y2ggYXMgUkZDNjk3MyBh bmQgZHJhZnQtZ29udC1wcmVkaWN0YWJsZS1udW1lcmljLWlkcw0KPiAoYmVzaWRlcyB0aGUgZmFj dCB0aGF0IG9uZSBjYW4gYWx3YXlzIHJlZmVyIGJhY2sgdG8gUkZDMzA0MSBvciBldmVuDQo+IFJG QzQ5NDEgZm9yIHN1Y2ggZGlzY3Vzc2lvbiwgaW4gdGhlIHNhbWUgd2F5IHdlIHJlZmVyZW5jZWQg UkZDMzA0MSBpbg0KPiBSRkM3NzIxKS4NCj4gDQo+IFdoZW4gaXQgY29tZXMgdG8gIjIpIiwgaWYg eW91IHJlYWxseSB3YW50IHRvIGFkZHJlc3MgdGhlIGlzc3VlcyBmb3VuZCBpbg0KPiBSRkM0OTQx LCBlc3NlbnRpYWxseSB5b3UgbmVlZCB0byByZXBsYWNlIHRoZSBhbGdvcml0aG0gd2l0aCBzb21l dGhpbmcNCj4gZWxzZS4gT25lIG1heSB0d2VhayBhIGZldyB0aGluZ3MgaGVyZSBhbmQgdGhlcmUg KGUuZy4sIHRoZSB1cGRhdGUgd2UNCj4gcHJvcG9zZSBpbiBvdXIgSS1EKSwgYnV0IHN0aWxsIHRo ZXJlIGFyZSBkcmF3YmFja3MgaW4gUkZDNDk0MSB0aGF0DQo+IGNhbm5vdCBiZSBhZGRyZXNzZWQg d2l0aG91dCBmdW5kYW1lbnRhbGx5IGNoYW5naW5nIHRoZSBhbGdvcml0aG0gKGZvcg0KPiBpbnN0 YW5jZSwgUkZDNDk0MSBoYXMgbm90YWJsZSBkcmF3YmFja3Mgd2hlbiBjb21wYXJlZCB0byBzaW1w bHkNCj4gZ2VuZXJhdGluZyB0aGUgSUlEIGFzIGEgcmFuZG9tIG51bWJlciB0aGF0IGlzIG5vdCB0 aWVkIHRvIHByZXZpb3VzbHkNCj4gc2VsZWN0ZWQgSUlEcykuIElmIG9uZSB3ZXJlIHRvIGRvIHJm YzQ5NDFiaXMsIHN1Y2ggZG9jdW1lbnQgY291bGQgbm90IGJlDQo+IHByb2dyZXNzZWQgdG8gU1RE LiBBbmQgc2luY2UgdGhlcmUgYXJlIGJldHRlciBhbmQvb3IgYWx0ZXJuYXRpdmUNCj4gYXBwcm9h Y2hlcyBmb3IgZ2VuZXJhdGluZyB0ZW1wb3JhcnkgYWRkcmVzc2VzLCBJJ20gbm90IHN1cmUgd2hh dCB3b3VsZA0KPiBiZSB0aGUgYmVuZWZpdCBoZXJlLg0KDQpCdXQgdGhlIHN0cnVjdHVyZSBvZiB5 b3VyIGRvY3VtZW50IGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgMzA0MSBhbmQgNDk0MToNCg0KMy4g IFByb2JsZW0gc3RhdGVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICAzDQo0LiAgR2VuZXJhdGlvbiBvZiBUZW1wb3JhcnkgSVB2NiBBZGRyZXNzZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYgDQo1LiAgVXBkYXRlIHRvIGV4aXN0aW5nIFJGQ3MgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCg0KQmFzaWNhbGx5LCBpdCdz IOKAnHRoZSBwcm9ibGVt4oCdIGFuZCDigJxnZW5lcmF0aW5nIHRlbXBvcmFyeSBhZGRyZXNzZXPi gJ0uDQoNCkkgdGhpbmsgd2UgYXJlIGRpc2N1c3NpbmcgdHdvIHRoaW5ncyB0aGF0IGFyZSBhY3R1 YWxseSBxdWl0ZSBzaW1pbGFyIGluIHN0cnVjdHVyZS4NCg0KVGlt From nobody Thu Jul 20 04:41:24 2017 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 56215131C19 for ; Thu, 20 Jul 2017 04:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 bNmirXONlANs for ; Thu, 20 Jul 2017 04:41:20 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 38CE7131C16 for ; Thu, 20 Jul 2017 04:41:20 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id h199so14411679ith.1 for ; Thu, 20 Jul 2017 04:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LWBZsjQdXrp+x5xPrDek6yp17aCGFTOwSv3vuz+zFVU=; b=A6Arq31Ka/usnmo2LYt8bsmcpwlFJtkK239C01lJ6schMQ7DZMZJRWTbmNTG42Gh76 WNwtGkZmlfYFujudxCEVh8VIC1uH/LCfezZWtexF+RGRy62lsYFs6b2uVmnk9/zICEq6 gwrw/oADDPRWVvVYxMZETOIiKIbY8WKZjTTGmSDu8f2ZQEUXZwwW0Tf/va0TT9sxR5DI QQDgiDn90cV4V07wNHr8A8uvUDbAkZTDNfCNRj3rgpwLdsG/TlOXn48GKegDylCo0TAX ltOXnPnomEz+RbAd9gybBxdDDDKmWalnu6Y7Q+kq1/3nADx9WKong0PJBxAh5ArNeZuW pY3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LWBZsjQdXrp+x5xPrDek6yp17aCGFTOwSv3vuz+zFVU=; b=QBDdstwkDulz+grSJPLS75ont4qdW2AcZ6+XkgHzR9vy9YX3GFwlqcaXhz1dGJudCR Pt4iRrsz/6kYmDqdmWyhM2UxewvujDufK5m/FmKcYScPhUUZMWk/u4U3G2Y1UBWcxzeh b0nYfMMr7ZZ8+NUduWawfHwzcMvXRavNwDLSAWMBjjJ6nRHJ++Boy3b/ba0tTPW/Oimr Qnx0hHvUku9ug+UNrmsTQeUD+7rblZC50jtu1EVBJ1qzXgmtZMFr+40LQxzel5lZVaQA vheQl7HTzCLLqXlfGKz1SklP+J0CYFrHxne1CUyblwfEwl830UDFnjyM7rbQsWOM94eh Ebjg== X-Gm-Message-State: AIVw111BL/ziuwBXovFglrbu89EKnNGor3D7aZ9YyOQwhh50flD4DkAZ 88QPKtqFlF5Vk8QgUctbW3o1JrEawVJ8 X-Received: by 10.36.93.16 with SMTP id w16mr2865524ita.170.1500550879173; Thu, 20 Jul 2017 04:41:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 04:40:58 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 13:40:58 +0200 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Brian E Carpenter Cc: Erik Nordmark , =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man Content-Type: multipart/alternative; boundary="001a1143d5fa1f77120554be3aff" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:41:22 -0000 --001a1143d5fa1f77120554be3aff Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Fair enough. My original point was that having DAD be less reliable > than basic ND, under adverse conditions such as an overloaded > 802.11 network, is IMHO a real problem. Yes, duplicates should > be extremely rare but they can also be extremely harmful. > Where "extremely rare", according to Warren's calculator , means: - 1 out of 3,689,385,709 times with 100,000 hosts per network - 1 out of 368,971,778,652 times with 10,000 hosts per network - ... Don't we have more important problems to solve? --001a1143d5fa1f77120554be3aff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
Fair enough. My original point was that having DAD be less reli= able
than basic ND, under adverse conditions such as an overloaded
802.11 network, is IMHO a real problem. Yes, duplicates should
be extremely rare but they can also be extremely harmful.
<= div>
Where "extremely rare", according to Warren's c= alculator, means:
  • 1 out of=C2=A03,689,385,709 times w= ith 100,000 hosts per network
  • 1 out of=C2=A0368,971,778,652 tim= es with 10,000 hosts per network
  • ...
Don't we hav= e more important problems to solve?
--001a1143d5fa1f77120554be3aff-- From nobody Thu Jul 20 04:46:01 2017 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 ED893131463 for ; Thu, 20 Jul 2017 04:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 kLXbOOjyOr0w for ; Thu, 20 Jul 2017 04:45:58 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 8074612EC30 for ; Thu, 20 Jul 2017 04:45:58 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h199so14707722ith.0 for ; Thu, 20 Jul 2017 04:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2Y7gJU+2VoYyNoYDGL5qacbKEa3FfRHVm456X0nzoHU=; b=mZGF76vYYZCoBvjHmDUc9X+Co9gto5g6v3kYjz4NZ4p0RoL5aFXIEjkkFG85ASH2QT A59Wgq+cFNoPfLj2XQaEBsjVbv0d05st+8yq/oVDbBoT/+LL3lmX3P9aCDBsgbbO16uu fy3Qk/CYThl1yBgLTxeXnnNRITyIgR0c6QlR/W15U9Y13TIbnpTzUtOBUnD3Adj94QEF 586i1QWiSi+FAc8XiEmPONKhvcXKnP52hVmk6eM2oxLCEjHqOYDMJvsMxD1aFnZIiiYx /lS7lUOwjRjDsOm0/xDavfpFmoaauHv5zBoIPaCiePXoXuU0vN7leyBCecS3HAJ2o04H wSKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2Y7gJU+2VoYyNoYDGL5qacbKEa3FfRHVm456X0nzoHU=; b=IroDXJ+qllYRGnz/J+9bNt/7vS9aBRU+DF8EXUDVJQ5aFDLA+XNfTepK7eg7YF2zop rWOrK3328bC0Qv1LIh4+Pb70JAaADggkMrvk9D5c5OpW6KAfc/rVvHsjVfbvgQrMXOsU gjwpLib36Af+xwzCK47cm8mslAy24ZQ+4RGl0mA/9pquGaXRnKC7p5gU/0pT+ncpkISw mpNmKs/GqsJMDPcSC++Zk5hplwfiZUDbR+yPrHqWbHCZCBphhtAl5P3SUnY5X0LVNHwe HMbZyKeDhECXY73IEiXKuSTmlCA0TqH8x8F8OhU8V4sYv9w4Lh6tS8+Mt7LsKud2eJah 4Gtg== X-Gm-Message-State: AIVw111qoYSY4oyD5rvKHyueOzFlJ4aJfCQtPKGoS00mi0iSQTPIgh4h syXOwlrPM/qysQ+2EfsOrvhWb2dmgbm4CUPmiA== X-Received: by 10.36.198.133 with SMTP id j127mr3073015itg.142.1500551157577; Thu, 20 Jul 2017 04:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 04:45:36 -0700 (PDT) In-Reply-To: <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 13:45:36 +0200 Message-ID: Subject: Re: Prefix Delegation and hosts To: Brian E Carpenter Cc: "Templin, Fred L" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07dd06b78cac0554be4a85" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:46:00 -0000 --94eb2c07dd06b78cac0554be4a85 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If it gets a /64 and > and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody > upstream will know (or care). Of course, SLAAC won't work for the friends, > but nobody upstream will know that either. (It should be a small matter > of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that > will show up in running code sometime.) Why pick /80 instead of something more familiar such as /120? The requesting router can even assign prefixes based on RFC1918 IPv4 /24 prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a few steps in the race to the bottom. --94eb2c07dd06b78cac0554be4a85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the frien= ds,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that will show up in running code sometime.)
=C2=A0
W= hy pick /80 instead of something more familiar such as /120? The requesting= router can even assign prefixes based on RFC1918 IPv4 /24 prefixes and IID= s based on the late 8 bits of the IPv4 address.=C2=A0Skip a few steps in th= e race to the bottom.
--94eb2c07dd06b78cac0554be4a85-- From nobody Thu Jul 20 04:46:50 2017 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 27681131C16 for ; Thu, 20 Jul 2017 04:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-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=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 1fShwp72Snvo for ; Thu, 20 Jul 2017 04:46:47 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 5030F131463 for <6man@ietf.org>; Thu, 20 Jul 2017 04:46:47 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id h199so14468371ith.1 for <6man@ietf.org>; Thu, 20 Jul 2017 04:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MXjtoY+D2CsTejEG4dn0U3dFjM2pAp4vjozbWr7s7Ro=; b=KMfPFOTyxMdN1bwBq2Jfbl+zc9oaPj45tgMbCgHKPYyHy/KxB04PFaoCxGp3BOtkqR 7/fwDe5lVvRJqh9W/dnizFo2O1gVIj0AnWA/frDK7IO1SthOax2LkrcxSXS6JhPilbqS 0IcS0tkE8dK10MJLynEir3tHXcPMYW55pngOYHI196V9h7fbeLxs1wgzeU+P4M6J9GOP 8qXsj42q5wEU6LvnWIcltM/KymKUUAb5tnn9VB+7FHy/AVZi4iNM4RXMvp1wH5pyCVkJ CvgdTRVqKUn/sHWOl7rPqjNVaDMQldqZla9mg1QnDHzROPbO8y2jWkLN3hsSx8O19o6x F/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MXjtoY+D2CsTejEG4dn0U3dFjM2pAp4vjozbWr7s7Ro=; b=lV4Fr6qZ+JrBNkpNE1RaE9mrsHWvShpyyWZ+PAn8dIV22Ds9lqgOpcSVFH9g7KXU19 JYrS0MNwdb6TQX7fy2zy5aUkYugFhINRsp8Y5C2yyhRTcODVaWy+D8id6G9dGLT1lTvK oce26GeXDu4TDJuGuzQzYDTXwUwZAvfFPDyIn217xu4oFCs5bjoCLuw//yTGbFRVk7P6 qzgCY7X6ZfCfxU3YcS8VcnDwfFoEFnO9Wy2+2NHYVguhQB7IUaOoG2KOv/0r1VbCUpQI tEOjDN6YOjIvlSlrtZ7C9oo3A2yPUWrTPIIeO9q5fF3RHnsa4aE5rfIzCMKCAu3RBJSp XGeA== X-Gm-Message-State: AIVw110VDOF1BPH8pwys0vytWUEzg0EVUNySlvQ2z8Y6zSG8L+PHBaMh C0DdrUoEmafDw8IZIiCjoFlAW05snjUi X-Received: by 10.36.4.139 with SMTP id 133mr3103572itb.142.1500551206487; Thu, 20 Jul 2017 04:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.195.137 with HTTP; Thu, 20 Jul 2017 04:46:25 -0700 (PDT) In-Reply-To: <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> From: Lorenzo Colitti Date: Thu, 20 Jul 2017 13:46:25 +0200 Message-ID: Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Tim Chown Cc: Fernando Gont , Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="001a113fe1e2a1cfa70554be4db8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:46:49 -0000 --001a113fe1e2a1cfa70554be4db8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 1:34 PM, Tim Chown wrote: > But the structure of your document is exactly the same as 3041 and 4941: > > 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 > 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6 > 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8 > > Basically, it's =E2=80=9Cthe problem=E2=80=9D and =E2=80=9Cgenerating tem= porary addresses=E2=80=9D. > > I think we are discussing two things that are actually quite similar in > structure. > +1 --001a113fe1e2a1cfa70554be4db8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 1:34 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
But the structure of your do= cument is exactly the same as 3041 and 4941:

3.=C2=A0 Problem statement . . . . . . . . . . . . . . . . . . . . . .=C2= =A0 =C2=A03
4.=C2=A0 Generation of Temporary IPv6 Addresses=C2=A0 . . . . . . . . . . .= =C2=A0 =C2=A06
5.=C2=A0 Update to existing RFCs . . . . . . . . . . . . . . . . . . .=C2= =A0 =C2=A08

Basically, it's =E2=80=9Cthe problem=E2=80=9D and =E2=80=9Cgenerating t= emporary addresses=E2=80=9D.

I think we are discussing two things that are actually quite similar in str= ucture.

+1=C2=A0
--001a113fe1e2a1cfa70554be4db8-- From nobody Thu Jul 20 04:55:33 2017 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 1CD15131C24 for ; Thu, 20 Jul 2017 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 KHxWokoQVRKx for ; Thu, 20 Jul 2017 04:55:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45277131C17 for ; Thu, 20 Jul 2017 04:55:10 -0700 (PDT) Received: from mb.local ([IPv6:2001:67c:370:1998:2c41:3f29:8c4c:2b37]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v6KBt5Ew010707 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 20 Jul 2017 11:55:08 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:1998:2c41:3f29:8c4c:2b37] claimed to be mb.local Subject: Re: Prefix Delegation and hosts To: Lorenzo Colitti , Brian E Carpenter Cc: "ipv6@ietf.org" References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> From: joel jaeggli Message-ID: <87915a3e-52a3-2fc4-6670-9cb2e2c89aed@bogus.com> Date: Thu, 20 Jul 2017 13:55:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IxfoNow634P6AQBkxChMqeD3qfd9AfdA4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:55:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IxfoNow634P6AQBkxChMqeD3qfd9AfdA4 Content-Type: multipart/mixed; boundary="40tG4P80mrK0s45NW8cKExogatdrFPwjn"; protected-headers="v1" From: joel jaeggli To: Lorenzo Colitti , Brian E Carpenter Cc: "ipv6@ietf.org" Message-ID: <87915a3e-52a3-2fc4-6670-9cb2e2c89aed@bogus.com> Subject: Re: Prefix Delegation and hosts References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> In-Reply-To: --40tG4P80mrK0s45NW8cKExogatdrFPwjn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/20/17 13:45, Lorenzo Colitti wrote: > On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter > > wrot= e: >=20 > If it gets a /64 and > and chooses to use DHCPv6-PD to hand out /80s to its friends, nobod= y > upstream will know (or care). Of course, SLAAC won't work for the > friends, > but nobody upstream will know that either. (It should be a small ma= tter > of coding to make SLAAC work with 48 bit IIDs, so I've no doubt tha= t > will show up in running code sometime.) >=20 > =C2=A0 > Why pick /80 instead of something more familiar such as /120? The > requesting router can even assign prefixes based on RFC1918 IPv4 /24 > prefixes and IIDs based on the late 8 bits of the IPv4 address.=C2=A0Sk= ip a > few steps in the race to the bottom. Presumably if your goal is to allow downstream devices to futher segment you will assign the shortest prefixes you can get away with in your model. if your goal is micro-segmentation of things like for example for containers or VMs, you'll probably assign as long as you can get away with e.g. /126 /127 /128 which can be littered all over the address space if you're so inclined. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list=20 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --40tG4P80mrK0s45NW8cKExogatdrFPwjn-- --IxfoNow634P6AQBkxChMqeD3qfd9AfdA4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAllwmhgACgkQ8AA1q7Z/VrIHnQCggF3c9MmWHfv37XkZsld9Crgg SBwAnA9S+CibUSCCxg4s1U5XDeUHxSav =o7gR -----END PGP SIGNATURE----- --IxfoNow634P6AQBkxChMqeD3qfd9AfdA4-- From nobody Thu Jul 20 05:04:59 2017 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 C0221126E3A for ; Thu, 20 Jul 2017 05:04:57 -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 w3xFQbZSY4e8 for ; Thu, 20 Jul 2017 05:04:48 -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 307BD131A86 for ; Thu, 20 Jul 2017 05:04:48 -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 v6KC4jRu006523; Thu, 20 Jul 2017 05:04:47 -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 v6KC4d8R006055 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 20 Jul 2017 05:04:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 05:04:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 05:04:38 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QAAwvhgAAASujQA= Date: Thu, 20 Jul 2017 12:04:38 +0000 Message-ID: References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> In-Reply-To: <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:04:58 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyA3OjM4IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBQcmVmaXggRGVsZWdhdGlvbiBhbmQgaG9zdHMNCj4gDQo+IE9uIDE5LzA3LzIwMTcgMjI6MjYs IFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBDbGFzc2ljYWwgREhDUHY2IFByZWZpeCBEZWxl Z2F0aW9uIGludm9sdmVzIGEgUmVxdWVzdGluZyBSb3V0ZXIgYW5kIGEgRGVsZWdhdGluZyBSb3V0 ZXIuDQo+ID4gUmVjZW50IGRpc2N1c3Npb25zIGFuZCBkcmFmdHMgaGF2ZSBzdWdnZXN0ZWQgdGhh dCB0aGUgIlJlcXVlc3RpbmcgUm91dGVyIiBjb3VsZCBiZSBhDQo+ID4gc2ltcGxlIGhvc3QgdGhh dCByZWNlaXZlcyBhIFByZWZpeCBEZWxlZ2F0aW9uIChvZiB3aGF0ZXZlciBwcmVmaXggbGVuZ3Ro KSBmb3IgaXRzIG93bg0KPiA+IG11bHRpLWFkZHJlc3NpbmcgcHVycG9zZXMuIE1lYW5pbmcsIHRo YXQgdGhlIGhvc3QgY29uZmlndXJlcyBhZGRyZXNzZXMgZnJvbSB0aGUNCj4gPiBwcmVmaXggYW5k IGFzc2lnbnMgdGhlbSwgZS5nLiwgdG8gYSBsb29wYmFjayBpbnRlcmZhY2Ugc28gdGhhdCBpdHMg bG9jYWwgYXBwbGljYXRpb25zIGNhbg0KPiA+IGVhY2ggdXNlIGEgZGlmZmVyZW50IGFkZHJlc3Mg aWYgZGVzaXJlZC4NCj4gPg0KPiA+IEJ1dCwgd2hldGhlciB0aGUgbm9kZSB1c2VzIHRoZSBkZWxl Z2F0ZWQgcHJlZml4IGZvciBtdWx0aS1hZGRyZXNzaW5nIChhcyBhIGhvc3QNCj4gPiB3b3VsZCkg b3IgZm9yIGFzc2lnbm1lbnQgdG8gZG93bnN0cmVhbSBsaW5rcyAoYXMgYSByb3V0ZXIgd291bGQp LCBpdCBzdGlsbCBoYXMgdGhlDQo+ID4gc2FtZSBhcHBlYXJhbmNlIGZyb20gdGhlIG91dHNpZGUg d29ybGQuIFNvLCBmcm9tIHRoZSBvdXRzaWRlIHdvcmxkLCB0aGUgbm9kZQ0KPiA+IHdvdWxkIGFw cGVhciBhcyBhIG11bHRpLWFkZHJlc3NpbmcgaG9zdCBldmVuIGlmIGl0IGlzIGFjdGluZyBhcyBh IHJvdXRlciBvbiBpdHMNCj4gPiBkb3duc3RyZWFtIGxpbmtzLiBUaGUgb25seSB0aW1lIGl0IHdv dWxkIGxvb2sgbGlrZSBhIHJvdXRlciBpcyBpZiBpdCBlbmdhZ2VkIGluIGENCj4gPiBkeW5hbWlj IHJvdXRpbmcgcHJvdG9jb2wgb24gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIGl0IHJlY2VpdmVk IHRoZSBwcmVmaXguDQo+IA0KPiBGb3JtYWxseSwgYSByb3V0ZXIgaXMgImEgbm9kZSB0aGF0IGZv cndhcmRzIElQdjYgcGFja2V0cyBub3QgZXhwbGljaXRseQ0KPiBhZGRyZXNzZWQgdG8gaXRzZWxm LiAgKFNlZSBOb3RlIGJlbG93LikiIFtSRkM4MjAwXS4gSSByZWNvbW1lbmQgcmVhZGluZw0KPiB0 aGUgbm90ZSBhcyB3ZWxsLiBCdXQgd2hhdCBpdCBhbW91bnRzIHRvIGlzOiBpdCdzIG5vIGJ1c2lu ZXNzIG9mIHRoZQ0KPiBkZWxlZ2F0aW5nIHJvdXRlciB3aGF0IHRoZSByZXF1ZXN0aW5nIHJvdXRl ciBjaG9vc2VzIHRvIGRvIHdpdGggdGhlDQo+IGRlbGVnYXRlZCBwcmVmaXgsIGFzIGxvbmcgYXMg aXQgb2JleXMgUkZDODIwMC4NCg0KQWdyZWVkLiBUaGUgInJlcXVlc3Rpbmcgcm91dGVyIChSUiki IGNvdWxkIGV2ZW4gYmUgYSBob3N0IHRoYXQgdXNlcyB0aGUgUERzDQpmb3IgaXRzIG93biBtdWx0 aS1hZGRyZXNzaW5nIHB1cnBvc2VzIGFuZCB3aXRob3V0IGZvcndhcmRpbmcgYW55IHBhY2tldHMg bm90DQpleHBsaWNpdGx5IGFkZHJlc3NlZCB0byBpdHNlbGYuIFNvLCBpbiB0aGF0IHNlbnNlLCBp dCBpcyBubyBidXNpbmVzcyBvZiAqYW55KiBvdGhlcg0Kbm9kZXMgb24gdGhlIGxpbmsgYXMgdG8g d2hhdCB0aGUgUlIgZG9lcyB3aXRoIHRoZSBwcmVmaXguDQoNCkJ1dCwgZm9yIHN1cmUsIHRoZSBS UiBpcyBOT1QgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIGxpbmsgb3ZlciB3aGljaCBpdCByZWNlaXZl cyB0aGUNClBEIHNvIGl0IHNob3VsZCBub3Qgc2VuZCBSQXMgb24gdGhhdCBsaW5rLiBPbmx5IHJv dXRlcnMgdGhhdCBhcmUgYXV0aG9yaXRhdGl2ZQ0KZm9yIHRoZSBsaW5rIHNob3VsZCBzZW5kIFJB cywgc2luY2UgUkFzIGNvbnRhaW4gY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmb3INCnRoZSBs aW5rLiBSUnMgc2hvdWxkIGluc3RlYWQgc2VuZCBOQSBtZXNzYWdlcyB3aXRoIFJJT3MuDQoNCj4g SWYgaXQgZ2V0cyBhIC82NCBhbmQNCj4gYW5kIGNob29zZXMgdG8gdXNlIERIQ1B2Ni1QRCB0byBo YW5kIG91dCAvODBzIHRvIGl0cyBmcmllbmRzLCBub2JvZHkNCj4gdXBzdHJlYW0gd2lsbCBrbm93 IChvciBjYXJlKS4gT2YgY291cnNlLCBTTEFBQyB3b24ndCB3b3JrIGZvciB0aGUgZnJpZW5kcywN Cj4gYnV0IG5vYm9keSB1cHN0cmVhbSB3aWxsIGtub3cgdGhhdCBlaXRoZXIuIChJdCBzaG91bGQg YmUgYSBzbWFsbCBtYXR0ZXINCj4gb2YgY29kaW5nIHRvIG1ha2UgU0xBQUMgd29yayB3aXRoIDQ4 IGJpdCBJSURzLCBzbyBJJ3ZlIG5vIGRvdWJ0IHRoYXQNCj4gd2lsbCBzaG93IHVwIGluIHJ1bm5p bmcgY29kZSBzb21ldGltZS4pDQoNCkkgZG9uJ3Qgc2VlIHdoeSBub3QsIEkgZ3Vlc3MuIEFmdGVy IGFsbCwgaXQgaXMgKnRoZWlyKiBwcmVmaXggYW5kIHRoZXkgY2FuIGRvDQp3aGF0ZXZlciB0aGV5 IHdhbnQgd2l0aCBpdCAtIHN0YW5kYXJkcyBvciBuby4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5s LnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+ICAgIEJyaWFuDQoNCg== From nobody Thu Jul 20 05:05:16 2017 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 1AB2F131C1A for ; Thu, 20 Jul 2017 05:05:14 -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 IGZHzVDy_YtV for ; Thu, 20 Jul 2017 05:05:03 -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 25999131C22 for <6man@ietf.org>; Thu, 20 Jul 2017 05:05:00 -0700 (PDT) Received: from [192.168.0.25] (unknown [46.13.174.201]) (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 0AB738253A; Thu, 20 Jul 2017 14:06:27 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Tim Chown Cc: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> From: Fernando Gont Message-ID: <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> Date: Thu, 20 Jul 2017 14:58:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:05:14 -0000 On 07/20/2017 02:34 PM, Tim Chown wrote: >> On 20 Jul 2017, at 12:03, Fernando Gont wrote: >> >> On 07/20/2017 11:21 AM, Suresh Krishnan wrote: >>> Hi Tim, >>> >>>> On Jul 19, 2017, at 6:00 PM, Tim Chown >>> > wrote: >>>> >>>>> On 19 Jul 2017, at 13:57, Fernando Gont >>>> > wrote: >>>>> >>>>> On 07/19/2017 01:58 PM, Tim Chown wrote: >>>>>>> On 18 Jul 2017, at 15:52, Fernando Gont >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941 >>>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in >>>>>>> IPv6"). >>>>>>> >>>>>>> As it stands, RFC4941 has a number of issues: >>>>>>> >>>>>>> * Using the same IID for multiple prefixes * Not changing the IID >>>>>>> upon "security events" (including e.g., change in the underlying >>>>>>> MAC address) * Using MD5 as opposed to something better * Requiring >>>>>>> the use of temporary addresses along stable addresses (preventing >>>>>>> use of temporary-only, for nodes that feel like) * Not treating >>>>>>> IIDs as opaque values (see RFC7136) when generating the randomized >>>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one >>>>>>> specific algorithm, when the same goals/properties can be achieved >>>>>>> with multiple algorithms (see section 4 of >>>>>>> draft-gont-6man-non-stable-iids-01) >>>>>>> >>>>>>> >>>>>>> Based on the above, I personally don't think that it would make >>>>>>> sense to progress RFC4941 to Internet Standard, but rather think >>>>>>> that we should work on a replacement of it -- our proposal being >>>>>>> draft-gont-6man-non-stable-iids-01. >>>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> Certainly any update on 4941 needs to be done in the light of a few >>>>>> deficiencies that have emerged over the years, and the publication of >>>>>> RFC7217. >>>>>> >>>>>> I think it’s still possible to do a -bis off 4941. >>>>> >>>>> My questions would be: >>>>> >>>>> 1) Can you actually address the aforementioned deficiencies without >>>>> significant changes to RFC4941? -- It would seem to me that in order to >>>>> address them, rfc4941bis would not be a bis document anymore. >>>>> >>>>> 2) If you were to address such deficiencies, could the bis document be >>>>> progressed to Internet Standard? -- My assessment of this question >>>>> is: No. >>>>> >>>>> If RFC4941 would take significant work, and the end result would >>>>> actually be significantly different from what's in RFC4941, then I'm not >>>>> sure that'd be different than starting from the I-D we already have... >>>> >>>> Just to be clear, I like the material in your new draft. >>>> >>>> That said, it seems you could do a similar style of update from 3041 >>>> to 4941, with a similar structure; the content is there in your draft, >>>> it “just" needs to be merged in. >>>> >>>> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you >>>> would include the details in 4941 that would carry forward. >>> >>> . I agree. If we are planning a drop in replacement to >>> RFC4941 creating a bis document from there is the right thing to do. >> >> Can you explain your rationale? (along with answering the two questions >> I posed to Tim). >> >> RFC4941 can be summarized as consisting of two parts: >> >> 1) A discussion of privacy implications of Identifiers, and of IIDs in >> particular >> >> 2) Specification of an algorithm to generate the IID >> >> >> "1)" was much needed when RFC3041 was published, and then carried to >> RFC4941 (when it was probably still needed). Nowadays, the security and >> privacy properties of IPv6 addresses are discussed more thoroughly (and >> in more dimensions) in RFC7721. And the discussion of identifiers in >> documents such as RFC6973 and draft-gont-predictable-numeric-ids >> (besides the fact that one can always refer back to RFC3041 or even >> RFC4941 for such discussion, in the same way we referenced RFC3041 in >> RFC7721). >> >> When it comes to "2)", if you really want to address the issues found in >> RFC4941, essentially you need to replace the algorithm with something >> else. One may tweak a few things here and there (e.g., the update we >> propose in our I-D), but still there are drawbacks in RFC4941 that >> cannot be addressed without fundamentally changing the algorithm (for >> instance, RFC4941 has notable drawbacks when compared to simply >> generating the IID as a random number that is not tied to previously >> selected IIDs). If one were to do rfc4941bis, such document could not be >> progressed to STD. And since there are better and/or alternative >> approaches for generating temporary addresses, I'm not sure what would >> be the benefit here. > > But the structure of your document is exactly the same as 3041 and 4941: > > 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 > 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6 > 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8 > > Basically, it's “the problem†and “generating temporary addressesâ€. > > I think we are discussing two things that are actually quite similar in structure. Just trying to get a clear picture in my head: Does the discussion boil down to renaming "draft-gont-6man-non-stable-iids" to "draft-gont-6man-rfc4941bis"? My mental model is that a bis document essentially incorporates errata and minor changes to a previous RFC. But this doesn't seem whre we want to go 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 Thu Jul 20 05:06:19 2017 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 72E5C12EA7C for ; Thu, 20 Jul 2017 05:06:16 -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, HTML_MESSAGE=0.001, 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 MSA5c65H5BMH for ; Thu, 20 Jul 2017 05:06:14 -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 983BB126E3A for ; Thu, 20 Jul 2017 05:06:14 -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 v6KC6DkF009319; Thu, 20 Jul 2017 05:06:13 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6KC6Aq7009309 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 20 Jul 2017 05:06:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 05:06:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 05:06:09 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Brian E Carpenter CC: "ipv6@ietf.org" Subject: RE: Prefix Delegation and hosts Thread-Topic: Prefix Delegation and hosts Thread-Index: AdMAeNcfCeHiFfYYSta5wvVaPMn/QAA1PDudAACtCsA= Date: Thu, 20 Jul 2017 12:06:09 +0000 Message-ID: References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.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: multipart/alternative; boundary="_000_de3f8de5db264bc288b9f4f0973eb06cXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:06:16 -0000 --_000_de3f8de5db264bc288b9f4f0973eb06cXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDQ6NDYgQU0NClRvOiBCcmlhbiBFIENhcnBlbnRl ciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KQ2M6IFRlbXBsaW4sIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBQcmVm aXggRGVsZWdhdGlvbiBhbmQgaG9zdHMNCg0KT24gVGh1LCBKdWwgMjAsIDIwMTcgYXQgNDozNyBB TSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86 YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj4gd3JvdGU6DQpJZiBpdCBnZXRzIGEgLzY0IGFu ZA0KYW5kIGNob29zZXMgdG8gdXNlIERIQ1B2Ni1QRCB0byBoYW5kIG91dCAvODBzIHRvIGl0cyBm cmllbmRzLCBub2JvZHkNCnVwc3RyZWFtIHdpbGwga25vdyAob3IgY2FyZSkuIE9mIGNvdXJzZSwg U0xBQUMgd29uJ3Qgd29yayBmb3IgdGhlIGZyaWVuZHMsDQpidXQgbm9ib2R5IHVwc3RyZWFtIHdp bGwga25vdyB0aGF0IGVpdGhlci4gKEl0IHNob3VsZCBiZSBhIHNtYWxsIG1hdHRlcg0Kb2YgY29k aW5nIHRvIG1ha2UgU0xBQUMgd29yayB3aXRoIDQ4IGJpdCBJSURzLCBzbyBJJ3ZlIG5vIGRvdWJ0 IHRoYXQNCndpbGwgc2hvdyB1cCBpbiBydW5uaW5nIGNvZGUgc29tZXRpbWUuKQ0KDQpXaHkgcGlj ayAvODAgaW5zdGVhZCBvZiBzb21ldGhpbmcgbW9yZSBmYW1pbGlhciBzdWNoIGFzIC8xMjA/IFRo ZSByZXF1ZXN0aW5nIHJvdXRlciBjYW4gZXZlbiBhc3NpZ24gcHJlZml4ZXMgYmFzZWQgb24gUkZD MTkxOCBJUHY0IC8yNCBwcmVmaXhlcyBhbmQgSUlEcyBiYXNlZCBvbiB0aGUgbGF0ZSA4IGJpdHMg b2YgdGhlIElQdjQgYWRkcmVzcy4gU2tpcCBhIGZldyBzdGVwcyBpbiB0aGUgcmFjZSB0byB0aGUg Ym90dG9tLg0KDQoNCsOYICAgIE9yLCBqdXN0IGp1bXAgdG8gLzEyOCBpbW1lZGlhdGVseSBhbmQg ZG8gTkFUPw0K --_000_de3f8de5db264bc288b9f4f0973eb06cXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxODg4Njg1NjM4Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTc4NDExNDcwIDQ0NzI3OTEw MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRp IFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDIwLCAyMDE3IDQ6NDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIEUgQ2FycGVudGVy ICZsdDticmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUZW1w bGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7OyBpcHY2QGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQcmVmaXggRGVsZWdhdGlvbiBhbmQgaG9zdHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyMCwgMjAxNyBhdCA0OjM3IEFNLCBCcmlhbiBFIENhcnBl bnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0IGdl dHMgYSAvNjQgYW5kPGJyPg0KYW5kIGNob29zZXMgdG8gdXNlIERIQ1B2Ni1QRCB0byBoYW5kIG91 dCAvODBzIHRvIGl0cyBmcmllbmRzLCBub2JvZHk8YnI+DQp1cHN0cmVhbSB3aWxsIGtub3cgKG9y IGNhcmUpLiBPZiBjb3Vyc2UsIFNMQUFDIHdvbid0IHdvcmsgZm9yIHRoZSBmcmllbmRzLDxicj4N CmJ1dCBub2JvZHkgdXBzdHJlYW0gd2lsbCBrbm93IHRoYXQgZWl0aGVyLiAoSXQgc2hvdWxkIGJl IGEgc21hbGwgbWF0dGVyPGJyPg0Kb2YgY29kaW5nIHRvIG1ha2UgU0xBQUMgd29yayB3aXRoIDQ4 IGJpdCBJSURzLCBzbyBJJ3ZlIG5vIGRvdWJ0IHRoYXQ8YnI+DQp3aWxsIHNob3cgdXAgaW4gcnVu bmluZyBjb2RlIHNvbWV0aW1lLik8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBwaWNrIC84MCBpbnN0ZWFkIG9mIHNvbWV0aGlu ZyBtb3JlIGZhbWlsaWFyIHN1Y2ggYXMgLzEyMD8gVGhlIHJlcXVlc3Rpbmcgcm91dGVyIGNhbiBl dmVuIGFzc2lnbiBwcmVmaXhlcyBiYXNlZCBvbiBSRkMxOTE4IElQdjQgLzI0IHByZWZpeGVzIGFu ZCBJSURzIGJhc2VkIG9uIHRoZSBsYXRlIDggYml0cyBvZiB0aGUgSVB2NCBhZGRyZXNzLiZuYnNw O1NraXAgYSBmZXcgc3RlcHMgaW4gdGhlIHJhY2UgdG8gdGhlIGJvdHRvbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T3IsIGp1c3QganVtcCB0byAvMTI4 IGltbWVkaWF0ZWx5IGFuZCBkbyBOQVQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_de3f8de5db264bc288b9f4f0973eb06cXCH150608nwnosboeingcom_-- From nobody Thu Jul 20 05:07:32 2017 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 94B26131A5F for ; Thu, 20 Jul 2017 05:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 zF8IDvAZUwOx for ; Thu, 20 Jul 2017 05:07:29 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 3F6FF131A86 for ; Thu, 20 Jul 2017 05:07:29 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id k71so16431314wrc.2 for ; Thu, 20 Jul 2017 05:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=LmVUFuvIGd0Tixg49xFmG1pRljFr0AWQ1XbJxsvwXbo=; b=gZDFiMiYuVugbuDt47gLc8CD1cNesKmaaqhdZYRiSBzmAAWJnQWb+Je5voudxSCG3m ht8f+nXVhfSMFmOEOowS9zSinIO/Vfd8fuHHmd6SpSk+eD63F7dyHXhHOyLth8mAT5Xo pn3P7X3pxe7CEJVYsZXKuXOevtQrXqwBP+QLq82sQXxkNm2GtwhnjTRoOHxO32tnh8NC S8ZiSZUy9XE4kgq0qmNQjsNG285QT6FZyhv0aa/d1f7ZX7Qt1f3ETHkiz2phAN//vPIE d8GDF2SjigDDoBoGf405gyXb+TEz1vRtnWwOJvXBvfG8tLleBVVllkSenNaMD1t+HVCn k84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=LmVUFuvIGd0Tixg49xFmG1pRljFr0AWQ1XbJxsvwXbo=; b=esdaa1U2U3qRmo148hjxJ+RfvMV+nm+ygsm02lE5a4dxns6KUm38gdn/wDj1/Z6pYg Z7wfJT+i/C3x2RenmZ1lvHnuwGPbL1p7xsAn46kcGjco0YkgYxVHvC/dtB6nacdEZRgq hfIR+jAM5vxCPkYQkg1CGCdaU4hQBJAStjCFnd4NqrFZmM1kahh8laZ+1v+vFzlv7ciT oIhB8W5AsvjJFeABtIB5QZH7PeT3JYlZyRUk3dH+GXVLIPNzI+YWafjDp4RiZsNXxaZw KAaF2qr+yfZGHVkajAhcMCIWK5CW/z6y+CeZ7ezaK2B+4zKdeEnhME1f353eeOKNcLtm cb4g== X-Gm-Message-State: AIVw1127LigjEr1oMwhzAd7EiLFgJp3H0e7VM7o4ox7sub9HLM1YuuXe 9muwCstrv3sUz4P0wB+/AA== X-Received: by 10.223.133.161 with SMTP id 30mr6588480wrt.102.1500552447315; Thu, 20 Jul 2017 05:07:27 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:59a7:a922:e7c7:ac0e? ([2001:67c:370:1998:59a7:a922:e7c7:ac0e]) by smtp.gmail.com with ESMTPSA id l22sm2381488wmi.48.2017.07.20.05.07.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 05:07:26 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_5BEB03A6-4995-4F51-87C3-717CDD7B58AB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: In consideration of I-D.templin-6man-rio-redirect Date: Thu, 20 Jul 2017 14:07:25 +0200 References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> <4a50273fd30849c8836ebc1dda0076d3@XCH15-06-08.nw.nos.boeing.com> <8009DD43-FB28-41E7-8439-EC7F559E0181@google.com> To: IPv6 List In-Reply-To: <8009DD43-FB28-41E7-8439-EC7F559E0181@google.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:07:31 -0000 --Apple-Mail=_5BEB03A6-4995-4F51-87C3-717CDD7B58AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 19, 2017, at 13:18, james woodyatt wrote: > On Jul 19, 2017, at 11:05, Bernie Volz (volz) > wrote: >>=20 >> Couldn't the LAN case be solved by sending a PIO with shorter prefix = length covering the address space with on-link set but SLAAC disabled? >=20 > That could work, but it would entail a NS/NS exchange and ND cache = entries at the Source for every address in use that is delegated to the = Target. Another similar method could work using the existing ND Redirect = messages, which would have the same effect: inserting ND cache entries = for each address. >=20 > You should think of our proposal as an optimization that lifts all = those ND cache entries up into the host route table for whole prefixes = at a time. In fact, while this usage scenario isn=E2=80=99t the primary motivation = of the authors, it probably warrants further discussion because adopting = this proposal might make some desirable aspects of this kind of = operating environment work better. Consider a network where the routers advertise M=3D1 and no PIO option = at all. In conformance with RFC 7934, a DHCPv6 service is provided that = grants leases to clients making Prefix Delegation (PD) requests with = delegated prefixes at least 64 bits in length, i.e. if a host asks for a = prefix shorter than a /64, then it gets a /64, and if it asks for a = longer one, then it gets a longer one. The DHCPv6 server is configured = with a pool of prefix space for which the routers serve the link. Hosts = use SLAAC (or some other method) to self-assign interface addresses in = the prefixes they are delegated by the DHCPv6 server, and because there = is no on-link prefix advertised, they send all their non-linklocal = destination packets to their default router. (A reason you might want to = do this is for scalability in networks with lots of hosts and terrible = L2 multicast capability.) Without our enhancements to RIO in this draft, optimizing the path from = a source address to destination on the link so that it need not be = forwarded by the default router entails the router sending ND Redirect = to the source and destination hosts for each to directly target the = other. This is kinda perilous, because redirection host route table = entries are only removed by NUD and updated only by the target sending = another ND Redirect. It=E2=80=99s also kinda tedious that you have to = arrange ND Redirect exchanges for every source/destination pair. Wouldn=E2=80=99t it be better if you could redirect an entire /64 prefix = all at once with a single ND Redirect message? Well, that=E2=80=99s what = our draft does. With the enhancements to RIO in this draft, rather than update the = neighbor cached with host redirect messages, we update the host route = table with prefix redirect messages. Additionally, our draft makes some = improvements to the operational semantics that allow for removing stale = routes in a timely way. In any case, we think this draft is in pretty good shape to be = considered for working group adoption, and it seems to use that it = provides a good solution to a variety of closely inter-related problems = that have been in front of this group and others for a long time. Does = anyone have further questions or comments to discuss? --james woodyatt > --Apple-Mail=_5BEB03A6-4995-4F51-87C3-717CDD7B58AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 19, 2017, at 13:18, james woodyatt <jhw@google.com> = wrote:
On Jul 19, = 2017, at 11:05, Bernie Volz (volz) <volz@cisco.com> wrote:

Couldn't the LAN case be solved by sending a PIO with shorter = prefix length covering the address space with on-link set but SLAAC = disabled?

That could work, but it would entail a NS/NS exchange and ND = cache entries at the Source for every address in use that is delegated = to the Target. Another similar method could work using the existing ND = Redirect messages, which would have the same effect: inserting ND cache = entries for each address.

You should think of our proposal as an optimization that = lifts all those ND cache entries up into the host route table for whole = prefixes at a time.

In fact, while this usage scenario isn=E2=80=99t = the primary motivation of the authors, it probably warrants further = discussion because adopting this proposal might make some desirable = aspects of this kind of operating environment work better.

Consider a network where the routers advertise M=3D1= and no PIO option at all. In conformance with RFC 7934, a DHCPv6 = service is provided that grants leases to clients making Prefix = Delegation (PD) requests with delegated prefixes at least 64 bits in = length, i.e. if a host asks for a prefix shorter than a /64, then it = gets a /64, and if it asks for a longer one, then it gets a longer one. = The DHCPv6 server is configured with a pool of prefix space for which = the routers serve the link. Hosts use SLAAC (or some other method) to = self-assign interface addresses in the prefixes they are delegated by = the DHCPv6 server, and because there is no on-link prefix advertised, = they send all their non-linklocal destination packets to their default = router. (A reason you might want to do this is for scalability in = networks with lots of hosts and terrible L2 multicast = capability.)

Without our = enhancements to RIO in this draft, optimizing the path from a source = address to destination on the link so that it need not be forwarded by = the default router entails the router sending ND Redirect to the source = and destination hosts for each to directly target the other. This is = kinda perilous, because redirection host route table entries are only = removed by NUD and updated only by the target sending another ND = Redirect. It=E2=80=99s also kinda tedious that you have to arrange ND = Redirect exchanges for every source/destination pair.

Wouldn=E2=80=99t it be better if you could = redirect an entire /64 prefix all at once with a single ND Redirect = message? Well, that=E2=80=99s what our draft does.

With the enhancements to RIO in this draft, rather = than update the neighbor cached with host redirect messages, we update = the host route table with prefix redirect messages. Additionally, our = draft makes some improvements to the operational semantics that allow = for removing stale routes in a timely way.

In any case, we think this draft is in pretty good = shape to be considered for working group adoption, and it seems to use = that it provides a good solution to a variety of closely inter-related = problems that have been in front of this group and others for a long = time. Does anyone have further questions or comments to = discuss?

--james woodyatt <jhw@google.com>

= --Apple-Mail=_5BEB03A6-4995-4F51-87C3-717CDD7B58AB-- From nobody Thu Jul 20 05:32:34 2017 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 1ED01131794 for ; Thu, 20 Jul 2017 05:32:30 -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, HTML_MESSAGE=0.001, 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 t1osjamJd_Eg for ; Thu, 20 Jul 2017 05:32:24 -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 99FE2131C1D for ; Thu, 20 Jul 2017 05:32:03 -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 v6KCW3a3046625; Thu, 20 Jul 2017 05:32:03 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6KCW2d8046607 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 20 Jul 2017 05:32:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 05:32:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 05:32:00 -0700 From: "Templin, Fred L" To: james woodyatt , IPv6 List Subject: RE: In consideration of I-D.templin-6man-rio-redirect Thread-Topic: In consideration of I-D.templin-6man-rio-redirect Thread-Index: AQHTAAqYiPckzv4gME6Aj7m1B2sutqJa1WkAgAAGwa+AAcVYEoAABjAA Date: Thu, 20 Jul 2017 12:32:00 +0000 Message-ID: References: <2C483555-4761-4149-B00D-DAA04CEE13E5@google.com> <4a50273fd30849c8836ebc1dda0076d3@XCH15-06-08.nw.nos.boeing.com> <8009DD43-FB28-41E7-8439-EC7F559E0181@google.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: multipart/alternative; boundary="_000_bd5ed5c234824b468a69e633a2b9e766XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:32:30 -0000 --_000_bd5ed5c234824b468a69e633a2b9e766XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBqYW1lcyB3b29keWF0dA0KU2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNTowNyBBTQ0K VG86IElQdjYgTGlzdCA8aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBJbiBjb25zaWRlcmF0 aW9uIG9mIEktRC50ZW1wbGluLTZtYW4tcmlvLXJlZGlyZWN0DQoNCk9uIEp1bCAxOSwgMjAxNywg YXQgMTM6MTgsIGphbWVzIHdvb2R5YXR0IDxqaHdAZ29vZ2xlLmNvbTxtYWlsdG86amh3QGdvb2ds ZS5jb20+PiB3cm90ZToNCk9uIEp1bCAxOSwgMjAxNywgYXQgMTE6MDUsIEJlcm5pZSBWb2x6ICh2 b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4gd3JvdGU6DQoNCkNv dWxkbid0IHRoZSBMQU4gY2FzZSBiZSBzb2x2ZWQgYnkgc2VuZGluZyBhIFBJTyB3aXRoIHNob3J0 ZXIgcHJlZml4IGxlbmd0aCBjb3ZlcmluZyB0aGUgYWRkcmVzcyBzcGFjZSB3aXRoIG9uLWxpbmsg c2V0IGJ1dCBTTEFBQyBkaXNhYmxlZD8NCg0KVGhhdCBjb3VsZCB3b3JrLCBidXQgaXQgd291bGQg ZW50YWlsIGEgTlMvTlMgZXhjaGFuZ2UgYW5kIE5EIGNhY2hlIGVudHJpZXMgYXQgdGhlIFNvdXJj ZSBmb3IgZXZlcnkgYWRkcmVzcyBpbiB1c2UgdGhhdCBpcyBkZWxlZ2F0ZWQgdG8gdGhlIFRhcmdl dC4gQW5vdGhlciBzaW1pbGFyIG1ldGhvZCBjb3VsZCB3b3JrIHVzaW5nIHRoZSBleGlzdGluZyBO RCBSZWRpcmVjdCBtZXNzYWdlcywgd2hpY2ggd291bGQgaGF2ZSB0aGUgc2FtZSBlZmZlY3Q6IGlu c2VydGluZyBORCBjYWNoZSBlbnRyaWVzIGZvciBlYWNoIGFkZHJlc3MuDQoNCllvdSBzaG91bGQg dGhpbmsgb2Ygb3VyIHByb3Bvc2FsIGFzIGFuIG9wdGltaXphdGlvbiB0aGF0IGxpZnRzIGFsbCB0 aG9zZSBORCBjYWNoZSBlbnRyaWVzIHVwIGludG8gdGhlIGhvc3Qgcm91dGUgdGFibGUgZm9yIHdo b2xlIHByZWZpeGVzIGF0IGEgdGltZS4NCg0KSW4gZmFjdCwgd2hpbGUgdGhpcyB1c2FnZSBzY2Vu YXJpbyBpc27igJl0IHRoZSBwcmltYXJ5IG1vdGl2YXRpb24gb2YgdGhlIGF1dGhvcnMsIGl0IHBy b2JhYmx5IHdhcnJhbnRzIGZ1cnRoZXIgZGlzY3Vzc2lvbiBiZWNhdXNlIGFkb3B0aW5nIHRoaXMg cHJvcG9zYWwgbWlnaHQgbWFrZSBzb21lIGRlc2lyYWJsZSBhc3BlY3RzIG9mIHRoaXMga2luZCBv ZiBvcGVyYXRpbmcgZW52aXJvbm1lbnQgd29yayBiZXR0ZXIuDQoNCkNvbnNpZGVyIGEgbmV0d29y ayB3aGVyZSB0aGUgcm91dGVycyBhZHZlcnRpc2UgTT0xIGFuZCBubyBQSU8gb3B0aW9uIGF0IGFs bC4gSW4gY29uZm9ybWFuY2Ugd2l0aCBSRkMgNzkzNCwgYSBESENQdjYgc2VydmljZSBpcyBwcm92 aWRlZCB0aGF0IGdyYW50cyBsZWFzZXMgdG8gY2xpZW50cyBtYWtpbmcgUHJlZml4IERlbGVnYXRp b24gKFBEKSByZXF1ZXN0cyB3aXRoIGRlbGVnYXRlZCBwcmVmaXhlcyBhdCBsZWFzdCA2NCBiaXRz IGluIGxlbmd0aCwgaS5lLiBpZiBhIGhvc3QgYXNrcyBmb3IgYSBwcmVmaXggc2hvcnRlciB0aGFu IGEgLzY0LCB0aGVuIGl0IGdldHMgYSAvNjQsIGFuZCBpZiBpdCBhc2tzIGZvciBhIGxvbmdlciBv bmUsIHRoZW4gaXQgZ2V0cyBhIGxvbmdlciBvbmUuIFRoZSBESENQdjYgc2VydmVyIGlzIGNvbmZp Z3VyZWQgd2l0aCBhIHBvb2wgb2YgcHJlZml4IHNwYWNlIGZvciB3aGljaCB0aGUgcm91dGVycyBz ZXJ2ZSB0aGUgbGluay4gSG9zdHMgdXNlIFNMQUFDIChvciBzb21lIG90aGVyIG1ldGhvZCkgdG8g c2VsZi1hc3NpZ24gaW50ZXJmYWNlIGFkZHJlc3NlcyBpbiB0aGUgcHJlZml4ZXMgdGhleSBhcmUg ZGVsZWdhdGVkIGJ5IHRoZSBESENQdjYgc2VydmVyLCBhbmQgYmVjYXVzZSB0aGVyZSBpcyBubyBv bi1saW5rIHByZWZpeCBhZHZlcnRpc2VkLCB0aGV5IHNlbmQgYWxsIHRoZWlyIG5vbi1saW5rbG9j YWwgZGVzdGluYXRpb24gcGFja2V0cyB0byB0aGVpciBkZWZhdWx0IHJvdXRlci4gKEEgcmVhc29u IHlvdSBtaWdodCB3YW50IHRvIGRvIHRoaXMgaXMgZm9yIHNjYWxhYmlsaXR5IGluIG5ldHdvcmtz IHdpdGggbG90cyBvZiBob3N0cyBhbmQgdGVycmlibGUgTDIgbXVsdGljYXN0IGNhcGFiaWxpdHku KQ0KDQpXaXRob3V0IG91ciBlbmhhbmNlbWVudHMgdG8gUklPIGluIHRoaXMgZHJhZnQsIG9wdGlt aXppbmcgdGhlIHBhdGggZnJvbSBhIHNvdXJjZSBhZGRyZXNzIHRvIGRlc3RpbmF0aW9uIG9uIHRo ZSBsaW5rIHNvIHRoYXQgaXQgbmVlZCBub3QgYmUgZm9yd2FyZGVkIGJ5IHRoZSBkZWZhdWx0IHJv dXRlciBlbnRhaWxzIHRoZSByb3V0ZXIgc2VuZGluZyBORCBSZWRpcmVjdCB0byB0aGUgc291cmNl IGFuZCBkZXN0aW5hdGlvbiBob3N0cyBmb3IgZWFjaCB0byBkaXJlY3RseSB0YXJnZXQgdGhlIG90 aGVyLiBUaGlzIGlzIGtpbmRhIHBlcmlsb3VzLCBiZWNhdXNlIHJlZGlyZWN0aW9uIGhvc3Qgcm91 dGUgdGFibGUgZW50cmllcyBhcmUgb25seSByZW1vdmVkIGJ5IE5VRCBhbmQgdXBkYXRlZCBvbmx5 IGJ5IHRoZSB0YXJnZXQgc2VuZGluZyBhbm90aGVyIE5EIFJlZGlyZWN0LiBJdOKAmXMgYWxzbyBr aW5kYSB0ZWRpb3VzIHRoYXQgeW91IGhhdmUgdG8gYXJyYW5nZSBORCBSZWRpcmVjdCBleGNoYW5n ZXMgZm9yIGV2ZXJ5IHNvdXJjZS9kZXN0aW5hdGlvbiBwYWlyLg0KDQpXb3VsZG7igJl0IGl0IGJl IGJldHRlciBpZiB5b3UgY291bGQgcmVkaXJlY3QgYW4gZW50aXJlIC82NCBwcmVmaXggYWxsIGF0 IG9uY2Ugd2l0aCBhIHNpbmdsZSBORCBSZWRpcmVjdCBtZXNzYWdlPyBXZWxsLCB0aGF04oCZcyB3 aGF0IG91ciBkcmFmdCBkb2VzLg0KDQpXaXRoIHRoZSBlbmhhbmNlbWVudHMgdG8gUklPIGluIHRo aXMgZHJhZnQsIHJhdGhlciB0aGFuIHVwZGF0ZSB0aGUgbmVpZ2hib3IgY2FjaGVkIHdpdGggaG9z dCByZWRpcmVjdCBtZXNzYWdlcywgd2UgdXBkYXRlIHRoZSBob3N0IHJvdXRlIHRhYmxlIHdpdGgg cHJlZml4IHJlZGlyZWN0IG1lc3NhZ2VzLiBBZGRpdGlvbmFsbHksIG91ciBkcmFmdCBtYWtlcyBz b21lIGltcHJvdmVtZW50cyB0byB0aGUgb3BlcmF0aW9uYWwgc2VtYW50aWNzIHRoYXQgYWxsb3cg Zm9yIHJlbW92aW5nIHN0YWxlIHJvdXRlcyBpbiBhIHRpbWVseSB3YXkuDQoNCkluIGFueSBjYXNl LCB3ZSB0aGluayB0aGlzIGRyYWZ0IGlzIGluIHByZXR0eSBnb29kIHNoYXBlIHRvIGJlIGNvbnNp ZGVyZWQgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24sIGFuZCBpdCBzZWVtcyB0byB1c2UgdGhh dCBpdCBwcm92aWRlcyBhIGdvb2Qgc29sdXRpb24gdG8gYSB2YXJpZXR5IG9mIGNsb3NlbHkgaW50 ZXItcmVsYXRlZCBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBpbiBmcm9udCBvZiB0aGlzIGdyb3Vw IGFuZCBvdGhlcnMgZm9yIGEgbG9uZyB0aW1lLiBEb2VzIGFueW9uZSBoYXZlIGZ1cnRoZXIgcXVl c3Rpb25zIG9yIGNvbW1lbnRzIHRvIGRpc2N1c3M/DQoNCg0Kw5ggICAgT25seSB0byBzYXkgdGhh dCBpdCBpcyBzaW1wbGUsIGNsZWFuIGFuZCBzb2x2ZXMgcmVhbC13b3JsZCBwcm9ibGVtcy4gQWxz byBmdWxseQ0KDQrDmCAgICBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGhvdXQgaGF2aW5nIHRvIGFk ZCBtb3JlIGJhZ2dhZ2UgdG8gdGhlIGFscmVhZHkNCg0Kw5ggICAgb3ZlcmxvYWRlZCBSQSBtZXNz YWdlLg0KDQotLWphbWVzIHdvb2R5YXR0IDxqaHdAZ29vZ2xlLmNvbTxtYWlsdG86amh3QGdvb2ds ZS5jb20+Pg0KDQo= --_000_bd5ed5c234824b468a69e633a2b9e766XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk0MjY5MTQzMTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc0MzE1Njk5NiAxMjIyNTczNDg4 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBpcHY2IFttYWlsdG86aXB2 Ni1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5qYW1lcyB3b29keWF0dDxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyA1OjA3IEFNPGJyPg0KPGI+ VG86PC9iPiBJUHY2IExpc3QgJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBJbiBjb25zaWRlcmF0aW9uIG9mIEktRC50ZW1wbGluLTZtYW4tcmlvLXJlZGlyZWN0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDE5 LCAyMDE3LCBhdCAxMzoxOCwgamFtZXMgd29vZHlhdHQgJmx0OzxhIGhyZWY9Im1haWx0bzpqaHdA Z29vZ2xlLmNvbSI+amh3QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDE5LCAy MDE3LCBhdCAxMTowNSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9s ekBjaXNjby5jb20iPnZvbHpAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q291bGRu J3QgdGhlIExBTiBjYXNlIGJlIHNvbHZlZCBieSBzZW5kaW5nIGEgUElPIHdpdGggc2hvcnRlciBw cmVmaXggbGVuZ3RoIGNvdmVyaW5nIHRoZSBhZGRyZXNzIHNwYWNlIHdpdGggb24tbGluayBzZXQg YnV0IFNMQUFDIGRpc2FibGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgY291bGQgd29yaywg YnV0IGl0IHdvdWxkIGVudGFpbCBhIE5TL05TIGV4Y2hhbmdlIGFuZCBORCBjYWNoZSBlbnRyaWVz IGF0IHRoZSBTb3VyY2UgZm9yIGV2ZXJ5IGFkZHJlc3MgaW4gdXNlIHRoYXQgaXMgZGVsZWdhdGVk IHRvIHRoZSBUYXJnZXQuIEFub3RoZXIgc2ltaWxhciBtZXRob2QgY291bGQgd29yayB1c2luZyB0 aGUgZXhpc3RpbmcgTkQgUmVkaXJlY3QgbWVzc2FnZXMsIHdoaWNoIHdvdWxkIGhhdmUNCiB0aGUg c2FtZSBlZmZlY3Q6IGluc2VydGluZyBORCBjYWNoZSBlbnRyaWVzIGZvciBlYWNoIGFkZHJlc3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv dSBzaG91bGQgdGhpbmsgb2Ygb3VyIHByb3Bvc2FsIGFzIGFuIG9wdGltaXphdGlvbiB0aGF0IGxp ZnRzIGFsbCB0aG9zZSBORCBjYWNoZSBlbnRyaWVzIHVwIGludG8gdGhlIGhvc3Qgcm91dGUgdGFi bGUgZm9yIHdob2xlIHByZWZpeGVzIGF0IGEgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4g ZmFjdCwgd2hpbGUgdGhpcyB1c2FnZSBzY2VuYXJpbyBpc27igJl0IHRoZSBwcmltYXJ5IG1vdGl2 YXRpb24gb2YgdGhlIGF1dGhvcnMsIGl0IHByb2JhYmx5IHdhcnJhbnRzIGZ1cnRoZXIgZGlzY3Vz c2lvbiBiZWNhdXNlIGFkb3B0aW5nIHRoaXMgcHJvcG9zYWwgbWlnaHQgbWFrZSBzb21lIGRlc2ly YWJsZSBhc3BlY3RzIG9mIHRoaXMga2luZCBvZiBvcGVyYXRpbmcgZW52aXJvbm1lbnQgd29yayBi ZXR0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvbnNpZGVyIGEgbmV0d29yayB3aGVyZSB0aGUgcm91dGVycyBhZHZlcnRpc2UgTT0xIGFu ZCBubyBQSU8gb3B0aW9uIGF0IGFsbC4gSW4gY29uZm9ybWFuY2Ugd2l0aCBSRkMgNzkzNCwgYSBE SENQdjYgc2VydmljZSBpcyBwcm92aWRlZCB0aGF0IGdyYW50cyBsZWFzZXMgdG8gY2xpZW50cyBt YWtpbmcgUHJlZml4IERlbGVnYXRpb24gKFBEKSByZXF1ZXN0cyB3aXRoIGRlbGVnYXRlZCBwcmVm aXhlcyBhdCBsZWFzdA0KIDY0IGJpdHMgaW4gbGVuZ3RoLCBpLmUuIGlmIGEgaG9zdCBhc2tzIGZv ciBhIHByZWZpeCBzaG9ydGVyIHRoYW4gYSAvNjQsIHRoZW4gaXQgZ2V0cyBhIC82NCwgYW5kIGlm IGl0IGFza3MgZm9yIGEgbG9uZ2VyIG9uZSwgdGhlbiBpdCBnZXRzIGEgbG9uZ2VyIG9uZS4gVGhl IERIQ1B2NiBzZXJ2ZXIgaXMgY29uZmlndXJlZCB3aXRoIGEgcG9vbCBvZiBwcmVmaXggc3BhY2Ug Zm9yIHdoaWNoIHRoZSByb3V0ZXJzIHNlcnZlIHRoZSBsaW5rLiBIb3N0cw0KIHVzZSBTTEFBQyAo b3Igc29tZSBvdGhlciBtZXRob2QpIHRvIHNlbGYtYXNzaWduIGludGVyZmFjZSBhZGRyZXNzZXMg aW4gdGhlIHByZWZpeGVzIHRoZXkgYXJlIGRlbGVnYXRlZCBieSB0aGUgREhDUHY2IHNlcnZlciwg YW5kIGJlY2F1c2UgdGhlcmUgaXMgbm8gb24tbGluayBwcmVmaXggYWR2ZXJ0aXNlZCwgdGhleSBz ZW5kIGFsbCB0aGVpciBub24tbGlua2xvY2FsIGRlc3RpbmF0aW9uIHBhY2tldHMgdG8gdGhlaXIg ZGVmYXVsdCByb3V0ZXIuIChBDQogcmVhc29uIHlvdSBtaWdodCB3YW50IHRvIGRvIHRoaXMgaXMg Zm9yIHNjYWxhYmlsaXR5IGluIG5ldHdvcmtzIHdpdGggbG90cyBvZiBob3N0cyBhbmQgdGVycmli bGUgTDIgbXVsdGljYXN0IGNhcGFiaWxpdHkuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRob3V0IG91ciBlbmhhbmNlbWVudHMgdG8gUklP IGluIHRoaXMgZHJhZnQsIG9wdGltaXppbmcgdGhlIHBhdGggZnJvbSBhIHNvdXJjZSBhZGRyZXNz IHRvIGRlc3RpbmF0aW9uIG9uIHRoZSBsaW5rIHNvIHRoYXQgaXQgbmVlZCBub3QgYmUgZm9yd2Fy ZGVkIGJ5IHRoZSBkZWZhdWx0IHJvdXRlciBlbnRhaWxzIHRoZSByb3V0ZXIgc2VuZGluZyBORCBS ZWRpcmVjdCB0byB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbg0KIGhvc3RzIGZvciBlYWNoIHRv IGRpcmVjdGx5IHRhcmdldCB0aGUgb3RoZXIuIFRoaXMgaXMga2luZGEgcGVyaWxvdXMsIGJlY2F1 c2UgcmVkaXJlY3Rpb24gaG9zdCByb3V0ZSB0YWJsZSBlbnRyaWVzIGFyZSBvbmx5IHJlbW92ZWQg YnkgTlVEIGFuZCB1cGRhdGVkIG9ubHkgYnkgdGhlIHRhcmdldCBzZW5kaW5nIGFub3RoZXIgTkQg UmVkaXJlY3QuIEl04oCZcyBhbHNvIGtpbmRhIHRlZGlvdXMgdGhhdCB5b3UgaGF2ZSB0byBhcnJh bmdlIE5EIFJlZGlyZWN0DQogZXhjaGFuZ2VzIGZvciBldmVyeSBzb3VyY2UvZGVzdGluYXRpb24g cGFpci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V291bGRu4oCZdCBpdCBiZSBiZXR0ZXIgaWYgeW91IGNvdWxkIHJlZGlyZWN0IGFuIGVudGly ZSAvNjQgcHJlZml4IGFsbCBhdCBvbmNlIHdpdGggYSBzaW5nbGUgTkQgUmVkaXJlY3QgbWVzc2Fn ZT8gV2VsbCwgdGhhdOKAmXMgd2hhdCBvdXIgZHJhZnQgZG9lcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCB0aGUgZW5oYW5jZW1lbnRz IHRvIFJJTyBpbiB0aGlzIGRyYWZ0LCByYXRoZXIgdGhhbiB1cGRhdGUgdGhlIG5laWdoYm9yIGNh Y2hlZCB3aXRoIGhvc3QgcmVkaXJlY3QgbWVzc2FnZXMsIHdlIHVwZGF0ZSB0aGUgaG9zdCByb3V0 ZSB0YWJsZSB3aXRoIHByZWZpeCByZWRpcmVjdCBtZXNzYWdlcy4gQWRkaXRpb25hbGx5LCBvdXIg ZHJhZnQgbWFrZXMgc29tZSBpbXByb3ZlbWVudHMgdG8gdGhlIG9wZXJhdGlvbmFsDQogc2VtYW50 aWNzIHRoYXQgYWxsb3cgZm9yIHJlbW92aW5nIHN0YWxlIHJvdXRlcyBpbiBhIHRpbWVseSB3YXku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IGFueSBjYXNlLCB3ZSB0aGluayB0aGlzIGRyYWZ0IGlzIGluIHByZXR0eSBnb29kIHNoYXBlIHRv IGJlIGNvbnNpZGVyZWQgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24sIGFuZCBpdCBzZWVtcyB0 byB1c2UgdGhhdCBpdCBwcm92aWRlcyBhIGdvb2Qgc29sdXRpb24gdG8gYSB2YXJpZXR5IG9mIGNs b3NlbHkgaW50ZXItcmVsYXRlZCBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBpbiBmcm9udCBvZiB0 aGlzIGdyb3VwDQogYW5kIG90aGVycyBmb3IgYSBsb25nIHRpbWUuIERvZXMgYW55b25lIGhhdmUg ZnVydGhlciBxdWVzdGlvbnMgb3IgY29tbWVudHMgdG8gZGlzY3Vzcz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25seSB0byBzYXkgdGhhdCBpdCBpcyBz aW1wbGUsIGNsZWFuIGFuZCBzb2x2ZXMgcmVhbC13b3JsZCBwcm9ibGVtcy4gQWxzbyBmdWxseTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5iYWNrd2FyZCBjb21wYXRpYmxlIHdpdGhvdXQg aGF2aW5nIHRvIGFkZCBtb3JlIGJhZ2dhZ2UgdG8gdGhlIGFscmVhZHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+b3ZlcmxvYWRlZCBSQSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tamFtZXMgd29vZHlhdHQgJmx0Ozxh IGhyZWY9Im1haWx0bzpqaHdAZ29vZ2xlLmNvbSI+amh3QGdvb2dsZS5jb208L2E+Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_bd5ed5c234824b468a69e633a2b9e766XCH150608nwnosboeingcom_-- From nobody Thu Jul 20 05:42:29 2017 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 1C3DA1317D5 for ; Thu, 20 Jul 2017 05:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, 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=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71XNJbgO6H_x for ; Thu, 20 Jul 2017 05:42:24 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8661315FF for <6man@ietf.org>; Thu, 20 Jul 2017 05:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500554542; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=am2DfnGPevuu95Q2CntujI+d0I2tf0DN2sWgX3fkqcA=; b=eHG/vhm8lisG3qbHppd3VFPPyX8dqe6HVH9y69WEcwgGmRIXsA8ocx8jmmXO8jCH6GOn31FDU5hy70ecK/hCz+uMY3sDEe3IFz35xPAAiFZR+OBSpsGxevZiuHJnf4ugdwVmO9cZ1iE070CN0up5OCNlcevsuzrYjeIBWby+Cyc= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-49-KrrGcLB7NtWwrvcbTZ6ftQ-1; Thu, 20 Jul 2017 13:42:19 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1172.eurprd07.prod.outlook.com (10.163.188.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 12:42:17 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 12:42:17 +0000 From: Tim Chown To: Fernando Gont CC: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Topic: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Index: AQHS/9WLcUlWmq4/K0ml7V6v7zatO6Ja/D+AgAAhKwCAADMrAIABEhiAgAAtRgCAAAjCAIAABr4AgAAMHIA= Date: Thu, 20 Jul 2017 12:42:17 +0000 Message-ID: References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> In-Reply-To: <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:370:128:78a0:2885:9daa:b38e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1172; 20:qsZVBTGZwjXXNJ/+MFatnGkZbmMxYqeTX7gLXZ1e2JKDpESdUuThyLOaJFXMmPTgyulXaihYMHXtzFMPEDE72XlqPYuvmbJEO1smNg9nsRfqUxsYnKYHTkCYFMxMKzNbHMidG4HMFL7A+PWnDZPHnynYEav63yP5vw6AdvXYSX0= x-ms-office365-filtering-correlation-id: 91099899-6f16-42a4-8a33-08d4cf6cc136 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1172; x-ms-traffictypediagnostic: AM3PR07MB1172: x-exchange-antispam-report-test: UriScan:(274715658323672)(278178393323532)(236129657087228)(192374486261705)(788757137089)(48057245064654)(148574349560750)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1172; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1172; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(377454003)(24454002)(6916009)(74482002)(6436002)(42882006)(2950100002)(83716003)(5660300001)(53546010)(7736002)(6246003)(2900100001)(102836003)(229853002)(561944003)(50986999)(6116002)(99286003)(39060400002)(6512007)(305945005)(38730400002)(5250100002)(53936002)(54906002)(72206003)(14454004)(8936002)(50226002)(3280700002)(86362001)(8676002)(6486002)(3660700001)(93886004)(36756003)(76176999)(230783001)(110136004)(478600001)(6506006)(2906002)(33656002)(189998001)(57306001)(4326008)(82746002)(81166006)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1172; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <3D771C527C3FA24DAC5E07C453EEF182@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 12:42:17.0452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1172 X-MC-Unique: KrrGcLB7NtWwrvcbTZ6ftQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:42:27 -0000 PiBPbiAyMCBKdWwgMjAxNywgYXQgMTI6NTgsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNy8yMC8yMDE3IDAyOjM0IFBNLCBUaW0gQ2hvd24g d3JvdGU6DQo+Pj4gT24gMjAgSnVsIDIwMTcsIGF0IDEyOjAzLCBGZXJuYW5kbyBHb250IDxmZ29u dEBzaTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IE9uIDA3LzIwLzIwMTcgMTE6MjEg QU0sIFN1cmVzaCBLcmlzaG5hbiB3cm90ZToNCj4+Pj4gSGkgVGltLA0KPj4+PiANCj4+Pj4+IE9u IEp1bCAxOSwgMjAxNywgYXQgNjowMCBQTSwgVGltIENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51 aw0KPj4+Pj4gPG1haWx0bzpUaW0uQ2hvd25AamlzYy5hYy51az4+IHdyb3RlOg0KPj4+Pj4gDQo+ Pj4+Pj4gT24gMTkgSnVsIDIwMTcsIGF0IDEzOjU3LCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZu ZXR3b3Jrcy5jb20NCj4+Pj4+PiA8bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbT4+IHdyb3Rl Og0KPj4+Pj4+IA0KPj4+Pj4+IE9uIDA3LzE5LzIwMTcgMDE6NTggUE0sIFRpbSBDaG93biB3cm90 ZToNCj4+Pj4+Pj4+IE9uIDE4IEp1bCAyMDE3LCBhdCAxNTo1MiwgRmVybmFuZG8gR29udCA8Zmdv bnRAc2k2bmV0d29ya3MuY29tDQo+Pj4+Pj4+PiA8bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNv bT4+DQo+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRm9sa3MsDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IEFtb25nIHRoZSBsaXN0IG9mIFJGQ3MgdG8gYmUgcHJvZ3Jlc3NlZCB0byBm dWxsIHN0ZCBpcy93YXMgUkZDNDk0MSANCj4+Pj4+Pj4+ICgiUHJpdmFjeSBFeHRlbnNpb25zIGZv ciBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbg0KPj4+Pj4+Pj4gSVB2NiIp Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBBcyBpdCBzdGFuZHMsIFJGQzQ5NDEgaGFzIGEgbnVtYmVy IG9mIGlzc3VlczoNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gKiBVc2luZyB0aGUgc2FtZSBJSUQgZm9y IG11bHRpcGxlIHByZWZpeGVzICogTm90IGNoYW5naW5nIHRoZSBJSUQNCj4+Pj4+Pj4+IHVwb24g InNlY3VyaXR5IGV2ZW50cyIgKGluY2x1ZGluZyBlLmcuLCBjaGFuZ2UgaW4gdGhlIHVuZGVybHlp bmcNCj4+Pj4+Pj4+IE1BQyBhZGRyZXNzKSAqIFVzaW5nIE1ENSBhcyBvcHBvc2VkIHRvIHNvbWV0 aGluZyBiZXR0ZXIgKiBSZXF1aXJpbmcNCj4+Pj4+Pj4+IHRoZSB1c2Ugb2YgdGVtcG9yYXJ5IGFk ZHJlc3NlcyBhbG9uZyBzdGFibGUgYWRkcmVzc2VzIChwcmV2ZW50aW5nDQo+Pj4+Pj4+PiB1c2Ug b2YgdGVtcG9yYXJ5LW9ubHksIGZvciBub2RlcyB0aGF0IGZlZWwgbGlrZSkgKiBOb3QgdHJlYXRp bmcNCj4+Pj4+Pj4+IElJRHMgYXMgb3BhcXVlIHZhbHVlcyAoc2VlIFJGQzcxMzYpICB3aGVuIGdl bmVyYXRpbmcgdGhlIHJhbmRvbWl6ZWQNCj4+Pj4+Pj4+IElJRHMgKHNlZSBzdGVwIDMgaW4gc2Vj dGlvbiAzLjIuMSBvZiBSRkM0OTQxKSAqIE1hbmRhdGluZyBvbmUNCj4+Pj4+Pj4+IHNwZWNpZmlj IGFsZ29yaXRobSwgd2hlbiB0aGUgc2FtZSBnb2Fscy9wcm9wZXJ0aWVzIGNhbiBiZSBhY2hpZXZl ZA0KPj4+Pj4+Pj4gd2l0aCBtdWx0aXBsZSBhbGdvcml0aG1zIChzZWUgc2VjdGlvbiA0IG9mIA0K Pj4+Pj4+Pj4gZHJhZnQtZ29udC02bWFuLW5vbi1zdGFibGUtaWlkcy0wMSkNCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBCYXNlZCBvbiB0aGUgYWJvdmUsIEkgcGVyc29uYWxseSBkb24n dCB0aGluayB0aGF0IGl0IHdvdWxkIG1ha2UNCj4+Pj4+Pj4+IHNlbnNlIHRvIHByb2dyZXNzIFJG QzQ5NDEgdG8gSW50ZXJuZXQgU3RhbmRhcmQsIGJ1dCByYXRoZXIgdGhpbmsNCj4+Pj4+Pj4+IHRo YXQgd2Ugc2hvdWxkIHdvcmsgb24gIGEgcmVwbGFjZW1lbnQgb2YgaXQgLS0gb3VyIHByb3Bvc2Fs IGJlaW5nIA0KPj4+Pj4+Pj4gZHJhZnQtZ29udC02bWFuLW5vbi1zdGFibGUtaWlkcy0wMS4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhvdWdodHM/DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBDZXJ0YWlubHkg YW55IHVwZGF0ZSBvbiA0OTQxIG5lZWRzIHRvIGJlIGRvbmUgaW4gdGhlIGxpZ2h0IG9mIGEgZmV3 DQo+Pj4+Pj4+IGRlZmljaWVuY2llcyB0aGF0IGhhdmUgZW1lcmdlZCBvdmVyIHRoZSB5ZWFycywg YW5kIHRoZSBwdWJsaWNhdGlvbiBvZg0KPj4+Pj4+PiBSRkM3MjE3Lg0KPj4+Pj4+PiANCj4+Pj4+ Pj4gSSB0aGluayBpdOKAmXMgc3RpbGwgcG9zc2libGUgdG8gZG8gYSAtYmlzIG9mZiA0OTQxLg0K Pj4+Pj4+IA0KPj4+Pj4+IE15IHF1ZXN0aW9ucyB3b3VsZCBiZToNCj4+Pj4+PiANCj4+Pj4+PiAx KSBDYW4geW91IGFjdHVhbGx5IGFkZHJlc3MgdGhlIGFmb3JlbWVudGlvbmVkIGRlZmljaWVuY2ll cyB3aXRob3V0DQo+Pj4+Pj4gc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBSRkM0OTQxPyAtLSBJdCB3 b3VsZCBzZWVtIHRvIG1lIHRoYXQgaW4gb3JkZXIgdG8NCj4+Pj4+PiBhZGRyZXNzIHRoZW0sIHJm YzQ5NDFiaXMgd291bGQgbm90IGJlIGEgYmlzIGRvY3VtZW50IGFueW1vcmUuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gMikgSWYgeW91IHdlcmUgdG8gYWRkcmVzcyBzdWNoIGRlZmljaWVuY2llcywgY291bGQg dGhlIGJpcyBkb2N1bWVudCBiZQ0KPj4+Pj4+IHByb2dyZXNzZWQgdG8gSW50ZXJuZXQgU3RhbmRh cmQ/IC0tIE15IGFzc2Vzc21lbnQgb2YgdGhpcyBxdWVzdGlvbg0KPj4+Pj4+IGlzOiBOby4NCj4+ Pj4+PiANCj4+Pj4+PiBJZiBSRkM0OTQxIHdvdWxkIHRha2Ugc2lnbmlmaWNhbnQgd29yaywgYW5k IHRoZSBlbmQgcmVzdWx0IHdvdWxkDQo+Pj4+Pj4gYWN0dWFsbHkgYmUgc2lnbmlmaWNhbnRseSBk aWZmZXJlbnQgZnJvbSB3aGF0J3MgaW4gUkZDNDk0MSwgdGhlbiBJJ20gbm90DQo+Pj4+Pj4gc3Vy ZSB0aGF0J2QgYmUgZGlmZmVyZW50IHRoYW4gc3RhcnRpbmcgZnJvbSB0aGUgSS1EIHdlIGFscmVh ZHkgaGF2ZS4uLg0KPj4+Pj4gDQo+Pj4+PiBKdXN0IHRvIGJlIGNsZWFyLCBJIGxpa2UgdGhlIG1h dGVyaWFsIGluIHlvdXIgbmV3IGRyYWZ0Lg0KPj4+Pj4gDQo+Pj4+PiBUaGF0IHNhaWQsIGl0IHNl ZW1zIHlvdSBjb3VsZCBkbyBhIHNpbWlsYXIgc3R5bGUgb2YgdXBkYXRlIGZyb20gMzA0MQ0KPj4+ Pj4gdG8gNDk0MSwgd2l0aCBhIHNpbWlsYXIgc3RydWN0dXJlOyB0aGUgY29udGVudCBpcyB0aGVy ZSBpbiB5b3VyIGRyYWZ0LA0KPj4+Pj4gaXQg4oCcanVzdCIgbmVlZHMgdG8gYmUgbWVyZ2VkIGlu Lg0KPj4+Pj4gDQo+Pj4+PiBUaGF0IHdvdWxkIG1lYW4gb2Jzb2xldGluZyA0OTQxLCBqdXN0IGFz IDQ5NDEgb2Jzb2xldGVkIDMwNDEuICBTbyB5b3UNCj4+Pj4+IHdvdWxkIGluY2x1ZGUgdGhlIGRl dGFpbHMgaW4gNDk0MSB0aGF0IHdvdWxkIGNhcnJ5IGZvcndhcmQuDQo+Pj4+IA0KPj4+PiA8QUQg aGF0IG9mZj4uIEkgYWdyZWUuIElmIHdlIGFyZSBwbGFubmluZyBhIGRyb3AgaW4gcmVwbGFjZW1l bnQgdG8NCj4+Pj4gUkZDNDk0MSBjcmVhdGluZyBhIGJpcyBkb2N1bWVudCBmcm9tIHRoZXJlIGlz IHRoZSByaWdodCB0aGluZyB0byBkby4NCj4+PiANCj4+PiBDYW4geW91IGV4cGxhaW4geW91ciBy YXRpb25hbGU/IChhbG9uZyB3aXRoIGFuc3dlcmluZyB0aGUgdHdvIHF1ZXN0aW9ucw0KPj4+IEkg cG9zZWQgdG8gVGltKS4NCj4+PiANCj4+PiBSRkM0OTQxIGNhbiBiZSBzdW1tYXJpemVkIGFzIGNv bnNpc3Rpbmcgb2YgdHdvIHBhcnRzOg0KPj4+IA0KPj4+IDEpIEEgZGlzY3Vzc2lvbiBvZiBwcml2 YWN5IGltcGxpY2F0aW9ucyBvZiBJZGVudGlmaWVycywgYW5kIG9mIElJRHMgaW4NCj4+PiBwYXJ0 aWN1bGFyDQo+Pj4gDQo+Pj4gMikgU3BlY2lmaWNhdGlvbiBvZiBhbiBhbGdvcml0aG0gdG8gZ2Vu ZXJhdGUgdGhlIElJRA0KPj4+IA0KPj4+IA0KPj4+ICIxKSIgd2FzIG11Y2ggbmVlZGVkIHdoZW4g UkZDMzA0MSB3YXMgcHVibGlzaGVkLCBhbmQgdGhlbiBjYXJyaWVkIHRvDQo+Pj4gUkZDNDk0MSAo d2hlbiBpdCB3YXMgcHJvYmFibHkgc3RpbGwgbmVlZGVkKS4gTm93YWRheXMsIHRoZSBzZWN1cml0 eSBhbmQNCj4+PiBwcml2YWN5IHByb3BlcnRpZXMgb2YgSVB2NiBhZGRyZXNzZXMgYXJlIGRpc2N1 c3NlZCBtb3JlIHRob3JvdWdobHkgKGFuZA0KPj4+IGluIG1vcmUgZGltZW5zaW9ucykgaW4gUkZD NzcyMS4gIEFuZCB0aGUgZGlzY3Vzc2lvbiBvZiBpZGVudGlmaWVycyBpbg0KPj4+IGRvY3VtZW50 cyBzdWNoIGFzIFJGQzY5NzMgYW5kIGRyYWZ0LWdvbnQtcHJlZGljdGFibGUtbnVtZXJpYy1pZHMN Cj4+PiAoYmVzaWRlcyB0aGUgZmFjdCB0aGF0IG9uZSBjYW4gYWx3YXlzIHJlZmVyIGJhY2sgdG8g UkZDMzA0MSBvciBldmVuDQo+Pj4gUkZDNDk0MSBmb3Igc3VjaCBkaXNjdXNzaW9uLCBpbiB0aGUg c2FtZSB3YXkgd2UgcmVmZXJlbmNlZCBSRkMzMDQxIGluDQo+Pj4gUkZDNzcyMSkuDQo+Pj4gDQo+ Pj4gV2hlbiBpdCBjb21lcyB0byAiMikiLCBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gYWRkcmVzcyB0 aGUgaXNzdWVzIGZvdW5kIGluDQo+Pj4gUkZDNDk0MSwgZXNzZW50aWFsbHkgeW91IG5lZWQgdG8g cmVwbGFjZSB0aGUgYWxnb3JpdGhtIHdpdGggc29tZXRoaW5nDQo+Pj4gZWxzZS4gT25lIG1heSB0 d2VhayBhIGZldyB0aGluZ3MgaGVyZSBhbmQgdGhlcmUgKGUuZy4sIHRoZSB1cGRhdGUgd2UNCj4+ PiBwcm9wb3NlIGluIG91ciBJLUQpLCBidXQgc3RpbGwgdGhlcmUgYXJlIGRyYXdiYWNrcyBpbiBS RkM0OTQxIHRoYXQNCj4+PiBjYW5ub3QgYmUgYWRkcmVzc2VkIHdpdGhvdXQgZnVuZGFtZW50YWxs eSBjaGFuZ2luZyB0aGUgYWxnb3JpdGhtIChmb3INCj4+PiBpbnN0YW5jZSwgUkZDNDk0MSBoYXMg bm90YWJsZSBkcmF3YmFja3Mgd2hlbiBjb21wYXJlZCB0byBzaW1wbHkNCj4+PiBnZW5lcmF0aW5n IHRoZSBJSUQgYXMgYSByYW5kb20gbnVtYmVyIHRoYXQgaXMgbm90IHRpZWQgdG8gcHJldmlvdXNs eQ0KPj4+IHNlbGVjdGVkIElJRHMpLiBJZiBvbmUgd2VyZSB0byBkbyByZmM0OTQxYmlzLCBzdWNo IGRvY3VtZW50IGNvdWxkIG5vdCBiZQ0KPj4+IHByb2dyZXNzZWQgdG8gU1RELiBBbmQgc2luY2Ug dGhlcmUgYXJlIGJldHRlciBhbmQvb3IgYWx0ZXJuYXRpdmUNCj4+PiBhcHByb2FjaGVzIGZvciBn ZW5lcmF0aW5nIHRlbXBvcmFyeSBhZGRyZXNzZXMsIEknbSBub3Qgc3VyZSB3aGF0IHdvdWxkDQo+ Pj4gYmUgdGhlIGJlbmVmaXQgaGVyZS4NCj4+IA0KPj4gQnV0IHRoZSBzdHJ1Y3R1cmUgb2YgeW91 ciBkb2N1bWVudCBpcyBleGFjdGx5IHRoZSBzYW1lIGFzIDMwNDEgYW5kIDQ5NDE6DQo+PiANCj4+ IDMuICBQcm9ibGVtIHN0YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgMw0KPj4gNC4gIEdlbmVyYXRpb24gb2YgVGVtcG9yYXJ5IElQdjYgQWRkcmVz c2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2IA0KPj4gNS4gIFVwZGF0ZSB0byBleGlzdGlu ZyBSRkNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQo+PiANCj4+ IEJhc2ljYWxseSwgaXQncyDigJx0aGUgcHJvYmxlbeKAnSBhbmQg4oCcZ2VuZXJhdGluZyB0ZW1w b3JhcnkgYWRkcmVzc2Vz4oCdLg0KPj4gDQo+PiBJIHRoaW5rIHdlIGFyZSBkaXNjdXNzaW5nIHR3 byB0aGluZ3MgdGhhdCBhcmUgYWN0dWFsbHkgcXVpdGUgc2ltaWxhciBpbiBzdHJ1Y3R1cmUuDQo+ IA0KPiBKdXN0IHRyeWluZyB0byBnZXQgYSBjbGVhciBwaWN0dXJlIGluIG15IGhlYWQ6IERvZXMg dGhlIGRpc2N1c3Npb24gYm9pbA0KPiBkb3duIHRvIHJlbmFtaW5nICJkcmFmdC1nb250LTZtYW4t bm9uLXN0YWJsZS1paWRzIiB0bw0KPiAiZHJhZnQtZ29udC02bWFuLXJmYzQ5NDFiaXMiPw0KPiAN Cj4gTXkgbWVudGFsIG1vZGVsIGlzIHRoYXQgYSBiaXMgZG9jdW1lbnQgZXNzZW50aWFsbHkgaW5j b3Jwb3JhdGVzIGVycmF0YQ0KPiBhbmQgbWlub3IgY2hhbmdlcyB0byBhIHByZXZpb3VzIFJGQy4g QnV0IHRoaXMgZG9lc24ndCBzZWVtIHdocmUgd2Ugd2FudA0KPiB0byBnbyBoZXJlLg0KDQpJIHRo aW5rIHRoZSBwdXJwb3NlIGFuZCBzcGlyaXQgYXJlIHZlcnkgc2ltaWxhciB0aG91Z2gsIGp1c3Qg d2l0aCBhIGZldyB5ZWFycyBvZiBleHRyYSBleHBlcmllbmNlLg0KDQpPbmUgb2YgdGhlIFJGQzQ5 NDEgYXV0aG9ycyBpcyBleHBsaWNpdGx5IGNvcGllZCBhYm92ZTsgaGF2ZSBhIGNoYXQgOikNCg0K KFRoYXTigJlzIHdoYXQgSSBkaWQgZm9yIGV4YW1wbGUgd2l0aCA2NzI0IGFuZCA2NDM0LWJpcykN Cg0KVGlt From nobody Thu Jul 20 05:51:34 2017 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 588F712EB99 for ; Thu, 20 Jul 2017 05:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 2TChVdM6CAtV for ; Thu, 20 Jul 2017 05:51:26 -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 E28271317A7 for <6man@ietf.org>; Thu, 20 Jul 2017 05:51:17 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6KCYeup033384; Thu, 20 Jul 2017 14:34:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707201234.v6KCYeup033384@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont cc: "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids In-reply-to: Your message of Thu, 20 Jul 2017 14:16:28 +0300. Date: Thu, 20 Jul 2017 14:34:40 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:51:28 -0000 In your previous mail you wrote: > On 07/19/2017 02:17 PM, Francis Dupont wrote: > >> Among the list of RFCs to be progressed to full std is/was RFC4941 > >> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). > > > > => I even published a document explaining what I thought about the > > whole idea (and I didn't change my mind). > > COuld you please provide a reference? => https://tools.ietf.org/html/draft-dupont-ipv6-rfc3041harmful-05 Note my concerns were integrated into RFC 4941 so they should look like pretty basic/old now. > > Now RFC4941bis is currently heavily deployed so it is far too soon > > to try to obsolete it. > > I'm not necessarily thinking about obsoleting it. This is, say, an open > question. I do think that you cannot move RFC4941 to STD, though. => I understand well it is a different question but IMHO your ultimate goal is to obsolete RFC 4941 (with other words I should not believe you if you answer you never had this idea :-). > > When I went to the mic at a previous IETF meeting some years ago > > to ask the IPv6 specs to be raise to full standard with at first > > the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left > > at the border of the road I shan't be sad... > > I don't think RFC4941 meet the criteria for elevating a document to STD, > though. => so at least we don't disagree... Regards Francis.Dupont@fdupont.fr From nobody Thu Jul 20 06:35:12 2017 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 AC259131C1C; Thu, 20 Jul 2017 06:35:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-segment-routing-header-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150055770164.22594.6653403935748331514@ietfa.amsl.com> Date: Thu, 20 Jul 2017 06:35:01 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:35:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF. Title : IPv6 Segment Routing Header (SRH) Authors : Stefano Previdi Clarence Filsfils Kamran Raza John Leddy Brian Field Daniel Voyer Daniel Bernier Satoru Matsushima Ida Leung Jen Linkova Ebben Aries Tomoya Kosugi Eric Vyncke David Lebrun Dirk Steinberg Robert Raszuk Filename : draft-ietf-6man-segment-routing-header-07.txt Pages : 34 Date : 2017-07-20 Abstract: Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-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 Thu Jul 20 07:23:11 2017 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 895A312704A; Thu, 20 Jul 2017 07:23:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 w09TLvetl_rr; Thu, 20 Jul 2017 07:23:03 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 E3CC6120725; Thu, 20 Jul 2017 07:22:59 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id y43so71452786wrd.3; Thu, 20 Jul 2017 07:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=LV3ZPW+3NdG7BQH3LQdUqBdoECgfOPgVcpp5dJ8SglI=; b=E87cmHA5Hyj6t6XJhpM1rEMRgmAMfhpGjDneX6r9u/Plnv/bbmN3dhLLNwV0oWQ3lu 9c6+SieUMSyiuyPSoSPDLRi0hXQ7pPKUVTny2waozM9cn2LMpU5o0Dc3TCGDgvrZwD/T T4AFpvC7j1ZTL49w+ZSyXRJqufQLWVOPcBpItWsDBmCFS3fuFhYmIHac5Fq3z8Wp24AB /2JvvzHqv2/+UBBRtgD8dUGCg+FOgOEMrOY3kjPXN/z3tZtpmomVPnccDN6f55ohViUa DS1MgyArfkszq6rZf/gsMCVB0wN/8GBOiJYRmaLSO5ByYvIHYYZBQ/zbrevsgVxlrqQn ntLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=LV3ZPW+3NdG7BQH3LQdUqBdoECgfOPgVcpp5dJ8SglI=; b=DdKwwIkWNxxE5gTrlsmuu/ynoQHzDZRaKjNZZe+ryWCv+RzhD/LfkE72gR2ZCV/dh9 +HL6+EOBlCURCpdvPvRSTIta11xysO82CiUjqC/MJgzlT2d3Nfa8VBt1bhbFrY/JpP+L yIQNvoi3wxLN/PcxT7A1J+qLB3j01s35OFXB7rRXIlKQlo5gDVOjuumhTdKi/Q9o1rf+ CNcJ+VFI5TPkVNA2v2CYNwCtnl1jCayaFmKtz3RJwaQyJmAWBXQmIjkEAV5RcYgGUnYZ Q9WSI9AAd4gtnBIlWqNqDh7HuDuv4ahvUy/C5OG+DEFb1gik8ltnYczxA9pN5fagjpRw g43g== X-Gm-Message-State: AIVw113O6EfQqUlLu+YEpOu6UYdT0JNlKWzBBEEaQX1uSdalmHreOB8e jxcyMLt+gJ7RGunKDjI= X-Received: by 10.223.153.234 with SMTP id y97mr7151884wrb.41.1500560578322; Thu, 20 Jul 2017 07:22:58 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:799c:671e:be9d:c1b3? ([2001:67c:1232:144:799c:671e:be9d:c1b3]) by smtp.gmail.com with ESMTPSA id 9sm2704684wmo.35.2017.07.20.07.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 07:22:57 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Subject: Turning on IPv6 Routers Message-Id: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> Date: Thu, 20 Jul 2017 16:22:56 +0200 Cc: 6man WG , IPv6 Ops WG To: draft-ietf-6man-rfc6434-bis@ietf.org X-Mailer: Apple Mail (2.3439) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:23:04 -0000 I write as co-chair of v6ops, under our charter element "comment to = other working groups when it seems appropriate".=20 One outcome from at least v6ops and I think a couple of other WGs and = RGs this week - may I suggest a change to Node Requirements and a = corresponding change to the IPv6 Ready Logo? General Category: "Good grief, it's 2017 for goodness' sake!" Something that would be helpful in IPv6 deployment would be to turn IPv6 = on by default in residential routers. Note that this is not the general = case. I can think of routers, whose vendors have C's and J's, and = probably H's, in their names, whose default configuration is as an = Internet Host. The following would apply to devices that are configured = by default as an IP router with routing enabled. Please add a requirement of the general form: "If IPv4 router operation is enabled by default, enable IPv6 router = operation by default." Note that this is not as simple as it might sound. There are at least = three configurations that must be allowed for upstream: bridging the ISP = downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, = and address allocation via SLAAC, and on the CPE downstream LAN(s), = address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a = flowchart for this or RFC 7084 defines the algorithms. The = implementation is going to have to enable all three, see which works, = and act accordingly. There may also be considerations for PPPOE: if IPv4 is configured for = PPPOE, turn it on for IPv6. Good Grief. This is 2017 for goodness' sake, and there are = implementations that turn IPv6 on by default and work. Do it. Just do = it.= From nobody Thu Jul 20 07:55:12 2017 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 EB9CF13188D for ; Thu, 20 Jul 2017 07:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U74miq-6d7m for ; Thu, 20 Jul 2017 07:55:10 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFC6131473 for ; Thu, 20 Jul 2017 07:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500562508; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=6hhb+B4A7qF4XsYofZHci4DANJJk+6Uqf+K+oz9NkYo=; b=fVx9hs1CLJSpX9la2EQc9tv7HBfWVJiqWPkguDvZ7nPsqjGN9ijzMuXqck0NHdUkGpdvHUSd2iUrMKXHiR4F2rmiev06yYtHwZDJjq6vHOXab3HL2phX+sqwZUgcrHnvZdIAFnS51jU8MlYM+cNi92vRcZdFQ38V1tfBqbR+COg= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-53-4-QU-IyPMBmALoybCYSVuA-1; Thu, 20 Jul 2017 15:54:00 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0760.eurprd07.prod.outlook.com (10.160.6.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 14:53:58 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 14:53:58 +0000 From: Tim Chown To: Fred Baker CC: "draft-ietf-6man-rfc6434-bis@ietf.org" , 6man WG , IPv6 Ops WG Subject: Re: Turning on IPv6 Routers Thread-Topic: Turning on IPv6 Routers Thread-Index: AQHTAWO3srz2b9wieU6bc38h1/dUM6JczT+A Date: Thu, 20 Jul 2017 14:53:58 +0000 Message-ID: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> In-Reply-To: <28757A47-53D8-459E-B76D-D5D5DE3D5897@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.3273) x-originating-ip: [2001:67c:370:128:5ce6:fe4e:7dfd:1781] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0760; 20:JKUtDm0oacJ6L6yD/2cQ3Vc9pAu8Eipa/aHffWEVqFcWZAxoK5Ke1R79L5QmwD7yfnzhGuwH/u564MC7qmM5PlFWIXy3FhQ49gqmn8Eg/TYDkbUGGY/gsL0RS9MajcUrD8ve9ghdk2be1rJB/UGVx8OiaMCTVFvZZmZyLCHcedk= x-ms-office365-filtering-correlation-id: 9ecdcacf-6d19-4e01-d313-08d4cf7f26d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0760; x-ms-traffictypediagnostic: AM3PR07MB0760: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0760; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0760; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(72206003)(6116002)(39060400002)(189998001)(102836003)(110136004)(305945005)(229853002)(7736002)(50226002)(99286003)(54906002)(83716003)(53546010)(6512007)(53936002)(6246003)(8676002)(8936002)(38730400002)(81166006)(14454004)(6436002)(5250100002)(74482002)(2900100001)(25786009)(3660700001)(3280700002)(86362001)(478600001)(36756003)(82746002)(2950100002)(2906002)(4326008)(6486002)(42882006)(6506006)(5660300001)(76176999)(57306001)(6916009)(50986999)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0760; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9FE214AB107F9C4F8C614A9039B46AFC@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 14:53:58.4397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0760 X-MC-Unique: 4-QU-IyPMBmALoybCYSVuA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:55:11 -0000 SGkgRnJlZCwNCg0KPiBPbiAyMCBKdWwgMjAxNywgYXQgMTU6MjIsIEZyZWQgQmFrZXIgPGZyZWRi YWtlci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBJIHdyaXRlIGFzIGNvLWNoYWlyIG9m IHY2b3BzLCB1bmRlciBvdXIgY2hhcnRlciBlbGVtZW50ICJjb21tZW50IHRvIG90aGVyIHdvcmtp bmcgZ3JvdXBzIHdoZW4gaXQgc2VlbXMgYXBwcm9wcmlhdGUiLiANCj4gDQo+IE9uZSBvdXRjb21l IGZyb20gYXQgbGVhc3QgdjZvcHMgYW5kIEkgdGhpbmsgYSBjb3VwbGUgb2Ygb3RoZXIgV0dzIGFu ZCBSR3MgdGhpcyB3ZWVrIC0gbWF5IEkgc3VnZ2VzdCBhIGNoYW5nZSB0byBOb2RlIFJlcXVpcmVt ZW50cyBhbmQgYSBjb3JyZXNwb25kaW5nIGNoYW5nZSB0byB0aGUgSVB2NiBSZWFkeSBMb2dvPw0K PiANCj4gR2VuZXJhbCBDYXRlZ29yeTogIkdvb2QgZ3JpZWYsIGl0J3MgMjAxNyBmb3IgZ29vZG5l c3MnIHNha2UhIg0KPiANCj4gU29tZXRoaW5nIHRoYXQgd291bGQgYmUgaGVscGZ1bCBpbiBJUHY2 IGRlcGxveW1lbnQgd291bGQgYmUgdG8gdHVybiBJUHY2IG9uIGJ5IGRlZmF1bHQgaW4gcmVzaWRl bnRpYWwgcm91dGVycy4gTm90ZSB0aGF0IHRoaXMgaXMgbm90IHRoZSBnZW5lcmFsIGNhc2UuIEkg Y2FuIHRoaW5rIG9mIHJvdXRlcnMsIHdob3NlIHZlbmRvcnMgaGF2ZSBDJ3MgYW5kIEoncywgYW5k IHByb2JhYmx5IEgncywgaW4gdGhlaXIgbmFtZXMsIHdob3NlIGRlZmF1bHQgY29uZmlndXJhdGlv biBpcyBhcyBhbiBJbnRlcm5ldCBIb3N0LiBUaGUgZm9sbG93aW5nIHdvdWxkIGFwcGx5IHRvIGRl dmljZXMgdGhhdCBhcmUgY29uZmlndXJlZCBieSBkZWZhdWx0IGFzIGFuIElQIHJvdXRlciB3aXRo IHJvdXRpbmcgZW5hYmxlZC4NCj4gDQo+IFBsZWFzZSBhZGQgYSByZXF1aXJlbWVudCBvZiB0aGUg Z2VuZXJhbCBmb3JtOg0KPiANCj4gIklmIElQdjQgcm91dGVyIG9wZXJhdGlvbiBpcyBlbmFibGVk IGJ5IGRlZmF1bHQsIGVuYWJsZSBJUHY2IHJvdXRlciBvcGVyYXRpb24gYnkgZGVmYXVsdC4iDQo+ IA0KPiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYXMgc2ltcGxlIGFzIGl0IG1pZ2h0IHNvdW5kLiBU aGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUgY29uZmlndXJhdGlvbnMgdGhhdCBtdXN0IGJlIGFsbG93 ZWQgZm9yIHVwc3RyZWFtOiBicmlkZ2luZyB0aGUgSVNQIGRvd25zdHJlYW0gYW5kIENQRSBkb3du c3RyZWFtIExBTnMsIEFkZHJlc3MgYWxsb2NhdGlvbiB2aWEgREhDUCBJQV9OQSwgYW5kIGFkZHJl c3MgYWxsb2NhdGlvbiB2aWEgU0xBQUMsIGFuZCBvbiB0aGUgQ1BFIGRvd25zdHJlYW0gTEFOKHMp LCBhZGRyZXNzIGFsbG9jYXRpb24gdmlhIERIQ1AgSUFfTkEgYW5kIFNMQUFDLiBCQkYgVFItMTI0 IGdpdmVzIGEgZmxvd2NoYXJ0IGZvciB0aGlzIG9yIFJGQyA3MDg0IGRlZmluZXMgdGhlIGFsZ29y aXRobXMuIFRoZSBpbXBsZW1lbnRhdGlvbiBpcyBnb2luZyB0byBoYXZlIHRvIGVuYWJsZSBhbGwg dGhyZWUsIHNlZSB3aGljaCB3b3JrcywgYW5kIGFjdCBhY2NvcmRpbmdseS4NCj4gDQo+IFRoZXJl IG1heSBhbHNvIGJlIGNvbnNpZGVyYXRpb25zIGZvciBQUFBPRTogaWYgSVB2NCBpcyBjb25maWd1 cmVkIGZvciBQUFBPRSwgdHVybiBpdCBvbiBmb3IgSVB2Ni4NCj4gDQo+IEdvb2QgR3JpZWYuIFRo aXMgaXMgMjAxNyBmb3IgZ29vZG5lc3MnIHNha2UsIGFuZCB0aGVyZSBhcmUgaW1wbGVtZW50YXRp b25zIHRoYXQgdHVybiBJUHY2IG9uIGJ5IGRlZmF1bHQgYW5kIHdvcmsuIERvIGl0LiBKdXN0IGRv IGl0Lg0KDQpOb3RlZCBmb3IgNjQzNC1iaXMsIGFuZCB3ZeKAmWxsIGRyYWZ0IHNvbWUgd29yZHMs IHRob3VnaCA2NDM0LWJpcyBpcyBtb3JlIGdlbmVyYWxseSBhaW1lZCBhdCBob3N0cywgZm9yIHdo aWNoIEkgdGhpbmsgYSBzaW1pbGFyIHN0YXRlbWVudCBzaG91bGQgYXBwbHksIHRob3VnaCB0aGlz IGlzIGZhciBtb3JlIGNvbW1vbiBwcmFjdGljZS4NCg0KU2ltaWxhciB0ZXh0IHNob3VsZCBiZSBh cHBsaWVkIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzLTAwLg0KDQpUaW0NCg0K From nobody Thu Jul 20 08:25:13 2017 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 E9A8E131CE6; Thu, 20 Jul 2017 08:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 TfhtlHfVTN5x; Thu, 20 Jul 2017 08:25:10 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F1C131C43; Thu, 20 Jul 2017 08:25:09 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6KFP5Yx088569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2017 16:25:06 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <5970CB51.3090806@foobar.org> Date: Thu, 20 Jul 2017 16:25:05 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Fred Baker CC: draft-ietf-6man-rfc6434-bis@ietf.org, IPv6 Ops WG , 6man WG Subject: Re: Turning on IPv6 Routers References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> In-Reply-To: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:25:12 -0000 Fred Baker wrote: > "If IPv4 router operation is enabled by default, enable IPv6 router > operation by default." this is undoubtedly well-intentioned, and the idealist bit in me sympathises with the principal. However with my enable hat on, a recommendation like this isn't going to fix any problem associated with ipv6 adoption. The problems with ipv6 adoption revolve entirely around cost/benefit. Pressing problems still include things that should have been resolved years ago, e.g. vendors charging extra for ipv6 support (today's bugbear: provisioning system vendors, please note that charging extra for basic ipv6 functionality is destructive in the long term and corrosive for your customer relationships) As a separate issue, from an operational point of view, implicit enabling of functionality in one area when it's explicitly enabled in another is something that needs to be handled carefully because otherwise you can end up violating the principal of least astonishment. Nick From nobody Thu Jul 20 08:33:50 2017 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 78C84126CB6; Thu, 20 Jul 2017 08:33:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 aDfmOvkQKHdW; Thu, 20 Jul 2017 08:33:37 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 F198E128BC8; Thu, 20 Jul 2017 08:33:36 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id 184so1396377wmo.3; Thu, 20 Jul 2017 08:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZydrDn7HXvtuZTSsoacZiGNWZ/7i9WFpKhKzZ2482Gg=; b=Wx2MKYVvGrDmKpcEg7GJE8dKmofIy1rv7Rrq9YSoZIwW0IJ6wVw1x7Xe0dFJn96Whv SbQ/llETC7mk01uXiMAtzWr3477rNsTu5KgeF6BnXaOQApx5hYdlf66wDKr18rmCDxDX 5vfLNxnNI3JmO7cvS96e4E2xfmEzawdA0+OYfL6i23I3wIjaeTXflYH1EtJkY/02cimR dvJgX1VvfVy84T6QQ72QgyPQNBZbl+Rq2UG4NMja4KJFmZEQrsuM5qvjC85CtOzMI4+Y e62jfVd4u5Lsjs4Ev7KG24/AU96BzuxgA6CB722kP5+a38SI5rt1FxRmiCGQsBP9glhY Q/bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZydrDn7HXvtuZTSsoacZiGNWZ/7i9WFpKhKzZ2482Gg=; b=dfOlL1YkQ7mP4K46qs7LZWjcaicTjtWDpFP6VuNLkKUBMPqfad1Q0ySb40Pwxhh58e lPUPaNmOarPmFSI98vnBR8oDh9zCIo1ytXYIWCfuW5/D8Qgkjut9AFf1GHkFky+EY0or 6H/NpbWrIP/Owlc/Kl6LgWB4MisOvTKSW6efp6Pxp6Ehx2mjCZtb5q82K5E0yBFgPgMh hKnjS4PpmIny/1TlFsSXd2iXC3iYGF32r+bIIoPyLxI+tqJWTg3KiFYgZAKZC5C1qADJ Lq0EcRS8Me/YJaAL1UYnSXLQDkNXSqzx2nsGjxxkGuV0gLTKyU+OolrIt5L99D7fOtrj SrDQ== X-Gm-Message-State: AIVw11015V5SDXKsl6pUTI5OMK9Pjvjy7v+Nz9NjX6EB+Vl0TvBhY3g2 OxPTrLfcisZzhg== X-Received: by 10.28.165.207 with SMTP id o198mr2683008wme.154.1500564815530; Thu, 20 Jul 2017 08:33:35 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:cd1:34c:a97d:4a84? ([2001:67c:1232:144:cd1:34c:a97d:4a84]) by smtp.gmail.com with ESMTPSA id 46sm8594158wrz.8.2017.07.20.08.33.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:33:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Subject: Re: Turning on IPv6 Routers From: Fred Baker In-Reply-To: Date: Thu, 20 Jul 2017 17:33:33 +0200 Cc: "draft-ietf-6man-rfc6434-bis@ietf.org" , 6man WG , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> To: Tim Chown , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org, JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3439) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:33:40 -0000 I'd guess 7084bis before one targeting big iron, but yes in concept. > On Jul 20, 2017, at 4:53 PM, Tim Chown wrote: >=20 > Hi Fred, >=20 >> On 20 Jul 2017, at 15:22, Fred Baker = wrote: >>=20 >> I write as co-chair of v6ops, under our charter element "comment to = other working groups when it seems appropriate".=20 >>=20 >> One outcome from at least v6ops and I think a couple of other WGs and = RGs this week - may I suggest a change to Node Requirements and a = corresponding change to the IPv6 Ready Logo? >>=20 >> General Category: "Good grief, it's 2017 for goodness' sake!" >>=20 >> Something that would be helpful in IPv6 deployment would be to turn = IPv6 on by default in residential routers. Note that this is not the = general case. I can think of routers, whose vendors have C's and J's, = and probably H's, in their names, whose default configuration is as an = Internet Host. The following would apply to devices that are configured = by default as an IP router with routing enabled. >>=20 >> Please add a requirement of the general form: >>=20 >> "If IPv4 router operation is enabled by default, enable IPv6 router = operation by default." >>=20 >> Note that this is not as simple as it might sound. There are at least = three configurations that must be allowed for upstream: bridging the ISP = downstream and CPE downstream LANs, Address allocation via DHCP IA_NA, = and address allocation via SLAAC, and on the CPE downstream LAN(s), = address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a = flowchart for this or RFC 7084 defines the algorithms. The = implementation is going to have to enable all three, see which works, = and act accordingly. >>=20 >> There may also be considerations for PPPOE: if IPv4 is configured for = PPPOE, turn it on for IPv6. >>=20 >> Good Grief. This is 2017 for goodness' sake, and there are = implementations that turn IPv6 on by default and work. Do it. Just do = it. >=20 > Noted for 6434-bis, and we=E2=80=99ll draft some words, though = 6434-bis is more generally aimed at hosts, for which I think a similar = statement should apply, though this is far more common practice. >=20 > Similar text should be applied to draft-ietf-v6ops-ipv6rtr-reqs-00. >=20 > Tim >=20 From nobody Thu Jul 20 09:37:07 2017 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 50F2F131714 for ; Thu, 20 Jul 2017 09:37:05 -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, RP_MATCHES_RCVD=-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 4FFCyc8nEcix for ; Thu, 20 Jul 2017 09:37:03 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C2D131A76 for ; Thu, 20 Jul 2017 09:37:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2E9391A071 for ; Thu, 20 Jul 2017 16:36:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Prefix Delegation and hosts From: Simon Hobson In-Reply-To: <87915a3e-52a3-2fc4-6670-9cb2e2c89aed@bogus.com> Date: Thu, 20 Jul 2017 17:36:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90332440-6219-4C89-99F1-940F61A8DB00@thehobsons.co.uk> References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> <87915a3e-52a3-2fc4-6670-9cb2e2c89aed@bogus.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:37:05 -0000 joel jaeggli wrote: >> Why pick /80 instead of something more familiar such as /120? The >> requesting router can even assign prefixes based on RFC1918 IPv4 /24 >> prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip = a >> few steps in the race to the bottom. >=20 > Presumably if your goal is to allow downstream devices to futher = segment > you will assign the shortest prefixes you can get away with in your > model. if your goal is micro-segmentation of things like for example = for > containers or VMs, you'll probably assign as long as you can get away > with e.g. /126 /127 /128 which can be littered all over the address > space if you're so inclined. I think you missed his point. The moment anyone admits that a network can have less than 64bits of = addressing to play with, then the sky will fall in, there'll be plagues = of locusts, the world will end, and everyone will start getting /128 = single addresses delegated to them. Thus, there should not be any = document anywhere even admitting that /64 isn't sacrosanct lest the ISPs = inhabiting the muddy bottom of the pond use it as an excuse to delegate = smaller than multiple /64s to their customers. From nobody Thu Jul 20 09:46:08 2017 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 BB62C131CEB for ; Thu, 20 Jul 2017 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Urj1CNWL59YB for ; Thu, 20 Jul 2017 09:46:04 -0700 (PDT) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 27CCB129B15 for ; Thu, 20 Jul 2017 09:46:04 -0700 (PDT) Received: from mail.fg-networking.de (mail.fg-networking.de [131.246.197.23]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v6KGk1Zn010303 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jul 2017 18:46:01 +0200 Received: from fgn-t61 (unknown [IPv6:2001:638:208:cd00:7157:bf2e:4678:fc09]) by mail.fg-networking.de (Postfix) with ESMTP id EE5752007A for ; Thu, 20 Jul 2017 18:45:57 +0200 (CEST) Received: by fgn-t61 (Postfix, from userid 1000) id 5969A1024DF; Thu, 20 Jul 2017 18:45:57 +0200 (CEST) Date: Thu, 20 Jul 2017 18:45:57 +0200 From: Erik Auerswald To: ipv6@ietf.org Subject: Suggestion for Subnet-Router anycast address section of draft-ietf-6man-rfc4291bis Message-ID: <20170720164557.GL4444@fg-networking.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:46:07 -0000 Hi, I have recently tried to implement 127-bit prefixes on inter-router point-to-point links [RFC6164]. The vendor gear used supposedly supported the RFC, but it created the Subnet-Router anycast address for that link in contradiction to RFC 6164. As a result one router answered to both addresses, that is the odd (LSB==1) address configured on the interface as well as the even (LSB==0) Subnet-Router anycast address for the link. Reading just RFC 4291 section 2.6.1 respectively the current version of draft-ietf-6man-rfc4291bis section 2.5.1, it is not clear from the section "Required Anycast Address" that the Subnet-Router anycast address MUST be disabled for /127 prefixes as per RFC 6164, section 6. Thus I suggest the following text to be added to draft-ietf-6man-rfc4291bis section 2.5.1. to the second-to-last paragraph: , except for inter-router point-to-point links using 127-bit prefixes [RFC6164] The paragraph would be changed to the following text: Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces, except for inter-router point-to-point links using 127-bit prefixes [RFC6164]. It would be great if you could add some text to section 2.5.1. of draft-ietf-6man-rfc4291bis to clarify this issue. Feel free to use the text suggested by me, or any other wording you may prefer. That change might make it simpler for implementers to consider the corner case of 127-bit prefixes. Thanks, Erik -- Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de T:+49-631-4149988-0 M:+49-176-64228513 Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630 From nobody Thu Jul 20 10:08:33 2017 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 7FBA9131CE2 for ; Thu, 20 Jul 2017 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0tzEGD--Gn7Q for ; Thu, 20 Jul 2017 10:08:30 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 2A620131C74 for <6man@ietf.org>; Thu, 20 Jul 2017 10:08:30 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id b40so28314876qtb.2 for <6man@ietf.org>; Thu, 20 Jul 2017 10:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4m3PRh7jgEPqBvzLtpj6m2lodzzZmDARvpqgWsvZpnw=; b=IgM4i84XIU9Tj91LnlvKhSXty46c1wRNikkf91NZWYhzDUAaVKuD4Ys5OK3N1HmdFb Yq09YbjqJVMnDM29ZpbqzAVSuTWzSwppcHjDaBj/qSNKzypJXWTRyeCP1Q4fKqAmaeGK tLmuVeSlzkCm9DLj01eAHIcaFw6SIE1nFkSdzwjTfFqH5ajESQ1tKF02tmAo6qCWVpwo piW24qzKb/IATnQF+gJ88w1RKybgPYUerMuo+nlhMDrhIYFx5KBpE8dhxplV3aBY63BK fuus+Jfwrt3UniY+RpyHRATOzY4OPxaWuIHCTL9UhW5sa6hYNLr7gQREEviHlCgSAqoY 8LTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4m3PRh7jgEPqBvzLtpj6m2lodzzZmDARvpqgWsvZpnw=; b=kfBbWEKez+7mXqwP3opYtcIsMGl5VG3aiIK8G2+y2sZVwhzS4Lpnh5xmPe3hQLiz6M YyqTiYnicDmTOAH5Cq9v/qTjbcigs2pcOeyLYcPZ9ctRzVLU44kK19gJDITOhdEC/yAE UkBLVZnzc7IiCHJ3YorDvMSwiESLtPzorpU8rxHLWAzouDDVAFsXu/Tx9LZ8AEudqhxU kkrfys4uXscTMm1Tw8A92wf0nXIC6Ey5MepfRzR1ZU3sIw3ITAdSsHYjDscyem5gZRFe w5dOFTZW4Nqqp9ghpXUPSd9K7nm6EfbKLUK3WqmGmh7Ugl5t0hxrst7IfWN6KV5QcBMM y4BQ== X-Gm-Message-State: AIVw111nT8Ji2rT9dfmIpZ324SHLokMr3OZSPr7QNzkYX73o9erv2jj2 kSmQ47aI/ItKa/T9+oJcdL+VfpVnHQ== X-Received: by 10.237.58.136 with SMTP id o8mr5519146qte.160.1500570507874; Thu, 20 Jul 2017 10:08:27 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Thu, 20 Jul 2017 10:08:27 -0700 (PDT) In-Reply-To: References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 20 Jul 2017 10:08:27 -0700 X-Google-Sender-Auth: x5g2BDUMVAzdAiMe3orKvtR1n7s Message-ID: Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Tim Chown Cc: Fernando Gont , Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:08:31 -0000 At Thu, 20 Jul 2017 12:42:17 +0000, Tim Chown wrote: > > My mental model is that a bis document essentially incorporates errata > > and minor changes to a previous RFC. But this doesn't seem whre we want > > to go here. > > I think the purpose and spirit are very similar though, just with a few years of extra experience. Even if not, I don't think a bis document can't do anything beyond incorporating errata and minor changes. The revised version of the advanced socket API (now published as RFC3542) was named draft-ietf-ipngwg-rfc2292bis and changed the RFC2292 API so substantially, many of which are completely new or backwarnd incompatible. That's an old example that I just happen to be involved with, but I believe there are newer such examples. In some cases a bis draft is actually really conservative, e.g., when it intends to elevate the status of the original RFC, but in my understanding there's no rule that other kinds of update can't have a bis name. BTW, I don't have a strong opinion on how to name the draft in question per se. But if I were to choice, I'd actually use 'rfc4941bis', since it would help tell people looking at RFC4941 the existence of an update attempt. -- JINMEI, Tatuya From nobody Thu Jul 20 13:39:28 2017 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 19842124D68 for ; Thu, 20 Jul 2017 13:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 wDsSKyTwABmY for ; Thu, 20 Jul 2017 13:39:25 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 3EF7C12420B for ; Thu, 20 Jul 2017 13:39:25 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d136so16384697qkg.3 for ; Thu, 20 Jul 2017 13:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0AIqNXmd6cwLQB//q181WqHOmU0JbBTdxGWwNyaI2W0=; b=S5qEF/6JSBwSQL9qX6L0kDJ+IOxW9gTUqQybzVJloxG9dnpixZ5+v3nmwRab9dKZPg 2OnYo2aPXx+Pc5DgxTh9nKr2vrqVjFmYgK2muT2wvCgl4YariUIMd2bquEiKcuAJBGbI DT7Zsq321snPyzBdlXORNwtEPpJZQc29SHzMiIUoP7K0q73K7RGrn8ERBIUW/uFzZfhu 8s8b7KLMPYZoJ4vZa+Khw45CnNbCvc9N9Y4JR296LOHEMIlg+jjUtVSM8cUw2IX+5xeA UynDjPiqRNwRPGs447eNF9+FOnTC8kfoEUVQ8m7Pr1DtsjyzfPlXoKHQ3iaYdiaKAVMD 3G+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0AIqNXmd6cwLQB//q181WqHOmU0JbBTdxGWwNyaI2W0=; b=aYhaJFwCEJkdefr1c2o29gLULDLTs5KYx3GX7hVlacMrg7xXAB44oHrj4Lxq/P4eBH WCI5ZVC7n4M5bD43q3uNuEDWIw5gSJJmYudtHgw42daB/HQkh3Kqzm4E4pexJJVxI5Ge p664rBJyahuY3Higr1FQO5GCAJ8KBk9leuUYEznY6iLmI7sq+Sl5/+7foT23CoPUzCpT z+j4PNkCpjkWrIcpv/ojWOUcgg+2pIXwQe7ANSTWyjGckk8a1tqEJY1W+lzH4zztWR1R b+J7ZG6eLIbu/w1TbAO39sgN8D1tLZgb0/gf4xm3JJHbaI3bgQ2vcGegsG6sHnRBuu7t qu/A== X-Gm-Message-State: AIVw111hBWT0y+M8rzo2d4v8KFyY1h2Bq5FyMZlYPNV8rZ/4laZUM9+h LdJyBBpWB9z3lWpZHxgOlYK1RmDls2rVCPw= X-Received: by 10.55.144.130 with SMTP id s124mr6842013qkd.136.1500583164279; Thu, 20 Jul 2017 13:39:24 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Thu, 20 Jul 2017 13:39:23 -0700 (PDT) In-Reply-To: <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 20 Jul 2017 13:39:23 -0700 X-Google-Sender-Auth: Vlch5xzsxRNhExmeyF2c20Y8V_0 Message-ID: Subject: Re: To: "Manfredi, Albert E" Cc: Brian E Carpenter , IPv6 List Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 20:39:27 -0000 At Thu, 20 Jul 2017 03:36:21 +0000, "Manfredi, Albert E" wrote: > >> why ask the question? > > > > a) Because of the several subtly different meanings of 'prefix' in IPv6. > > Some prefixes can be on-link, while others are not. Okay, but this > is a question of address architecture, and whatever prefix bits > exist in that 128-bit address, the remaining bits are by definition > IID. I suspect Brian tried to explain that some people interpret prefixes for on-link determination are a different kind of prefix than the "subnet prefix" as defined in Section 2.5 of RFC4291. For those people it's not obvious whether the remaining bits that follow the on-link prefix are "by definition IID". Before saying "those people are simply wrong because section X of RFC Y says this...", please see below. > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ > > > b) Because some people seem to be limiting their use of 'IID' to the SLAAC > > meaning of 'prefix'. > > I see only a small ambiguity in this regard. From RFC 4862: > > interface identifier - a link-dependent identifier for an interface [...] > This definition does not limit the IID to 64 bits either, giving RFC > 2464 only as an example, and saying only that "in many cases," the > IID is derived from the link layer address. Without specifying how > long that might be. And it refers back to RFC 4291, which does not > limit IID to 64 bits. I don't see how this can be a counter-argument to what Brian said, which was not about the length of IID. The original question was whether the "remaining bits" in the above context are considered to be IID. In that context, 'b' should be interpreted as: - some people seem to be limiting their use of 'IID' to SLAAC meaning of 'prefix', i.e, a prefix advertised via RA PIO with A flag being 1. - if a prefix for on-link determination (a prefix advertised via PIO with L flag being 1 and A flag maybe being 0) is different from this 'SLAAC meaning of prefix' (either in the bit pattern or in the prefix length), this means the "remaining bits" are not IID "by definition" for those people since in their definition "IID" is used only for remaining bits that follow an SLAAC meaning of prefix. Whether the IID in those people's definition is fixed at 64 bits is irrelevant in this context. Here, I'm not trying to convince you that their view is correct. To me, however, those "some people" and people like you or Brian have both some valid points, and it's not that one of the views is definitely correct and the other is completely wrong. The difference of the views comes from the fact that RFC4291 or its bis is not super crystal clear and there is some possible inconsistency between it and other IPv6 RFCs, leaving questions like this one to one's interpretation. It seems that people believing one particular view tend to refer to some specific part of those RFCs or drafts or existing implementations that are convenient to reach their favorite interpretation, but the reality is that other interpretations can be quite possible. I don't expect either group with a strong opinion to agree with the other, but at least unless they recognize both groups have some reason to believe a particular view, we will never be able to escape from this gridlock, at least in the scope of rfc4291bis. -- JINMEI, Tatuya From nobody Thu Jul 20 14:04:21 2017 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 89D0B12FB9C for ; Thu, 20 Jul 2017 14:04: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 gjIpWx4YkzVr for ; Thu, 20 Jul 2017 14:04:18 -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 5808F12ECB7 for ; Thu, 20 Jul 2017 14:04:18 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id h199so22410074ith.0 for ; Thu, 20 Jul 2017 14:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cdDR3m7b4v3lrTNo6AYu6kLMWS7sED1pIWxXWWnelvA=; b=tHgvJhcRRruzmHvAXPxsM+WpkaGBfvG6N4z1gIGye4IGHZThnGtlw1d8Lvusn0vmLW kGd2h/e0cKfExwpLf9Yy7lUwgK5gsqe3C9+7EX7zlco+vpsXsbkHd1260b+UfWcqqwA4 ioXaSYbvdZ+0/w8I8OChJuZMng82pS8SjsMe8yU3UwD/be9sNqEKOTNdauhDAIG6PPWx QztK6/JMYsyFozWrHDOFdaiXRPGVh9HaPmbB3vnxhCczjdZLwAYk2BW+x4kuhxpBm4p/ 5uY+9qD/+BL+d+qVMMk0I4Xp+hX6Zd2XFgL9eOGlsiw+LMNMKXD6tsBt6A5lZ5LO7Fr7 L3Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cdDR3m7b4v3lrTNo6AYu6kLMWS7sED1pIWxXWWnelvA=; b=Iz7yXPtQGSn666fEBMY/7+d9D2/4GuoJS2b7RSEAoJ7GY7nu3AIRQLEc1hk5+JimVf RSf54pZVwQFhvHlaHx5rem9lEbPye1Kktgu3kRdEZ26x29EO4iL0pzXLToSqZU/w9Bcg 7d04L3sQHMSRqOoFIucdxcfxPiSoqCwUVeYG/xQAloEvg/fTFyJa77m4c6G6owO7RCcQ YUp9cpPP0qVOlAQVyb2ly476MWCIdjDQontKdTztiY2hCwkdr/zqnynH8/d9iL98i9fC wOvvTN+XL5whRY9gY0D9AywLw0PnbPl3hB8wG5W82Ot8wP7P1XB6z3n9nl1ap5xMDm9q eThw== X-Gm-Message-State: AIVw111sAYdGbnhVWPEkQnRtu2Ouot9OuO4SvAVsZ9cehRf5fQGTThYx SKPhbrNDEh0l15UDig0S2wO+z5RsmA== X-Received: by 10.36.3.72 with SMTP id e69mr5009035ite.154.1500584657574; Thu, 20 Jul 2017 14:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.173.162 with HTTP; Thu, 20 Jul 2017 14:04:17 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Sowmini Varadhan Date: Thu, 20 Jul 2017 17:04:17 -0400 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Lorenzo Colitti Cc: Brian E Carpenter , Erik Nordmark , 6man , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 21:04:19 -0000 On Thu, Jul 20, 2017 at 7:40 AM, Lorenzo Colitti wrote: > On Tue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter > wrote: >> >> Fair enough. My original point was that having DAD be less reliable >> than basic ND, under adverse conditions such as an overloaded >> 802.11 network, is IMHO a real problem. Yes, duplicates should >> be extremely rare but they can also be extremely harmful. > > > Where "extremely rare", according to Warren's calculator, means: > > 1 out of 3,689,385,709 times with 100,000 hosts per network > 1 out of 368,971,778,652 times with 10,000 hosts per network > ... > > Don't we have more important problems to solve? Hmm, one could extend that argument to seat-belts, air-bags, air-travel-safety-regulations, and a number of things, but I, for one, am glad, someone spent some time trying to figure it out :-) (even though, I'm also glad I've never had to use one of these back-up-safety-plans). YMMV, of course. --Sowmini From nobody Thu Jul 20 15:21:08 2017 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 74420126B7E for ; Thu, 20 Jul 2017 15:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 C4uhb2zi7WfK for ; Thu, 20 Jul 2017 15:21:05 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 0399E129AFF for ; Thu, 20 Jul 2017 15:21:05 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q25so14662755uah.1 for ; Thu, 20 Jul 2017 15:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nnAcFhsgXWYWB+UBUsXlZHqNl8KGpNvZYGK7J8zwPl4=; b=HrDH3kWoUJlC5Pyf16zvkEgz3+kmCdruNrNUFFMxDIGfeVkr09HG21tZlwSAlvmlVj IoRv0K5TYTXXafiMLOIz7vBAGZzW/U6t/uYmpzGQBMWZw7Z1P6HtQPqe14MWkbStPo7o JwCacI9kjweeHBZnU6tuz2x2q3n3R0vY87beRbtRVqiixUInQgRrUnDHYOuz7NdcgiJ7 k+U15cHTUCIp+ArwxPS7bG75A5mZO5Zcc+OjoQvbVvsJsjuhmXU15UQSoaDdw4EwbWbp VpYOISP29Ty5HrzW1SXd7aT4UVo7i8Y2yYbA/4m21D3Z9bMe7efSFLvIHCg7pUZJhG8R eo+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nnAcFhsgXWYWB+UBUsXlZHqNl8KGpNvZYGK7J8zwPl4=; b=NxezweZpUa7EHhb9E87sjGRhhDMJcJPZPAqE9QN7negZDshN9JhqHf1aOuNlygIVRP o2fKQhM2k+/e8EWRh9PQfM7LTT7P8JB3aLtGfPc3/4z3E93Srtt+3UrQohov5b5ciEhO hRHgtqKjELBzO5w1aSCg9D8qo1nB+CeKkf0Lx9YbUvkkMsJF6KBCJ2bPlv50BiJZUwN5 rRB0znKPyuLwjBZJzMhZ6h0+YKWshhDfhzURvbm6V76tst9GgsRqO8AF4v7L9IRk+TOo JFZ52+UAonUKFJnLtY7wvTwXuTiUz1IInFmsJA7G0kMo3QNqfMspTTfGI4PdcQEr83lm L5kQ== X-Gm-Message-State: AIVw113Z0PlHaDKNOVoHk0MKhSrdleqT4Z3QmbOambswEMNWb0DAaZSP f4pSsr3lrJWn2uQqbttAj58wOGvHzw== X-Received: by 10.159.52.79 with SMTP id s15mr3302921uab.157.1500589264067; Thu, 20 Jul 2017 15:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 20 Jul 2017 15:20:33 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Mark Smith Date: Fri, 21 Jul 2017 08:20:33 +1000 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Sowmini Varadhan Cc: Lorenzo Colitti , Erik Nordmark , 6man , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 22:21:06 -0000 On 21 July 2017 at 07:04, Sowmini Varadhan wrote: > On Thu, Jul 20, 2017 at 7:40 AM, Lorenzo Colitti wrote: >> On Tue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter >> wrote: >>> >>> Fair enough. My original point was that having DAD be less reliable >>> than basic ND, under adverse conditions such as an overloaded >>> 802.11 network, is IMHO a real problem. Yes, duplicates should >>> be extremely rare but they can also be extremely harmful. >> >> >> Where "extremely rare", according to Warren's calculator, means: >> >> 1 out of 3,689,385,709 times with 100,000 hosts per network >> 1 out of 368,971,778,652 times with 10,000 hosts per network >> ... >> >> Don't we have more important problems to solve? > > Hmm, one could extend that argument to seat-belts, air-bags, > air-travel-safety-regulations, and a number of things, but I, for > one, am glad, someone spent some time trying to figure it out :-) > (even though, I'm also glad I've never had to use one of these > back-up-safety-plans). YMMV, of course. > I had a very quick look. There's no mention of anycast addresses. They're need to be ignored because they're specifically intended to be duplicated. Regards, Mark. > --Sowmini > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jul 20 17:27:21 2017 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 BF2B5131B44 for ; Thu, 20 Jul 2017 17:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3H2kuEANK5vM for ; Thu, 20 Jul 2017 17:27:19 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 CD5D6131B3F for ; Thu, 20 Jul 2017 17:27:18 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so35018236uax.3 for ; Thu, 20 Jul 2017 17:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=i5Y9DZN+t9uRripW5KCE5uhlnpYiGcbdBXlQ2fPFM+U=; b=B/n+dVHFYzuCm/0kKN74VnUTjgwCO90ANm37lhwZBlTEre0P1+WuwsqCs1RskxBFEp O9bMcfzUwGONn8z9yN4PPKFjZjdzlHFhtY/vn65dFlpjvUoeMv0yRvxABrSTJS/Rev3W //oV/mTx09R4cmjy18VQWuyQ+W5ZP609GJFvjmB+aM97tlCCYQ21guY61Jw2Mjt1vKdC 9qBcJf6f+X+IxGHe9KwnxYTa8vMDfjSOcc84vVrNAf98uq7pnaQSjl9/ryYLdKEGIc3X lOlZaAY4R76+Qyhuuu4QP9BJF6YH4vjm88LXSQCby0rL6EZgKAIt/LuHJ2AKujg02vul fVaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=i5Y9DZN+t9uRripW5KCE5uhlnpYiGcbdBXlQ2fPFM+U=; b=MO3UFPXNjtJAMoVR8kEMDgHEZ/5YIQt2nvXW6c03Ykb80sMavaMAZ4yEiQ4uWGZ13V nExfpeUFd/fMdN7Vf2YF/bWEj6I6GBXmi1YgUDbmw8PTeJaPuPzxdNBEDNK2uM9veH8L qnZZUgNCA7NdNY9JulKqbN5Xlj8nEleRsAgnlLDwsGGk5EmNVZt7zibRPDo4IAGIXfUo m4LoC0CHDwXqekjK9EjX9FMciTJIsQZDb/cEVVTS2ZdPrMqtdzD9zdGdKSUemEhrz2vr TJRM48pnzzVSvCKcNcsuv9jPfoyR6y0fabbQjfPEdEHLbUsA/lqL1EIY4sxbjdjIPKln Smiw== X-Gm-Message-State: AIVw111AsoXW+FfJGB0831UlBfW2kczCU8r+pOSFHCMhldYRYX6oAzoQ BUgM4G1TZ9jvSM5KpewwZBi94TdxdQ== X-Received: by 10.31.94.138 with SMTP id s132mr3107435vkb.206.1500596837791; Thu, 20 Jul 2017 17:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 20 Jul 2017 17:26:47 -0700 (PDT) From: Mark Smith Date: Fri, 21 Jul 2017 10:26:47 +1000 Message-ID: Subject: Battling human nature (Re: Prefix Delegation and hosts) To: Simon Hobson Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:27:20 -0000 On 21 July 2017 at 02:36, Simon Hobson wrote: > joel jaeggli wrote: > >>> Why pick /80 instead of something more familiar such as /120? The >>> requesting router can even assign prefixes based on RFC1918 IPv4 /24 >>> prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a >>> few steps in the race to the bottom. >> >> Presumably if your goal is to allow downstream devices to futher segment >> you will assign the shortest prefixes you can get away with in your >> model. if your goal is micro-segmentation of things like for example for >> containers or VMs, you'll probably assign as long as you can get away >> with e.g. /126 /127 /128 which can be littered all over the address >> space if you're so inclined. > > I think you missed his point. > The moment anyone admits that a network can have less than 64bits of addr= essing to play with, then the sky will fall in, there'll be plagues of locu= sts, the world will end, and everyone will start getting /128 single addres= ses delegated to them. Thus, there should not be any document anywhere even= admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bot= tom of the pond use it as an excuse to delegate smaller than multiple /64s = to their customers. > I think your scepticism is overlooking human nature. Human nature is to try to avoid change and to do what is familiar. It is motivated by the fear of the unknown. Human nature is to try to be lazy by default - to do the minimum necessary to achieve the intended outcome. The combination of these two natures means trying to do the most familiar with the least effort. Since giving a site a single public address and having the site use NAPT are the IPv4 norm, there will be a strong human tendency to try copy that norm in IPv6 if possible. It would be "the most familiar with the least effort". If a norm of per-site IPv6 /128s and NAPT became reality, it also makes deploying IPv6 pointless. The fundamental goal of IPv6 is to have enough public addresses so that each host that wants a globally unique and public IPv6 address can have one, for something in the order of at least the next 30 years. Allowing IIDs that are smaller than 64 bits and more specifically arbitrary in size formally permits the creation of IIDs that may be too small for the number of IPv6 hosts that somebody wants to attach to the link. That formality would act as a strong signal that the IPv4 norm of a per-site single public address and NAPT is perfectly acceptable in IPv6 - despite it being a direct contradiction to IPv6's raison d'=C3=AAtre. Regards, Mark. From nobody Thu Jul 20 17:45:24 2017 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 8545D12942F for ; Thu, 20 Jul 2017 17:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u1a6ozl8xrHu for ; Thu, 20 Jul 2017 17:45:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 7DDAB128BA2 for ; Thu, 20 Jul 2017 17:45:20 -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.ams1.isc.org (Postfix) with ESMTPS id 55FB424AE08; Fri, 21 Jul 2017 00:43:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E8AE3160044; Fri, 21 Jul 2017 00:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D76AC160045; Fri, 21 Jul 2017 00:43:59 +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 7rMsKYwfax98; Fri, 21 Jul 2017 00:43:59 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6218E160044; Fri, 21 Jul 2017 00:43:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4519A7F0C564; Fri, 21 Jul 2017 10:43:57 +1000 (AEST) To: Mark Smith Cc: Simon Hobson , 6man WG From: Mark Andrews References: Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) In-reply-to: Your message of "Fri, 21 Jul 2017 10:26:47 +1000." Date: Fri, 21 Jul 2017 10:43:57 +1000 Message-Id: <20170721004357.4519A7F0C564@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:45:22 -0000 In message , Mark Smith writes: > On 21 July 2017 at 02:36, Simon Hobson wrote: > > joel jaeggli wrote: > > > >>> Why pick /80 instead of something more familiar such as /120? The > >>> requesting router can even assign prefixes based on RFC1918 IPv4 /24 > >>> prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a > >>> few steps in the race to the bottom. > >> > >> Presumably if your goal is to allow downstream devices to futher > segment > >> you will assign the shortest prefixes you can get away with in your > >> model. if your goal is micro-segmentation of things like for example > for > >> containers or VMs, you'll probably assign as long as you can get away > >> with e.g. /126 /127 /128 which can be littered all over the address > >> space if you're so inclined. > > > > I think you missed his point. > > The moment anyone admits that a network can have less than 64bits of > > addressing to play with, then the sky will fall in, there'll be plagues > > of locusts, the world will end, and everyone will start getting /128 > > single addresses delegated to them. Thus, there should not be any > > document anywhere even admitting that /64 isn't sacrosanct lest the ISPs > > inhabiting the muddy bottom of the pond use it as an excuse to delegate > > smaller than multiple /64s to their customers. > > > > I think your scepticism is overlooking human nature. > > Human nature is to try to avoid change and to do what is familiar. It > is motivated by the fear of the unknown. > > Human nature is to try to be lazy by default - to do the minimum > necessary to achieve the intended outcome. > > The combination of these two natures means trying to do the most > familiar with the least effort. > > Since giving a site a single public address and having the site use > NAPT are the IPv4 norm, there will be a strong human tendency to try > copy that norm in IPv6 if possible. It would be "the most familiar > with the least effort". > > If a norm of per-site IPv6 /128s and NAPT became reality, it also > makes deploying IPv6 pointless. I hate to be the devil's advocate here but IPv6 + NAPT is still better that IPv4 + CGN + NAPT. Both however are still bad. > The fundamental goal of IPv6 is to > have enough public addresses so that each host that wants a globally > unique and public IPv6 address can have one, for something in the > order of at least the next 30 years. > > Allowing IIDs that are smaller than 64 bits and more specifically > arbitrary in size formally permits the creation of IIDs that may be > too small for the number of IPv6 hosts that somebody wants to attach > to the link. > > That formality would act as a strong signal that the IPv4 norm of a > per-site single public address and NAPT is perfectly acceptable in > IPv6 - despite it being a direct contradiction to IPv6's raison > d'tre. > > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 20 18:05:41 2017 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 C9D7C126BFD for ; Thu, 20 Jul 2017 18:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 bpkyyl_fzG6A for ; Thu, 20 Jul 2017 18:05:38 -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 BE2921287A0 for ; Thu, 20 Jul 2017 18:05:37 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v139so250680wmv.0 for ; Thu, 20 Jul 2017 18:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L5NSiJgSIETJPxoD2QnvaYp1LKp2PYQJB+yU/rCS7FU=; b=PuEo1yjGNtuYkgZ0570xvuL00ZmGJmVEik7XdX+mokTDTPa9D+8t/SPxpcxIAsBLFJ uXY0GIi/zPKWTlXAgWnyxNTedn0nlRIt3pJXmcOwJlf/fWZZ3zGL3ENV1sqYwn77Sa3L TxHfw4jcA9PwHatrcZZwY+6hgtsNEyTFkmlfx0fE9IDK1PJY19NB/c614Hy9PS15oyBg uuVsw6YLJUhN01NpiC6NZTI+yp3uHajbHYXQYq2erMm/XWVvSopmf7Z4fxn1a8CvPIdb dVD+dGsdfTW/qdcrl4ekp2AsRSbuIvf+X1ot43KRqsfRvIVsi4RKPZI8slqfyB4jsa2n IhYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L5NSiJgSIETJPxoD2QnvaYp1LKp2PYQJB+yU/rCS7FU=; b=ntper3nbLk/6ppcJCssJGeB9zpN+4mx9W+tweOXLV38kjIVHJ6MKaFW0FIStxzGPfT T1F4m8uweQ6RBu9ZjTndgZZnMN5CeBSjZK7P7/8tStWYfAzEd7NVHcE+kb5eJQ6MJ5qt 2I+aKdR9lciC3h8ijyIEpkR9zRNd9w3NWcEFe8OscUphVkqHpdjtwsH5wEX+S/bsonD5 YR2iAoPIcOg6V8oKhfZoDWWoCGAcUfwxyC5fZGXKb70D8+RRUdTxAYCnIaU5RP07fzh5 pfLPdeNmKHWjUNUWrtzJ8lM8jS61m7xWAdLiEEMqjvRVGyjVCylAhQLFWPP4xgTwp7F6 Ikdg== X-Gm-Message-State: AIVw110ZjpGM+eolFSF2x1kRZ0umiWr7s7D1WwsBwj3JKTom3uNQqcqh u/LrJK41Yr9a3gRUJ+xuI4CGbbjmxhng X-Received: by 10.28.175.135 with SMTP id y129mr3526219wme.87.1500599136194; Thu, 20 Jul 2017 18:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.66 with HTTP; Thu, 20 Jul 2017 18:05:35 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 20 Jul 2017 18:05:35 -0700 Message-ID: Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) To: Mark Smith Cc: Simon Hobson , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 01:05:40 -0000 On Thu, Jul 20, 2017 at 5:26 PM, Mark Smith wrote: > On 21 July 2017 at 02:36, Simon Hobson wrote: >> joel jaeggli wrote: >> >>>> Why pick /80 instead of something more familiar such as /120? The >>>> requesting router can even assign prefixes based on RFC1918 IPv4 /24 >>>> prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a >>>> few steps in the race to the bottom. >>> >>> Presumably if your goal is to allow downstream devices to futher segmen= t >>> you will assign the shortest prefixes you can get away with in your >>> model. if your goal is micro-segmentation of things like for example fo= r >>> containers or VMs, you'll probably assign as long as you can get away >>> with e.g. /126 /127 /128 which can be littered all over the address >>> space if you're so inclined. >> >> I think you missed his point. >> The moment anyone admits that a network can have less than 64bits of add= ressing to play with, then the sky will fall in, there'll be plagues of loc= usts, the world will end, and everyone will start getting /128 single addre= sses delegated to them. Thus, there should not be any document anywhere eve= n admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bo= ttom of the pond use it as an excuse to delegate smaller than multiple /64s= to their customers. >> > > I think your scepticism is overlooking human nature. > > Human nature is to try to avoid change and to do what is familiar. It > is motivated by the fear of the unknown. > > Human nature is to try to be lazy by default - to do the minimum > necessary to achieve the intended outcome. > > The combination of these two natures means trying to do the most > familiar with the least effort. > > Since giving a site a single public address and having the site use > NAPT are the IPv4 norm, there will be a strong human tendency to try > copy that norm in IPv6 if possible. It would be "the most familiar > with the least effort". > > If a norm of per-site IPv6 /128s and NAPT became reality, it also > makes deploying IPv6 pointless. The fundamental goal of IPv6 is to > have enough public addresses so that each host that wants a globally > unique and public IPv6 address can have one, for something in the > order of at least the next 30 years. > > Allowing IIDs that are smaller than 64 bits and more specifically > arbitrary in size formally permits the creation of IIDs that may be > too small for the number of IPv6 hosts that somebody wants to attach > to the link. > Mark, I don't understand the basis for unilateral statements like this that /64 is the _only_ usable prefix length and anything else work. Sure /128, /127, /126 are silly, but I could surely believe that most sites could use a /96 which allows 4B hosts in the network without resorting to NAT or running out of IP addresses. Tom > That formality would act as a strong signal that the IPv4 norm of a > per-site single public address and NAPT is perfectly acceptable in > IPv6 - despite it being a direct contradiction to IPv6's raison > d'=C3=AAtre. > > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jul 20 18:54:31 2017 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 1B2D8129AF3 for ; Thu, 20 Jul 2017 18:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HKOUjQfyfDVD for ; Thu, 20 Jul 2017 18:54:27 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 D1A3B1287A0 for ; Thu, 20 Jul 2017 18:54:26 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id f9so35889542uaf.4 for ; Thu, 20 Jul 2017 18:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dqa1NiOceiBJrfkaH1gMKPq/ChOcWiaaQb1+LplPRCY=; b=VBk6hi3m3E5SCYfWts9G4/RWqXAs63dc16v6KnVOd0MZhP6RogteqsLPRf5c2Ch92+ NIZ3Hd+gQ98TuGoGru+SdMLwfCAMMuwiRxBzcnvi24Iu86ST6JIbsi3JLsnG4Dh6Ucxz OgCCHpXwnxLzsqHNh7+dbGeYzl+Wu457U9HvR6ucezk7m9cLA6Z3wdnztfgKqtHG7hKn 9Cesr3ZFhMcFj5ROsoUnyeTh3t9WcLshFGQ+mUgGgvViL/EteKlyo1eO+bTVEc+vszQp HxYLdMJ/QOiQd3fiUQSmtSmaWuLTSegC2btAHZ/Q717FaF+OIPm0l1/w5nwtV+qTdn73 i6Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dqa1NiOceiBJrfkaH1gMKPq/ChOcWiaaQb1+LplPRCY=; b=AAJZGGJqzWIUdT9K1IpquM2kFvo+MAcyFLHc70gWsQXe2760ec3VfZvfVcKsFkCJ60 DhkBZEf2exiENITWdVfTNFzUfWgNlKUJNF6pNZBdovzjREaTrAhfco7McoB8z0MXGG8e ZQyKjfxm1Hyx/9latKDvFoykhKp4NSlOpsjXm1k5FLRzJq9wpf/KnvdXW6O9YTE57gKp fAfMEh0FdIC+Dxegxy1/7Zldgai1PyzDUvyIithLDNqKxlxJ/mXOY2slUgjWGwBcFpaw w3mEXGkQly9LgMcJlzlxS2lX1ar50LUKTq2+jnnkQSP35HGy5zl1qkAqq+vDmp78ZaBU VRKg== X-Gm-Message-State: AIVw113BPaszsCX05dtX7bokKdULPzSczNdPMB6Ngm7umKr0CFt3xim/ NdhNYuRFlOExvc1nV2ry7NGznvgmGA== X-Received: by 10.31.59.69 with SMTP id i66mr2674675vka.105.1500602065887; Thu, 20 Jul 2017 18:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 20 Jul 2017 18:53:55 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Fri, 21 Jul 2017 11:53:55 +1000 Message-ID: Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) To: Tom Herbert Cc: Simon Hobson , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 01:54:29 -0000 Hi Tom, On 21 July 2017 at 11:05, Tom Herbert wrote: > On Thu, Jul 20, 2017 at 5:26 PM, Mark Smith wrote: >> On 21 July 2017 at 02:36, Simon Hobson wrote: >>> joel jaeggli wrote: >> Allowing IIDs that are smaller than 64 bits and more specifically >> arbitrary in size formally permits the creation of IIDs that may be >> too small for the number of IPv6 hosts that somebody wants to attach >> to the link. >> > Mark, > > I don't understand the basis for unilateral statements like this that > /64 is the _only_ usable prefix length and anything else work. Sure > /128, /127, /126 are silly, but I could surely believe that most sites > could use a /96 which allows 4B hosts in the network without resorting > to NAT or running out of IP addresses. > Is unique host addressing the only requirement? "48-bit Absolute Internet and Ethernet Host Numbers", July 1981 http://www.textfiles.com/bitsavers/pdf/xerox/parc/techReports/OPD-T8101_48-Bit_Absolute_Internet_and_Ethernet_Host_Numbers.pdf "Xerox internets and Ethernet local computer networks use 48-bit absolute host numbers. This is a radical departure from practices currently in use in internetwork systems and local networks." "Ethernet host numbers are 48 bits long [Ethernet80]. 48 bits can uniquely identify 281,474,977 million different hosts! Since the Ethernet specification permits only 1024 hosts per Ethernet system, the question that is often asked is: "why use 48 bits when 10, or 11, or at most 16 will suffice?" This paper answers this question, and describes the benefits of using large absolute host numbers. " (I think there is quite a bit of significance in the date of that paper - 35+ years of Ethernet deployment has provided plenty of opportunity for that addressing size decision to be proven incorrect.) Surely the global network layer address space should always be much larger than a link-layer address space, and the portion of global address space available on a link should be at least as large as the link-layer's address space? A network layer address space available on a link that it is at least as large as the link-layer address space would ensure that a links traffic capacity is the primary and fundamental constraint on the number of devices that can be attached, rather than the ability to uniquely identify them at either the link or network layers. Your suggested /96 or 32 bit IIDs are still smaller than what the hosts have at the Ethernet link layer. We could settle on /80s and 48 bit IIDs, which is what was described in the first edition of the IPv6 addressing architecture RFC, RFC1884. For various reasons 64 bit IIDs evolved on from that per RFC7421. 48 bits is probably enough for other beneficial IID properties such as security, privacy and low likelihood of collision. However, is the effort of shifting from 64 bit IIDs back to 48 bit IIDs worth the benefit of getting back those 16 bits? Regards, Mark. From nobody Thu Jul 20 19:18:03 2017 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 E685013167A for ; Thu, 20 Jul 2017 19:18:00 -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 hQHRjZOt2GFO for ; Thu, 20 Jul 2017 19:17:59 -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 A07641272E1 for ; Thu, 20 Jul 2017 19:17:59 -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 v6L2HwAY061295; Thu, 20 Jul 2017 19:17:58 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6L2HtaL061263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 20 Jul 2017 19:17:55 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 19:17:54 -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.1263.000; Thu, 20 Jul 2017 19:17:54 -0700 From: "Manfredi, Albert E" To: Mark Smith CC: 6man WG Subject: RE: Battling human nature (Re: Prefix Delegation and hosts) Thread-Topic: Battling human nature (Re: Prefix Delegation and hosts) Thread-Index: AQHTAbgpTYNtg2Hx7EaHyf6ofbDP/qJd7NKAgAANgYD//4zswA== Date: Fri, 21 Jul 2017 02:17:54 +0000 Message-ID: <710a7d9ef9444eefa4f45d4ea7a29e03@XCH15-06-11.nw.nos.boeing.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 x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 02:18:01 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith > Surely the global network layer address space should always > be much larger than a link-layer address space, Yes, that's intuitively obvious. > and the portion of global address space available on a link > should be at least as large as the link-layer's address space? That's problematic. The "link layer address space," in this instance, is no= t really an address space at all. It is instead a unique product ID code (m= anufacturer plus serial number). There's no reason to assume that an attemp= t at creating globally unique product IDs has any relation to the address p= rovided in a globally routed network. It was just a convenient way of defin= ing an interface, that was supposedly guaranteed to be unique, at least on = that subnet. Making the IID smaller than a product ID code should not be a problem. Look= at your automobile's VIN. It's humongous. Surely, we're not going to insis= t that the VIN become part of the car's Internet address? It's just not log= ical to assume that a globally unique product ID code must be part of a glo= bal address. Although if we wanted to create a flat global address scheme, = stripping off the address prefix completely, it would be a decent idea. I think the argument about SLAAC IID collisions within a subnet prefix is r= easonable. Maybe the privacy concerns too, but certainly not on all network= s. But we shouldn't take this 64-bit religion too far? Bert From nobody Thu Jul 20 21:40:55 2017 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 04E45126DFF for ; Thu, 20 Jul 2017 21:40:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hVTi36bH-Q7l for ; Thu, 20 Jul 2017 21:40:52 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 D241E126C23 for <6man@ietf.org>; Thu, 20 Jul 2017 21:40:52 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id s70so19723045pfs.0 for <6man@ietf.org>; Thu, 20 Jul 2017 21:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4PLhS1uxrjpxe8jqPheynUp9Se2SGexHHthmCfbq6WE=; b=mM3CwQgXLaG/KdDYvlFOlZiUjsUy/tfAcklRIkdlK/ZlxPQ8IGmh4WCJhCcC1uMo8l CFihQnRaIyoayEGnxUUtwgiyLiwrbR5NCVo1V4a3oMvfjwN16kqEcAHq+EwunqA+vtWB 0eZJ2qHJ4oVV87OJxQWaPn8hXd+APyBj62HhOfMUzTMuQq+bF34Icib/DOzOtK2nC93w /TiyDMxXrwthv3SAkzLia8XGA4nOWYy7jo21zAMnz3n3T8UNQXQ/EbSmASLajan3BLDb fcDeMsOHimBG26FxJDkSY68HjVIBv/c8oxIo1h1Jr1OqyWUUupYCDyy7HS/Lvuoqnb4T VMPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4PLhS1uxrjpxe8jqPheynUp9Se2SGexHHthmCfbq6WE=; b=pEeQOCVcwdKB+cZFHR6KfPKv3V6KeeS3O0vxCPSn9wwdVAto2wchGlHH4let8tUTs3 ZKpg8WWA5oFniEC7N+qAGVJ9EzYl7dg2SWcoT55nH/lnNpwjsoamvCiKH+zgvsIh2Img UXkADirfqGWeqUcFZcn/bUEs5lMYQKTWVE11LxcF7wF+IYKfpUe+f6TKt6jRxNbh1Ql5 h9NNZbDLFBS0CwkcMHn3hziRRCnkwI4UViHOKBMiCL5vIUBqPQUp2ihVsWHOWMf72G1p XbOAvl4TWbIBJXddw0ay3j6z8CwMpvrhdCAjojc5vWnjyDtT3r4/YWvjiVWF4gZrvatF H7BQ== X-Gm-Message-State: AIVw113S3CRhrs2JfioqlMgVgI5eHLrZF+ww0eTBYOyviwgNj7YuDaDP domcV6UlWX6t6bxJ X-Received: by 10.84.224.13 with SMTP id r13mr6554003plj.327.1500612052175; Thu, 20 Jul 2017 21:40:52 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id t3sm6464570pfb.147.2017.07.20.21.40.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 21:40:51 -0700 (PDT) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Fernando Gont , Tim Chown Cc: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> References: <4d1ef3d1-1c21-ec76-7c1b-7bb0f5eaa805@si6networks.com> <51F41F55-27B2-43BC-9199-FBE59B98BCFB@jisc.ac.uk> <6a64b2ad-6cc6-40e3-efa1-dee2eb2206cf@si6networks.com> <71446686-1B03-4A06-B4D3-74AFF6B98C14@jisc.ac.uk> <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <71240a1a-6e8f-3509-a2f2-dc38308ff1c1@gmail.com> Date: Fri, 21 Jul 2017 16:40:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2d54e5d5-b69d-e43b-8559-1c6b5de8e58b@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 04:40:54 -0000 On 20/07/2017 23:58, Fernando Gont wrote: ... > My mental model is that a bis document essentially incorporates errata > and minor changes to a previous RFC. But this doesn't seem whre we want > to go here. I think that is actually an over-interpretation** of the suffix "bis". It isn't in any way an IETF rule, it's just a habit (copied from ISO or ITU-T, I suspect). All it tells me is that draft-something-rfc9999bis is intended to *obsolete and replace* RFC 9999. That doesn't mean that it is based directly on the text of RFC 9999, although it might be, and often is, for convenience. It's only an ill-defined naming convention, in the end. ** and the dictionary meaning is different: twice; for a second time; again; once more. Brian From nobody Thu Jul 20 21:58:38 2017 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 77E9F126D05 for ; Thu, 20 Jul 2017 21:58:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GLkO286xE0eq for ; Thu, 20 Jul 2017 21:58:34 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 DC333126C23 for ; Thu, 20 Jul 2017 21:58:34 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v190so23737219pgv.2 for ; Thu, 20 Jul 2017 21:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/xLL7Mz370kLn7ERx6oqLqoIBGbxDdvS2NEkzZEX9Qo=; b=oAiS/KuqbwaUZYRU2xgeipOJ5DMhEmjq3JayMbzMmQnrX+wPIgb5ZzCbkWP4NAT5In fwf8xVYBsW/f32Bwt8gtlHlcDb4AcG1M4guS1jvIo9ZfiHY68ihfSRIJioVfBjMrQAQ2 nlILGGXzHAgB+i9NUg2p/DCUWpZeKygYLVxen5kP5hDVpfZlpT43hr4MkvgPI/Ych6tE f8ZlJq2a9rn0hEyhJM2yDLFC7vKhOqIOkca7rvQ53PmlG+/1rruLVtC2yflydQEMk9nm xNaHFqnJww3Z2e3zkbyzYYrRRyugw6evbSQ7j8HFb0LbN7aaXSF9EgIcS3oJnpM97cLi HyNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/xLL7Mz370kLn7ERx6oqLqoIBGbxDdvS2NEkzZEX9Qo=; b=AUIM//3wY3XPyZjt9iEPtU9fh1wqlnYvhRxs+sQUF2Rq1myFJTTP+/D/8l22tbCxlt n4/l2PmpVzXXmFKHM3q34B54wev46OJCXNI40yxB9C7204UyvKZPAG19zcpJVjfNvDvD QC8lWhQBuFbiswWc8f4cgrLniQ0eC3Ow6QxXMss0dQGxl/VpHxYl+WhLbwmQ2wSPDZID AlVvBe0Z1M0sR7lWX/IL90HkKhu82J3apkUCwN+W3q3tW/UXWvbV8fQUGNleM7PyhgVp TzbxZ9zzwn8ZZB6l5fUQx0/kR4+sCUhtD2mfWwPdzX6G7E+ZTVyAquT0u1YOTbCH1CI5 3qzg== X-Gm-Message-State: AIVw110ynjtRdfQwreZuxat/+VqqmYrE3svzTFMi2DH+nXAAiijW0IRs +yLq3PCO4TKarht1 X-Received: by 10.99.147.19 with SMTP id b19mr6172604pge.67.1500613114299; Thu, 20 Jul 2017 21:58:34 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id f13sm6814944pgr.78.2017.07.20.21.58.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 21:58:33 -0700 (PDT) Subject: Re: rationale for the default of DupAddrDetectTransmits To: Lorenzo Colitti Cc: Erik Nordmark , =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 21 Jul 2017 16:58:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 04:58:36 -0000 On 20/07/2017 23:40, Lorenzo Colitti wrote: > On Tue, Jul 18, 2017 at 1:10 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Fair enough. My original point was that having DAD be less reliable >> than basic ND, under adverse conditions such as an overloaded >> 802.11 network, is IMHO a real problem. Yes, duplicates should >> be extremely rare but they can also be extremely harmful. >> > > Where "extremely rare", according to Warren's calculator > , means: > > - 1 out of 3,689,385,709 times with 100,000 hosts per network > - 1 out of 368,971,778,652 times with 10,000 hosts per network > - ... > > Don't we have more important problems to solve? Yes. Collisions caused by human error or by malicious action. At Three Mile Island, they assumed that nobody would forget to turn *two* valves back on. Actually, that proved to be much more probable that turning one of them on and forgetting the second one. Brian > From nobody Thu Jul 20 22:06:07 2017 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 4622C129B7A for ; Thu, 20 Jul 2017 22:06:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rJ4_FSps2O8N for ; Thu, 20 Jul 2017 22:06:04 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 DE8EC126C23 for ; Thu, 20 Jul 2017 22:06:04 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v190so23811091pgv.2 for ; Thu, 20 Jul 2017 22:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z//6ClSXA7LBiTCEebXez1tdcBi2UcCfF+Hj1sOvLjU=; b=qaQEKrl4mK+lTiLtyjRzUijRTQZttjF6faNTvrK90zUn9BAm1NvuR+mgjuQwvTpmos CRNLMmnRyM2PNxELEj7f/otXF7aLkPbYDCeBX89k7y0SGr6NnRnUogfVHRhGk3/2nth6 RwDoT10OiDR7rqdcgJGZ56D6kIcXoRLvroMdqye/gHpZTgHSJDc/s4dWs//8qk18gwnD oQJ1JTAzuRmFmDQ/m49NVLhajHvbay8qizyHWoEeOTh7tG4rwf2Kp7i5RmIs+W3Sxhnv fo+CUkHXew94dXD+9iX1v7eyXTlaISBcY4ulRdV9x9vSb6GF1v9gozPCoEB3SyLmU4I5 VF5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z//6ClSXA7LBiTCEebXez1tdcBi2UcCfF+Hj1sOvLjU=; b=PygFocgPBgd9YIisdPAXV00FbYcmkicst4O3TN1aLwJ4ksGrmxunm39ki/n9IskSO9 EA/ITKGmg5CbMzcQzVWmOT59KmqAZ9lg7oQrnCEHRSAGpI6oKYMmhpYbaU+rZTJKm8Bd Rcfei4Qz+EwOwzc1EbGdr9+vY367NqJPxNxXZgJxnVnIhjxZU1ZSi/AFulq6aj29EitJ Bi32rJR8a033XtIbT3puukZRYCfhU+EJwAhBKSMEeyXK/ZL71DpKNqRRnos4lr4gyop9 4A+LmBA4SwjWPzmEtyMFiEWCnA2HAt/oAlxeN2dY/Wr7ShtEv7QTP8wv7AIbGXCWfIxf f4Yg== X-Gm-Message-State: AIVw110klQtm7rYy/yStBuwvff7Vo2eg0kNTLJKSVx5nJfxArqLULN2l euOfrFN1OB0xLaV0 X-Received: by 10.84.232.134 with SMTP id i6mr6883173plk.50.1500613564206; Thu, 20 Jul 2017 22:06:04 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id b13sm6977349pfj.141.2017.07.20.22.06.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 22:06:03 -0700 (PDT) Subject: Re: Prefix Delegation and hosts To: Lorenzo Colitti Cc: "Templin, Fred L" , "ipv6@ietf.org" References: <382f4a7bed6d48bbb7156c74bad716d9@XCH15-06-08.nw.nos.boeing.com> <13f89708-ad07-4af6-c21c-76803dafba57@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <02c7ffe5-e71c-dce3-4e73-48f96d9c0c2b@gmail.com> Date: Fri, 21 Jul 2017 17:06:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 05:06:06 -0000 On 20/07/2017 23:45, Lorenzo Colitti wrote: > On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> If it gets a /64 and >> and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody >> upstream will know (or care). Of course, SLAAC won't work for the friends, >> but nobody upstream will know that either. (It should be a small matter >> of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that >> will show up in running code sometime.) > > > Why pick /80 Since you ask, because that allows for a 48-bit IID, which is big enough to satisfy privacy and collision requirements. /120 isn't, which means it would only be suitable for infrastructure components where neither personal privacy nor pseudo-random assignment is needed. I'm not convinced about the race to the bottom. But I'd better go and read Mark's message next. Brian > instead of something more familiar such as /120? The > requesting router can even assign prefixes based on RFC1918 IPv4 /24 > prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a few > steps in the race to the bottom. > From nobody Thu Jul 20 22:19:02 2017 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 3261712EAAA for ; Thu, 20 Jul 2017 22:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 AduK-yko4xnL for ; Thu, 20 Jul 2017 22:19:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A14126C23 for ; Thu, 20 Jul 2017 22:19:00 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6L5IuWh026581 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jul 2017 05:18:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v6L5IuuH021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jul 2017 05:18:56 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6L5Ito7027364; Fri, 21 Jul 2017 05:18:55 GMT Received: from oracle.com (/31.133.149.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jul 2017 22:18:55 -0700 Date: Fri, 21 Jul 2017 01:18:47 -0400 From: Sowmini Varadhan To: Mark Smith Cc: Sowmini Varadhan , Erik Nordmark , 6man , ???????????? Subject: Re: rationale for the default of DupAddrDetectTransmits Message-ID: <20170721051847.GA26792@oracle.com> References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> 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) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 05:19:01 -0000 On (07/21/17 08:20), Mark Smith wrote: > > I had a very quick look. There's no mention of anycast addresses. > They're need to be ignored because they're specifically intended to be > duplicated. > > Regards, > Mark. Is the above with reference to the anycast behavior described for 4861/4862? IIRC that should be ok? NS will go out with for the anycast target addr, but the NA will be unicast (or am I mis-remembering?) But I agree that the solaris implementation (which would sometimes solmcast the NA) would need adjustment. And if we formalize this into a draft for other implementations to follow, then we'd need to take that (and probably some other things, to make it generally applicable) into account. --Sowmini From nobody Fri Jul 21 00:46:22 2017 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 94B9012783A for ; Fri, 21 Jul 2017 00:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6a9U1f7kILuL for ; Fri, 21 Jul 2017 00:46:18 -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 904D012714F for ; Fri, 21 Jul 2017 00:46:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0FF81A2; Fri, 21 Jul 2017 09:46:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1500623176; bh=EUYTKMESBpNaouVa4AyAduQuOdMslYKmctxaLsWjnyU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Xu6DETrFQO8ItIsYzn9kHvMphdBK9Ctsftq1ExMXTkqHuZYRFJZEE0hUAPb8iwyAq OKYQ8880mHT1eyRklAmVkqcBcUmg+3Uih10KAp53zyhRr5TCI+W2LqOe+8pApsEs31 sCmpCMJO8OtZLa2zPmuslYGcrUOINYsJ8or78h50= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0CF17A1; Fri, 21 Jul 2017 09:46:16 +0200 (CEST) Date: Fri, 21 Jul 2017 09:46:16 +0200 (CEST) From: Mikael Abrahamsson To: Tom Herbert cc: 6man WG Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:46:21 -0000 On Thu, 20 Jul 2017, Tom Herbert wrote: > I don't understand the basis for unilateral statements like this that > /64 is the _only_ usable prefix length and anything else work. Sure > /128, /127, /126 are silly, but I could surely believe that most sites > could use a /96 which allows 4B hosts in the network without resorting > to NAT or running out of IP addresses. Yes, and why would a home need more than a single network, thus a /64? That's what a non-trivial amount of operators are doing right now. They PD /64 and only that. It's silly, it only allows single network in the home, but it's most likely due to copying IPv4 thinking that this happened. If we didn't have the /64 hard limit, they'd probably hand out a lot smaller network than a /64. So the thing is that if we allow smaller than /64, then if /96 is then enough for a user, then perhaps /112 is enough, or a /120 is enough, or why not a /124? Most people don't have more than 14 devices right? Or perhaps why do you even need more than a single address, it's working so great in IPv4, so there you go. I know there is fundamental disagreement on this topic, and I don't think we'll make people change their minds anytime soon about what they believe will be the consequence of changing the /64 default. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jul 21 00:57:34 2017 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 AFD77131BC3 for ; Fri, 21 Jul 2017 00:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DMN4dOzGhto3 for ; Fri, 21 Jul 2017 00:57:19 -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 4121C129B34 for <6man@ietf.org>; Fri, 21 Jul 2017 00:57:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6L7edWt004994; Fri, 21 Jul 2017 09:40:39 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201707210740.v6L7edWt004994@givry.fdupont.fr> From: Francis Dupont To: Brian E Carpenter cc: Fernando Gont , Tim Chown , Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids In-reply-to: Your message of Fri, 21 Jul 2017 16:40:56 +1200. <71240a1a-6e8f-3509-a2f2-dc38308ff1c1@gmail.com> Date: Fri, 21 Jul 2017 09:40:39 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:57:21 -0000 When following a number it can get a specific meaning: in a postal address bis (and ter) means something was inserted between two numbers (usually between N and N + 2 as streets have an even side and an odd side). In the IETF context I agree "bis" means more a revamp and major changes come from consolidation with other related documents published after. So in the RFC4941bis particular case the name is really arguable and IMHO if the new mechanism is not backward compatible the bis name should not be used. Now the I-D name is temporary so it should be more important to discuss about its content... Regards Francis.Dupont@fdupont.fr From nobody Fri Jul 21 02:26:17 2017 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 5D1C713147E for ; Fri, 21 Jul 2017 02:26:13 -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] 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 5BTEGSix9y4O for ; Fri, 21 Jul 2017 02:26:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id B6EE11317A1 for ; Fri, 21 Jul 2017 02:26:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dYUCB-0000F6C; Fri, 21 Jul 2017 11:26:03 +0200 Message-Id: To: ipv6@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 20 Jul 2017 13:39:23 -0700 ." Date: Fri, 21 Jul 2017 11:26:01 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:26:13 -0000 >Here, I'm not trying to convince you that their view is correct. To >me, however, those "some people" and people like you or Brian have >both some valid points, and it's not that one of the views is definitely >correct and the other is completely wrong. The difference of the >views comes from the fact that RFC4291 or its bis is not super crystal >clear and there is some possible inconsistency between it and other >IPv6 RFCs, leaving questions like this one to one's interpretation. >It seems that people believing one particular view tend to refer to >some specific part of those RFCs or drafts or existing implementations >that are convenient to reach their favorite interpretation, but the >reality is that other interpretations can be quite possible. I don't >expect either group with a strong opinion to agree with the other, but >at least unless they recognize both groups have some reason to believe >a particular view, we will never be able to escape from this gridlock, >at least in the scope of rfc4291bis. Independent of what RFC 4291 currently says, I would prefer IID to only refer to address configuration using SLAAC. What we currently have is that requirements on IID depend on the use case. If you use an IID in the context of SLAAC then we have one set of requirements (link dependent lenght), if you use it with a /127 prefix or manual config it's. This causes way too much confusion. Then again I'm of the opinion that the relevant sections of rfc4291bis need to be rewritten to be actually readable. The current text should not be published as an internet standard. From nobody Fri Jul 21 03:39:15 2017 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 9F9F812ECF0 for ; Fri, 21 Jul 2017 03:39:13 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FZy6a8iSu1Qf for ; Fri, 21 Jul 2017 03:39:11 -0700 (PDT) Received: from mail.sba-research.org (mail.sba-research.org [188.21.236.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D65127337 for <6man@ietf.org>; Fri, 21 Jul 2017 03:39:10 -0700 (PDT) Received: from SATVIEEX03.securityresearch.local (172.16.0.17) by SATVIEEX03.securityresearch.local (172.16.0.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Jul 2017 12:39:08 +0200 Received: from SATVIEEX03.securityresearch.local ([fe80::a91d:83ac:63e0:937c]) by SATVIEEX03.securityresearch.local ([fe80::a91d:83ac:63e0:937c%12]) with mapi id 15.00.1210.000; Fri, 21 Jul 2017 12:39:08 +0200 From: Johanna Ullrich To: Francis Dupont , Brian E Carpenter CC: Fernando Gont , Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> Subject: AW: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Topic: "RFC4941bis" and draft-gont-6man-non-stable-iids Thread-Index: AQHTAfSlU3QyWVcLoEaMNQ1+r7EaXKJeFvol Date: Fri, 21 Jul 2017 10:39:07 +0000 Message-ID: <1500633546946.27169@sba-research.org> References: Your message of Fri, 21 Jul 2017 16:40:56 +1200. <71240a1a-6e8f-3509-a2f2-dc38308ff1c1@gmail.com>, <201707210740.v6L7edWt004994@givry.fdupont.fr> In-Reply-To: <201707210740.v6L7edWt004994@givry.fdupont.fr> Accept-Language: de-DE, de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.100.18] 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.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 10:39:14 -0000 >> Now the I-D name is temporary so it should be more important to=0A= >> discuss about its content...=0A= +1=0A= =0A= Beyond Fernando's issues, I'd like to add the following:=0A= * Subsequent addresses are concatenated with each other. =0A= * There is no entropy added when calculating the next IID based on the curr= ent history value.=0A= * Instead, only values that are likely to be known by other parties (MAC ad= dresses) are included. =0A= * Initial randomization of the algorithm is rather low (only 64 bits).=0A= =0A= With regard to the specific algorithms that are proposed in draft-gont-6man= -non-stable-iids:=0A= I prefer to use randomized IIDs as it bears advantages. If a random number = generator became vulnerable at some point in the future, the generator woul= d be fixed anyway and the privacy extension implementation would automatica= lly benefit. In addition, no alternative version of the privacy extension f= or devices without stable storage is needed.=0A= =0A= The algorithm of RFC 4941 must not be used. An adversary is able to perform= address correlation having reasonable effort, and protection against such = attacks is the privacy extension's one and only purpose.=0A= =0A= Regards,=0A= Johanna Ullrich=0A= =0A= ________________________________________=0A= Von: ipv6 im Auftrag von Francis Dupont =0A= Gesendet: Freitag, 21. Juli 2017 09:40=0A= An: Brian E Carpenter=0A= Cc: Fernando Gont; Suresh Krishnan; 6man@ietf.org=0A= Betreff: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids=0A= =0A= When following a number it can get a specific meaning: in a postal=0A= address bis (and ter) means something was inserted between two=0A= numbers (usually between N and N + 2 as streets have an even side=0A= and an odd side).=0A= =0A= In the IETF context I agree "bis" means more a revamp and major=0A= changes come from consolidation with other related documents=0A= published after.=0A= =0A= So in the RFC4941bis particular case the name is really arguable=0A= and IMHO if the new mechanism is not backward compatible the bis=0A= name should not be used.=0A= =0A= Now the I-D name is temporary so it should be more important to=0A= discuss about its content...=0A= =0A= Regards=0A= =0A= Francis.Dupont@fdupont.fr=0A= =0A= --------------------------------------------------------------------=0A= IETF IPv6 working group mailing list=0A= ipv6@ietf.org=0A= Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A= --------------------------------------------------------------------=0A= From nobody Fri Jul 21 04:24:55 2017 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 AFF7B131483; Fri, 21 Jul 2017 04:24:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Zo57jjBSgS83; Fri, 21 Jul 2017 04:24:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A824B129B7F; Fri, 21 Jul 2017 04:24:47 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-9cfb.meeting.ietf.org [31.133.156.251]) by relay.sandelman.ca (Postfix) with ESMTPS id 825F31F8F6; Fri, 21 Jul 2017 11:24:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1851C1638; Fri, 21 Jul 2017 13:24:37 +0200 (CEST) From: Michael Richardson To: Fred Baker cc: IPv6 Ops WG , 6man WG Subject: Re: Turning on IPv6 Routers In-reply-to: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> Comments: In-reply-to Fred Baker message dated "Thu, 20 Jul 2017 16:22:56 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 13:24:37 +0200 Message-ID: <7172.1500636277@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:24:49 -0000 --=-=-= Content-Type: text/plain Fred Baker wrote: > Note that this is not as simple as it might sound. There are at least > three configurations that must be allowed for upstream: bridging the > ISP downstream and CPE downstream LANs, Address allocation via DHCP > IA_NA, and address allocation via SLAAC, and on the CPE downstream > LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a > flowchart for this or RFC 7084 defines the algorithms. The > implementation is going to have to enable all three, see which works, > and act accordingly. As an implementer of a PPPoE aggregator/access-router, I found that I had to invert 7084 to determine what I had to implement. It might be worth a document, if only so that ISPs would have something against which to issue RFPs. Maybe. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZceR0AAoJEJVM4Vb9/EKQCqkH/0c9FAxQkHkxtUenPlRkD5mR 77BCopNVhBb4Hvd+rnZaSBqUwldNCQy9gmEbCSirirbyinbpbwI1iOiJAuyb2Iqx PCJO7MfNTsSBJzYCF8x3yzORCs1RrrIlIdVXTwzZQZ8znnTihXha7YFic1XF4Hmb hkRQUxZc9m9MD9PndXnLLqFj4FlC/0V2JpVPwbLxAn1qLEaH0grKTWMXhxnGCF9L 1FikW9Wt82YXZdE/nOJ1wR3EVYuuNVt9Lr9CUctfYaJvcu9fO31+W2WMdXyzTh3N fxCyGKGdWBsLMIGAuzMnBNJErAGZsCNTWgA+NXjbpi9O77DOBIbtIvCf1zNxzik= =lizs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 04:49:38 2017 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 A1CA8131A85; Fri, 21 Jul 2017 04:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 ojYXFcnQlvhR; Fri, 21 Jul 2017 04:49:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2F69F131667; Fri, 21 Jul 2017 04:49:29 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6LBj39V014558; Fri, 21 Jul 2017 07:49:26 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2bu989h4tv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 07:49:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6LBnPX6004930; Fri, 21 Jul 2017 07:49:26 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6LBnLG8004852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 07:49:21 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 21 Jul 2017 11:49:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 21 Jul 2017 07:49:09 -0400 From: "STARK, BARBARA H" To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Subject: Re: [v6ops] Turning on IPv6 Routers Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWPFkLIZRLGj4keSA/TjIMCW16JeaCWA///Dy6U= Date: Fri, 21 Jul 2017 11:49:08 +0000 Message-ID: <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>, <7172.1500636277@dooku.sandelman.ca> In-Reply-To: <7172.1500636277@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210185 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:49:31 -0000 --_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an implementer of a PPPoE aggregator/access-router, I found that I had to invert 7084 to determine what I had to implement. It might be worth a document, if only so that ISPs would have something against which to issue RFPs. Maybe. BBF TR-187 documents the telco IPv6 over pppoe access network archite= cture with some specific requirements for access network elements. https://= www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf --_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an implementer of a PPPoE a= ggregator/access-router, I found that I
had to invert 7084 to determine what I had to implement.

It might be worth a document, if only so that ISPs would have somethi= ng
against which to issue RFPs.  Maybe.

<bhs> BBF TR-187 documents the telco IPv6 over pppoe access network a= rchitecture with some specific requirements for access network elements.&nb= sp;https://www.broadband-forum.org/technical/download/TR-187_Issue-2= .pdf
--_000_9EBF75B4CF2F42C2B0B4EC4948F27843attcom_-- From nobody Fri Jul 21 04:53:24 2017 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 84C1212ECB7 for ; Fri, 21 Jul 2017 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UL1htfVnTMy for ; Fri, 21 Jul 2017 04:53:14 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B2D13157A for ; Fri, 21 Jul 2017 04:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1500637991; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=wiNq3B4k2HIgvZYbNRVaa05LDxtv8lCFRl3EWwWdCkw=; b=FlgFjRAlvHhSOEmg08UonhnmKcbufwAOrunc+F6WWzYuu/PiHpCJiUo8LhBnKmlecGd88kMDjJPbttTdoJ1o8sQMFiMFzRtutvsIPzkwiuyhmpb+64YfuPdlU200HXbjnPcA3hnz1YL5ZMpFdFWM0S1/uSfK03BukmK1LUUUwTI= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-29-douavmQPM7q6RGs5xGr7CQ-1; Fri, 21 Jul 2017 12:53:06 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1156.eurprd07.prod.outlook.com (10.163.188.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Fri, 21 Jul 2017 11:53:03 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1304.010; Fri, 21 Jul 2017 11:53:02 +0000 From: Tim Chown To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Subject: Re: [v6ops] Turning on IPv6 Routers Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWO3srz2b9wieU6bc38h1/dUM6JeJReAgAAH8QA= Date: Fri, 21 Jul 2017 11:53:02 +0000 Message-ID: <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <7172.1500636277@dooku.sandelman.ca> In-Reply-To: <7172.1500636277@dooku.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:67c:1232:144:ccb6:479:3700:e540] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1156; 20:st0fyP/zcLSa2Mgwb+FvDfBauHOAV8vsIWQK6zM0cV3bZPss3/ji2KKfXDC3ZBxb/jKx5ZsIx+liOZMpcNagUjSPrU14YARANR9bnETjLu1JnScH4OlHIbHElAZV/iVKrfso9le810LXQDTZuLMQ6TkaacGpjJqvBaOE3DDsz7c= x-ms-office365-filtering-correlation-id: f7b15c21-a354-4d63-9e96-08d4d02f0ad4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1156; x-ms-traffictypediagnostic: AM3PR07MB1156: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1156; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1156; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39840400002)(39850400002)(39410400002)(199003)(24454002)(189002)(2906002)(966005)(74482002)(6246003)(305945005)(53546010)(8936002)(101416001)(6116002)(110136004)(72206003)(4326008)(7736002)(97736004)(38730400002)(102836003)(81156014)(76176999)(81166006)(33656002)(50986999)(189998001)(5660300001)(8676002)(50226002)(39060400002)(2900100001)(14454004)(6436002)(82746002)(36756003)(105586002)(106356001)(86362001)(6306002)(54906002)(68736007)(6486002)(3280700002)(5250100002)(229853002)(57306001)(6506006)(25786009)(478600001)(3660700001)(99286003)(53936002)(83716003)(6512007)(2950100002)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1156; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <486C3312BB13924DBB30B14D72109C71@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 11:53:02.9204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1156 X-MC-Unique: douavmQPM7q6RGs5xGr7CQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:53:16 -0000 PiBPbiAyMSBKdWwgMjAxNywgYXQgMTI6MjQsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZA c2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+PiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYXMgc2ltcGxlIGFzIGl0 IG1pZ2h0IHNvdW5kLiBUaGVyZSBhcmUgYXQgbGVhc3QNCj4+IHRocmVlIGNvbmZpZ3VyYXRpb25z IHRoYXQgbXVzdCBiZSBhbGxvd2VkIGZvciB1cHN0cmVhbTogYnJpZGdpbmcgdGhlDQo+PiBJU1Ag ZG93bnN0cmVhbSBhbmQgQ1BFIGRvd25zdHJlYW0gTEFOcywgQWRkcmVzcyBhbGxvY2F0aW9uIHZp YSBESENQDQo+PiBJQV9OQSwgYW5kIGFkZHJlc3MgYWxsb2NhdGlvbiB2aWEgU0xBQUMsIGFuZCBv biB0aGUgQ1BFIGRvd25zdHJlYW0NCj4+IExBTihzKSwgYWRkcmVzcyBhbGxvY2F0aW9uIHZpYSBE SENQIElBX05BIGFuZCBTTEFBQy4gQkJGIFRSLTEyNCBnaXZlcyBhDQo+PiBmbG93Y2hhcnQgZm9y IHRoaXMgb3IgUkZDIDcwODQgZGVmaW5lcyB0aGUgYWxnb3JpdGhtcy4gVGhlDQo+PiBpbXBsZW1l bnRhdGlvbiBpcyBnb2luZyB0byBoYXZlIHRvIGVuYWJsZSBhbGwgdGhyZWUsIHNlZSB3aGljaCB3 b3JrcywNCj4+IGFuZCBhY3QgYWNjb3JkaW5nbHkuDQo+IA0KPiBBcyBhbiBpbXBsZW1lbnRlciBv ZiBhIFBQUG9FIGFnZ3JlZ2F0b3IvYWNjZXNzLXJvdXRlciwgSSBmb3VuZCB0aGF0IEkNCj4gaGFk IHRvIGludmVydCA3MDg0IHRvIGRldGVybWluZSB3aGF0IEkgaGFkIHRvIGltcGxlbWVudC4NCj4g DQo+IEl0IG1pZ2h0IGJlIHdvcnRoIGEgZG9jdW1lbnQsIGlmIG9ubHkgc28gdGhhdCBJU1BzIHdv dWxkIGhhdmUgc29tZXRoaW5nDQo+IGFnYWluc3Qgd2hpY2ggdG8gaXNzdWUgUkZQcy4gIE1heWJl Lg0KDQpUaGUgcXVlc3Rpb24gZm9yIDY0MzRiaXMgYW5kIHBlcmhhcHMgNzA4NGJpcyBpZiBpdCBo YXBwZW5zIGlzIHdoYXQgd29yZGluZyB0byBwdXQgaW4uDQoNClR1cm5pbmcgb24gSVB2NiBpbiBh IHRlc3RlZCBJU1DigJlzIHByb3ZpZGVkIENQRSBpcyBhIGRpZmZlcmVudCBtYXR0ZXIgdG8gYSDi gJxyYW5kb23igJ0gZGV2aWNlLCB3aGljaCBtYXkgb3IgbWF5IG5vdCBiZSBjZXJ0aWZpZWQgYWdh aW5zdCB0aGUgSVB2NiBSZWFkeSBwcm9ncmFtIGZvciA3MDg0IGNvbXBsaWFuY2UuDQoNCknigJlt IG5vdCBzdXJlIGlmIHRoZSBmb2xsb3dpbmcgaXMgdGhlIGN1cnJlbnQgdGVzdCBzY2VuYXJpbyBz cGVjIChsYXN0IHVwZGF0ZWQgSmFuIDIwMTYpLCBidXQgaXQgbGlzdHMgdGhlIENFIHRlc3RzIHRo YXQgdGhhdCBJUHY2IFJlYWR5IHByb2dyYW0gaW5jbHVkZXMsIGluY2x1ZGluZyA3MDg0Og0KaHR0 cHM6Ly93d3cuaW9sLnVuaC5lZHUvc2l0ZXMvZGVmYXVsdC9maWxlcy90ZXN0c3VpdGVzL2huYy9p cHY2X3JlYWR5X3Rlc3Rfc3BlY2lmaWNhdGlvbl9jZV9yb3V0ZXJfY29uZm9ybWFuY2UucGRmDQoN ClRpbQ== From nobody Fri Jul 21 06:00:26 2017 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 7E0AA131C13 for ; Fri, 21 Jul 2017 06:00: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 nBKV-H_UoSl5 for ; Fri, 21 Jul 2017 06:00:22 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 53BC9131BFA for ; Fri, 21 Jul 2017 06:00:22 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w45so44810869uac.5 for ; Fri, 21 Jul 2017 06:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Zhb0gApqU6bdKuAHST085Xpvu+y4V79FqtofVjVM6FI=; b=GnfWdF3C2cNbGgbOvAmxyLoGG/1nfzh9tZBeJe3zjzw3LQUlfjBF+KXzaUBmGnPy0L oiF6fDqLl/EjLw22Oi7R+camz7mE6tIbjEqqLx72DYQcpVNF0wt8LlPRc42D8i8zhWaQ niOkoWYnarNTMLJlzWKgeKkAQ7azYiqZeUolxv+JReCHyfz39iyFkQ9GRvkyMuOo0jNF 7/kenP5Q7cNkpjpCXYudVgfCxxbL4oEFBgeHOF/81WOSph0tFZeQ6f6429qmmr1EFmWi M7VOzradv3W/q9r9lXeAcVJopepY9Vg7lYE8teeb3OsBuTtZcQI7Z6R8T9XE90P0DuQJ ktxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zhb0gApqU6bdKuAHST085Xpvu+y4V79FqtofVjVM6FI=; b=Y8skTI7NkSK8Yb1hRpx8dYVd8rQ8nXGmeeQTw8ukpL5suOgn5Du48ajUwsNbaQsquc +hsxY+G/XnylOef/QY9UZpLAfkI9OeArfJxjd9aHnZ5YX3LYrWEleCRw9rP7a9gNBlOR QHhXv6CzPudb2F1PU2rQTnIubHPMdv75KiUh0c4sDB1lxDXKjDQIxzXOjL9kWviZD626 XtE2RUiyviES6B60AenuQrVRn4DskR5s7jFctHI0At9FAqTMlYHVGvvWiCQ3ussn9apJ 1+RHzv93tIbMOK90TdYN9X29t0izhEosxuI2vWWngC6SzQKRJZQlJFmDYD/4nZxWY9UW VQzg== X-Gm-Message-State: AIVw110m0CU6gnPqKmbdK1dDLlDvdnDR0vo50wisTc9wREjC4hNMfgT8 2FCIKYqRFgZf962Tgki6K2czpuaZOCvv X-Received: by 10.176.23.3 with SMTP id j3mr4942968uaf.128.1500642021442; Fri, 21 Jul 2017 06:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Fri, 21 Jul 2017 06:00:20 -0700 (PDT) X-Originating-IP: [212.71.191.138] In-Reply-To: <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <7172.1500636277@dooku.sandelman.ca> <7A7963E2-F45B-4ACC-9627-060D8BDBF5E7@jisc.ac.uk> From: George Michaelson Date: Fri, 21 Jul 2017 15:00:20 +0200 Message-ID: Subject: Re: [v6ops] Turning on IPv6 Routers To: Tim Chown Cc: Michael Richardson , IPv6 Ops WG , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:00:24 -0000 Somebody muttered to me that bridge mode means customer devices 'inside' the demarc present their identity to the BNG demanding some V6 love, which makes accountants very unhappy because they were using that CPE identity as a billing cycle token. So bridge mode, which we all love, can be a bit of a pain, if you decided to use something clever in IID. On Fri, Jul 21, 2017 at 1:53 PM, Tim Chown wrote: >> On 21 Jul 2017, at 12:24, Michael Richardson wro= te: >> >> Fred Baker wrote: >>> Note that this is not as simple as it might sound. There are at least >>> three configurations that must be allowed for upstream: bridging the >>> ISP downstream and CPE downstream LANs, Address allocation via DHCP >>> IA_NA, and address allocation via SLAAC, and on the CPE downstream >>> LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a >>> flowchart for this or RFC 7084 defines the algorithms. The >>> implementation is going to have to enable all three, see which works, >>> and act accordingly. >> >> As an implementer of a PPPoE aggregator/access-router, I found that I >> had to invert 7084 to determine what I had to implement. >> >> It might be worth a document, if only so that ISPs would have something >> against which to issue RFPs. Maybe. > > The question for 6434bis and perhaps 7084bis if it happens is what wordin= g to put in. > > Turning on IPv6 in a tested ISP=E2=80=99s provided CPE is a different mat= ter to a =E2=80=9Crandom=E2=80=9D device, which may or may not be certified= against the IPv6 Ready program for 7084 compliance. > > I=E2=80=99m not sure if the following is the current test scenario spec (= last updated Jan 2016), but it lists the CE tests that that IPv6 Ready prog= ram includes, including 7084: > https://www.iol.unh.edu/sites/default/files/testsuites/hnc/ipv6_ready_tes= t_specification_ce_router_conformance.pdf > > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 21 10:25:41 2017 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 1B6EA127601; Fri, 21 Jul 2017 10:25: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ilxtHpSdjyj2; Fri, 21 Jul 2017 10:25:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9239A13167B; Fri, 21 Jul 2017 10:25:38 -0700 (PDT) Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 6B6F61F8F6; Fri, 21 Jul 2017 17:25:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 15DD61673; Fri, 21 Jul 2017 19:25:28 +0200 (CEST) From: Michael Richardson To: "STARK\, BARBARA H" cc: Fred Baker , IPv6 Ops WG , "6man WG" Subject: Re: [v6ops] Turning on IPv6 Routers In-reply-to: <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>, <7172.1500636277@dooku.sandelman.ca> <9EBF75B4-CF2F-42C2-B0B4-EC4948F27843@att.com> Comments: In-reply-to "STARK, BARBARA H" message dated "Fri, 21 Jul 2017 11:49:08 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 21 Jul 2017 19:25:28 +0200 Message-ID: <25429.1500657928@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 17:25:40 -0000 --=-=-= Content-Type: text/plain STARK, BARBARA H wrote: > As an implementer of a PPPoE aggregator/access-router, I found that I > had to invert 7084 to determine what I had to implement. > It might be worth a document, if only so that ISPs would have something > against which to issue RFPs. Maybe. bhs> BBF TR-187 documents the telco IPv6 over pppoe access network bhs> architecture with some specific requirements for access network bhs> elements. bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf Yes, I worked from TR-187 as well. It's close to what I want, but it doesn't say what the access network elements *MUST* do, but rather tells you what the CPE boxes MUST try. For instance: *SHOULD* a PPPoE access router provide an address for the CPE router link via RA or via DHCPv6? If it does both, should it offer the same address? It would be rather better if one *knew* the CPE would do PD and then assign itself an address out of one of the /64s. That would eliminate a bunch of routes. Part of the problem is that one can't necessarily depend upon the CPE to do DHCPv6 (-PD) at all! It would just be nice to reduce the number of options. Maybe a BCP is in order. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZcjkHAAoJEJVM4Vb9/EKQjd8H/jUk5cj6MKeNd5FQ1+5p/FC7 EQl55objELygcfadEiuH+NgVCSZmXWaM3zzr7343+S8LPboP72WWvpFVH1JbjlsR GnMPxk2+a3AOoFWVuDYmLYNqZ9102QB31B32WY23xiXKc8OOQ+xrvPqqLq92kcVs As1Mra+A0NjGv80rjOxcLs26flvB8bQfjjh9RDevvFVW44Ijd2MwSLJKZP2GH7Eu be33RP6vOlhJIshXtboX/yxrt4slwgfhj7oaGpHvEYqWgOz/+Mcb78qQt/Wn5a0X DryKKZjQJNMU6TZ82iaZmGzyZHpWLmJmHJakDiQdsnh5erlr0oMZMMZTO+iNAks= =mA1e -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 21 10:41:31 2017 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 507AA131C37 for ; Fri, 21 Jul 2017 10:41:30 -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 hY90sg8-ZIPK for ; Fri, 21 Jul 2017 10:41:29 -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 69202129B15 for ; Fri, 21 Jul 2017 10:41:29 -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 v6LHfS5r055032; Fri, 21 Jul 2017 10:41:29 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6LHfKWD054509 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 21 Jul 2017 10:41:21 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Jul 2017 10:41:19 -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.1263.000; Fri, 21 Jul 2017 10:41:19 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTAgN2ebTBUJ8rD0OoodR21OzKJKJejDkQ Date: Fri, 21 Jul 2017 17:41:19 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 17:41:30 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > Independent of what RFC 4291 currently says, I would prefer IID to > only refer to address configuration using SLAAC. Might I suggest that this is a bigger change than that of removing notions = of hard 64-bit boundaries? Two routers interconnected with /127s. Does that last bit not identify the = interface? Bert From nobody Fri Jul 21 11:44:52 2017 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 D4F89131545 for ; Fri, 21 Jul 2017 11:44:50 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 SU0AYy4hGLWe for ; Fri, 21 Jul 2017 11:44:49 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FD2129B26 for ; Fri, 21 Jul 2017 11:44:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id EFB9E1BC37 for ; Fri, 21 Jul 2017 18:44:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Vehicle VINs (Was: Battling human nature) From: Simon Hobson In-Reply-To: <710a7d9ef9444eefa4f45d4ea7a29e03@XCH15-06-11.nw.nos.boeing.com> Date: Fri, 21 Jul 2017 19:44:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <710a7d9ef9444eefa4f45d4ea7a29e03@XCH15-06-11.nw.nos.boeing.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 18:44:51 -0000 "Manfredi, Albert E" wrote: > Look at your automobile's VIN. It's humongous. Surely, we're not going = to insist that the VIN become part of the car's Internet address?=20 Going off topic, already been done (sort of) - and the obvious security = implications found out after the fact ! https://www.theregister.co.uk/2016/07/08/bmw_vulns/ And slightly related, the danger of having primary keys publicly visible = https://www.theregister.co.uk/2017/05/31/bikers_hack_jeeps_in_auto_theft_s= pree/ From nobody Fri Jul 21 13:34:24 2017 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 0413C129AD2 for ; Fri, 21 Jul 2017 13:34:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BE0UOYEO2ceM for ; Fri, 21 Jul 2017 13:34:21 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DD0124E15 for ; Fri, 21 Jul 2017 13:34:21 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 123so32976890pgj.1 for ; Fri, 21 Jul 2017 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n951VIBRXvceVNfvMNx6CtAWZtYBrjLDZiy/5Td4CfM=; b=icoVuqmAfc4G3N+2/nV6YX3lXtl96fWWRlbJoHDJlClgxbVJlCLpIfB2hD8aZPNOPj pYumYYu4Oeoq8SM0JfR4Yg/LhxZUPgPjSqg6vyDEHlsvcoVo0waR2km7PzDhLLC5AiR8 b0HqQsRjtui9jun6xKmXMAYlDgQvyx0wF2b7lkjxMokscIuhXRZPA2H5EGEEKg9LC6/E u4O8xVkdc4uviBUbSX32JWU/dZFJ2kOfXAAMuO/k3XsycOJFeiQoxPt2zzVX9YsvJN5t KJZKur54qFZlUi5t+gzFD/koTVGYC1NrOEW9LkDGciG+3AsbC7Gn81DxWJX9/QhgndWr z9yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=n951VIBRXvceVNfvMNx6CtAWZtYBrjLDZiy/5Td4CfM=; b=A0EAX+RHxu1OB6M4+ZyLqO54HQBlLL6gr/Z6Dj8lgEY3aEVjcyfElfnDEdQIQ5mmdG XzRFKZUi57MiA1jKxoznbFiP1kyxl79b/L07kIV3z6Hh0DSxNWNKr4fjcRI8YmRFWazl uV/29pdQl39dKlcrNQ8oXtvTs8oh2FoKgeJi2A9R4NLjnLI/uy+NGkRHD5YM7QoBP8rX AwgvfcDUBJQNjKTWy2j5ZYaU2ZWI+qzQPSBC1rQKRcjixgg9TdZ2qyMH0NA+jsyDdeAl HYHcVf409g5fzPa+YZLcnL9H0tWjH2C1wAZgWvGRHuGr4dHhNtxHP6Fa3tRel2KMZm3+ kfUA== X-Gm-Message-State: AIVw11124NWZV+KPKJzLDzL1pQtFR0wX60B18LO2VN4y6Rp8uPAC18Nq Pq/7JNajnRAlyAma57Y= X-Received: by 10.99.3.198 with SMTP id 189mr7198776pgd.49.1500669260692; Fri, 21 Jul 2017 13:34:20 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q3sm9825744pgf.69.2017.07.21.13.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 13:34:20 -0700 (PDT) Subject: Re: To: Philip Homburg , ipv6@ietf.org Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 22 Jul 2017 08:34:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:34:23 -0000 On 21/07/2017 21:26, Philip Homburg wrote: >> Here, I'm not trying to convince you that their view is correct. To >> me, however, those "some people" and people like you or Brian have >> both some valid points, and it's not that one of the views is definitely >> correct and the other is completely wrong. The difference of the >> views comes from the fact that RFC4291 or its bis is not super crystal >> clear and there is some possible inconsistency between it and other >> IPv6 RFCs, leaving questions like this one to one's interpretation. >> It seems that people believing one particular view tend to refer to >> some specific part of those RFCs or drafts or existing implementations >> that are convenient to reach their favorite interpretation, but the >> reality is that other interpretations can be quite possible. I don't >> expect either group with a strong opinion to agree with the other, but >> at least unless they recognize both groups have some reason to believe >> a particular view, we will never be able to escape from this gridlock, >> at least in the scope of rfc4291bis. > > Independent of what RFC 4291 currently says, I would prefer IID to only refer > to address configuration using SLAAC. Then you really have to answer my question: if they are not called "interface identifier" what are those bits called? > What we currently have is that requirements on IID depend on the use case. If they are called something else, the requirements will still depend on the use case. Brian > If you use an IID in the context of SLAAC then we have one set of requirements > (link dependent lenght), if you use it with a /127 prefix or manual config > it's. This causes way too much confusion. > > Then again I'm of the opinion that the relevant sections of rfc4291bis need > to be rewritten to be actually readable. The current text should not be > published as an internet standard. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Fri Jul 21 13:40:24 2017 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 1C556129B61 for ; Fri, 21 Jul 2017 13:40:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KXDKm3DqorsW for ; Fri, 21 Jul 2017 13:40:22 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72FD12EAB0 for ; Fri, 21 Jul 2017 13:40:21 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id s70so27841557pfs.0 for ; Fri, 21 Jul 2017 13:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4gjOYC3wwm58/JoMAPvbf/PrXyfkJCPT/fjhSKSP9UI=; b=JrqJeensKoz5ouaRJLC+rmBr+IU3YiUJSt4JXD6UT4UeR8E3Hlf6oiTKLj517rHahs DdiwwbAuwkecG2Q0liXvbVkD66TdTU8tOcHH3e2cWo9mtrMpQEyQAw0/kQC/eWsGTOAW sUVZkl8A0IJY3/oghn9E4zGz1yU+2z2pz4ykd8acZzihz4gYN5tmdQnpW2b4MLTUAUDj oaqrtVEDP1cJAo31qW2VtlPxfIbaKNgb5OA2oh8JCE7BwkH3tyHuKxbnv8nF9zSqmY/y drKRXHKCtri2fbMYJLgj9KWUyAuUGoa7CRdpVi1dvG5lebtRaiH2DtHUeMtivDYCnN72 ZREA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4gjOYC3wwm58/JoMAPvbf/PrXyfkJCPT/fjhSKSP9UI=; b=SebDBXfwW0LNT3kfTdgCI1bACgj+U7ei14kNfbhguyexh31ai02tP4K4PrDnNsvwXr 8+BiUPodPzZ4H4UmGbr/st8M4vDedDxNr6oacJX69z3/Y7m1TRbvMiD12BFUstSpa0yG viV6fxLU3njwWByY8OL2fEHimrEj/LEXPG/yKU5tbwA7U6VoVoqF+Lv757jKl2yp7jMF 6jzaG2deqTc0MnzHCDsV27i2qmRqg/+TvdKuQsvLuL2gYxpksZwnhIb/0vBoB+7qxQGQ 3U6cPGt4muiy0gGOjuJzmVFWsk2iHFuQx4NIoj3MAAQuOZJjOr8tUlSvotjJzQuMPndN 5gTw== X-Gm-Message-State: AIVw113dZBnWDYR9men9guKJdHMaUvQZiWOHfF4PvAK91WnZW/o4cYlC KBfXnQ6FykfbUhSMkmU= X-Received: by 10.99.36.5 with SMTP id k5mr8507362pgk.328.1500669621413; Fri, 21 Jul 2017 13:40:21 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 205sm9054620pga.65.2017.07.21.13.40.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 13:40:20 -0700 (PDT) Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 22 Jul 2017 08:40:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:40:23 -0000 On 21/07/2017 19:46, Mikael Abrahamsson wrote: ... > I know there is fundamental disagreement on this topic, and I don't think > we'll make people change their minds anytime soon about what they believe > will be the consequence of changing the /64 default. Who's proposing to change it? Currently it isn't a default, it's fixed. The strongest proposal I've seen is to state that it's a default rather than a fixed value. Brian From nobody Fri Jul 21 15:18:15 2017 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 C5CDF1300CE for ; Fri, 21 Jul 2017 15:18:13 -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 V9VkFfaGEmwo for ; Fri, 21 Jul 2017 15:18:12 -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 71C5B129ADA for ; Fri, 21 Jul 2017 15:18:12 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h199so13438451ith.1 for ; Fri, 21 Jul 2017 15:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qJNbEkpgaLvwaTCDERBu8AnqyyZ5UGB0V7u900QBa+w=; b=jnWjZUkcOWxBjHULV9jxpI2hgzQhPlETUooegrOSXA+yIho7f0rJC2fslpsrTIwKC0 OpIHp6MdNwXeBh5bJFtPY9hoKbjaMYbSgjTYz1rywURFLg5mn639sJQcAy8Th9lfP5mx qltQUpfB89FbXqp71ldw1UmJPq98j5WIZt8L0fyenWvdfCi5jHoIt6VatMKHVANtOh9L pnNYszvMpA+ltfLpFxm2sUbBDBdTc/Bhs+p4ePBwv14Aa/If2mQBNUWGeylZJgkjn/Pw 6uLxWQ5n4eNAaQ5BtWs3GiAjIniM3uc7g4f4y53r6uQiHaxM/gsN/UtkNB912wTaCoio 7t7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qJNbEkpgaLvwaTCDERBu8AnqyyZ5UGB0V7u900QBa+w=; b=dRkFZ0aH/WR0G7O0XDHCVo03uw+2qWO+36CxX6+8C4iFs4p57w18VLKxbUu3nApdft ngyKkO3Yu34mkmSrwcedJPI4fBNVnvrUdP6DoMgAN3OdgMJiyvSQuKqeRmFAv1aC3vtM 3F8K05DY7D5OL4xPPysb2CHkrNDdjzdBfakdle151eQHP9TzxHnsCo0P0o0Tm1PnewqG kuiV/6JHIQ8wIe5j/ZX+n8oPaLsDJMKKkDRjbFhIVENGGrHFK+CSgg9YxhVIypn4qV9a qZG+iPk0UEQe7kLbZ2VTU1r4KtQO5iX7mOgFaOY4gCFQPc64xoRRMMKe7PPdvn5+w7UK KjwA== X-Gm-Message-State: AIVw11110mo9EPHkA+m43BnzARUo4BH1DBCTJP/E602HY0K3/4PNvh9B eAdPZqKmjwGTQvzdFyH+lJy+lBLBIw== X-Received: by 10.36.134.197 with SMTP id u188mr457830itd.73.1500675491833; Fri, 21 Jul 2017 15:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.173.162 with HTTP; Fri, 21 Jul 2017 15:18:11 -0700 (PDT) In-Reply-To: References: <5a3ae0e0-f850-4a2d-d417-6b6de1c9ce6c@acm.org> <800FCF2A-9E7A-4150-859A-3ACB0BDFB1CA@thehobsons.co.uk> From: Sowmini Varadhan Date: Fri, 21 Jul 2017 18:18:11 -0400 Message-ID: Subject: Re: rationale for the default of DupAddrDetectTransmits To: Mark Smith Cc: Simon Hobson , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 22:18:13 -0000 On Wed, Jul 19, 2017 at 5:18 AM, Mark Smith wrote: > > A duplicate can only occur when a node tries to bring up a new address > on the link, and that is the time for that node to check to see if the > new address is a duplicate. If the new address is a duplicate of an > existing address, the existing address user gets to keep using it, and > the new node has to pick another address. that assumes that the second node asserting the address is well-behaved, and will politely give up the address when DAD announcment from the first node comes through. The usurper may not always be well-behaved. > Ongoing DAD by existing nodes could overcome the reliability issues > being discussed, however it is really better to have the new entrant > try harder. It's a once off period of checking to ensure and get the > set of addresses to being unique verses an ongoing period of checking > that has no value once the set of addresses are unique. there are other cases of network partition and rejoin, where its not practiical to use optimistic DAD addresses for extended periods of time. --Sowmini From nobody Sat Jul 22 04:12:54 2017 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 711F4131DFD for ; Sat, 22 Jul 2017 04:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 KJ0Su8wJpkST for ; Sat, 22 Jul 2017 04:12:50 -0700 (PDT) Received: from atl4mhob03.registeredsite.com (atl4mhob03.registeredsite.com [209.17.115.41]) (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 AC405127869 for ; Sat, 22 Jul 2017 04:12:50 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob03.registeredsite.com (8.14.4/8.14.4) with ESMTP id v6MBClGf001350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 22 Jul 2017 07:12:47 -0400 Received: (qmail 22431 invoked by uid 0); 22 Jul 2017 11:12:47 -0000 X-TCPREMOTEIP: 174.221.131.177 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?100.87.27.48?) (lee@asgard.org@174.221.131.177) by 0 with ESMTPA; 22 Jul 2017 11:12:46 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [v6ops] Turning on IPv6 Routers From: Lee Howard X-Mailer: iPhone Mail (14F89) In-Reply-To: <5970CB51.3090806@foobar.org> Date: Sat, 22 Jul 2017 13:12:44 +0200 Cc: Fred Baker , IPv6 Ops WG , 6man WG , draft-ietf-6man-rfc6434-bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> To: Nick Hilliard Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 11:12:52 -0000 Sent from my iPhone > On Jul 20, 2017, at 5:25 PM, Nick Hilliard wrote: >=20 > Fred Baker wrote: >> "If IPv4 router operation is enabled by default, enable IPv6 router >> operation by default." >=20 > this is undoubtedly well-intentioned, and the idealist bit in me > sympathises with the principal. However with my enable hat on, a > recommendation like this isn't going to fix any problem associated with > ipv6 adoption. >=20 > The problems with ipv6 adoption revolve entirely around cost/benefit. I disagree.=20 IPv6 enablement by the ISP requires work. But once it's enabled, there's oft= en a gap between "100% enabled" and "100% active" that is directly due to CP= E either not supporting or not enabling IPv6.=20 > Pressing problems still include things that should have been resolved > years ago, e.g. vendors charging extra for ipv6 support (today's > bugbear: provisioning system vendors, please note that charging extra > for basic ipv6 functionality is destructive in the long term and > corrosive for your customer relationships) It's great that there are others to choose from. It's unfortunate that the m= arginal cost to buy and integrate is higher than the extra fee for feature s= upport. That recalcitrant vendor better hope you love them enough to stay.=20= >=20 > As a separate issue, from an operational point of view, implicit > enabling of functionality in one area when it's explicitly enabled in > another is something that needs to be handled carefully because > otherwise you can end up violating the principal of least astonishment. Once it's enabled at the edge, it seems more astonishing to me when it doesn= 't work than when it does. The vast majority of IPv6 tickets I've seen have b= een "Why don't I have it yet?" >=20 > Nick >=20 Lee > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sat Jul 22 06:29:15 2017 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 4BF98127058 for ; Sat, 22 Jul 2017 06:29:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-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 zuuAsJr86ivb for ; Sat, 22 Jul 2017 06:29:12 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 C61E612EAF0 for ; Sat, 22 Jul 2017 06:29:11 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id 33so34550290wrz.4 for ; Sat, 22 Jul 2017 06:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E74SFDBhRUk4S5HofjPtoX3LQi5SjFX0AMS+BTkLebs=; b=BynVTsRcD+JXpcvkAM0H8DdZ4U6nF/VoinLfU93XtlT9vjp3VxUjeT2grjb1P9hluy +r9231JxlxyViazr3RtksyOCV5mmBBcUGYShRth0cSFxUlssZjIby86JD/TiBX3FQ9Fa 6C2AIJCTISm8t2kKMyyWjMdQ+snQ/E3KSE5VdIOgCOZcIOOAEf7+ISexpRkbCdvQklvT ZMFKGn0BXYwByywXrMleJK8GKrgM9j4H0WZ5x8s3ACGEX6VPKpa8XUOR7GRJ3L8UHjIE 0YlSsQwxbdg+k/JebL3HFrVVqk3GKCUCx8/rKxQ7VQr9t2WtcZrjB1jopRpkmX4HCc+I yr6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E74SFDBhRUk4S5HofjPtoX3LQi5SjFX0AMS+BTkLebs=; b=oAHs87q+1QMQ7SODjT3BRGtmt81+oBaQQlHrkLVo/8VykVEeavJWXETyXsA8xAiRjV zWdCuY3tBlIiAtmiiQL5R0tjvyG/fzbvWuZqElIFXzG12DguJchjQTpQL57PdT5+eKdd nCR8aa158LA3klHhvV5IbFdtzXhc3tmWVGIfc3Fnud/IeH5IcjfE2Loa3bZMJdrUCYdO IMiO/uRkyMH5l6CZ9bQz/m6YXBPnW/cGAv3PQQNdHnf1KV36MQ9XbADh1Fe3Qsc9AbR3 6D2XC8MhufhsePpgQUoiBSwqQKD+YUtoSKJqEcb+LiPTfZOGdLRib2/Ky7hHCtpzhfjp bvfw== X-Gm-Message-State: AIVw110YbGar8Dr4pEUwy3/uKCIIb89IMEwSOg+f5QlJ1Tg8IFTHkmMT lDlllE4e4PZWQJ8Gp94Bqj6I68fMnFhy X-Received: by 10.223.151.135 with SMTP id s7mr9570931wrb.231.1500730150271; Sat, 22 Jul 2017 06:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.27.207 with HTTP; Sat, 22 Jul 2017 06:29:09 -0700 (PDT) In-Reply-To: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> From: Victor Kuarsingh Date: Sat, 22 Jul 2017 09:29:09 -0400 Message-ID: Subject: Re: [v6ops] Turning on IPv6 Routers To: IPv6 Ops WG Cc: Nick Hilliard , 6man WG , draft-ietf-6man-rfc6434-bis@ietf.org, Lee Howard Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 13:29:14 -0000 On Sat, Jul 22, 2017 at 7:12 AM, Lee Howard wrote: > > > Sent from my iPhone > >> On Jul 20, 2017, at 5:25 PM, Nick Hilliard wrote: >> >> Fred Baker wrote: >>> "If IPv4 router operation is enabled by default, enable IPv6 router >>> operation by default." >> >> this is undoubtedly well-intentioned, and the idealist bit in me >> sympathises with the principal. However with my enable hat on, a >> recommendation like this isn't going to fix any problem associated with >> ipv6 adoption. >> >> The problems with ipv6 adoption revolve entirely around cost/benefit. > > I disagree. > IPv6 enablement by the ISP requires work. But once it's enabled, there's often a gap between "100% enabled" and "100% active" that is directly due to CPE either not supporting or not enabling IPv6. For operators deploying Native IPv6, I would say this sounds about right. I can't say my area is representative of the entire world, but here, once IPv6 was on for the upstream provider, it only took an IPv6 enabled CPE (which I assisted in for multiple folks) to get full IPv6 service (dual stack in the cases I saw). Operators will likely get their boxes upto IPv6 standard on their own. Depending on how they decided to IPv6 enable a given sets of customer endpoints (or residence) , it may require a call (i.e. provisioning modes can be different for enabled and non-enabled IPv6 customer sites). Operators will likely track their ability to have IPv6 working for a given residence based on their own CPEs capability/support (if they offer that). > > >> Pressing problems still include things that should have been resolved >> years ago, e.g. vendors charging extra for ipv6 support (today's >> bugbear: provisioning system vendors, please note that charging extra >> for basic ipv6 functionality is destructive in the long term and >> corrosive for your customer relationships) > > It's great that there are others to choose from. It's unfortunate that the marginal cost to buy and integrate is higher than the extra fee for feature support. That recalcitrant vendor better hope you love them enough to stay. I have not actually experienced ISPs charing more for IPv6 to date. Early adaptor ISPs seem to have done it as part of the standard offering (incremental network costs likely buried in normal development cycles since it can require significant upgrades - at least historically - to ready the entire network and provisioning systems to support IPv6). > >> >> As a separate issue, from an operational point of view, implicit >> enabling of functionality in one area when it's explicitly enabled in >> another is something that needs to be handled carefully because >> otherwise you can end up violating the principal of least astonishment. > > Once it's enabled at the edge, it seems more astonishing to me when it doesn't work than when it does. The vast majority of IPv6 tickets I've seen have been "Why don't I have it yet?" If you look at the message boards for areas where there are tech savvy customers, you can see many trying to get IPv6 working on their own CPEs or using the operator's provide one , once IPv6 is known to be available. Example here - - http://www.dslreports.com/forum/r30687933-Internet-Rogers-IPv6-appears-to-be-rolling-out - http://www.dslreports.com/forum/r30238214-TELUS-IPv6-on-GPON-CE-network > >> >> Nick >> > > Lee > regards, Victor K From nobody Sat Jul 22 08:28:10 2017 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 8FF8C131DA1 for ; Sat, 22 Jul 2017 08:28:07 -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] 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 Uv55XyhjyXn5 for ; Sat, 22 Jul 2017 08:28:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC29131B27 for ; Sat, 22 Jul 2017 08:28:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dYwJx-0000KWC; Sat, 22 Jul 2017 17:27:57 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Fri, 21 Jul 2017 17:41:19 +0000 ." Date: Sat, 22 Jul 2017 17:27:51 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 15:28:08 -0000 >> Independent of what RFC 4291 currently says, I would prefer IID to >> only refer to address configuration using SLAAC. > >Might I suggest that this is a bigger change than that of removing notions = >of hard 64-bit boundaries? Note that it is meant to be a documentation change. No change in how IPv6 is currently deployed. So IID only refers to SLAAC. >Two routers interconnected with /127s. Does that last bit not identify the = >interface? Let me just call the part after the prefix 'host part'. Then in the case of a /127 the host part would be 1 bit. By and large a 'host part' does have any properties. Other than that for a /n prefix, the host part is of length 128-n bits. From nobody Sat Jul 22 08:37:44 2017 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 C69B0131DFC for ; Sat, 22 Jul 2017 08:37:42 -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] 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 iF5d-TKaCDRg for ; Sat, 22 Jul 2017 08:37:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 529F2131DB6 for ; Sat, 22 Jul 2017 08:37:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dYwTM-0000FzC; Sat, 22 Jul 2017 17:37:40 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Sat, 22 Jul 2017 08:34:26 +1200 ." Date: Sat, 22 Jul 2017 17:37:39 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 15:37:43 -0000 >Then you really have to answer my question: if they are not called "interface >identifier" what are those bits called? So let me call them 'host part' >> What we currently have is that requirements on IID depend on the use case. > >If they are called something else, the requirements will still depend on >the use case. Basically a 'host part' doesn't have any properties. You can say it identifies an interface, but that is not the case if a 'host part' is part of an anycast address. So a host part has a specific length, which is of course related to the prefix length. And that's it. For manual address configuration, a host part doesn't have any properties except that it should be unique. For DHCP IA_NA the same applies. Though in the context of DHCP you may also want to talk about privacy. But that goes way beyond what rfc4291 deals with. Some host parts may be anycast addresses. But by and large whether an address is anycast is a local flag that needs to be set. There are no specific requirements for host parts that are anycast addresses. Only when a host part happens to be used in SLAAC, we get a completely different story. From nobody Sat Jul 22 09:09:52 2017 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 87792129B10 for ; Sat, 22 Jul 2017 09:09:51 -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 XI7m1T3w-z-6 for ; Sat, 22 Jul 2017 09:09:50 -0700 (PDT) Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48]) (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 12A90120725 for ; Sat, 22 Jul 2017 09:09:49 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id v6MG9lGE016250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 22 Jul 2017 12:09:47 -0400 Received: (qmail 23554 invoked by uid 0); 22 Jul 2017 16:09:47 -0000 X-TCPREMOTEIP: 70.196.7.242 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?100.95.51.157?) (lee@asgard.org@70.196.7.242) by 0 with ESMTPA; 22 Jul 2017 16:09:46 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Battling human nature (Re: Prefix Delegation and hosts) From: Lee Howard X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sat, 22 Jul 2017 18:09:44 +0200 Cc: Simon Hobson , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 16:09:51 -0000 Top-posting because I'm posting from a phone in a hospital room.=20 1. We can't change the protocol while promoting it to Internet Standard.=20 2. I am interested in seeing what happens in the field and what people do wi= th all the bits.=20 Lee Sent from my iPhone > On Jul 21, 2017, at 2:26 AM, Mark Smith wrote: >=20 >> On 21 July 2017 at 02:36, Simon Hobson wrote: >> joel jaeggli wrote: >>=20 >>>> Why pick /80 instead of something more familiar such as /120? The >>>> requesting router can even assign prefixes based on RFC1918 IPv4 /24 >>>> prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a >>>> few steps in the race to the bottom. >>>=20 >>> Presumably if your goal is to allow downstream devices to futher segment= >>> you will assign the shortest prefixes you can get away with in your >>> model. if your goal is micro-segmentation of things like for example for= >>> containers or VMs, you'll probably assign as long as you can get away >>> with e.g. /126 /127 /128 which can be littered all over the address >>> space if you're so inclined. >>=20 >> I think you missed his point. >> The moment anyone admits that a network can have less than 64bits of addr= essing to play with, then the sky will fall in, there'll be plagues of locus= ts, the world will end, and everyone will start getting /128 single addresse= s delegated to them. Thus, there should not be any document anywhere even ad= mitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bottom o= f the pond use it as an excuse to delegate smaller than multiple /64s to the= ir customers. >>=20 >=20 > I think your scepticism is overlooking human nature. >=20 > Human nature is to try to avoid change and to do what is familiar. It > is motivated by the fear of the unknown. >=20 > Human nature is to try to be lazy by default - to do the minimum > necessary to achieve the intended outcome. >=20 > The combination of these two natures means trying to do the most > familiar with the least effort. >=20 > Since giving a site a single public address and having the site use > NAPT are the IPv4 norm, there will be a strong human tendency to try > copy that norm in IPv6 if possible. It would be "the most familiar > with the least effort". >=20 > If a norm of per-site IPv6 /128s and NAPT became reality, it also > makes deploying IPv6 pointless. The fundamental goal of IPv6 is to > have enough public addresses so that each host that wants a globally > unique and public IPv6 address can have one, for something in the > order of at least the next 30 years. >=20 > Allowing IIDs that are smaller than 64 bits and more specifically > arbitrary in size formally permits the creation of IIDs that may be > too small for the number of IPv6 hosts that somebody wants to attach > to the link. >=20 > That formality would act as a strong signal that the IPv4 norm of a > per-site single public address and NAPT is perfectly acceptable in > IPv6 - despite it being a direct contradiction to IPv6's raison > d'=C3=AAtre. >=20 >=20 > Regards, > Mark. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Jul 22 13:47:31 2017 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 0B88B131822 for ; Sat, 22 Jul 2017 13:47:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 P9NoN6KgMQdK for ; Sat, 22 Jul 2017 13:47:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 939E7131A4F for ; Sat, 22 Jul 2017 13:47:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s70so34691940pfs.0 for ; Sat, 22 Jul 2017 13:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2r4EfNZZLE6SgQlLUkNQFxa4FbOR12k91XV50Frrq98=; b=C8M2iyhJoFcvHsLEDzMQLM0CGT9xUQ/oCuFCFNnjWjCcpQUBOxnH/57isKEPfz+8kB 51yuFteWz/EdG53sIIRB6miMLWfRdW0Bxs7UIiTq+O74X+dbYQ+dlKsirCpikU6HyJKq BjwslR1yPoZz1SBt6L/xJTOUbSNMIMLSjyBJH+jVK3PnZwxan6bpbBkjnwgNsCsyrG6v 3zMzBpWGCjxbUtV2XEzRI04k3nb34JD1WL2x6b2nK82wYbaGzVYyiFMzg46i+S2KDdgF R3Qj/JnGTFNDRi94huVL/vkIcn7IQ0Spe+NKl9J2arypHnqwpz7twNTe4VaWYK36tv2+ Ob+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2r4EfNZZLE6SgQlLUkNQFxa4FbOR12k91XV50Frrq98=; b=CJp1w7hDDcPm0ykgc7GxSSXroYmDgfL43jbbBWZHuLqs2PA0hAqU338Aq8zNwtxdXB qCyDc0/tdOm1h1eiix3dslfXzES4qn2yyi35rS8++d0OvoET/IySmi4wawECY5jN4Yp1 dHRW1mYIOqf0rrrQMHkOVKqcHwIArBJ8nuqEMrIbS2F0rgbvGbjPjXFzOiIp5Sq/pLgq bKjbaJNn+lUSn1HNlzHHHSiyPwKrdP1dWbTvAlvSjslNuSEQhiOTIH+s6tC5Bdx569sM 9C8+xsqaAPENmSy6tffkExao4sM0r/a7kw3OUY19reX3JQTVloaxt1VLUNUpg5LW+A4u 1ggw== X-Gm-Message-State: AIVw112+CTyYC6mulHmHK4GFMfaWnLuLBaYVKGlWcs6XryQ6+i7GNePI QqnzloCfKg06Xft+ X-Received: by 10.101.83.197 with SMTP id z5mr11608716pgr.261.1500756448012; Sat, 22 Jul 2017 13:47:28 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s17sm15962462pfg.166.2017.07.22.13.47.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 13:47:27 -0700 (PDT) Subject: Re: To: Philip Homburg , ipv6@ietf.org References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 23 Jul 2017 08:47:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 20:47:30 -0000 On 23/07/2017 03:37, Philip Homburg wrote: >> Then you really have to answer my question: if they are not called "interface >> identifier" what are those bits called? > > So let me call them 'host part' Hate to be picky but in RFC8200 'host' does not include 'router' and these bits certainly exist in router addresses. So it would have to be 'node part'. But in most cases (the only exception being anycast) these bits may be (not must be) different in the node per interface, so 'node' is still wrong. I just don't get why it isn't 'interface part' (with an exception for anycast). And if it's 'interface part' I really don't see why it isn't 'interface identifier'. Here's a thought. How would it be if the contentious sentence in 4291bis read, in its entirety: "Interface Identifiers are 64 bits long when used for Stateless Address Autoconfiguration (SLAAC) [RFC4862]." ?. Who here could not live with that? Brian > >>> What we currently have is that requirements on IID depend on the use case. >> >> If they are called something else, the requirements will still depend on >> the use case. > > Basically a 'host part' doesn't have any properties. You can say it > identifies an interface, but that is not the case if a 'host part' is > part of an anycast address. > > So a host part has a specific length, which is of course related to the > prefix length. And that's it. > > For manual address configuration, a host part doesn't have any properties > except that it should be unique. > > For DHCP IA_NA the same applies. Though in the context of DHCP you may also > want to talk about privacy. But that goes way beyond what rfc4291 deals > with. > > Some host parts may be anycast addresses. But by and large whether an > address is anycast is a local flag that needs to be set. There are no specific > requirements for host parts that are anycast addresses. > > Only when a host part happens to be used in SLAAC, we get a completely > different story. > From nobody Sat Jul 22 13:54:10 2017 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 ACE05131919 for ; Sat, 22 Jul 2017 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOiZ5tLE_ega for ; Sat, 22 Jul 2017 13:54:06 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 A264A1317BE for ; Sat, 22 Jul 2017 13:54:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 1B13AAB3 for ; Sat, 22 Jul 2017 20:54:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZCuQHscI5QK for ; Sat, 22 Jul 2017 15:54:05 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id C5CBE9F0 for ; Sat, 22 Jul 2017 15:54:05 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id i187so10801451vke.2 for ; Sat, 22 Jul 2017 13:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Piki4SiO+BChUkciNLpbfePNFSCTtqGc87VybiDhb0Y=; b=PCfhqwikBRc4iItJLK9sRZzA2UKqCBuauCtuNNNReEVSAXdP6wifE6QFIdo+wISQpQ +x0EYrYknvN8Lu5xvSEIHyUCd4h4JtG9eHee/1reijbAGMSSRh98s7f0Yaq038/dZFPA HzaX9pvrFhFuRiIO8GQeiGh6r6udilPKQUexK12CWCUw+oP9Mu1dmSJLjITqylP/MSkn 6WKLv0zgJXAhNs9sKljaFdsFNxcOCmpdp9qaNJIt8iirghs9LRvB0Y7EchkVCnwngP7E iersicX7IL2Om808PdUr6vwlk3YwvMstDjXMMEeEsDBYJY0lzgbNT/SwC1FqZY6pXKLp B4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Piki4SiO+BChUkciNLpbfePNFSCTtqGc87VybiDhb0Y=; b=tVUOYVYYWU9FV/Vz3i1MaxpPjmmXLZZYRNVOiaAq0TV75NIo63+x7kz5CVS7salgm6 3nl212s7kVymnhDp2QjZtMwlaQi+Q4MdnVj75i6bmrZFrF190QpQcOvj+e833cpe7+ud fk2453vceUxLLu6lt8N3vcOW1pCbGeupWexzwmwJ8EkWiJiSXtSgnoQU94ul/1X662sl 9Qi+0easXZdPop2zuybezwU65ctn7SEz/jf8yasWTHu0pVSvMuaYX3Da4TTYLrRJsx/7 TzQTpJDacy5YTHVcH9xsh+HG0qJ0+qkTLabiNxwEz6xmpQHiTHbgxzdxQW5Om/NjMoxm bT8w== X-Gm-Message-State: AIVw110LOJdMVTgSnQ5ezDWC2bcBm3O6SI7R0NQNuBEf6dvVDLSeGUZl cMSggjTHTAcf0YOrnBu/wJQlMPNRhzJBBdFnxtKwZAEA7fVyd2pU778xHikwVddPzDcorfhtIJG Yrg6FKEIIN27/qqU= X-Received: by 10.159.33.211 with SMTP id 77mr5962933uac.218.1500756844522; Sat, 22 Jul 2017 13:54:04 -0700 (PDT) X-Received: by 10.159.33.211 with SMTP id 77mr5962929uac.218.1500756844329; Sat, 22 Jul 2017 13:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Sat, 22 Jul 2017 13:54:03 -0700 (PDT) In-Reply-To: <345495C4-030E-41FA-98CD-B403509B9402@google.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> From: David Farmer Date: Sat, 22 Jul 2017 15:54:03 -0500 Message-ID: Subject: Re: To: james woodyatt Cc: Brian E Carpenter , IPv6 List Content-Type: multipart/alternative; boundary="001a1135526099d7380554ee2e08" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 20:54:09 -0000 --001a1135526099d7380554ee2e08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt wrote: > On Jul 19, 2017, at 09:57, Brian E Carpenter > wrote: > > On 19/07/2017 18:22, james woodyatt wrote: > > On Jul 19, 2017, at 01:15, Brian E Carpenter > wrote: > > > Hmm. Let's consider a case in which the last-hop route to a given LAN has > a prefix of > length, say, /80. What is the name of the bit-string from bits 81 through > 127 of the > host address? If they aren't called the "IID" what are they called? > > > If have yet to find where RFC 4291 clearly names the part of an IPv6 > address that follows a *routing* prefix apart from a *subnet* prefix. > Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is n= ot equivalent to > the concept of a subnet, and such a routing prefix is not equivalent to a > subnet prefix. As RFC 5942 clarifies. > > > Agreed, but I phrased my question in full knowledge of that. What do we > call those trailing > bits of the address? (I was reading the source of the Python 'ipaddress' > module yesterday, > and saw a comment about 'host bits', but that seems very 20th century, > given that the > IPv6 architecture refers to interfaces.) > > > I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for thi= s concept, and I find > that I rarely have much need for it. I suppose if I were using on-link > prefixes longer than /64, then I=E2=80=99d need it so I could differentia= te between > the 64-bit Interface ID and the shorter part of the address that follows > the on-link prefix. > I think I'd prefer to call the righthand side of both a subnet prefix and a on-link prefix an interface identifier, because in both case it is a node's interface that is being identified. Then generically they are interface identifiers, if you are referring to a specific aspect it is qualified with the aspect. generically; prefix / interface identifier with specific aspects being referred to as; subnet prefix / subnet interface identifier on-link prefix / on-link interface identifier Then it would be subnet interface identifiers that are 64 bits, except ... and on-link interface identifiers are any length. That is basically the assertion that started this part of the discussion, and that did fly with at least some. So, I've been kicking around other ideas, because if the righthand side of an on-link prefix isn't an interface identifier, it needs another name. How about; node identifier on-link identifier host identifier on-link node on-link host I think I like on-link node best, but on-link identifier is a close second for me. so; subnet prefix / interface identifier on-link prefix / on-link node or; subnet prefix / interface identifier on-link prefix / on-link identifier What do others think? --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1135526099d7380554ee2e08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <<= a href=3D"mailto:jhw@google.com" target=3D"_blank">jhw@google.com> wrote:
On Jul 19, 2017, at 09:57, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
On 19/07/2017 18:22, james woodyatt wrote:
On Jul 19, 2017, at 01:15, Brian E Carpenter <brian.e.carpen= ter@gmail.com> wrote:

Hmm. Let'= s consider a case in which the last-hop route to a given LAN has a prefix o= f
length, say, /80. What is the name of the bit-string from bits 81 thro= ugh 127 of the
host address? If they aren't called the "IID&quo= t; what are they called?

If have yet to find where RFC = 4291 clearly names the part of an IPv6 address that follows a *routing* pre= fix apart from a *subnet* prefix. Moreover, the phrase =E2=80=9Clast-hop ro= ute to a given LAN=E2=80=9D is not equivalent to the concept of a subnet, a= nd such a routing prefix is not equivalent to a subnet prefix. As RFC 5942 = clarifies.

Agreed, but I = phrased my question in full knowledge of that. What do we call those traili= ng
bits of the address? (I was read= ing the source of the Python 'ipaddress' module yesterday,and saw a comment about 'host bits'= , but that seems very 20th century, given that the
IPv6 architecture refers to interfaces.)

I=E2=80=99ve been mentally using =E2=80=9Caddress suffi= x=E2=80=9D for this concept, and I find that I rarely have much need for it= . I suppose if I were using on-link prefixes longer than /64, then I=E2=80= =99d need it so I could differentiate between the 64-bit Interface ID and t= he shorter part of the address that follows the on-link prefix.
=

I think I'd prefer to call the rightha= nd side of both a subnet prefix and a on-link prefix an interface identifie= r, because in both case it is a node's interface that is being identifi= ed.=C2=A0 Then generically they are interface identifiers, if you are refer= ring to a specific aspect it is qualified with the aspect.

generically; =C2=A0

prefix / interface id= entifier

with specific aspects being referred to a= s;

subnet prefix / subnet interface identifier
on-link prefix / on-link interface identifier=C2=A0
Then it would be subnet interface identifiers that are 64 bits= , except ... and on-link interface identifiers are any length.=C2=A0

That is basically the assertion that started this pa= rt of the discussion, and that did fly with at least some.=C2=A0

So, I've been kicking around other ideas, because = if the righthand side of an on-link prefix isn't an interface identifie= r, it needs another name. How about; =C2=A0

node i= dentifier
on-link identifier=C2=A0
host identifier=C2= =A0
on-link node
on-link host

= I think I like on-link node best, but on-link identifier is a close second = for me.

so;

subnet prefix= / interface identifier=C2=A0
on-link prefix / on-link node

or;

subnet prefix / i= nterface identifier=C2=A0
on-link prefix / on-link identifi= er=C2=A0

What do others think?

<= /div>--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David = Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
N= etworking & Telecommunication Services
Office of Information Technol= ogy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0= =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1135526099d7380554ee2e08-- From nobody Sat Jul 22 14:02:32 2017 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 C71A11317BE for ; Sat, 22 Jul 2017 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggXVaPy2Je26 for ; Sat, 22 Jul 2017 14:02:29 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6323F12711E for ; Sat, 22 Jul 2017 14:02:28 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id D1E41B67 for ; Sat, 22 Jul 2017 21:02:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw31jPkbCypu for ; Sat, 22 Jul 2017 16:02:27 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 99B809AD for ; Sat, 22 Jul 2017 16:02:27 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id x24so61450228uah.7 for ; Sat, 22 Jul 2017 14:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/JorsRGyGj6dHjqO5Whhvh13nLxcRAtL2Vjr0Gq9OGA=; b=KvNKa8PYFuz7YzUrYTcFKkSgQpTooLgavIViH9cYthDZHJTl4nDeW2vFdeVudcVw98 fqijnT549ayPFK3Gbu2StMu6j1Uf+U64wNpOKT9TRWWPnz75XThGP1qCAitMFRt3yC/q TKiGZfdSb3Dqcp9eIQIDyGU3FecWM4e39GUV1W8XZtW9cKKxlxAR7Rc5XEYUC1sdZT0f YZxhA9Adc4hsLeOcTJS5idojOGbAOFiIDrJM793YtjIfNpAUmdzLIgr2R9pwp+YLxJtJ Y779cPzKS5C/Uq/NYhS7h2uKhNSj5geunlluDR/osbx9tFciP+6lWYVpTHPipWXItqTT K9QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/JorsRGyGj6dHjqO5Whhvh13nLxcRAtL2Vjr0Gq9OGA=; b=J67E4md7kIoL9ZVvyk+Q9QA+mh9Yt1+fng1E1UNmA6HtGX24YKevX3BJ4VxTsh1Stn EZHzaKkdajvR2iXOB+/k3MiAGR/aNEcu6rfYt5J26nUwtqJKHZ5qVENBy3DFWCo66hen oQEVym6FjzEsrvkfmqXLFPXioEAi7ST9B+/EqbAESao99AwECAKaXPjMcqQQtsPrD2Eg gOBeTVeVpRd2qTW7PDY9GMDhk8JikH3+/sVrfWeO/PDxZdPPzzn78ex2YQlnpRvTUYD3 li5hMuJZ+18jlFNLxswgC93sZNq4aSKbYVEJi1+c5KKXoLWLLEMpHFj3gFp0UMF8zC8Z o04w== X-Gm-Message-State: AIVw111pCh8AxnTKLIJc4i6A+p7XxYOIskdQVxfucEOx2JzCKVBZSr7G 2+rQEnmJH64LW3GysZo5RNewwbGgqKSndyiaxcp1llrjZ8uVFezypdCgNBb/6QLLG7Wsm5khFKv DJqFRAhHGCPjxGqM= X-Received: by 10.176.27.160 with SMTP id k32mr6966916uai.200.1500757346646; Sat, 22 Jul 2017 14:02:26 -0700 (PDT) X-Received: by 10.176.27.160 with SMTP id k32mr6966909uai.200.1500757346490; Sat, 22 Jul 2017 14:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Sat, 22 Jul 2017 14:02:25 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Sat, 22 Jul 2017 16:02:25 -0500 Message-ID: Subject: Re: To: Brian E Carpenter Cc: Philip Homburg , 6man WG Content-Type: multipart/alternative; boundary="94eb2c117a548835d40554ee4cbe" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 21:02:31 -0000 --94eb2c117a548835d40554ee4cbe Content-Type: text/plain; charset="UTF-8" On Sat, Jul 22, 2017 at 3:47 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 23/07/2017 03:37, Philip Homburg wrote: > >> Then you really have to answer my question: if they are not called > "interface > >> identifier" what are those bits called? > > > > So let me call them 'host part' > > Hate to be picky but in RFC8200 'host' does not include 'router' and these > bits certainly exist in router addresses. > > So it would have to be 'node part'. But in most cases (the only exception > being anycast) these bits may be (not must be) different in the node per > interface, so 'node' is still wrong. I just don't get why it isn't > 'interface part' (with an exception for anycast). And if it's 'interface > part' I really don't see why it isn't 'interface identifier'. > > Here's a thought. How would it be if the contentious sentence in 4291bis > read, in its entirety: > > "Interface Identifiers are 64 bits long when used for Stateless > Address Autoconfiguration (SLAAC) [RFC4862]." > > ?. > > Who here could not live with that? > I'd be fine with that. But , how about instead of scoping it to SLAAC specifically, how bout more generically scoping it to automatically configured addresses or self-configured addresses as opposed to an address provided to the node externally. Just a suggestion, I can live with SLAAC specifically. thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c117a548835d40554ee4cbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 22, 2017 at 3:47 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 23/07/2017 03:37, Philip Homburg wrote:
>> Then you really have to answer my question: if they are not called= "interface
>> identifier" what are those bits called?
>
> So let me call them 'host part'

Hate to be picky but in RFC8200 'host' does not include 'router= ' and these
bits certainly exist in router addresses.

So it would have to be 'node part'. But in most cases (the only exc= eption
being anycast) these bits may be (not must be) different in the node per interface, so 'node' is still wrong. I just don't get why it is= n't
'interface part' (with an exception for anycast). And if it's &= #39;interface
part' I really don't see why it isn't 'interface identifier= '.

Here's a thought. How would it be if the contentious sentence in 4291bi= s
read, in its entirety:

"Interface Identifiers are 64 bits long when used for Stateless
Address Autoconfiguration (SLAAC) [RFC4862]."

?.

Who here could not live with that?

I= 9;d be fine with that.=C2=A0

But , how about inste= ad of scoping it to SLAAC specifically, how bout more generically scoping i= t to automatically configured addresses or self-configured addresses as opp= osed to an address provided to the node externally.

Just a suggestion, I can live with SLAAC specifically.

thanks
--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--94eb2c117a548835d40554ee4cbe-- From nobody Sat Jul 22 16:34:44 2017 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 85F07128AB0 for ; Sat, 22 Jul 2017 16:34: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, 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 XQjPyncad7H2 for ; Sat, 22 Jul 2017 16:34:42 -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 4E880126BF0 for ; Sat, 22 Jul 2017 16:34:41 -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 v6MNYecd015152; Sat, 22 Jul 2017 16:34:40 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6MNYY6R014774 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 16:34:36 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-10.nw.nos.boeing.com (137.136.239.219) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 22 Jul 2017 16:34:33 -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.1263.000; Sat, 22 Jul 2017 16:34:33 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTAwCAjdXC4YWz5kiBDEudqkiPiqJgfLiQ Date: Sat, 22 Jul 2017 23:34:33 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 23:34:43 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > So let me call them 'host part' So we would be renaming IID in every RFC. Quite a change. And it's not "hos= t" anyway, right? Those bits identify an interface, not a host. So call it = "interface part," or "interface ID." > Basically a 'host part' doesn't have any properties. But that's not a distinction. I can just as easily give a structure to an I= ID as I can to any non-64-bit IID, if I so choose. Or, use a pseudo random = value if I'm worried about privacy or security. > You can say it identifies an interface, but that is not the case if > a 'host part' is part of an anycast address. Not sure why you make this distinction. Even in the anycast address, these = last bits identify an interface, even if one of several possible. It's the = topologically closest interface, and others would be identified by the same= bit pattern. It's still an ID of an interface, as opposed to being a prefi= x. I just don't see why IIDs used in SLAAC should be thought of differently. I= mean, the anycast example was always a little weird, but those are a tiny = minority anyway. Bert From nobody Sat Jul 22 16:42:23 2017 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 04D87128B8D for ; Sat, 22 Jul 2017 16:42:22 -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 vgm24G2P6g0C for ; Sat, 22 Jul 2017 16:42:19 -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 C605D128AB0 for ; Sat, 22 Jul 2017 16:42:19 -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 v6MNgJg4033709; Sat, 22 Jul 2017 16:42:19 -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 v6MNgBj3033609 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 16:42:11 -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.1263.5; Sat, 22 Jul 2017 16:42:10 -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.1263.000; Sat, 22 Jul 2017 16:42:10 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTAyvE6xwZQzr840WQqx+S20+FCqJggQxQ Date: Sat, 22 Jul 2017 23:42:10 +0000 Message-ID: <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 23:42:22 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Here's a thought. How would it be if the contentious sentence in > 4291bis read, in its entirety: > > "Interface Identifiers are 64 bits long when used for Stateless > Address Autoconfiguration (SLAAC) [RFC4862]." I think that is a pointless semantic complication for no benefit other than= to make non-64-bit IIDs appear to be more outcasts. I vote -1 on that. Bert From nobody Sat Jul 22 16:55:14 2017 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 7D55E12F258 for ; Sat, 22 Jul 2017 16:55:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pp3P6hchtTvm for ; Sat, 22 Jul 2017 16:55:11 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448881300CE for ; Sat, 22 Jul 2017 16:55:11 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 125so42395760pgi.3 for ; Sat, 22 Jul 2017 16:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=elGpK6E4oZZMGk9uhKsE9gwBFLGJvGPjxTXDiEOCV6o=; b=NCJcBwODrc2sPoUcyT2vHZ1D0+ExsuZHM/MrQLHArLdVo5p24u29nOVEm8CDfzkB3K uoS0rQp7+kFNG+29CXxaxZHxeMd/a8D4NbYIM+OQ+AXAwe2XihFv9zpnoO9CACe+Vt0q mQR6RCdhlv4ff5+NKlKZTx2vbR1ph6uRyL4hSfRyOWFya7Knf6TD9saiAI+s68AUsW8J bHYRcZ/5hvg4fP/pmFCqZ8nsa/yKdliVTWVuBCB6JizyAnUIajh8B4iH/QkLHUwk8Sc2 IaYgBVWkHvNP9pXamaWT2UE7m1GhxopldEOlJmaFz8ITyFEYLdHLi8l3IsY/+H67Lshk m50Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=elGpK6E4oZZMGk9uhKsE9gwBFLGJvGPjxTXDiEOCV6o=; b=kZ5qPeW5AEYRrMgdaHOYpIhMQanZZlwzUK0C+1SCmgrnHymIaG6uFdyzhBLcQPEE7K pXlwn6EXjirMccpcb7Bqa4rCWHPBoS6o+2pUQY+9ZUNLg8GE8+e32gmaCzf4sTUK7TAr l41W9rq74KvGZ7mcUaq3xWcR8ymrfk5+OThH5v3F+wcmY2B2KLu/XkQeIZxZcPn6kVj6 ngo4AzN1vqpsSJa01Pb3VsvAvvzzl4q5CcxZVt8SnFLGLyI0qMCwBEG8ZP7NuamDvHIt GByqg5w1b1ieXuhtmc0RbzEMMc05EIfW27agorJH7JMwmqxJXIvlnZkQxjPuawhlbQh3 5YWA== X-Gm-Message-State: AIVw110Z0zHUxXjmxgSe7vs/Y61xQ0fXp56xE5hMO7gGNA4pYSSYIiFA jpn2/SZgxjSvdvDF X-Received: by 10.98.79.130 with SMTP id f2mr11961274pfj.133.1500767710666; Sat, 22 Jul 2017 16:55:10 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l8sm14408071pgs.30.2017.07.22.16.55.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 16:55:10 -0700 (PDT) Subject: Re: To: "Manfredi, Albert E" , "ipv6@ietf.org" References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> Date: Sun, 23 Jul 2017 11:55:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 23:55:12 -0000 On 23/07/2017 11:42, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >> Here's a thought. How would it be if the contentious sentence in >> 4291bis read, in its entirety: >> >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." > > I think that is a pointless semantic complication Actually, by removing all the exceptions in the -09 text, I contend it is a considerable semantic simplification. > for no benefit other than to make non-64-bit IIDs appear to be more outcasts. Not at all. It sticks to the principle that an Internet Standard doesn't change the existing protocol but clarifies the applicability of the 64 bit rule. You need to compare it with RFC4291, not with the -09 text. If you want to *change* the rule for SLAAC IID lengths, that's outside the scope of promoting 4291 to IS status. Regards, Brian From nobody Sat Jul 22 17:10:23 2017 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 059A312FB9C for ; Sat, 22 Jul 2017 17:10:22 -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 LnsXEBCWhOym for ; Sat, 22 Jul 2017 17:10:21 -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 E90BA12F268 for ; Sat, 22 Jul 2017 17:10:20 -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 v6N0AJEo064093; Sat, 22 Jul 2017 17:10:19 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6N0A9T4064057 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 17:10:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-09.nw.nos.boeing.com (137.136.239.172) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 22 Jul 2017 17:10: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.1263.000; Sat, 22 Jul 2017 17:10:09 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTAyvE6xwZQzr840WQqx+S20+FCqJggQxQgAB51wD//4tooA== Date: Sun, 23 Jul 2017 00:10:08 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> In-Reply-To: <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 00:10:22 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPiBBY3R1YWxseSwgYnkgcmVtb3Zp bmcgYWxsIHRoZSBleGNlcHRpb25zIGluIHRoZSAtMDkgdGV4dCwgSQ0KPiBjb250ZW5kIGl0IGlz IGEgY29uc2lkZXJhYmxlIHNlbWFudGljIHNpbXBsaWZpY2F0aW9uLg0KDQpJIGFncmVlIHRoYXQg dGhlICJleGNlcHRpb25zIiBjb3VsZCBiZSByZXdvcmRlZCwgYmVjYXVzZSB0aGUgaXNzdWUgaXMg ZmFyIHNpbXBsZXIgbm93IHRoYW4gd2hhdCB0aGUgImV4Y2VwdGlvbnMiIGltcGx5Lg0KDQpJSURz IHVzZWQgaW4gU0xBQUMsIExMQSwgb3IgVUxBLCBtdXN0IGJlIDY0IGJpdHMgbG9uZy4gT3RoZXJ3 aXNlLCB0aGVyZSBhcmUgbm8gcmVzdHJpY3Rpb25zLCBvdGhlciB0aGFuIHRoZSB0b3RhbCBhZGRy ZXNzIGxlbmd0aCBtdXN0IGJlIDEyOCBiaXRzLiBTbyB0aGlzIGF2b2lkcyBjcmVhdGluZyBhbm90 aGVyIG5ldyBzdWJ0bGV0eSBmb3IgSVB2NiwgdGhhdCBzZXJ2ZXMgbm8gdXNlZnVsIHB1cnBvc2Ug KElNTykuDQoNCk9uZSBvZiB0aGUgYmlnZ2VzdCBjaGFuZ2VzIGluIDQyOTEtYmlzLCB3aGljaCBz aG91bGQgY2Fycnkgb3ZlciB0byBSRkMgMjQ2NCBhbmQgb3RoZXJzLCBoYXMgYmVlbiBkZXByZWNh dGlvbiBvZiB0aGUgdXNlIG9mIEVVSS02NC4gVGhlIGNvbnNlcXVlbmNlIG9mIHRoYXQgY2hhbmdl IGlzIHRoYXQgdGhpcyA2NC1iaXQgSUlEIHJlcXVpcmVtZW50IGJlY29tZXMgZGltaW5pc2hlZCwg YW5kIGJ5IGV4dGVuc2lvbiwgdGhlIHByZXZpb3VzbHktbGlzdGVkIGV4Y2VwdGlvbnMgaW5jcmVh c2UuIFNvIG5vdywgcmF0aGVyIHRoYW4gbGlzdCB0aGUgZXhjZXB0aW9ucywgd2Ugc2hvdWxkIGJl IGxpc3Rpbmcgd2hlcmUgNjQtYml0IElJRHMgYXJlIHN0aWxsIHJlcXVpcmVkLg0KDQpJJ3ZlIG5v IG9iamVjdGlvbiB0byB1c2luZyBsYW5ndWFnZSBsaWtlICJkZWZhdWx0IiBvciAicmVjb21tZW5k ZWQsIiB0aG91Z2guDQoNCkJlcnQNCg0K From nobody Sat Jul 22 18:58:10 2017 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 6E8F8124D37 for ; Sat, 22 Jul 2017 18:58:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nrWVYwSOEyVY for ; Sat, 22 Jul 2017 18:58:06 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 9D0A31318A3 for ; Sat, 22 Jul 2017 18:58:06 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id s70so35681597pfs.0 for ; Sat, 22 Jul 2017 18:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8n2qVJGdEA9NpnhhY15QbNGZtkSwt08KIvLLvgthYrI=; b=MFa44altydF6RAuXRP+TMYgMep3xsO4rEeDeMtCZVLvVEgFSnJAQZ9LgCABe9tkQNk 63dOhY8mIfy8x9GIMp7I/FeeNBYgPqNa16MZ05jKHjBNBnUTkJFBJTT/cmmfcK/SP7Ax ++XvHWzQg03chFrCoNGqmVbFB5fguucjbFW+SR8JTLfSeRzGYhwU/sESW1PLDXpAa7ln KknxIN/0Uk/7ZsmEqag1kTzCyHMFP6BBB/NI28zdMLqLsGUOZc5S/MsrOKIsZVogrpm/ w/QwDQ/dzDje7uj8zXwP2lOjBstQ9eUpQj/4XskuxuHoqRv0JHgS87tuFmS6MpA7KVhr D56g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8n2qVJGdEA9NpnhhY15QbNGZtkSwt08KIvLLvgthYrI=; b=oadFDj5rwZKo3py2WQ5dxnK81WfKwoDcc6O3J68lkWCbll9XbutS4KoTHfqpoaAN/s 15RgbjJvs7yPh6D5HvPP5JY5b2jEL0iZ2WWZ9w6uES4xJBBmB3N4U4YE2KhJisAx1V1L JRWU6+2FsKpP9vg/tXyJhKWLIho7oWJ72S0Zi+wxN3enqYsmXqstooDVUqyfFX7TjxOI DwFmbIBsIdyS+X04IePN9HrNh1PXmH/8HF9KIfeB8lNqy7nFxPznVt/vyu9QlasXJ933 MFnkxmW4f3Viq79H1IqQLHe/pQOkp0igL2qM+Pebkh11iXvNULYWtjet3gsoVmcN1Erv 3D9Q== X-Gm-Message-State: AIVw110FY16EgBUe6V4DXpyeBjOzSMGuh3eeXtzj0tXD/aBvQCITxHNo prqzSstCER0RzTlM X-Received: by 10.99.126.86 with SMTP id o22mr11845184pgn.383.1500775085998; Sat, 22 Jul 2017 18:58:05 -0700 (PDT) Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a29sm16962493pfg.30.2017.07.22.18.58.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 18:58:04 -0700 (PDT) Subject: Re: To: "Manfredi, Albert E" , "ipv6@ietf.org" References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <422c7640-4dbe-26ce-a45a-f26a7cd6d3fe@gmail.com> Date: Sun, 23 Jul 2017 13:58:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 01:58:08 -0000 On 23/07/2017 12:10, Manfredi, Albert E wrote: > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Actually, by removing all the exceptions in the -09 text, I >> contend it is a considerable semantic simplification. > > I agree that the "exceptions" could be reworded, because the issue is far simpler now than what the "exceptions" imply. > > IIDs used in SLAAC, LLA, Link-local address creation is part of SLAAC (RFC4862 section 5.3). > or ULA, There is nothing special about a ULA prefix. An address derived from a ULA prefix may, or may not, be created by SLAAC. BCP198 applies to ULA prefixes. Brian > must be 64 bits long. Otherwise, there are no restrictions, other than the total address length must be 128 bits. So this avoids creating another new subtlety for IPv6, that serves no useful purpose (IMO). > > One of the biggest changes in 4291-bis, which should carry over to RFC 2464 and others, has been deprecation of the use of EUI-64. The consequence of that change is that this 64-bit IID requirement becomes diminished, and by extension, the previously-listed exceptions increase. So now, rather than list the exceptions, we should be listing where 64-bit IIDs are still required. > > I've no objection to using language like "default" or "recommended," though. > > Bert > From nobody Sun Jul 23 06:54:46 2017 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 15261129AA8 for ; Sun, 23 Jul 2017 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 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_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 lc-uIFPNYrUi for ; Sun, 23 Jul 2017 06:54:43 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 3B839127058 for ; Sun, 23 Jul 2017 06:54:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v6NDsevi188361 for ; Sun, 23 Jul 2017 15:54:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9779620264B for ; Sun, 23 Jul 2017 15:54:40 +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 8E40B20242F for ; Sun, 23 Jul 2017 15:54:40 +0200 (CEST) Received: from [132.166.84.2] ([132.166.84.2]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v6NDseS2010389 for ; Sun, 23 Jul 2017 15:54:40 +0200 Subject: Re: Vehicle VINs (Was: Battling human nature) To: ipv6@ietf.org References: <710a7d9ef9444eefa4f45d4ea7a29e03@XCH15-06-11.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Sun, 23 Jul 2017 15:54:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 13:54:45 -0000 off-topic, about the the press and automobile technology. Le 21/07/2017 à 20:44, Simon Hobson a écrit : > "Manfredi, Albert E" wrote: > >> Look at your automobile's VIN. It's humongous. Surely, we're not >> going to insist that the VIN become part of the car's Internet >> address? > > Going off topic, already been done (sort of) - and the obvious > security implications found out after the fact ! > https://www.theregister.co.uk/2016/07/08/bmw_vulns/ One should be careful with what the press says. Because, when that URL says this: > The first (and more serious) vulnerability creates a means for a > hacker to access another driver’s Vehicle Identification Number (VIN) > before changing in-car settings such as lock/unlocking the vehicle, It obviously ignores that the VIN is required to be displayed under the windshield. It must be there and visible. One difficulty may be in the distance (it's written in smaller characters), but certainly in the reach of longer lenses. Others pointed that VIN identification is readily available on the OBDII port to CAN networks of some automobiles. If it's a risk, then maybe CAN network managers should protect that CAN. On another hand, if we need to consider the privacy of some identifier of some car, that may be the MAC address of 802.11-OCB beacons (DSRC) that may be periodically advertised by cars, and sniffed by anyone along the road. The MAC address could be considered as a 'signature' that is not required to be public, and is hence private. Or maybe they will want it to become public... Alex From nobody Sun Jul 23 13:27:01 2017 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 468E7129B5E for ; Sun, 23 Jul 2017 13:27:00 -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, RP_MATCHES_RCVD=-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 GbZuu6kTHTGC for ; Sun, 23 Jul 2017 13:26:58 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD83129B15 for ; Sun, 23 Jul 2017 13:26:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 7FF361BC37; Sun, 23 Jul 2017 20:26:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [OT] Vehicle VINs From: Simon Hobson In-Reply-To: Date: Sun, 23 Jul 2017 21:26:53 +0100 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <710a7d9ef9444eefa4f45d4ea7a29e03@XCH15-06-11.nw.nos.boeing.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 20:27:00 -0000 Alexandre Petrescu wrote: > One should be careful with what the press says. Indeed. > On another hand, if we need to consider the privacy of some identifier > of some car, that may be the MAC address of 802.11-OCB beacons (DSRC) > that may be periodically advertised by cars, and sniffed by anyone = along > the road. >=20 > The MAC address could be considered as a 'signature' that is not > required to be public, and is hence private. Or maybe they will want = it > to become public... That is indeed going to be an interesting discussion. Sadly, in these = days when so many people see no problem filling the data silos of the = likes of FaceBook, I can see a lot of the public going "meh ?" and not = seeing any problem with it. From nobody Sun Jul 23 16:27:38 2017 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 C1B5E1270AC for ; Sun, 23 Jul 2017 16:27:36 -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 IsN8o_lL7f4k for ; Sun, 23 Jul 2017 16:27:35 -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 ABD59124BE8 for ; Sun, 23 Jul 2017 16:27:35 -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 v6NNRYx4004014; Sun, 23 Jul 2017 16:27:34 -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 v6NNRUTo004001 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 23 Jul 2017 16:27:30 -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.1263.5; Sun, 23 Jul 2017 16:27:29 -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.1263.000; Sun, 23 Jul 2017 16:27:29 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTAyvE6xwZQzr840WQqx+S20+FCqJggQxQgAB51wD//4tooIAAlvCAgADlwHA= Date: Sun, 23 Jul 2017 23:27:29 +0000 Message-ID: <256639f6155049069dae4e86d236833b@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> <422c7640-4dbe-26ce-a45a-f26a7cd6d3fe@gmail.com> In-Reply-To: <422c7640-4dbe-26ce-a45a-f26a7cd6d3fe@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 23:27:37 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANCg0KPj4gSUlEcyB1c2VkIGluIFNMQUFD LCBMTEEsIA0KPg0KPiBMaW5rLWxvY2FsIGFkZHJlc3MgY3JlYXRpb24gaXMgcGFydCBvZiBTTEFB Qw0KDQpUcnVlIC4uLiBhbHRob3VnaCB0aGlzIHdlYWtlbnMgdGhlIGFyZ3VtZW50IGZvciBjbGFp bWluZyB0aGF0IElJRHMgbXVzdCBvbmx5IGJlIDY0IGJpdHMgbG9uZy4gU3RyaWN0IGludGVycHJl dGF0aW9uIG9mIFJGQyA0ODYyIGltcGxpZXMgdGhhdCBzb21lIFNMQUFDIGFkZHJlc3NlcyBjb3Vs ZCBoYXZlIG90aGVyIGxlbmd0aHMgb2YgSUlELCBhdCBsZWFzdCBpbiBwcmluY2lwbGUuIFJGQyA0 ODYyIHNheXMgdG8gcmVmZXIgdG8gdGhlIGxpbmsgbGF5ZXItc3BlY2lmaWMgUkZDIHRvIHNlZSBo b3cgbG9uZyB0aGUgSUlEIGhhZCB0byBiZS4gSXMgdGhpcyBzdGlsbCB3aGF0IHBlb3BsZSB3YW50 PyBTb3VuZHMgbGlrZSBhbm90aGVyIGdvb2QgcmVhc29uIGZvciBOT1QgcmVkZWZpbmluZyBJSURz IGFzIG9ubHkgYXBwbHlpbmcgdG8gNjQtYml0IElJRHMuDQoNCj4gVGhlcmUgaXMgbm90aGluZyBz cGVjaWFsIGFib3V0IGEgVUxBIHByZWZpeC4gQW4gYWRkcmVzcyBkZXJpdmVkDQo+IGZyb20gYSBV TEEgcHJlZml4IG1heSwgb3IgbWF5IG5vdCwgYmUgY3JlYXRlZCBieSBTTEFBQy4NCg0KQnV0IFJG QyA0MTkzIGlzIHByZXR0eSBzcGVjaWZpYyBhYm91dCBJSUQgbGVuZ3RoIG9mIFVMQXM6DQoNCjMu MS4gIEZvcm1hdA0KDQogICBUaGUgTG9jYWwgSVB2NiBhZGRyZXNzZXMgYXJlIGNyZWF0ZWQgdXNp bmcgYSBwc2V1ZG8tcmFuZG9tbHkNCiAgIGFsbG9jYXRlZCBnbG9iYWwgSUQuICBUaGV5IGhhdmUg dGhlIGZvbGxvd2luZyBmb3JtYXQ6DQoNCiAgICAgIHwgNyBiaXRzIHwxfCAgNDAgYml0cyAgIHwg IDE2IGJpdHMgIHwgICAgICAgICAgNjQgYml0cyAgICAgICAgICAgfA0KICAgICAgKy0tLS0tLS0t Ky0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICAgICB8IFByZWZpeCB8THwgR2xvYmFsIElEICB8IFN1Ym5ldCBJRCB8ICAgICAgICBJbnRl cmZhY2UgSUQgICAgICAgIHwNCiAgICAgICstLS0tLS0tLSstKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBXaGVyZToNCg0KICAgICAg UHJlZml4ICAgICAgICAgICAgRkMwMDo6LzcgcHJlZml4IHRvIGlkZW50aWZ5IExvY2FsIElQdjYg dW5pY2FzdA0KICAgICAgICAgICAgICAgICAgICAgICAgYWRkcmVzc2VzLg0KDQogICAgICBMICAg ICAgICAgICAgICAgICBTZXQgdG8gMSBpZiB0aGUgcHJlZml4IGlzIGxvY2FsbHkgYXNzaWduZWQu DQogICAgICAgICAgICAgICAgICAgICAgICBTZXQgdG8gMCBtYXkgYmUgZGVmaW5lZCBpbiB0aGUg ZnV0dXJlLiAgU2VlDQogICAgICAgICAgICAgICAgICAgICAgICBTZWN0aW9uIDMuMiBmb3IgYWRk aXRpb25hbCBpbmZvcm1hdGlvbi4NCg0KICAgICAgR2xvYmFsIElEICAgICAgICAgNDAtYml0IGds b2JhbCBpZGVudGlmaWVyIHVzZWQgdG8gY3JlYXRlIGENCiAgICAgICAgICAgICAgICAgICAgICAg IGdsb2JhbGx5IHVuaXF1ZSBwcmVmaXguICBTZWUgU2VjdGlvbiAzLjIgZm9yDQogICAgICAgICAg ICAgICAgICAgICAgICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLg0KDQogICAgICBTdWJuZXQgSUQg ICAgICAgICAxNi1iaXQgU3VibmV0IElEIGlzIGFuIGlkZW50aWZpZXIgb2YgYSBzdWJuZXQNCiAg ICAgICAgICAgICAgICAgICAgICAgIHdpdGhpbiB0aGUgc2l0ZS4NCg0KICAgICAgSW50ZXJmYWNl IElEICAgICAgNjQtYml0IEludGVyZmFjZSBJRCBhcyBkZWZpbmVkIGluIFtBRERBUkNIXS4NCg0K U28gaGV5LCBwZXJoYXBzIFVMQXMgYXJlIHRoZSAqb25seSogc3RyaWN0bHkgbWFuZGF0ZWQgNjQt Yml0IElJRCwgYXMgb2Ygbm93PyBSRkMgMjQ2NCBpcyBpbiBqZW9wYXJkeSwgc29ydCBvZiwgZ2l2 ZW4gaXRzIHJhdGlvbmFsZSBmb3IgcmVxdWlyaW5nIDY0LWJpdCBJSUQgb3ZlciBFdGhlcm5ldCBs aW5rcy4gRm9yIGV4YW1wbGUsIG9uY2UgdXBvbiBhIHRpbWUsIHRoZXJlIHdhcyBhIDE2LWJpdCBv cHRpb24gZm9yIE1BQyBhZGRyZXNzZXMuIENvdWxkIHRoYXQgY3JlZXAgaW50byBSRkMgMjQ2NC1i aXMgc29tZWhvdz8gTm8gdGVsbGluZyB3aGF0IG90aGVyIElJRCBsZW5ndGhzIHdvdWxkIGJlIHJl cXVpcmVkIGZvciBvdGhlciBsaW5rIGxheWVyIHR5cGVzLCBpbiB0aGUgZnV0dXJlPyBJJ20gcHJl dHR5IHN1cmUgbW9zdCBwZW9wbGUgd291bGRuJ3QgYXBwcm92ZSBvZiB0aGUgZGlyZWN0aW9uIHRo ZXNlIGNvbnNpZGVyYXRpb25zIHdvdWxkIGxlYWQgdXMgdG8sIG9uIHRoZSA2NC1iaXQgYm91bmRh cnkgcXVlc3Rpb24uDQoNCkJlcnQNCg0K From nobody Mon Jul 24 01:51:50 2017 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 3EF5B12EC30 for ; Mon, 24 Jul 2017 01:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 IT9f9guHwAuX for ; Mon, 24 Jul 2017 01:51:45 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DC2129ACD for ; Mon, 24 Jul 2017 01:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KO7tsX3dlif/5kEhO7YMiOvAKId/QVeQLN+9FX3u3D4=; b=Ge7LONjE4f/aE7Ow4ShpwX15mbcXYj/OA8o6YdE/U8zP410DtRZ+2qGsW3KCYiIv7qe4ei57Hw2iZlabLizIXPmT/952DBr/XUsAXfkfQAHQ2QXy/TS9/CTLd5Jn8kq/hoGVI0oGCjnasxIx+dXlLUy1ncBf5nUeqpM+HlJPWsQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.171.5.69) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 24 Jul 2017 08:51:40 +0000 Message-ID: <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "David Farmer" Cc: "IPv6 List" References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> Subject: Re: Date: Mon, 24 Jul 2017 09:47:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.5.69] X-ClientProxiedBy: VI1PR09CA0058.eurprd09.prod.outlook.com (2603:10a6:802:28::26) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 605f5c30-a543-4b2a-6d25-08d4d2713409 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:9L7epxyOTe6UNml2K44XY+52UQl/+JlB2PWJfFSKg7xsuVjyhq5L+ekqlYyXX1oHWb+L+MBra1LjZ48eQ6YCMy+/1lzUKIBGADuqfE9Wbqslm09ZxsiszNyyZzxW+KaB0NPkhDOVKoFvbr4GNXo/sPf94IxYCVYZGgadd7t9ZQ95oGXbB1y/mDQxDXoMA8axLCD55nV6MoFpUnUUtM2FyApT5xy3NSzkAdjleT5bXrx1pvoD9i/Po6es/n2nHIQ+i1BOg8QY5bV0T7s0L05HPoJtKP0hHxRjOFWyI/bE33YDbi+4dxV9nE/JtYe+d3XJXtxAHLqKacCgrMkPfQDSRDhNcGMwLAVc7EjSm5wu65fQwJloZlC6WZrtBEQTBoA6zmDesk7c1IRTZ0qtQCbhctXhFSmRXQ/bpu2f0AtMKMgqW+iBc5JSrHY8mWLAHA31KNYUMe3Y9/pK0/Z50hEKwA0oU6L54+g4QQmGPlHUpOCMl0laMCBqO1X/q2vli6kgcNZ5MswVbThwTN5wrkEAw6GcOimMLCrErzKFBlhJqIL+McH2xh9OspquOw4prcwEUln9dGpJzMxyIwJ2TjF8Lbqu0oDVz1yxsQbH3sHU56P6sRlenAL4Fea1O43c05/kKGMV1D0clEOz9bu1Mz7nFnNrUKo4pWRsNvTcmNTEA4nIrVFT6JkySFYkvKjHiXJ/WaYFCHywveS+pqFxb8ZhlR9987XulqdgfwuwGrnAmrQ= X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 25:aT4EWPnUy5VZk8ZS38f2LHeZindgtUf+BR7Cvj/MOm8FgaC5BWCVWdgc0JOZxk9+tUyOg8RAIsmu3+enBszRt9rxvvNd1T0i8jE+H3rgbSZ7BHW5relWQ2IFFhLlEyWu8xAi8S9ME6vhdLWLWY/FP6EQXPnps9f2sCNrrc8EMaDx4wnZ/1zpxwIKWEJaxIf5IXZc66h/HtswEMkoWMAMpl2Z4AA4NCsX7dMjCd0ScZy8mchiMWSzrhe76ffqKWydCBn3vZkekUWELEIgBvsMMA5Ewe+g5onA6VDpd1aNHdZzp/7gc219dVMeZaEoZs55T1aFltTxS7NThfD3jSSZcRbADoCUeqhOIaAh9XDKKiHUmpNOmtuD0gY4ACOdizeMr9Mur9tspaq80XsNgieAveE6PFBDcsg3YIDykyJ8dh5OZNFojLyJ2qJjw4uPYKhDWGacVXfFE2FxVTGuTogieVa1mfbkV8TOJ/S/KlQUA3MpSOXhK4Qp2H1e8Ye24p4hrZQAUbYDDQ2GI20zfYDdfNmBba1ShovNZsWcdUO0l6jzQS6GWvvOLQH7ULK6YmfEmsi7IKTRtQSvuZysjWts3xJYI2v/W1MH27daxZL4/DXgQt3DlwInckoZEhx3RMOdwESCpAtHHthLh5g503+38kYNQ/8RtQdVGBoFGcBF6rg5SWv+IfnE56jj9n/PNR1yAPJ1T3sORgvkqeMWMpnS+yi4JRabrtmw3p6aabC8iPXlz/OjXjCfXhFRAV3G2hdiuXjmgUu+7vY/CnnWJj3Lw4QpAeS9k0ATv0iO2R0XL7ZUTYw/MQfr0mEUUYOLvbgvYWmrbwlB3Eirjz0tlsf5uomC0MmmVh1sjnQKXK+vSAU/Jtkzj3KnUOdIU+4FqkIbI2YRRp4SqDbhQzkYafLxrrNTm9BUhUaRfgd0ZoRsjAY= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:oNUogS57GyizRvap5QFiow5SQnbmXD97upbpMTJximgrgvsErgt0CRMQ0H410ej0asRVIrTMtBdRTr3a2FGCD8EeGqm/JqVZVBYIt7gec7k4rxaGskKV6zffDaKLr2M7aTuw69K9r3SsN2jAyYOLYzOvWRPWLwdchmOish2tiMamLjIxrup+j3RrDPwTARsd70g8x5mWzk44kkY7vSabg8Pao89Dn31gx1PVNWDq8+o/xpRrIkXHYXgfv5S0ArOr6SAF1czHcJEUSoniZw+eRfJUl8+9EN+ETUu4uznfgIcdR5eddOfMwBvLOZQA56koaPxM79PMQQD9zVw874MINHkDKinetJ3fmda4nBg+471a0N3E2XylD3NhWAEGOVvZ+QPEXRNfKrR9ubGPJYSERUJ1vP5IqqvHk8IHky3q6HqWLfYlL1AEG3/aHiRFZR3s51LnkGbqP87sUsjPl28snONkFeL5DHxy670ceh1wY6WrdgUhM4qPLag8qSZS378fu2E6M6hpw1hwef4O7prDY4vjtq15iYRtLDUjpYl39zsuGLwEzd2X1INizGASb3YfhuT8C48wd2+kr5ZhOIpDpNpJhBKcYsz2DVcge1Q98N5Mg2O2gcGmcZr2aloHVFlbgD0pZm2MkrZ5XianMm0QQK1AJO0aHU1Y34YBOI6eQOu4CpPt/pr8hjIoq5Z0gxcO X-Exchange-Antispam-Report-Test: UriScan:(211936372134217)(153496737603132)(8104003914727); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(920507026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7NDozUkRneDRNSzNhVUpyUHlYL21Cb2o5S2dr?= =?utf-8?B?eGNlZ1BoNm9xY2QwSVZzd3Vwc1NJTHNLTndqSWxVczF3c3BzYXQwdzhXejIw?= =?utf-8?B?Wno3RlB4NkxFcVl4NmVwTGNmRVZrUUI3aXBmalVLaTJaYVpvRkdhVkxueHBv?= =?utf-8?B?N3NlUDR6QWtkOU1MbkdLazJaOERrUHFINTBwOVRmYXkyVktjUDM5YVdnRFJW?= =?utf-8?B?SXc2aVpPQ29VOWdzMFNxTGVUV0FUUXhTQkdmMW9Nb3pMd2k0QSsxTWh3SzRJ?= =?utf-8?B?MHVyWjB6WjE5WUtVR0s4M3pYRFBhRmhJS0FDNmRPVFBlMThrVU9hekFhTmpJ?= =?utf-8?B?eWhqb3JGSHIvODE0aDVWU3FKWTdSbEJwemtPSlpSQ3FYMW1IaFgxeGhEU0hn?= =?utf-8?B?RVV4NGlMeUpmeFdBTjZ2SWgveTA3ZnNUbkNNNm9Ib1ppeFo1eWRNZFFBY3lT?= =?utf-8?B?SU1jZ1BrbUZvVTBtMWtuOXNKbU5iY085N0syaEhWNVRNcnlWTWJLZzR2M0s2?= =?utf-8?B?SEdkcHlhMlBYUkxGdFpBbzAreGE4Y2tvU2JpcFMzNWQ4ZEV4b0VBNlhDbEYz?= =?utf-8?B?NzlyYmpJV3Q2RitBaWw0S1FCSFZvRndwRGZ2a2FuWjd1OVZWdUROQnpucDk3?= =?utf-8?B?dlU0YTMzakhKNGZpMTFvaDJCVDhrZWJiR2cyNHhWM0Exa1Zrai84L0xwYVVr?= =?utf-8?B?bXdlbFZ3aHdPWUVoYTFQNmcxdEMxdTVxZzc0c29qTkJkanl2a3RNT0FSMThZ?= =?utf-8?B?RzRyUGREdHgzZSt2VzNJVy9qaHJzU3hRZERTVGhxT05HUmNFR25oUGVMZU9M?= =?utf-8?B?cCtaalVESU5LUHdaTTRhLytMUmZWL3VNZTZTYUNxK3NwNG1BUG1sdFZEVS9n?= =?utf-8?B?dit6U044eDBFcnlXSVJtNlVtaTM1UWw3emd2ekk0ZWZ1TjlYeWQ1dzJwOVA0?= =?utf-8?B?L25SQ2VjdWhxZ2RFL0hVbCtLc1lPRU5ISUFaelp0aWVOM1lpbXQ5UlBIMDRP?= =?utf-8?B?WWRNY1JtQ0xqM1Z1NnVZN3lOc1FCeXdDazNka2g5aEltS1FSeDVlelE5TGxZ?= =?utf-8?B?c1J1UVlMWUhwMEZqSnE2UCtweE94Tmk2Q2RueURYbEVVeTV2aG53Z3VBc1Vm?= =?utf-8?B?THRmdDc3RWJxNUR6YzRGY0FCVWpxM0Y5ZmdqRDlWaDVNN1RweU9Rd28wcmJh?= =?utf-8?B?K1Z4bEJRaStsLzdyTlhvWlpFTWhqWUtRRTAvWktlM2pIVzFyclBUZmdGaFpr?= =?utf-8?B?TVAvNEcrMVdPeGJ3WHUweWFGeHowS09jL0s0NnJveGdza1p0T050N0ZydkxB?= =?utf-8?B?bmZTRjRJOEpWWnpCS2lzL0JXVVluODhCMGJyMWpsTnhqMkVmaXhOaHkvK29z?= =?utf-8?B?dkpXYUJ2Qk1taGR5SmhmWDBTMXd2NDMrQ0tCR2JacnlIcE5sS3cyT2NFSS9O?= =?utf-8?B?TWtEelh1QjlZZVFYN0hKK3hhSTlyNzExNElZVzBpdnFUTVpFUTd3aDk4eFdF?= =?utf-8?B?M1JxYlJpNitNclJaNm9uY0hEMVgzTU9pd3VwSEZQWGlVcDdtSzFLRlFqUm5S?= =?utf-8?B?bmI5ZFhLdVJQckJMQ2tSN2JqQkVHL0o1MDlDTGRkK3E1RmQyejNPSnJjQUE3?= =?utf-8?B?eGtjY2c4ajhSNkQzd0pGcjdtc29qN0UrcXNjRHlXZVprVVU4OTB0T05DRGNE?= =?utf-8?Q?qdu5CEOWdmqlR1cIIrbUXsEeq3HX4Ueiglo68BLD?= X-Forefront-PRVS: 0378F1E47A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(39410400002)(39860400002)(39400400002)(39850400002)(39450400003)(39840400002)(199003)(13464003)(189002)(377454003)(24454002)(97736004)(7350300001)(6116002)(50466002)(189998001)(14496001)(6486002)(23676002)(6666003)(3846002)(1556002)(33646002)(86362001)(44736005)(4720700003)(6916009)(53546010)(105586002)(42186005)(229853002)(2906002)(53936002)(61296003)(34040400001)(5820100001)(106356001)(66066001)(5660300001)(2870700001)(62236002)(4326008)(38730400002)(81156014)(6496005)(101416001)(116806002)(1456003)(478600001)(8676002)(6306002)(81816999)(2171002)(76176999)(81166006)(50986999)(305945005)(966005)(25786009)(47776003)(230783001)(50226002)(9686003)(68736007)(93886004)(110136004)(6246003)(81686999)(44716002)(84392002)(7736002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7MjM6TmRyK0tSV0t2dnBabUtqR1V5aG1UbkNP?= =?utf-8?B?OGtodWdyZDdyWllsYjY4MklDaVBOK0czU1VhR2xMV1J1QzJlZlBqTUNtM1U3?= =?utf-8?B?WUFXTC9kVkFqOFpRVm83ZXBOeHRPZDQvaC9IbEg1ZVJ5bGxvS1BjVmFZYUZK?= =?utf-8?B?aTUvNzFQMXpOcGs1L2lScStDVSszaVIycTY3Y2k3M2NJRUVUQzdTaldjamQ3?= =?utf-8?B?TllHaVY2TFVOREd1Qit2TnhSb24wZnRiN2J1TzdpUlhsMW5LOE9pQS91d2Yr?= =?utf-8?B?cFA3c040T0tHUmRDeStQOUZaWE51emFXakhFS09MSGRTL3RPZ2JUb2labWdo?= =?utf-8?B?NlYvaGswM3NFb2c0UnNyRGNWaEZrdEpJdnFheHhwZ21oK00rOEcvdm5NOFBF?= =?utf-8?B?c0JQNy9vZnBWc3cwMzJlM2VrTVhlTDNXNjN2RlFPdXBZRWpVaHhLemEvK3Bm?= =?utf-8?B?b3RmRXdnYjNWWXdWQzNTWi9XcnhrVWR0M0d1T3NheE9DWXhFNVJ1RGdXaUM1?= =?utf-8?B?aWxaeUFxWnRCWENKNTlsVjNPUnVYZU5waVVQQlhHUzFTOERPWFgwak9nTC8w?= =?utf-8?B?ZWIvbjRuR1RCVzZzQkFPSGRUdTRXbytCVnBqejIzd3hyMHdub1A4dU93UnZj?= =?utf-8?B?QWZSZUt3Y0lhQlNuK3NsMW1oRjlYSGZhVnBsNVBOVm5QR1ZybU42Zkx0R1Fu?= =?utf-8?B?MS9Fbmp4UlNsSmVDcjVhZWFPMjRWWEJhT20yOGw4TWtlVmd5OG5ITFRoeGp1?= =?utf-8?B?dlBoRlZia3dXODRtclkycE9wTnlqMWxSbXYrVW5oTjd4NXcwYnJSNVVUQVYw?= =?utf-8?B?V1A2ZzBVWXdmbFliSzcwWGtkTTdRN08wV0FtYndGUFczaFMyZHFXbWo1YnB4?= =?utf-8?B?bVRlWStXWGtXLzVtWHRRUUhwcWRDb0FpTG94Vk95NG5XQ1Z6VWdIN1p1M0FJ?= =?utf-8?B?YlBocDhMcHMwTkpYUUFYcGFwNVpvVjd1cUR4YnpFemVSTXBteEFHM05pbmlp?= =?utf-8?B?WmdpOE43Z1RNNUcrTTY5Y0lwK0FFYWJJeEpkUFFXaDBjQmQyM2FqcnQ1RzV5?= =?utf-8?B?cnJIVEkyOFBRWTlnZ0FYbjdVM04vd1Q2RXI5Z2dQbU93MDFuaFlPcVBvVGtP?= =?utf-8?B?Z01oUFpUODBFZ1E0cHY5ZE5YZG9VYjRkNW9HM2d6MFpKNFBnbGZJUEsvQito?= =?utf-8?B?NEFZU0U2N3hFaGxIQUNBVkhrQUJiOVE4YnhFM2wvOG1WSGhGOVJMdXZOV3F3?= =?utf-8?B?NWZqcmNTZ3hzZzJXMldYYTVZV28ybTdpOE9IS2YwTlkxclFJSFhCQWVpSmxT?= =?utf-8?B?M3MxdnhtVE5vKzNheEQyY0piZEh3MXQ1Y2VMZXVoNDAvd3NaRjQrS0hjRXN5?= =?utf-8?B?cUo4Z3RpcTV6eHlyUXhaMUpvd1BPQ1FxcDN4VmdRbE1qTkNicGE0TDZ4RmN2?= =?utf-8?B?ZTJTMjRPNzNWeVRERzhKaVhPMTdhREtkWTI1YlVUYVpFOXJKa05uVnZUV0NP?= =?utf-8?B?enF4aCsxV2pka09RYmlmYmE1T0tLRC9kU2svVDRkTnhDR2w2djdoRTdoOEZP?= =?utf-8?B?UHE3ZnI2aGlFT3hqa1RrZ3VvSWNheXdmOHB0U0FCTFNFRCtyNXNNalNGeUNz?= =?utf-8?B?eStHQkdBRkhxWFE1aXRDR1R5bTBDRTFWZ3Q2MktVS3pNVVRIN3dod2U1SGRt?= =?utf-8?B?anpKck9ZSzFZUEZVL284cHFKMUZBcGpualhBdjA0RGxCSDV5ZmlOSUkxY1hS?= =?utf-8?B?MTI3ZU0zWVA0SW9CbmZPYjZCN2JwdnhaaWVjWmFINkhIU0RNY1k1K3NGMVRG?= =?utf-8?B?ZVpDeS9abXg0czdkTDRuYkF0eDN5bnpXbFkyRThTZWxxTGE5MUo2QUk1SjVy?= =?utf-8?B?YktwY2g4NDZNVnB5ZEdIZGhsV1hzdmh0L3cxdjBTV1pDMTlEd25rdmVTS0Fw?= =?utf-8?B?MHRLTHZiRmI5U0ZjemhkREZLdll5Q21TSittSk1OdGpYNnM1Y2FlaGRrZk1k?= =?utf-8?B?cVRyRXlXSWFUR1NLRm5YZlZOcVhUSEptbEFyQmZBQ1BpWStBZkxkSjArQmQv?= =?utf-8?B?Mzl5K0FRVSsyWkZIeU9mNmo1QmVMK0RzbytMaHRYWEZOOUpMOEx3YXNnaDBB?= =?utf-8?B?R0xybXBZcDRIZFZDTTgyWTZXOGlUVG5NY3gzTWxNSi8xWXlhY09mY1AwR2hl?= =?utf-8?B?NCt5NlJ6WitUOTE1b0hnSVN5SGc0a0UyZEdrek85OXFTM0kxRVE1ZGV2QkMy?= =?utf-8?B?S2JpdERqeERvcm5yR0dFeTlrME9BSHpURlYwcHFSSTB4cU5UbzFDMFF5ZVVr?= =?utf-8?B?M1crRk44SnVpMzZDcmt1UitvZUp4eGxJQUVYMDJwcmVkYkpnSUgvYzlyZ3oy?= =?utf-8?B?dnRwMzNPcnlSSi9mMFlSSWR3ajZMVVdXWWJYOEc2cDl2WVR3VE9VZ0VEamNJ?= =?utf-8?Q?jjZm1o9lVuQaD?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7NjpDZWt5YVNrUnNVQlYwN21UVkFXUU91OHZU?= =?utf-8?B?TzI1czcvM0dxMVhEYzlZWk9Pdnc0TGM0R1F3Vm0rdVZhVHZDU1JuWExLeTFk?= =?utf-8?B?c1hsVTc3MElNakpnY0lra3Z1SUFzeGsvTUM5RjNjRnozOVpmQ052M1NXRVFO?= =?utf-8?B?QWNLUWtjRTk3Uk9vVTNxR3oxdmJKbm5pcGRFQkhlTFY5RjhJNVl2N3RGeldQ?= =?utf-8?B?QVRyd3VVM0ZMZG9QU3lRRFgzUVcwd2k1RmUrZU9xL2pETGJuRWxKV252VWJM?= =?utf-8?B?SEwzenJJV1BIQkdrRk1qMlRIQkI5TzNPbUlJRjRyd3VuU2JRVkhXTVZQZnFN?= =?utf-8?B?ZFJCVHBrUFdFQ1hQVDdyaVZzNmtuME04WWQwb1ZMVFhYYmZ0U1lrZENGTHNw?= =?utf-8?B?dm1BS1ZCb2pUaFFma1lWTHdSUjE1Y3lXeGFMcTBtNkxjbzJPM1g0cm16U0ZT?= =?utf-8?B?OWhYQ2daWWFhaENpRy9rbWlwTTlRb0tzSnh6dXN5emdBaWNzNDlabUdnQmhw?= =?utf-8?B?VmVacVNjWXYzMm93bE9yYlJkZm1Cd0lpV3YvN2hzTE9kQVFyVm5Ja1FrMGxW?= =?utf-8?B?QUVSTVBvMG13N1dVS29oWGtleXJadkU0RXAwMHpLMlBHQ2cxY1Y2VVRsd0R6?= =?utf-8?B?ZnJPMS9hZ1dGeW1TODh6U05wMlRDR3RNNGZBanNZcGlHckpvUnRVQkk1Z1hR?= =?utf-8?B?bkhlblFNUGhSTGcwZTduSW1LaDNjdzV5YU9MWU1jMzl2QUtKNjBDNGZaaVJH?= =?utf-8?B?VlhzZGIrRGVJaTBDcmZUa25DOUx0QXpRTVh1ejBkVTA3N3FiZUwzWnA4UHpz?= =?utf-8?B?b0p4dU5Ob2JzV3hBT29YaUpuQjU4bHFSTTZKemROT040M0dYQ0gzV0lsekhx?= =?utf-8?B?MFBYcE41RGRzL090V0Fnc0ZnRUlJZTFtSmNWNHlKWTAwT3o3S1B4OXZWcXVs?= =?utf-8?B?aEZHWW96S2MvTHdocitYampQTlVIZ2hMTWE0VkFwYjFwN2MwSDdUcFZIcStv?= =?utf-8?B?d1NNdGtoV1RjUHkvMHRPRjl5STY4Y01sRkNJWUduc1Rva2RmaFVhbDRKVGU0?= =?utf-8?B?VnMvZFBSUFpLYmNHWmFDUUNKVXVKVGtZenQyVVI5WjNzamxCRGwrMnIvd1Zm?= =?utf-8?B?SWJIK3dlMitSd08rakdXT2ZadG1rYzBGUTZqRUpHcWluMnZKTWdTcEduRmV2?= =?utf-8?B?Yy8zanhPaTFPL3ZPa0U2Mm9SbWlKOGJDejNIVTNHeEJRZk9USHY0cE9DeHNQ?= =?utf-8?B?L2luVGd4di9DWk5KaHVGQmd1SVZyOFZEQ1NkWFNnTEpvcVFvVTVTYlJ4b05j?= =?utf-8?Q?1Rct12dF39CEXqUAt8aScTtPixvdjiIIE=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 5:on2qNDKDLUeh8TJ4I0vJPcSUlUjpBw7HaBrCH7p9DVTe2OciEOP+Q+D3n9tlB6KpjczFbXJvnBpPM5uivQNvrEZ66gKDqsKLojX6ppDJtodlH8HeBwqduC7fXxniWpxZt0qJVpY9HoC/OQgqW0GC7mwpyBKoz7kP4lcLy7NKYBcIoi76nnO4CYd0HTfGW7etLimBzNT7twJxjmJENILoKYsLzBLtoslZ/KlUlkTx+akpp95vp7Ezh76c824SQi97jMfh/4r+NEmcQZb6DZGuvAzWs2f81K6W23YxHaSijn+wc+xA42IiDfFKGb3zTbi+TAxL9lvgcetqhbMI1bpLoBUz5E/1GscY2B7+rE3W6iARLwfqjv8uTOi9SX54rLmShEnZ2PnoI3MifKh89cQmZ3KGthw6pRymfJMPVHC9EvlWiXqwq5t4TsE6sx7ibCWKFYViG2Xmb4Ie9blJ0UdbZ08tXixZ7IxPerXvCKn10WEobOheTav7n0ShqnTxeaEY; 24:A96ikkcLI7kKXfQN4Kk+SrAdQk5IH9D+umJdd1Sw5uOYXJIUd4s9/1iCtf6eYgccaLkU6ulzn4bSE8XLDD2tBSyKZSIphaBKWwo0ToccSy0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:DL/qp66gblMnRRGbeR/12Vb4NPlxynfCjBBVjdP4n6aL8g+s9NuOQhGqHEIPxr4IJ0ldRGnypr9qOLfpp0PBbj9PRhVtArqUa9bCtMgLcE9Xv06I0w+yPQR7p7nHnEUyClJLJtbUFwxAL0bh9QrMXFhsygBK7gAxQbyUpSM93oPBydfAqMiVl3fVhuQXZiHcF57KVt92TEvbeNMVCP2MsDXXy7iySf+8KtmPhS5RFn/PaonobjFZnz2yKLLjwcIRkC/jVQPSFkM2R/9Wb2s5Zhjq8Dxe2THZ4f9s66VimcFFzOiYiEQTQjkBuubTI1dXUCLgVWt4gaHiGByzDsyn9l/1R6dVwVrP/5ikcilBaQuQz9nORO0lhN3LpguZK30pTIi+bO1d0drbiJ5e0KVLFZpce69PQjfx0ylZqCizH9Q8ao2QVc/iA6nA3bfQjO+P+yc8IBRq7eoTLlO2uOlQosAqbEl6E9TfbxND6CHpa5C5VRWu/tSkVXkbkwqvOBRX/yLmIkkauRjWG9hAFELaHPEqpt25TV3SLvYs8u25AyxemRQykOB5tKWrlIEpifLnHqqe6QmfMh3IAoDB+pPOP/ziTf0HTwsg6YIDTHueNhQReTmNgMm07gh/doaaxPFkGWJP04CjjBEL9cMhOIRGZILwQrX8fufToCeAwd83LHbEMC0gwR1F5D4gV33yNWI58lOmZyGz+wbg3x0sRt4+CqaSEXdOvmh6Ar25zwVrocaPFdJR3DUtMFqX++6HZBp8x+ECvKI905QHzTTk7yvzBFOpXtbf/gIMFEkgWekB4LI= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2017 08:51:40.8346 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 08:51:48 -0000 ----- Original Message ----- From: "David Farmer" To: "james woodyatt" Cc: "IPv6 List" Sent: Saturday, July 22, 2017 9:54 PM On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt wrote: > On Jul 19, 2017, at 09:57, Brian E Carpenter > wrote: > > On 19/07/2017 18:22, james woodyatt wrote: > > On Jul 19, 2017, at 01:15, Brian E Carpenter > wrote: > > > Hmm. Let's consider a case in which the last-hop route to a given LAN has > a prefix of > length, say, /80. What is the name of the bit-string from bits 81 through > 127 of the > host address? If they aren't called the "IID" what are they called? > > > If have yet to find where RFC 4291 clearly names the part of an IPv6 > address that follows a *routing* prefix apart from a *subnet* prefix. > Moreover, the phrase “last-hop route to a given LAN†is not equivalent to > the concept of a subnet, and such a routing prefix is not equivalent to a > subnet prefix. As RFC 5942 clarifies. > > > Agreed, but I phrased my question in full knowledge of that. What do we > call those trailing > bits of the address? (I was reading the source of the Python 'ipaddress' > module yesterday, > and saw a comment about 'host bits', but that seems very 20th century, > given that the > IPv6 architecture refers to interfaces.) > > > I’ve been mentally using “address suffix†for this concept, and I find > that I rarely have much need for it. I suppose if I were using on-link > prefixes longer than /64, then I’d need it so I could differentiate between > the 64-bit Interface ID and the shorter part of the address that follows > the on-link prefix. > I think I'd prefer to call the righthand side of both a subnet prefix and a on-link prefix an interface identifier, because in both case it is a node's interface that is being identified. Then generically they are interface identifiers, if you are referring to a specific aspect it is qualified with the aspect. generically; prefix / interface identifier with specific aspects being referred to as; subnet prefix / subnet interface identifier on-link prefix / on-link interface identifier Then it would be subnet interface identifiers that are 64 bits, except ... and on-link interface identifiers are any length. That is basically the assertion that started this part of the discussion, and that did fly with at least some. So, I've been kicking around other ideas, because if the righthand side of an on-link prefix isn't an interface identifier, it needs another name. How about; node identifier on-link identifier host identifier on-link node on-link host I think I like on-link node best, but on-link identifier is a close second for me. so; subnet prefix / interface identifier on-link prefix / on-link node or; subnet prefix / interface identifier on-link prefix / on-link identifier What do others think? How would that cope with address assignment prefixes being longer than on-link prefixes? My on-link prefix is /60 but for address assignment I use a /64 and have one /64 for network management devices, another for print servers, another for routers, one or more for hosts and so on. Tom Petch =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== ------------------------------------------------------------------------ -------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jul 24 02:36:17 2017 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 2A69B1317CC for ; Mon, 24 Jul 2017 02:36:16 -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] 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 63DjZ1Jk8lrk for ; Mon, 24 Jul 2017 02:36:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E781B12EC06 for ; Mon, 24 Jul 2017 02:36:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dZZmc-0000CkC; Mon, 24 Jul 2017 11:36:10 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Sun, 23 Jul 2017 08:47:23 +1200 ." Date: Mon, 24 Jul 2017 11:36:09 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 09:36:16 -0000 >> So let me call them 'host part' > >Hate to be picky but in RFC8200 'host' does not include 'router' and these >bits certainly exist in router addresses. > >So it would have to be 'node part'. But in most cases (the only exception >being anycast) these bits may be (not must be) different in the node per >interface, so 'node' is still wrong. I just don't get why it isn't >'interface part' (with an exception for anycast). And if it's 'interface >part' I really don't see why it isn't 'interface identifier'. I'm not attached to any particular term. However, I think it is important that the reader of rfc4291bis gets a clear under standing of the difference between an IID as used for SLAAC. Which has a lot of properties, including that it is generated locally on the node and is used for address configuration. And on the other hand, what I called 'host part' which in general doesn't have any properties. Calling it an 'interface identifier' is confusing if the address is an anycast address. In the context of ND, an address is either covered by an onlink prefix which means that a sending node should try to resolve the address to a link layer address or if not, the packet should be passed to a (default) router. In the context of ND, the 'host part' is completely transparent to the sending host, except that a NA indirectly signals whether the address is anycast or not. >Here's a thought. How would it be if the contentious sentence in 4291bis >read, in its entirety: > >"Interface Identifiers are 64 bits long when used for Stateless >Address Autoconfiguration (SLAAC) [RFC4862]." In my opinion rfc4291bis should not be a random collection of true statements that have to be assembled by the reader. From nobody Mon Jul 24 02:51:33 2017 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 870831317CC for ; Mon, 24 Jul 2017 02:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 FhixusMS7pJB for ; Mon, 24 Jul 2017 02:51:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E8AD012EC4B for ; Mon, 24 Jul 2017 02:51:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dZa1L-0000I3C; Mon, 24 Jul 2017 11:51:23 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Sat, 22 Jul 2017 23:34:33 +0000 ." Date: Mon, 24 Jul 2017 11:51:19 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 09:51:30 -0000 >> Basically a 'host part' doesn't have any properties. > But that's not a distinction. I can just as easily give a structure to an I= >ID as I can to any non-64-bit IID, if I so choose. Or, use a pseudo random = >value if I'm worried about privacy or security. I cannot parse this. > >> You can say it identifies an interface, but that is not the case if >> a 'host part' is part of an anycast address. > >Not sure why you make this distinction. Even in the anycast address, these = >last bits identify an interface, even if one of several possible. It's the = >topologically closest interface, and others would be identified by the same= > bit pattern. It's still an ID of an interface, as opposed to being a prefi= >x. Maybe I spend to much time with math, but for me an anycast address identifies a set of interfaces and packet destined to such an address ends up on any of them. To me that is completely different from the case where an address identifies at most one interface and you know that if it gets delivered to the destination it will always be the same interface. >> So let me call them 'host part' > >So we would be renaming IID in every RFC. Quite a change. And it's not "hos= >t" anyway, right? Those bits identify an interface, not a host. So call it = >"interface part," or "interface ID." Possibly. Thought it seems that RFC 4861 and 4862 use IID only in the context of SLAAC so that would not change. And as a I said before, I consider a set of interfaces something quite distinct from a single interface. >I just don't see why IIDs used in SLAAC should be thought of differently. I= > mean, the anycast example was always a little weird, but those are a tiny = >minority anyway. Because way too many seem hopelessly confused. They read about 64 bit IIDs and do not realize that this only applies to SLAAC. People write code that if you configure an address manually, the system automatically considers the /64 prefix onlink. People managed to write code that drops an onlink prefix because it doesn't match the length of a SLAAC IID. From nobody Mon Jul 24 07:18:22 2017 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 60B7B131D28 for ; Mon, 24 Jul 2017 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMFNBIiv8si1 for ; Mon, 24 Jul 2017 07:18:19 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 2F795131D1E for ; Mon, 24 Jul 2017 07:18:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 7DFC19E6 for ; Mon, 24 Jul 2017 14:18:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O--DEU4f_R-A for ; Mon, 24 Jul 2017 09:18:18 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 349E7A09 for ; Mon, 24 Jul 2017 09:18:18 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id 80so84284223uas.8 for ; Mon, 24 Jul 2017 07:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8qXBCyTv1LfpRBwEn3/XET+EladFNJ415G3xu5g1M5k=; b=P3S9yRnhp+xFQmzV/a3VvFMgySANrEU4G0RYI5uJKXeeNL66OVL/2ROB9m8H9HySO0 O8FuaTmPof1l9xZAxX6IKU8t+pOIMgZONxJ4ahV3j2oYTWaFFbGRSmVLdtvbx80+FJwy 0hpnvA+Uv6hWABYY+Qe2f79sih2gpgTvn2WRXTL9m6bHroLxWqxoqs+dnoPIsmhyfHiJ sewwFXpmKTIB6I+7URVSVU+9KHtCViBIxX2U/NS/J4YF/Nj0GmO3/2m+BmyOryQdC4gf e+3ZsdcGXrXnBchc2fpTm4oenyvHrNKQoW6SRtgyPHiUWPkQARozcliuiPyCXN/TyIjz 0zYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8qXBCyTv1LfpRBwEn3/XET+EladFNJ415G3xu5g1M5k=; b=OIw+E28gYv7e+ZhviVKW3eJUiq55Ekkl/TzedhjQcDQTuOE+/uCt0gB/YRQbS3tSVS 2tYlSlScpGdla3/k8g/BvFxZlE3RV0OZ3/Oluqrhcv2St8ObfYnmu+q9TUhGRauuM5aX S38Rce9glU5yMP+tG+OF9hFUSXKj1Hza1MTLvExidt80fCMV5djEyoryYFU5p8Yd3C6d cmJvS5zOkRdjG7H+GB1YTwoZkipV80tqw15WKHgWYMFuFspKXMESx4vrJLSK2dzht450 f5c/nxVVKSN0BcDT5q6jDOPqWvkgcjZ6TGEhILQQfDYoiOo26Vxuh1yrO9thMiLtsI5d c7Tg== X-Gm-Message-State: AIVw113W9hrtdA5S4da7jdIRaj3A9kzEyk6qf9e608eUbG2apkiEew4F yqO6FYBllc3xoxaVhr6me+1O3oiETXyRX0R/J9zu6ZamjIhvLlTJJY2+3Izt8P75eWkHl6TWQ3O QGn4DLduUlX3pBqs= X-Received: by 10.176.0.33 with SMTP id 30mr10877905uai.29.1500905896931; Mon, 24 Jul 2017 07:18:16 -0700 (PDT) X-Received: by 10.176.0.33 with SMTP id 30mr10877896uai.29.1500905896739; Mon, 24 Jul 2017 07:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 24 Jul 2017 07:18:15 -0700 (PDT) In-Reply-To: <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> From: David Farmer Date: Mon, 24 Jul 2017 09:18:15 -0500 Message-ID: Subject: Re: To: "t.petch" Cc: IPv6 List Content-Type: multipart/alternative; boundary="001a114506b4d1402e055510e200" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:18:21 -0000 --001a114506b4d1402e055510e200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 24, 2017 at 3:47 AM, t.petch wrote: > ----- Original Message ----- > From: "David Farmer" > To: "james woodyatt" > Cc: "IPv6 List" > Sent: Saturday, July 22, 2017 9:54 PM > > On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt wrote: > > > On Jul 19, 2017, at 09:57, Brian E Carpenter > > > wrote: > > > > On 19/07/2017 18:22, james woodyatt wrote: > > > > On Jul 19, 2017, at 01:15, Brian E Carpenter > > > wrote: > > > > > > Hmm. Let's consider a case in which the last-hop route to a given LAN > has > > a prefix of > > length, say, /80. What is the name of the bit-string from bits 81 > through > > 127 of the > > host address? If they aren't called the "IID" what are they called? > > > > > > If have yet to find where RFC 4291 clearly names the part of an IPv6 > > address that follows a *routing* prefix apart from a *subnet* prefix. > > Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D is= not equivalent > to > > the concept of a subnet, and such a routing prefix is not equivalent > to a > > subnet prefix. As RFC 5942 clarifies. > > > > > > Agreed, but I phrased my question in full knowledge of that. What do > we > > call those trailing > > bits of the address? (I was reading the source of the Python > 'ipaddress' > > module yesterday, > > and saw a comment about 'host bits', but that seems very 20th century, > > given that the > > IPv6 architecture refers to interfaces.) > > > > > > I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for t= his concept, and I find > > that I rarely have much need for it. I suppose if I were using on-link > > prefixes longer than /64, then I=E2=80=99d need it so I could different= iate > between > > the 64-bit Interface ID and the shorter part of the address that > follows > > the on-link prefix. > > > > I think I'd prefer to call the righthand side of both a subnet prefix > and a > on-link prefix an interface identifier, because in both case it is a > node's > interface that is being identified. Then generically they are interface > identifiers, if you are referring to a specific aspect it is qualified > with > the aspect. > > generically; > > prefix / interface identifier > > with specific aspects being referred to as; > > subnet prefix / subnet interface identifier > on-link prefix / on-link interface identifier > > Then it would be subnet interface identifiers that are 64 bits, except > ... > and on-link interface identifiers are any length. > > That is basically the assertion that started this part of the > discussion, > and that did fly with at least some. > > So, I've been kicking around other ideas, because if the righthand side > of > an on-link prefix isn't an interface identifier, it needs another name. > How > about; > > node identifier > on-link identifier > host identifier > on-link node > on-link host > > I think I like on-link node best, but on-link identifier is a close > second > for me. > > so; > > subnet prefix / interface identifier > on-link prefix / on-link node > > or; > > subnet prefix / interface identifier > on-link prefix / on-link identifier > > What do others think? > > > > How would that cope with address assignment prefixes being longer than > on-link prefixes? > You say an address assignment prefix longer than the on-link prefix, but then you describe below a on-link prefix longer than the address assignment prefixes below, which do you really mean? My on-link prefix is /60 but for address assignment I use a /64 and have > one /64 for network management devices, another for print servers, > another for routers, one or more for hosts and so on. > > Tom Petch > To achieve the desired result you state above, a /60 on-link prefix and /64 address assignment prefixes, I don't see how you would be able to use SLAAC, but you could achieve what you state above with DHCPv6, or manual config. Having the on-link prefix as a /60 just says that all 16 /64s are associated with that link. But SLAAC devices will have no knowledge of which of the 16 /64 they are suppose to generate an addresses from. You could have a PIO with a /60 prefix with the L flag set, and 1 to 16 /64 PIOs with the A flag set. Most devices will generate addresses on all the /64s that have an A flag set. Printers will have no way to know they should only use the first /64 verses the last /64 or any in between. Same for management devices. Now you could manually assign devices to different /64s or use DHCPv6. You could use DHCP for the hosts, but if set a PIO with a A flag for the hosts on one /64 you would need to configure the non-hosts to not use SLAAC, which is not a trivial thing to do as far as I've seen on most devices. What we name the righthand side of a on-link prefix isn't going to change how it works, as Shakespeare says "a rose by any other name would smell as sweet", we just need to agree its called a rose. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114506b4d1402e055510e200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 24, 2017 at 3:47 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
-----= Original Message -----
From: "David Farmer" <farmer= @umn.edu>
To: "james woodyatt" <jhw@go= ogle.com>
Cc: "IPv6 List" <ipv6@ietf.or= g>
Sent: Saturday, July 22, 2017 9:54 PM

On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <jhw@google.com> wrote:

> On Jul 19, 2017, at 09:57, Brian E Carpenter
<brian.e.carpenter@gmail.= com>
> wrote:
>
> On 19/07/2017 18:22, james woodyatt wrote:
>
> On Jul 19, 2017, at 01:15, Brian E Carpenter
<brian.e.carpenter@gmail.= com>
> wrote:
>
>
> Hmm. Let's consider a case in which the last-hop route to a given = LAN
has
> a prefix of
> length, say, /80. What is the name of the bit-string from bits 81
through
> 127 of the
> host address? If they aren't called the "IID" what are t= hey called?
>
>
> If have yet to find where RFC 4291 clearly names the part of an IPv6 > address that follows a *routing* prefix apart from a *subnet* prefix.<= br> > Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D i= s not equivalent
to
> the concept of a subnet, and such a routing prefix is not equivalent to a
> subnet prefix. As RFC 5942 clarifies.
>
>
> Agreed, but I phrased my question in full knowledge of that. What do we
> call those trailing
> bits of the address? (I was reading the source of the Python
'ipaddress'
> module yesterday,
> and saw a comment about 'host bits', but that seems very 20th = century,
> given that the
> IPv6 architecture refers to interfaces.)
>
>
> I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for = this concept, and I find
> that I rarely have much need for it. I suppose if I were using on-link=
> prefixes longer than /64, then I=E2=80=99d need it so I could differen= tiate
between
> the 64-bit Interface ID and the shorter part of the address that
follows
> the on-link prefix.
>

I think I'd prefer to call the righthand side of both a subnet prefix and a
on-link prefix an interface identifier, because in both case it is a
node's
interface that is being identified.=C2=A0 Then generically they are interfa= ce
identifiers, if you are referring to a specific aspect it is qualified
with
the aspect.

generically;

prefix / interface identifier

with specific aspects being referred to as;

subnet prefix / subnet interface identifier
on-link prefix / on-link interface identifier

Then it would be subnet interface identifiers that are 64 bits, except
...
and on-link interface identifiers are any length.

That is basically the assertion that started this part of the
discussion,
and that did fly with at least some.

So, I've been kicking around other ideas, because if the righthand side=
of
an on-link prefix isn't an interface identifier, it needs another name.=
How
about;

node identifier
on-link identifier
host identifier
on-link node
on-link host

I think I like on-link node best, but on-link identifier is a close
second
for me.

so;

subnet prefix / interface identifier
on-link prefix / on-link node

or;

subnet prefix / interface identifier
on-link prefix / on-link identifier

What do others think?

<tp>

How would that cope with address assignment prefixes being longer than
on-link prefixes?

You say an addre= ss assignment prefix longer than the on-link prefix, but then you describe = below a on-link prefix longer than the address assignment prefixes below, w= hich do you really mean?

My on-link prefix is /60 but for address assignment I use a /64 and have one /64 for network management devices, another for print servers,
another for routers, one or more for hosts and so on.

Tom Petch

To achieve the desired result= you state above, a /60 on-link prefix and /64 address assignment prefixes,= =C2=A0I don't see how you would be able to use SLAAC, but you could ac= hieve what you state above with DHCPv6, or manual config.

Having the on-link prefix as a /60 just says that all 16 /64s are a= ssociated with that link. But SLAAC devices will have no knowledge of which= of the 16 /64 they are suppose to generate an addresses from.
You could have a PIO with a /60 prefix with the L flag set, an= d 1 to 16 /64 PIOs with the A flag set. Most devices will generate addresse= s on all the /64s that have an A flag set.=C2=A0 Printers will have no way = to know they should only use the first /64 verses the last /64 or any in be= tween. Same for management devices.=C2=A0 Now you could manually assign dev= ices to different /64s or use DHCPv6.=C2=A0 You could use DHCP for the host= s, but if set a PIO with a A flag for the hosts on one /64 you would need t= o configure the non-hosts to not use SLAAC, which is not a trivial thing to= do as far as I've seen on most devices.

What = we name the righthand side of a on-link prefix isn't going to change ho= w it works, as Shakespeare says "a rose by any other name would smell = as sweet", we just need to agree its called a rose.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDavid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information = Technology
University of Minnesota=C2=A0=C2=A0
2218 University Ave S= E=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3= 029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114506b4d1402e055510e200-- From nobody Mon Jul 24 10:22:39 2017 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 EF4DB129B14 for ; Mon, 24 Jul 2017 10:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_O6RCADEeeA for ; Mon, 24 Jul 2017 10:22:34 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EBD12426E for ; Mon, 24 Jul 2017 10:22:34 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 3F44FBC6 for ; Mon, 24 Jul 2017 17:22:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSKxIY7nCz1K for ; Mon, 24 Jul 2017 12:22:34 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id DFB34945 for ; Mon, 24 Jul 2017 12:22:33 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id x24so89168135uah.7 for ; Mon, 24 Jul 2017 10:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I1Gnjx+i3EUI6s+UVeGyg4/jbwhc2Em02IXn7egkctY=; b=cq0Rb/Tu2xaWuOIaGDNyuuyjVpNCR86Upm37B76nyiczK9J6L16iOoLpzIu4WA26MI GGn/+vfUAVFY9JD5yHAoNvzB8+pEIUg8Z6V0srYm4JZ0IKSbff/XioqmaD4Ia9EQcucS lda/r92YnuGRpuEXE/hSu8AxGuoQeH+Hm9FowItqTm2Iy9yxk50OctcuE/Rc65K4ZW8H LaqKi15+tgG1g2Lkqdg+16cOUN0U+GnJ8BqWaXZE1+DTyWsAYSKaVLxpC0YlagNWgm9V d1aLcEgGVvzbt7N+GfSaDo2XpxWwvaxAshPHBW35NMqHt5SjKbuagwXy0vKEtuLmNpVI 8BFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I1Gnjx+i3EUI6s+UVeGyg4/jbwhc2Em02IXn7egkctY=; b=CVcLNd4Qx7t3676xx/TJDPZ6kPRNmBy6rywqSz+Mi5VhVRVtPtLayblUJU9oS1Qu2J xqOIEltKdMMLZdX0MyS/LlevcVv6w4CW0UEfy5r5bGtu1rV70IP/Q7XkNxApjzaif2Sd uq9NtCDLO1u29L0xcsRPLTtYk0b2ZbXixGdXSk2smIiJUdHWSuFYJkIYTcN87gItYza4 S5c57+FntmSDgdgIRh9rYrxgJku7ZqlT0xefoccHq+hBIwTx7hWiDYG6Kr37OzPWJoBy GL1V4XmhTXSR0+ndbDBChi+qJACx6Aqaj5hetsNUvJs7Ya97jk/mAn3x/wD6qnHWSe2/ Zqrg== X-Gm-Message-State: AIVw11120teht8IA60uVpm9KpgzyGtCcceORWPzqWLV1arJZWmCxaqCx yIWS7PZvtLAldOoUCKSsLZJqSJ7H7pqE22f+x2EE/V4MGZ1tcUk8oe2teUsm8QWt3pR1qWtex0q 3P9Sm52O74h56g7A= X-Received: by 10.159.33.211 with SMTP id 77mr8822390uac.218.1500916952933; Mon, 24 Jul 2017 10:22:32 -0700 (PDT) X-Received: by 10.159.33.211 with SMTP id 77mr8822365uac.218.1500916952664; Mon, 24 Jul 2017 10:22:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 24 Jul 2017 10:22:31 -0700 (PDT) In-Reply-To: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> From: David Farmer Date: Mon, 24 Jul 2017 12:22:31 -0500 Message-ID: Subject: Re: To: "t.petch" Cc: IPv6 List Content-Type: multipart/alternative; boundary="001a11355260cdec0b05551375b4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 17:22:37 -0000 --001a11355260cdec0b05551375b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 24, 2017 at 9:18 AM, David Farmer wrote: > > > On Mon, Jul 24, 2017 at 3:47 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "David Farmer" >> To: "james woodyatt" >> Cc: "IPv6 List" >> Sent: Saturday, July 22, 2017 9:54 PM >> >> On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt wrote: >> >> > On Jul 19, 2017, at 09:57, Brian E Carpenter >> >> > wrote: >> > >> > On 19/07/2017 18:22, james woodyatt wrote: >> > >> > On Jul 19, 2017, at 01:15, Brian E Carpenter >> >> > wrote: >> > >> > >> > Hmm. Let's consider a case in which the last-hop route to a given LAN >> has >> > a prefix of >> > length, say, /80. What is the name of the bit-string from bits 81 >> through >> > 127 of the >> > host address? If they aren't called the "IID" what are they called? >> > >> > >> > If have yet to find where RFC 4291 clearly names the part of an IPv6 >> > address that follows a *routing* prefix apart from a *subnet* prefix. >> > Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D i= s not equivalent >> to >> > the concept of a subnet, and such a routing prefix is not equivalent >> to a >> > subnet prefix. As RFC 5942 clarifies. >> > >> > >> > Agreed, but I phrased my question in full knowledge of that. What do >> we >> > call those trailing >> > bits of the address? (I was reading the source of the Python >> 'ipaddress' >> > module yesterday, >> > and saw a comment about 'host bits', but that seems very 20th century, >> > given that the >> > IPv6 architecture refers to interfaces.) >> > >> > >> > I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for = this concept, and I find >> > that I rarely have much need for it. I suppose if I were using on-link >> > prefixes longer than /64, then I=E2=80=99d need it so I could differen= tiate >> between >> > the 64-bit Interface ID and the shorter part of the address that >> follows >> > the on-link prefix. >> > >> >> I think I'd prefer to call the righthand side of both a subnet prefix >> and a >> on-link prefix an interface identifier, because in both case it is a >> node's >> interface that is being identified. Then generically they are interface >> identifiers, if you are referring to a specific aspect it is qualified >> with >> the aspect. >> >> generically; >> >> prefix / interface identifier >> >> with specific aspects being referred to as; >> >> subnet prefix / subnet interface identifier >> on-link prefix / on-link interface identifier >> >> Then it would be subnet interface identifiers that are 64 bits, except >> ... >> and on-link interface identifiers are any length. >> >> That is basically the assertion that started this part of the >> discussion, >> and that did fly with at least some. >> >> So, I've been kicking around other ideas, because if the righthand side >> of >> an on-link prefix isn't an interface identifier, it needs another name. >> How >> about; >> >> node identifier >> on-link identifier >> host identifier >> on-link node >> on-link host >> >> I think I like on-link node best, but on-link identifier is a close >> second >> for me. >> >> so; >> >> subnet prefix / interface identifier >> on-link prefix / on-link node >> >> or; >> >> subnet prefix / interface identifier >> on-link prefix / on-link identifier >> >> What do others think? >> >> >> >> How would that cope with address assignment prefixes being longer than >> on-link prefixes? >> > > You say an address assignment prefix longer than the on-link prefix, but > then you describe below a on-link prefix longer than the address assignme= nt > prefixes below, which do you really mean? > Sorry, I should have had caffeine before doing email. :( /64 address assignment prefixes are longer than /60 on-link prefixes. I think everything below is correct though. :) > My on-link prefix is /60 but for address assignment I use a /64 and have >> one /64 for network management devices, another for print servers, >> another for routers, one or more for hosts and so on. >> >> Tom Petch >> > > To achieve the desired result you state above, a /60 on-link prefix and > /64 address assignment prefixes, I don't see how you would be able to us= e > SLAAC, but you could achieve what you state above with DHCPv6, or manual > config. > > Having the on-link prefix as a /60 just says that all 16 /64s are > associated with that link. But SLAAC devices will have no knowledge of > which of the 16 /64 they are suppose to generate an addresses from. > > You could have a PIO with a /60 prefix with the L flag set, and 1 to 16 > /64 PIOs with the A flag set. Most devices will generate addresses on all > the /64s that have an A flag set. Printers will have no way to know they > should only use the first /64 verses the last /64 or any in between. Same > for management devices. Now you could manually assign devices to differe= nt > /64s or use DHCPv6. You could use DHCP for the hosts, but if set a PIO > with a A flag for the hosts on one /64 you would need to configure the > non-hosts to not use SLAAC, which is not a trivial thing to do as far as > I've seen on most devices. > > What we name the righthand side of a on-link prefix isn't going to change > how it works, as Shakespeare says "a rose by any other name would smell a= s > sweet", we just need to agree its called a rose. > > Thanks. > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a11355260cdec0b05551375b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 24, 2017 at 9:18 AM, David Farmer <farmer@umn.edu> wrote:


On Mon, Jul 24, 2017 at 3:= 47 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "David Farmer" <farmer@umn.edu>
To: "james woodyatt" <jhw@google.com>
Cc: "IPv6 List" <ipv6@ietf.org>
Sent: Saturday, July 22, 2017 9:54 PM

On Wed, Jul 19, 2017 at 3:12 AM, james woodyatt <jhw@google.com> wrote:

> On Jul 19, 2017, at 09:57, Brian E Carpenter
<brian.= e.carpenter@gmail.com>
> wrote:
>
> On 19/07/2017 18:22, james woodyatt wrote:
>
> On Jul 19, 2017, at 01:15, Brian E Carpenter
<brian.= e.carpenter@gmail.com>
> wrote:
>
>
> Hmm. Let's consider a case in which the last-hop route to a given = LAN
has
> a prefix of
> length, say, /80. What is the name of the bit-string from bits 81
through
> 127 of the
> host address? If they aren't called the "IID" what are t= hey called?
>
>
> If have yet to find where RFC 4291 clearly names the part of an IPv6 > address that follows a *routing* prefix apart from a *subnet* prefix.<= br> > Moreover, the phrase =E2=80=9Clast-hop route to a given LAN=E2=80=9D i= s not equivalent
to
> the concept of a subnet, and such a routing prefix is not equivalent to a
> subnet prefix. As RFC 5942 clarifies.
>
>
> Agreed, but I phrased my question in full knowledge of that. What do we
> call those trailing
> bits of the address? (I was reading the source of the Python
'ipaddress'
> module yesterday,
> and saw a comment about 'host bits', but that seems very 20th = century,
> given that the
> IPv6 architecture refers to interfaces.)
>
>
> I=E2=80=99ve been mentally using =E2=80=9Caddress suffix=E2=80=9D for = this concept, and I find
> that I rarely have much need for it. I suppose if I were using on-link=
> prefixes longer than /64, then I=E2=80=99d need it so I could differen= tiate
between
> the 64-bit Interface ID and the shorter part of the address that
follows
> the on-link prefix.
>

I think I'd prefer to call the righthand side of both a subnet prefix and a
on-link prefix an interface identifier, because in both case it is a
node's
interface that is being identified.=C2=A0 Then generically they are interfa= ce
identifiers, if you are referring to a specific aspect it is qualified
with
the aspect.

generically;

prefix / interface identifier

with specific aspects being referred to as;

subnet prefix / subnet interface identifier
on-link prefix / on-link interface identifier

Then it would be subnet interface identifiers that are 64 bits, except
...
and on-link interface identifiers are any length.

That is basically the assertion that started this part of the
discussion,
and that did fly with at least some.

So, I've been kicking around other ideas, because if the righthand side=
of
an on-link prefix isn't an interface identifier, it needs another name.=
How
about;

node identifier
on-link identifier
host identifier
on-link node
on-link host

I think I like on-link node best, but on-link identifier is a close
second
for me.

so;

subnet prefix / interface identifier
on-link prefix / on-link node

or;

subnet prefix / interface identifier
on-link prefix / on-link identifier

What do others think?

<tp>

How would that cope with address assignment prefixes being longer than
on-link prefixes?

You say an addre= ss assignment prefix longer than the on-link prefix, but then you describe = below a on-link prefix longer than the address assignment prefixes below, w= hich do you really mean?
Sorry, I should have had caffeine before doing email. :(
<= div>
/64 address assignment prefixes are longer than /60 on-l= ink prefixes.

I think everything below is correct = though. :)
=C2=A0
My on-link prefix is /60 but for address assignment I use a /64 and have one /64 for network management devices, another for print servers,
another for routers, one or more for hosts and so on.

Tom Petch

To achieve the desired result= you state above, a /60 on-link prefix and /64 address assignment prefixes,= =C2=A0I don't see how you would be able to use SLAAC, but you could ac= hieve what you state above with DHCPv6, or manual config.

Having the on-link prefix as a /60 just says that all 16 /64s are a= ssociated with that link. But SLAAC devices will have no knowledge of which= of the 16 /64 they are suppose to generate an addresses from.
You could have a PIO with a /60 prefix with the L flag set, an= d 1 to 16 /64 PIOs with the A flag set. Most devices will generate addresse= s on all the /64s that have an A flag set.=C2=A0 Printers will have no way = to know they should only use the first /64 verses the last /64 or any in be= tween. Same for management devices.=C2=A0 Now you could manually assign dev= ices to different /64s or use DHCPv6.=C2=A0 You could use DHCP for the host= s, but if set a PIO with a A flag for the hosts on one /64 you would need t= o configure the non-hosts to not use SLAAC, which is not a trivial thing to= do as far as I've seen on most devices.

What = we name the righthand side of a on-link prefix isn't going to change ho= w it works, as Shakespeare says "a rose by any other name would smell = as sweet", we just need to agree its called a rose.

Thanks.
-= -
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking= & Telecommunication Services
Office of Information Technology
Un= iversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2= =A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--001a11355260cdec0b05551375b4-- From nobody Mon Jul 24 11:03:03 2017 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 6361F129B55 for ; Mon, 24 Jul 2017 11:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 J4byrafANzuX for ; Mon, 24 Jul 2017 11:03:00 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FBB129B19 for ; Mon, 24 Jul 2017 11:03:00 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id g14so11396337pgu.0 for ; Mon, 24 Jul 2017 11:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=P8DML9lUfkMHDkEGQ6EeSkwYiSlR/hbfbWy5pSadbGc=; b=lC6IwvtFrbglpdT2uuw8Ss3md439TsC9H5VVgBFridMnyWBijqyU0yEDl9tUKGteg0 Gsw+vgdyrJGo8O+0ftsuXVos1Zexq+g3lf9JYui467hCpWKvEOgGJef+xqMfHWYiEp9o z0gO25pYeSA8ECYmtLg7crgwwq2N8aD2jgqIprLrE2xUQ3t55hUphHscVpxbHa/j+7ne iM5soUYueK8IgSlykCGq0YXzF7iN+NwmudNIsKvPdX7lpz1MfVFevLHLJM/wiTalvg4/ x/DNzZ9URoyKyvTwpUfbCnBD/L93ws+VGQdpSQsE4I3wcDCkdJ1suSvzRJaBoDPP4CJY eNqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=P8DML9lUfkMHDkEGQ6EeSkwYiSlR/hbfbWy5pSadbGc=; b=EmpMbnzT8JldYh5fdqMhA6+U6eD9OZbWPbVowJ96hPVrCVgmmx1PyEgqDNAOBzG396 wVavAFKbTwqwaynicBXbPL3ENWBNY4be8D1H3QJulCzlfDOPphixW5SYCakale6q9AfZ UL0foS7iJmXfgDj9T4h5GJsJ2g1STkvzB38KwovSLetiZRJSsbt0Gx1OpTYAQAAop+G4 eSgCW9AbJ2Kl6xu9/g6QZsEZtduuZulL/MfDiLqFOONM5e1VhKnqO6EpTsJeYgfjjbYX zqM69zdzzTBRZxDo2/u8qdg06ZGmOEUI8oINEPmWTWC1+c/do05LKg8VYKSi1CvaVeNC aafw== X-Gm-Message-State: AIVw111ysShZ2XAbT7y/DzRPf1+brOXCXu8kBSr1FmTVFLFmQgyiGtTx H6Dihu+NmCDTDkafpOrmog== X-Received: by 10.84.137.3 with SMTP id 3mr18544517plm.319.1500919379552; Mon, 24 Jul 2017 11:02:59 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:e1af:98b2:35d1:ff60? ([2620:0:10e7:10:e1af:98b2:35d1:ff60]) by smtp.gmail.com with ESMTPSA id y22sm22524322pfi.159.2017.07.24.11.02.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 11:02:58 -0700 (PDT) From: james woodyatt Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D762CE3-A581-4283-BDA4-C019187A05EB" X-Priority: 3 Subject: Re: Date: Mon, 24 Jul 2017 20:02:57 +0200 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <88a8e423-535a-d794-6f46-b89daeb21328@gmail.com> <25C70103-5F10-441E-8A1D-D7C7248AC1BB@google.com> <1aaa2f1c-45c4-2e27-a85c-1f21a340f099@gmail.com> <345495C4-030E-41FA-98CD-B403509B9402@google.com> <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> To: IPv6 List In-Reply-To: <010901d30459$794a76c0$4001a8c0@gateway.2wire.net> Message-Id: <80A571CE-9E91-45E1-A453-1780B512BF00@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 18:03:02 -0000 --Apple-Mail=_1D762CE3-A581-4283-BDA4-C019187A05EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 24, 2017, at 10:47, t.petch wrote: >=20 > I think I'd prefer to call the righthand side of both a subnet prefix = and a on-link prefix an interface identifier, because in both case it is = a node=E2=80=99s interface that is being identified. Then generically = they are interface identifiers, if you are referring to a specific = aspect it is qualified with the aspect. Here is the reason I can=E2=80=99t do that: the fact a destination = address has an on-link prefix does not, in fact, identify a destination = at a node on that link. For one, it may be an anycast address. However, = even if it=E2=80=99s a unicast address, it may=E2=80=94 in practice, if = not in standard theory=E2=80=94 identify a destination on a node that in = reality is attached to a completely different link. An important exception, with which I find myself increasingly concerned = these days, is the case where a 6LBR is sharing the subnet prefix = advertised in PIO by a CE router, preferably, with plen=3D64, L=3D1 and = A=3D1, naturally, and proposals to make plen>64 + L=3D1 into BCP is = worrisome accordingly=E2=80=94 and providing reachability at global = scope addresses to nodes on another link by proxying ND. In this case, = the CE router sends inbound packets to the 6LBR which retransmits them = to the destination on its 6LO interface only if it has a host route and = a ND proxy binding. In that scenario, to say that the part of the IPv6 address that follows = the on-link prefix, which=E2=80=9A let me repeat, is really a routing = prefix and its address configuration operational semantics are = completely orthogonal to this discussion, identifies the interface on = the 6LBR node and not the real destination address at the downstream 6LO = node's interface, is to make a technical distinction in the context of = forwarding and routing without any good purpose. For that reason, I=E2=80=99d prefer not to use =E2=80=9Cinterface = identifier=E2=80=9D for the part of a unicast address that follows a = routing prefix, particularly the part the follows the routing prefix = advertised in RA message PIO elements with A=3D0 and L=3D1. --james woodyatt > --Apple-Mail=_1D762CE3-A581-4283-BDA4-C019187A05EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jul 24, 2017, at 10:47, t.petch <ietfc@btconnect.com>= wrote:

I think I'd prefer = to call the righthand side of both a subnet prefix and = a on-link prefix an interface identifier, because = in both case it is a node=E2=80=99s interface that is = being identified.  Then generically they are = interface identifiers, if you are referring to a = specific aspect it is qualified with the = aspect.

Here is the reason I can=E2=80=99t do that: the = fact a destination address has an on-link prefix does not, in fact, = identify a destination at a node on that link. For one, it may be an = anycast address. However, even if it=E2=80=99s a unicast address, it = may=E2=80=94 in practice, if not in standard theory=E2=80=94 identify a = destination on a node that in reality is attached to a completely = different link.

An important = exception, with which I find myself increasingly concerned these days, = is the case where a 6LBR is sharing the subnet prefix advertised in PIO = by a CE router, preferably, with plen=3D64, L=3D1 and A=3D1, naturally, = and proposals to make plen>64 + L=3D1 into BCP is worrisome = accordingly=E2=80=94 and providing reachability at global scope = addresses to nodes on another link by proxying ND. In this case, the CE = router sends inbound packets to the 6LBR which retransmits them to the = destination on its 6LO interface only if it has a host route and a ND = proxy binding.

In that scenario, to = say that the part of the IPv6 address that follows the on-link prefix, = which=E2=80=9A let me repeat, is really a routing prefix and its address = configuration operational semantics are completely orthogonal to this = discussion, identifies the interface on the 6LBR node and not the real = destination address at the downstream 6LO node's interface, is to make a = technical distinction in the context of forwarding and routing without = any good purpose.

For that reason, = I=E2=80=99d prefer not to use =E2=80=9Cinterface identifier=E2=80=9D for = the part of a unicast address that follows a routing prefix, = particularly the part the follows the routing prefix advertised in RA = message PIO elements with A=3D0 and L=3D1.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_1D762CE3-A581-4283-BDA4-C019187A05EB-- From nobody Mon Jul 24 11:26:56 2017 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 CEC50131ED2 for ; Mon, 24 Jul 2017 11:26:54 -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 3pOgqxKlCwi7 for ; Mon, 24 Jul 2017 11:26:53 -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 1BA15131467 for ; Mon, 24 Jul 2017 11:26:53 -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 v6OIQqWX064589; Mon, 24 Jul 2017 11:26:52 -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 v6OIQiRw064506 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 24 Jul 2017 11:26:46 -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.1263.5; Mon, 24 Jul 2017 11:26:43 -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.1263.000; Mon, 24 Jul 2017 11:26:43 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTBGBYa/gXp6X1yEuE5Z0fN/zr5KJjPJPg Date: Mon, 24 Jul 2017 18:26:43 +0000 Message-ID: References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 18:26:55 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > I'm not attached to any particular term. However, I think it is > important that the reader of rfc4291bis gets a clear under standing of > the difference between an IID as used for SLAAC. Which has a lot of > properties, including that it is generated locally on the node and is > used for address configuration. > > And on the other hand, what I called 'host part' which in general > doesn't have any properties. So let's look at this. The properties of the SLAAC IID, according to RFC 48= 62 anyway, are that it must be whatever the IPv6-over-foo RFC tells us it m= ust be. "Properties" would include the length, in principle not constrained= to 64 bits, and for Ethernet, in accordance RFCs 2464, 4291 and 4862, an e= xact, predictable value, EUI-64. In the newer implementation of SLAAC, we h= ave said that the IID for SLAAC must be a random 64 bits. And RFC 4291-bis = wants to stipulate this aversion to EUI-64. For LLAs, same deal. IID must be EUI-64 for Ethernet. We may prefer to mode= rnize that to a random sequence, same considerations as in SLAAC. For ULAs, RFC 4193 requires IIDs to be as defined in RFC 3513, so there too= , EUI-64, exactly like SLAAC according to RFC 4862, and LLA according to RF= C 2464. With our new sensitivities, probably the ULA IIDs should also be ra= ndomly chosen. I suppose SLAAC can also be used with ULA prefixes. I don't = see any difference in properties so far? The IID used in DHCPv6 can be predictable, like 1, 2, 3, etc. But theoretic= ally, EUI-64 or a random sequence can also be applied to DHCPv6. The same c= onsiderations apply as in the previous two examples, in terms of properties= we might or might not care about. In principle, even using DHCPv6, we migh= t care not to make IIDs too obvious. Statically assigned IIDs, much the same, except they're going to have long = lifetimes. > In my opinion rfc4291bis should not be a random collection of true > statements that have to be assembled by the reader. Agreed, but RFC 4291-bis should be consistent and logical. The properties w= e worry about for IIDs are not necessarily different, in any of these addre= ss assignment schemes, that I can tell, and it doesn't make a lot of sense = to give "IID" a different name for every address assignment scheme? That wo= uld get too confusing. Bert From nobody Mon Jul 24 11:27:36 2017 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 78D37131EDE for ; Mon, 24 Jul 2017 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ppIPfjdmgJEb for ; Mon, 24 Jul 2017 11:27:32 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 C665512EB99 for ; Mon, 24 Jul 2017 11:27:31 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r14so41565677qte.4 for ; Mon, 24 Jul 2017 11:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3CbRhgYYT0hHBy3+dsTT2+SftrG4mdPxR6CZg8qItZE=; b=POg2d0lh15xY1DBhZvWaItgmqMxQ8du7NF5hC2RQb62QmIgr6Qn9Tkp712Ocd20ACF orE87pcdc+2e1IKIf9B5ueBvhnD/LWKHjZscQfkeTcJlKl8lJYwXw6O+8s2P7Vxz2Na6 hOszN4RfMaOBBUVFfO1oLqTISem5jBtkYejs2NJm0TELrM+IHUyAtMrVbWnkDwt+5PrS eW4CTMW1x3EXN2W+mQtK6FhTP7BJ3QdD89CLF9GQViIVJd6fMzJ5XRwWrp3jWitN1DZI U1meavJZe8DqYAF5BRbbROSihP5BOIXILs+KksNMt1u/i8fMG8P7MY4FmUV1JO4FrfoI 84GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3CbRhgYYT0hHBy3+dsTT2+SftrG4mdPxR6CZg8qItZE=; b=eamEVp61izy3J1PH0qcJuwJrDqPkhEqSyTW2rwGHYlZaBIuhWyEA7D3zu0nigqIL12 wto5X85ciwVXll9iFA40MRpPSkawT6+ntBTlsiAXpHF8vcNz3Xn0RT3r8/gv7/gX96sC P21msKqVV3HHU+VxsL3a+v3lar1YpCidM+aPi6W8Hxul/FHrYZgsH3/P1Qbwc2g3awRw vOM0gD/DS1fFa2rOlZDLHzzUUDWnd5kz4EH/hJBbk4BdMJV25hznyyCv9N/0ui7PGXfy yXX8+bTtvffXTlg92ga4x8i0mcFPMZgT8XjmspZX+aSJuKqNOAQckqa9QVKwViL0hsl8 53fA== X-Gm-Message-State: AIVw110rTOykXQd+w5tAi0bQB5R66CIBmt4XvcIfrYNfjv7JMUQhMXTZ T4t1IVwz0T8betwWB/ZvVavaw1bJgMCZcQI= X-Received: by 10.237.46.230 with SMTP id k93mr6203139qtd.198.1500920850782; Mon, 24 Jul 2017 11:27:30 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.44 with HTTP; Mon, 24 Jul 2017 11:27:29 -0700 (PDT) In-Reply-To: <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <1f01821f068b42839f238dfb06cf53ad@XCH15-06-11.nw.nos.boeing.com> <0a87d897-05f6-0834-3eb6-a72b36e29378@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 24 Jul 2017 11:27:29 -0700 X-Google-Sender-Auth: 35sIpTIoMqft2PdFOFtohbfHPiY Message-ID: Subject: Re: To: Brian E Carpenter Cc: "Manfredi, Albert E" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 18:27:33 -0000 At Sun, 23 Jul 2017 11:55:06 +1200, Brian E Carpenter wrote: > Actually, by removing all the exceptions in the -09 text, I contend > it is a considerable semantic simplification. > > > for no benefit other than to make non-64-bit IIDs appear to be more outcasts. > > Not at all. It sticks to the principle that an Internet Standard doesn't > change the existing protocol but clarifies the applicability of the > 64 bit rule. You need to compare it with RFC4291, not with the -09 text. > > If you want to *change* the rule for SLAAC IID lengths, that's outside > the scope of promoting 4291 to IS status. +1. We really need to stop introducing the discussion on non-64 SLAAC IID length to the rfc4291bis discussion. It's perfectly fine to discuss it in any post-rfc4291bis updates (although I'm quite skeptical whether we can reach any consensus), or we could even say "given the possibility of the post-rfc4291bis discussion we should now give up promoting RFC4291 to IS". But, due to the conservative nature of rfc4291bis we can't simply have this discussion in that context anyway, and given its controversy it would simply waste our time. We don't need any more unnecessary controversy for out-of-scope topics and need to focus on the point. BTW, as for this one: >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." >> Who here could not live with that? I'd personally live with any editorial hack as long as we can reach rough consensus (and unless it violates RFC4291 or current deployments). Also, IMO it's at least better than the draft-09 text (excluding addresses "manually configured") as it's less ambiguous. But I thought Bob didn't like to refer to a particular way of generating addresses whether it's SLAAC or DHCPv6. -- JINMEI, Tatuya From nobody Mon Jul 24 11:44:41 2017 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 E12E8129B53 for ; Mon, 24 Jul 2017 11:44:38 -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 S0DjcA79t_u8 for ; Mon, 24 Jul 2017 11:44:37 -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 E7985124234 for ; Mon, 24 Jul 2017 11:44:36 -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 v6OIiZWA016620; Mon, 24 Jul 2017 11:44:35 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6OIiQKM016454 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 24 Jul 2017 11:44:26 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 11:44:25 -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.1263.000; Mon, 24 Jul 2017 11:44:25 -0700 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTBGBYa/gXp6X1yEuE5Z0fN/zr5KJjPJPggAASaCA= Date: Mon, 24 Jul 2017 18:44:25 +0000 Message-ID: <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 18:44:39 -0000 Oh, on the IID length, as far as I can tell, we have fairly much agreed tha= t SLAAC should insist on 64 bit IIDs, and as written, RFC 4193 clearly mand= ates 64-bit IIDs for ULAs, in its current incarnation. Even after EUI-64 ha= s been deprecated, the prefix described for ULAs is going to be 64 bits. Fo= r all other examples of addresses, the length restriction doesn't need to b= e stated, however all the other "properties" of predictability and lifetime= should still be a consideration. >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." >> Who here could not live with that? Works for me. Bert -----Original Message----- From: Manfredi, Albert E=20 Sent: Monday, July 24, 2017 14:27 To: 'Philip Homburg' ; ipv6@ietf.org Subject: RE: =20 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > I'm not attached to any particular term. However, I think it is > important that the reader of rfc4291bis gets a clear under standing of > the difference between an IID as used for SLAAC. Which has a lot of > properties, including that it is generated locally on the node and is > used for address configuration. > > And on the other hand, what I called 'host part' which in general > doesn't have any properties. So let's look at this. The properties of the SLAAC IID, according to RFC 48= 62 anyway, are that it must be whatever the IPv6-over-foo RFC tells us it m= ust be. "Properties" would include the length, in principle not constrained= to 64 bits, and for Ethernet, in accordance RFCs 2464, 4291 and 4862, an e= xact, predictable value, EUI-64. In the newer implementation of SLAAC, we h= ave said that the IID for SLAAC must be a random 64 bits. And RFC 4291-bis = wants to stipulate this aversion to EUI-64. For LLAs, same deal. IID must be EUI-64 for Ethernet. We may prefer to mode= rnize that to a random sequence, same considerations as in SLAAC. For ULAs, RFC 4193 requires IIDs to be as defined in RFC 3513, so there too= , EUI-64, exactly like SLAAC according to RFC 4862, and LLA according to RF= C 2464. With our new sensitivities, probably the ULA IIDs should also be ra= ndomly chosen. I suppose SLAAC can also be used with ULA prefixes. I don't = see any difference in properties so far? The IID used in DHCPv6 can be predictable, like 1, 2, 3, etc. But theoretic= ally, EUI-64 or a random sequence can also be applied to DHCPv6. The same c= onsiderations apply as in the previous two examples, in terms of properties= we might or might not care about. In principle, even using DHCPv6, we migh= t care not to make IIDs too obvious. Statically assigned IIDs, much the same, except they're going to have long = lifetimes. > In my opinion rfc4291bis should not be a random collection of true > statements that have to be assembled by the reader. Agreed, but RFC 4291-bis should be consistent and logical. The properties w= e worry about for IIDs are not necessarily different, in any of these addre= ss assignment schemes, that I can tell, and it doesn't make a lot of sense = to give "IID" a different name for every address assignment scheme? That wo= uld get too confusing. Bert From nobody Mon Jul 24 12:43:55 2017 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 C329B12420B for ; Mon, 24 Jul 2017 12:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmIjndQGjE5U for ; Mon, 24 Jul 2017 12:43:50 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 D635512942F for ; Mon, 24 Jul 2017 12:43:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 4586F86E for ; Mon, 24 Jul 2017 19:43:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIgNZ2Ffxn5A for ; Mon, 24 Jul 2017 14:43:50 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 1091B1A0 for ; Mon, 24 Jul 2017 14:43:49 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id f9so91217488uaf.1 for ; Mon, 24 Jul 2017 12:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yr7t6o74AYyPR2IOVaDl7Nc1x46B/lTwqeHxsXsT3Os=; b=F/WAlLCuAjLVYv+H0hmjSLyY0vN7gwY3QUgWmIzBaZCqQG/2BUc+ppN08Z+8RXu48f 1FGJgeoUoWujDjpb1rSbbryAYdn3uWzxtKTx1TIKSRyZCbF+E8DQT3RRd31IlQ59oGXs m37+DNVaGYGh11RF5SECzbBViMt4fSy4HFE3TVtS5n3+xW+vEH8pDNbcHiT+7aQ4aUh0 4MjcmFQuPcK1YwqIKGOgF1EdcWFiKikkpJkw1hY/cdf1eVwe/Ni3EbK8/xqzrdextIlw Xf8BtMuzu7ljerweMf9/dNSsiHtkka595TKv0hTSb/rDC1yInkqnwD4cp2O7bkEWvB8D PRvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yr7t6o74AYyPR2IOVaDl7Nc1x46B/lTwqeHxsXsT3Os=; b=WltyirBwwmevaW48CD49QYwjg5+Sq5kHXEd/yEKvMrPQp2+LcZADCMfI88qSUbOMM1 G7/3bMfgq9+0Gj06hfihioGk0O2fpFCaqBMPF36WO9jHhWeOSCoUQs+sLEV0v/eYNhee cKg4vhyLQDmZ/mXlTXhmbt0o7fd+Ny9oi2CNTMfKb1iSf199+eWp9wA5Etwv5E8EOYFz 9HTyatGkZ9FBF2L/MTZ5VRe0yODhjiOY5Xypn4uojFBkfpscX5ns+9MJemUJenapGfZ/ hjKsDEZZvcn6Wd3hwwyU4tATY+eLe9mOIA4ebMobAnHsI6+XoUG1SbAR32QVFxH1Y9if k+/w== X-Gm-Message-State: AIVw112TvZCXCRFLwrUFu8xDu+0bAw0Q12zs0R0HkpQdqJ4nyf+4WgbF nxi+roGMkHs51icujWTaEWFfpsrM3zcvgbjMT1pTyOjfGCr+loN4BCXQt0TJdpAwLfBME8tGLLL I9417/pIYidTnc+s= X-Received: by 10.176.74.133 with SMTP id s5mr11464961uae.172.1500925428786; Mon, 24 Jul 2017 12:43:48 -0700 (PDT) X-Received: by 10.176.74.133 with SMTP id s5mr11464954uae.172.1500925428607; Mon, 24 Jul 2017 12:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 24 Jul 2017 12:43:47 -0700 (PDT) In-Reply-To: <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Mon, 24 Jul 2017 14:43:47 -0500 Message-ID: Subject: Re: To: "Manfredi, Albert E" Cc: Philip Homburg , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="f403045f9058021a380555156f73" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 19:43:53 -0000 --f403045f9058021a380555156f73 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 24, 2017 at 1:44 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > Oh, on the IID length, as far as I can tell, we have fairly much agreed > that SLAAC should insist on 64 bit IIDs, and as written, RFC 4193 clearly > mandates 64-bit IIDs for ULAs, in its current incarnation. What? Yes it says they are 64bits, but it is just referencing RFC 3513, which is what I would expect it to do, which is the predecessor of RFC 4291. If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so is RFC 3513 and RFC 4193 too. > Even after EUI-64 has been deprecated, the prefix described for ULAs is > going to be 64 bits. For all other examples of addresses, the length > restriction doesn't need to be stated, however all the other "properties" > of predictability and lifetime should still be a consideration. > > >> "Interface Identifiers are 64 bits long when used for Stateless > >> Address Autoconfiguration (SLAAC) [RFC4862]." > > >> Who here could not live with that? > > Works for me. > > Bert > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045f9058021a380555156f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 24, 2017 at 1:44 PM, Manfredi, Albert E &= lt;albert= .e.manfredi@boeing.com> wrote:
Oh, on the IID length, as far as I can tell, we have= fairly much agreed that SLAAC should insist on 64 bit IIDs, and as written= , RFC 4193 clearly mandates 64-bit IIDs for ULAs, in its current incarnatio= n.

What? Yes it says they are 64bits, but = it is just referencing RFC 3513, which is what I would expect it to do, whi= ch is the predecessor of RFC 4291. If you think RFC 4291 is really saying S= LAAC IIDs are 64 bits then so is RFC 3513 and RFC 4193 too.=C2=A0
=C2=A0
Even after E= UI-64 has been deprecated, the prefix described for ULAs is going to be 64 = bits. For all other examples of addresses, the length restriction doesn'= ;t need to be stated, however all the other "properties" of predi= ctability and lifetime should still be a consideration.

>> "Interface Identifiers are 64 bits long when used for Statele= ss
>> Address Autoconfiguration (SLAAC) [RFC4862]."

>> Who here could not live with that?

Works for me.

Bert

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDavid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information = Technology
University of Minnesota=C2=A0=C2=A0
2218 University Ave S= E=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3= 029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045f9058021a380555156f73-- From nobody Mon Jul 24 13:01:15 2017 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 066FF131F02; Mon, 24 Jul 2017 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 TByNeWabNJKY; Mon, 24 Jul 2017 13:01:04 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E035C131EFE; Mon, 24 Jul 2017 13:01:04 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6OJtLmr046536; Mon, 24 Jul 2017 16:01:03 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2bwma3pv1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 16:01:03 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0whj024670; Mon, 24 Jul 2017 16:01:00 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6OK0m35024292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jul 2017 16:00:54 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi134.aldc.att.com (RSA Interceptor); Mon, 24 Jul 2017 20:00:35 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Mon, 24 Jul 2017 16:00:34 -0400 From: "STARK, BARBARA H" To: Michael Richardson CC: Fred Baker , IPv6 Ops WG , "6man WG" Subject: PPPoE requirements (was Turning on IPv6 Routers) Thread-Topic: PPPoE requirements (was Turning on IPv6 Routers) Thread-Index: AdMEt31v4/lFzKojS3arT0hUd4QLuQ== Date: Mon, 24 Jul 2017 20:00:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.213.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240304 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:01:07 -0000 > > As an implementer of a PPPoE aggregator/access-router, I found that= I > > had to invert 7084 to determine what I had to implement. >=20 > > It might be worth a document, if only so that ISPs would have somet= hing > > against which to issue RFPs. Maybe. >=20 > bhs> BBF TR-187 documents the telco IPv6 over pppoe access > network > bhs> architecture with some specific requirements for access network > bhs> elements. > bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue-= 2.pdf >=20 > Yes, I worked from TR-187 as well. It's close to what I want, but it does= n't say > what the access network elements *MUST* do, but rather tells you what the > CPE boxes MUST try. ?? Section 9 of TR-187 is all about the BNG (BBF term for access network IP ed= ge router that does aggregation) requirements. But the doc as a whole presents a number of ways to do IPv6 over PPPoE -- n= ot just one. This means the ISP has to pick one and configure it appropriat= ely. The BNG requirements include support for all of the described ways. Th= e conditional wording in some of the requirements is a bit strange, though. > For instance: *SHOULD* a PPPoE access router provide an address for the > CPE router link via RA or via DHCPv6? =20 The BNG has to support RA (SLAAC), IA_NA, and IA_PD. The ISP is responsible= for configuring the BNG appropriately/correctly per the ISP's chosen archi= tecture. The ISP can choose to provide the address by RA (SLAAC), IA_NA, or= go with the unnumbered model (CE router picks address from IA_PD prefix). > If it does both, should it offer the same > address? =20 I would recommend against configuring the BNG to use the same prefix for SL= AAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really be ne= eded. And I don't understand why anyone would want to. I would recommend th= e ISP pick a single method to use. The TR-124 RG is expected (by default) t= o support all numbering models. If offered SLAAC, it must take an address f= rom that prefix (at least one). If offered IA_NA, it must accept that. It m= ust do IA_PD. If neither SLAAC nor IA_NA are offered, then it must assign i= tself an address from the IA_PD.=20 > It would be rather better if one *knew* the CPE would do PD > and then assign itself an address out of one of the /64s. That would > eliminate a bunch of routes. =20 TR-124 RG requirements (referenced by TR-187) do require support for IA_PD = and the unnumbered model. RFC 7084 does not require support for the unnumbe= red model; there it's optional. An ISP procuring CE routers can use TR-124 = for an RFP. But such an ISP cannot depend on "retail" CE routers supporting= the unnumbered model. This is because CableLabs eRouters do not support th= e unnumbered model, and eRouters needed to be compliant with RFC 7084. I'm = not sure of the status of the unnumbered model in non-eRouter "retail" CE r= outers. > Part of the problem is that one can't necessarily > depend upon the CPE to do DHCPv6 (-PD) at all! Support for IA_PD is mandatory in RFC 7084, CableLabs eRouters, and TR-124.= The default flow in TR-124 (Appendix A.1 which leads to A.2) is for IA_PD = always to be requested (don't wait for RA). TR-124 was specifically designe= d for use in RFPs. RFC 7084 requires IA_PD be requested if M or O =3D 1. Th= e fact that some CE routers don't support any of these specs doesn't mean w= e need more specs. It means we need more compliant CE routers. > It would just be nice to reduce the number of options. Maybe a BCP is in > order. Unless we know some of the options aren't being used by any ISP, it would b= e hard to get agreement to get rid of any. My sense is there is widespread = support of both IA_NA and unnumbered. I don't know if anyone is using SLAAC= over PPPoE, but I suspect there are. But since the IPv6 over PPPoE flow is= identical to native IPv6 after IPv6CP is done, and for native IPv6 we do k= now of deployments with SLAAC, I would be tempted to keep that same flow ra= ther than get rid of an option for IPv6 over PPPoE. My recommended practices would be more like: - if doing PPPoE, make sure your CE routers / RGs are compliant with TR-= 124 WAN.PPP and WAN.PPP.IPv6 modules - make your CE router vendors get the IPv6 Ready CE router certification - don't configure the same prefix on SLAAC and IA_* or IA_NA and IA_PD I would like to see if we could reduce the number of v4 over v6 tunneling o= ptions that v6ops will be "recommending". I think the current laundry list = is a bad idea. But that's another topic. From nobody Mon Jul 24 13:18:41 2017 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 9377A131F0C for ; Mon, 24 Jul 2017 13:18:40 -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 hGVNE_CFl2n8 for ; Mon, 24 Jul 2017 13:18:39 -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 DD46C131F0B for ; Mon, 24 Jul 2017 13:18:38 -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 v6OKIbSJ042810; Mon, 24 Jul 2017 13:18:38 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6OKIbXj042802 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 24 Jul 2017 13:18:37 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 13:18:36 -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.1263.000; Mon, 24 Jul 2017 13:18:36 -0700 From: "Manfredi, Albert E" To: David Farmer CC: "ipv6@ietf.org" Subject: RE: Thread-Topic: Thread-Index: AQHTBLUzKB8IDmOgm0WjWtwsxbZ3VKJjZK6Q Date: Mon, 24 Jul 2017 20:18:36 +0000 Message-ID: <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 20:18:40 -0000 RnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdIA0KDQo+IFdoYXQ/IFll cyBpdCBzYXlzIHRoZXkgYXJlIDY0Yml0cywgYnV0IGl0IGlzIGp1c3QgcmVmZXJlbmNpbmcgUkZD IDM1MTMsDQo+IHdoaWNoIGlzIHdoYXQgSSB3b3VsZCBleHBlY3QgaXQgdG8gZG8sIHdoaWNoIGlz IHRoZSBwcmVkZWNlc3NvciBvZiBSRkMgNDI5MS4NCg0KQWdyZWVkLiBUaGVzZSB0d28gUkZDcyBk byBub3QgZGlmZmVyLCBpbiByZWdhcmRzIHRvIHJlcXVpcmluZyA2NCBiaXRzLCAqYW5kKiBFVUkt NjQgaW4gcGFydGljdWxhci4NCg0KPiBJZiB5b3UgdGhpbmsgUkZDIDQyOTEgaXMgcmVhbGx5IHNh eWluZyBTTEFBQyBJSURzIGFyZSA2NCBiaXRzIHRoZW4gc28gaXMNCj4gUkZDIDM1MTMgYW5kIFJG QyA0MTkzIHRvby4NCg0KTm8sIFJGQyA0MjkxIGlzIGFnbm9zdGljIG9uIFNMQUFDIElJRCBsZW5n dGguIEl0IHJlZmVycyB0aGUgcmVhZGVyIHRvIHdoYXRldmVyIElQdjYtb3Zlci1mb28gUkZDLCBm b3IgSUlEIGxlbmd0aCBhbmQgZm9ybXVsYXRpb24uIEJ1dCBSRkMgNDE5MyAoVUxBKSBzZWVtcyBt b3JlIGluc2lzdGVudCB0aGF0IGl0IG11c3QgYmUgNjQgYml0cyBhbmQgRVVJLTY0LiBBZnRlciBh bGwsIGFzIHNwZWNpZmljIGFzIFJGQyA0MTkzIGlzIG9uIGhvdyB0byBjcmVhdGUgVUxBIHByZWZp eGVzLCB0aGVyZSdzIG5vIG90aGVyIG9wdGlvbiB0aGFuIDY0LWJpdCBJSURzLCBmb3IgVUxBcy4N Cg0KV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IDZtYW4gc2VlbXMgdG8gaGF2ZSBjb21lIHRvIGFu IGFncmVlbWVudCB0aGF0IFNMQUFDIHNob3VsZCBiZSByZXN0cmljdGVkIHRvIHVzaW5nIDY0LWJp dCBJSURzLg0KDQpUaGlzIFNMQUFDIHJlc3RyaWN0aW9uIGlzIG5vdCBkaXJlY3RseSByZWxhdGVk IHRvIFJGQ3MgMjQ2NCwgNDI5MSwgb3IgNDg2MiwgYmVjYXVzZSB0aGVzZSBhbGwgbWFuZGF0ZWQg RVVJLTY0LiBTdGlsbCwgd2Ugc2VlbSB0byB3YW50IDY0LWJpdCBJSURzIG1hbmRhdG9yeSBmb3Ig U0xBQUMuIFdoeT8gQmVjYXVzZSB3ZSB3YW50IDY0LWJpdCBJSURzIHRvIGJlIHRoZSAiZGVmYXVs dCIgYW5kICJyZWNvbW1lbmRlZCIgbGVuZ3RoLCBhbmQgYmVjYXVzZSB3ZSBmaWd1cmUgdGhhdCBT TEFBQyB3aWxsIGJlIHRoZSBtb3N0IHBvcHVsYXIgd2F5IG9mIGZvcm1pbmcgSVB2NiBhZGRyZXNz ZXMuDQoNClNvLCBpZiBSRkMgNDI5MS1iaXMgd2FudHMgdG8gc3RhdGUgYXMgbXVjaCwgdGhhdCdz IG9rYXkgd2l0aCBtZS4NCg0KSSB0aGluayB0aGUgSUlEIGxlbmd0aCBydWxlcyBjYW4gYmUgY29u c2lkZXJhYmx5IHNpbXBsaWZpZWQsIGNvbXBhcmVkIHdpdGggdGhlICJleGNlcHRpb25zIiBsaXN0 ZWQgaW4gUkZDIDQyOTEuIEluc3RlYWQgb2YgImV4Y2VwdGlvbnMiIHRvIHRoZSA2NC1iaXQgaGFy ZCBib3VuZGFyeSwgbGlzdCB0aGUgY2FzZXMgd2hlcmUgaXQgYXBwbGllcy4gU0xBQUMgbW9zdGx5 LCBtYXliZSBhIG1lbnRpb24gb2YgRXRoZXJuZXQgTExBcyAoYWx0aG91Z2ggc3ViamVjdCB0byB1 cGRhdGUgb2YgUkZDIDI0NjQpLCBhbmQgVUxBcy4gSnVzdCB0cnlpbmcgdG8gYmUgY29uc2lzdGVu dCBoZXJlLg0KDQpCZXJ0DQoNCg== From nobody Mon Jul 24 19:56:11 2017 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 0C020129AD2 for ; Mon, 24 Jul 2017 19:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ULf0hGmypUnA for ; Mon, 24 Jul 2017 19:56:00 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 101D112969E for ; Mon, 24 Jul 2017 19:56:00 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id a12so60386269ywh.3 for ; Mon, 24 Jul 2017 19:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ol2ei7n6Zf0cTjhkQW2Zm4+0iCOP9BeFkE4PReOe+Zs=; b=TrG0Fwro3tWb6DRq1kWbbgQpwXbO0dcnPIFaTRKoi7jPBFx7Kg2ka7ZZ9fBeaC7KuO MkZFKmNJEolZ1jyY76e89VP6IMD6c/xx1fqXS6cECGF6uU7N2IiYJwZPk1rkXD0fmbGa YbOArNeM9UyJ+RUa+ZPpHIONTzcsmXMyMlutylorLkXEVCGSBqVYTYLn2ILrTXdmzBN1 R6rpiJaMm2VWXg/NiRZ1Ai1bseXDkkrKjcn87AbrEhSv2b8SD2rftvTMXLJ4NsLriVwX tfvyJYh14I1Fo1f0JW6qlh6uqeEu6PRPCoOlmS9i+IiSrOjlDDL7Hm7TkXC4eub0j702 TjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ol2ei7n6Zf0cTjhkQW2Zm4+0iCOP9BeFkE4PReOe+Zs=; b=fbaK8ZZQS8lmlW5DFWjg2MtqQDVLakmkrBw6bs391mfhtY6alYba7tr29ulQ2pq4vO ubBMbxZggnNPotwRAoWvEcasjvbwTHUrCxw97BujMT6YTxs2D4Iq7/zxSgHyxvFVUrxi gpF+GGj3dQA3qFRkKpV77+rfq5a/z1NAgCrKuXFiOWe0Zogve+dgr9o1/BFe5XMz+jA2 eQckteWtDnPd/4aerxzO2XqDinOSyBQVi42OGI7Jyp0Kd8IYr4Tu1u5ZAFWDrdXlqB6W gDmJwVcTYw/yelDYaS0yMn76jR7BEqq61d9DRKTDe4q2rt7toDv+lpMkyefDmsXePrR8 d+Ew== X-Gm-Message-State: AIVw113YGqgQbUqCoBD3rqmOaJtlo/+qbePpprzBG7lyEp98q2mo53gh TK/C6jeQGOBz6BTQYiTCenHKOKAsdcWGdds= X-Received: by 10.37.32.193 with SMTP id g184mr16178717ybg.4.1500951358974; Mon, 24 Jul 2017 19:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.50.65 with HTTP; Mon, 24 Jul 2017 19:55:38 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Erik Kline Date: Tue, 25 Jul 2017 11:55:38 +0900 Message-ID: Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) To: "STARK, BARBARA H" Cc: Michael Richardson , IPv6 Ops WG , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1143e0d89be7cf05551b78ee" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 02:56:04 -0000 --001a1143e0d89be7cf05551b78ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 25 July 2017 at 05:00, STARK, BARBARA H wrote: >> > As an implementer of a PPPoE aggregator/access-router, I found tha= t I >> > had to invert 7084 to determine what I had to implement. >> >> > It might be worth a document, if only so that ISPs would have some= thing >> > against which to issue RFPs. Maybe. >> >> bhs> BBF TR-187 documents the telco IPv6 over pppoe access >> network >> bhs> architecture with some specific requirements for access network >> bhs> elements. >> bhs> https://www.broadband-forum.org/technical/download/TR-187_Issue= -2.pdf >> >> Yes, I worked from TR-187 as well. It's close to what I want, but it doe= sn't say >> what the access network elements *MUST* do, but rather tells you what th= e >> CPE boxes MUST try. > > ?? > Section 9 of TR-187 is all about the BNG (BBF term for access network IP = edge router that does aggregation) requirements. > But the doc as a whole presents a number of ways to do IPv6 over PPPoE --= not just one. This means the ISP has to pick one and configure it appropri= ately. The BNG requirements include support for all of the described ways. = The conditional wording in some of the requirements is a bit strange, thoug= h. > >> For instance: *SHOULD* a PPPoE access router provide an address for the >> CPE router link via RA or via DHCPv6? > > The BNG has to support RA (SLAAC), IA_NA, and IA_PD. The ISP is responsib= le for configuring the BNG appropriately/correctly per the ISP's chosen arc= hitecture. The ISP can choose to provide the address by RA (SLAAC), IA_NA, = or go with the unnumbered model (CE router picks address from IA_PD prefix)= . > >> If it does both, should it offer the same >> address? > > I would recommend against configuring the BNG to use the same prefix for = SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really be = needed. And I don't understand why anyone would want to. I would recommend = the ISP pick a single method to use. The TR-124 RG is expected (by default)= to support all numbering models. If offered SLAAC, it must take an address= from that prefix (at least one). If offered IA_NA, it must accept that. It= must do IA_PD. If neither SLAAC nor IA_NA are offered, then it must assign= itself an address from the IA_PD. You don't need DAD to deal for link-local addresses? >> It would be rather better if one *knew* the CPE would do PD >> and then assign itself an address out of one of the /64s. That would >> eliminate a bunch of routes. > > TR-124 RG requirements (referenced by TR-187) do require support for IA_P= D and the unnumbered model. RFC 7084 does not require support for the unnum= bered model; there it's optional. An ISP procuring CE routers can use TR-12= 4 for an RFP. But such an ISP cannot depend on "retail" CE routers supporti= ng the unnumbered model. This is because CableLabs eRouters do not support = the unnumbered model, and eRouters needed to be compliant with RFC 7084. I'= m not sure of the status of the unnumbered model in non-eRouter "retail" CE= routers. > >> Part of the problem is that one can't necessarily >> depend upon the CPE to do DHCPv6 (-PD) at all! Is this because it might actually just be a host that's connecting? > Support for IA_PD is mandatory in RFC 7084, CableLabs eRouters, and TR-12= 4. The default flow in TR-124 (Appendix A.1 which leads to A.2) is for IA_P= D always to be requested (don't wait for RA). TR-124 was specifically desig= ned for use in RFPs. RFC 7084 requires IA_PD be requested if M or O =3D 1. = The fact that some CE routers don't support any of these specs doesn't mean= we need more specs. It means we need more compliant CE routers. > >> It would just be nice to reduce the number of options. Maybe a BCP is i= n >> order. > > Unless we know some of the options aren't being used by any ISP, it would= be hard to get agreement to get rid of any. My sense is there is widesprea= d support of both IA_NA and unnumbered. I don't know if anyone is using SLA= AC over PPPoE, but I suspect there are. But since the IPv6 over PPPoE flow = is identical to native IPv6 after IPv6CP is done, and for native IPv6 we do= know of deployments with SLAAC, I would be tempted to keep that same flow = rather than get rid of an option for IPv6 over PPPoE. > My recommended practices would be more like: > - if doing PPPoE, make sure your CE routers / RGs are compliant with T= R-124 WAN.PPP and WAN.PPP.IPv6 modules > - make your CE router vendors get the IPv6 Ready CE router certificati= on > - don't configure the same prefix on SLAAC and IA_* or IA_NA and IA_PD > > I would like to see if we could reduce the number of v4 over v6 tunneling= options that v6ops will be "recommending". I think the current laundry lis= t is a bad idea. But that's another topic. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143e0d89be7cf05551b78ee Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgg6wSmL+wACFM2TutI5/ENTWrE39VXKaN A/7mEZRGxzswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNzI1 MDI1NTU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAH8d5GZDBy91VOauf3i+9Fh7qzVLiolj51RUwhrLQxzVj88GdSDH I6mAMa+yxSyslA86LDyeCpaCprJ8GuqR+OvNuBgLhRFOX9u+/oo/sclLXCFOPIo0npaw25fHLS8X RxHHT46i/ruobzgfa/MBZj4xQjtdOoz7sENJis/7X9+OlKqpuQaMZJBFNpar/KPswjFj3djAYX6n i1CqzKGLW9dRev//0ke38wVf6C0Qa4aVlGMTqJquA+L4zQ/C6VGDdfMZuJOjfbP+c+exMEB2CdDh tqYnJItB+UqD1TMVRvjnmlt3ZgARBGU0ek1SzSF9y31Bj67xX5jPEBka9yFFODw= --001a1143e0d89be7cf05551b78ee-- From nobody Mon Jul 24 23:08:47 2017 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 44E25126B7E for ; Mon, 24 Jul 2017 23:08:46 -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, RP_MATCHES_RCVD=-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 q3NS47C3avzw for ; Mon, 24 Jul 2017 23:08:44 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9A1205F0 for ; Mon, 24 Jul 2017 23:08:43 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 6D2F4E6065; Tue, 25 Jul 2017 08:08:41 +0200 (CEST) Date: Tue, 25 Jul 2017 08:08:41 +0200 (CEST) Message-Id: <20170725.080841.74682960.sthaug@nethelp.no> To: albert.e.manfredi@boeing.com Cc: farmer@umn.edu, ipv6@ietf.org Subject: Re: From: sthaug@nethelp.no In-Reply-To: <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> References: <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 06:08:46 -0000 > I think the IID length rules can be considerably simplified, compared with the "exceptions" listed in RFC 4291. Instead of "exceptions" to the 64-bit hard boundary, list the cases where it applies. SLAAC mostly, maybe a mention of Ethernet LLAs (although subject to update of RFC 2464), and ULAs. Just trying to be consistent here. ULAs work just fine with manual configuration, and therefore should come under the same exception for manually configured addresses. Steinar Haug, AS2116 From nobody Tue Jul 25 05:55:49 2017 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 B431E131CA2; Tue, 25 Jul 2017 05:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 RPPgcBGA0mYp; Tue, 25 Jul 2017 05:55:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 03165131C4F; Tue, 25 Jul 2017 05:55:45 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6PCt2ZX006424; Tue, 25 Jul 2017 08:55:41 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2bwttrvpc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jul 2017 08:55:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6PCtdrl006375; Tue, 25 Jul 2017 08:55:40 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6PCtXNs006258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jul 2017 08:55:34 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 25 Jul 2017 12:55:20 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0319.002; Tue, 25 Jul 2017 08:55:20 -0400 From: "STARK, BARBARA H" To: Erik Kline CC: Michael Richardson , IPv6 Ops WG , 6man WG Subject: RE: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) Thread-Topic: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) Thread-Index: AdMEt31v4/lFzKojS3arT0hUd4QLuQAW4gkAAAtzsBA= Date: Tue, 25 Jul 2017 12:55:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.240.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-25_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250209 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 12:55:48 -0000 PiA+PiBGb3IgaW5zdGFuY2U6ICpTSE9VTEQqIGEgUFBQb0UgYWNjZXNzIHJvdXRlciBwcm92aWRl IGFuIGFkZHJlc3MgZm9yIHRoZQ0KPiA+PiBDUEUgcm91dGVyIGxpbmsgdmlhIFJBIG9yIHZpYSBE SENQdjY/DQo+ID4+IElmIGl0IGRvZXMgYm90aCwgc2hvdWxkIGl0IG9mZmVyIHRoZSBzYW1lDQo+ ID4+IGFkZHJlc3M/DQo+ID4NCj4gPiBJIHdvdWxkIHJlY29tbWVuZCBhZ2FpbnN0IGNvbmZpZ3Vy aW5nIHRoZSBCTkcgdG8gdXNlIHRoZSBzYW1lIHByZWZpeCBmb3INCj4gU0xBQUMgYW5kIElBX05B IG9yIElBX1BELCBvciBmb3IgSUFfTkEgYW5kIElBX1BELiBUaGVuIERBRCB3b3VsZCByZWFsbHkN Cj4gYmUgbmVlZGVkLiBBbmQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBhbnlvbmUgd291bGQgd2Fu dCB0by4gSSB3b3VsZA0KPiByZWNvbW1lbmQgdGhlIElTUCBwaWNrIGEgc2luZ2xlIG1ldGhvZCB0 byB1c2UuIA0KPiANCj4gWW91IGRvbid0IG5lZWQgREFEIHRvIGRlYWwgZm9yIGxpbmstbG9jYWwg YWRkcmVzc2VzPw0KDQpOby4gT24gUFBQIHlvdSBkb24ndCBuZWVkIERBRCBmb3IgTExBLiBCdXQg aW4gdGhlIGNvbnRleHQgb2YgIm9mZmVyaW5nIiBhZGRyZXNzZXMgdmlhIFJBIGFuZCBESENQdjYg dXNpbmcgdGhlIHNhbWUgcHJlZml4Li4uDQpXZWxsLCBvZiBjb3Vyc2UsIHlvdSBjYW4ndCBhY3R1 YWxseSAib2ZmZXIiIGEgc3BlY2lmaWMgYWRkcmVzcyB2aWEgUkEuIEJ1dCBpZiB5b3UgZW52aXNp b24gYSBDRSBSb3V0ZXIgdGhhdCB1c2VkIHRoZSBFVUktNjQgdG8gZGVyaXZlIGEgU0xBQUMgYWRk cmVzcyBmcm9tIGEgcHJlZml4IGFuZCB0aGVuIG9mZmVyaW5nIHRoYXQgaWRlbnRpY2FsIGFkZHJl c3MgdmlhIERIQ1B2Ni4uLg0KTm8uIEl0J3MganVzdCB0b28gaG9ycmlibGUuIEkgZG9uJ3Qgd2Fu dCB0byB0aGluayBhYm91dCBpdC4gDQogDQo+ID4+IEl0IHdvdWxkIGJlIHJhdGhlciBiZXR0ZXIg aWYgb25lICprbmV3KiB0aGUgQ1BFIHdvdWxkIGRvIFBEDQo+ID4+IGFuZCB0aGVuIGFzc2lnbiBp dHNlbGYgYW4gYWRkcmVzcyBvdXQgb2Ygb25lIG9mIHRoZSAvNjRzLiAgVGhhdCB3b3VsZA0KPiA+ PiBlbGltaW5hdGUgYSBidW5jaCBvZiByb3V0ZXMuDQo+ID4NCj4gPiBUUi0xMjQgUkcgcmVxdWly ZW1lbnRzIChyZWZlcmVuY2VkIGJ5IFRSLTE4NykgZG8gcmVxdWlyZSBzdXBwb3J0IGZvcg0KPiBJ QV9QRCBhbmQgdGhlIHVubnVtYmVyZWQgbW9kZWwuIFJGQyA3MDg0IGRvZXMgbm90IHJlcXVpcmUg c3VwcG9ydCBmb3INCj4gdGhlIHVubnVtYmVyZWQgbW9kZWw7IHRoZXJlIGl0J3Mgb3B0aW9uYWwu IEFuIElTUCBwcm9jdXJpbmcgQ0Ugcm91dGVycyBjYW4NCj4gdXNlIFRSLTEyNCBmb3IgYW4gUkZQ LiBCdXQgc3VjaCBhbiBJU1AgY2Fubm90IGRlcGVuZCBvbiAicmV0YWlsIiBDRSByb3V0ZXJzDQo+ IHN1cHBvcnRpbmcgdGhlIHVubnVtYmVyZWQgbW9kZWwuIFRoaXMgaXMgYmVjYXVzZSBDYWJsZUxh YnMgZVJvdXRlcnMgZG8NCj4gbm90IHN1cHBvcnQgdGhlIHVubnVtYmVyZWQgbW9kZWwsIGFuZCBl Um91dGVycyBuZWVkZWQgdG8gYmUgY29tcGxpYW50DQo+IHdpdGggUkZDIDcwODQuIEknbSBub3Qg c3VyZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSB1bm51bWJlcmVkIG1vZGVsIGluIG5vbi0NCj4gZVJv dXRlciAicmV0YWlsIiBDRSByb3V0ZXJzLg0KPiA+DQo+ID4+IFBhcnQgb2YgdGhlIHByb2JsZW0g aXMgdGhhdCBvbmUgY2FuJ3QgbmVjZXNzYXJpbHkNCj4gPj4gZGVwZW5kIHVwb24gdGhlIENQRSB0 byBkbyBESENQdjYgKC1QRCkgYXQgYWxsIQ0KPiANCj4gSXMgdGhpcyBiZWNhdXNlIGl0IG1pZ2h0 IGFjdHVhbGx5IGp1c3QgYmUgYSBob3N0IHRoYXQncyBjb25uZWN0aW5nPw0KDQpUaGUgcG9wdWxh dGlvbiBvZiBwZW9wbGUgd2FudGluZyB0byBkbyBQUFBvRSBmcm9tIGEgKG5vbiByb3V0ZXIpIGhv c3QgdG8gZ2V0IElQdjYganVzdCB0byB0aGF0IGhvc3QgaXMgZ29pbmcgdG8gYmUgcmVhbGx5LCBy ZWFsbHksIHJlYWxseSBzbWFsbC4gSnVtcGluZyB0aHJvdWdoIGhvb3BzIHRvIGNyZWF0ZSBhbiBh Y2Nlc3MgbmV0d29yayBhcmNoaXRlY3R1cmUgdGhhdCBzdXBwb3J0cyBib3RoIENFIHJvdXRlcnMg YW5kIGhvc3RzIGlzbid0IHdvcnRoIHRoZSB0cm91YmxlLiBJZiBhbiBJU1Agd2FudHMgdG8gc3Vw cGx5IElQdjYgb3ZlciBQUFBvRSBmb3IgYm90aCBob3N0cyBhbmQgQ0Ugcm91dGVycywgbXkgc3Vn Z2VzdGlvbiB3b3VsZCBiZSB0byBzdXBwbHkgc3BlY2lhbCBQUFBvRSBzb2Z0d2FyZSAoZm9yIGRv d25sb2FkIG9udG8gaG9zdHMpIHRoYXQgd2lsbCBsb29rIHRvIHRoZSBhY2Nlc3MgbmV0d29yayBs aWtlIGEgQ0Ugcm91dGVyIChpLmUuLCBhc2sgZm9yIElBX1BELCBldGMuKS4gRG9uJ3QgZXhwZWN0 IHRoZSBQUFBvRSBjbGllbnQgbmF0aXZlIHRvIHlvdXIgT1MgdG8gd29yay4NCkJhcmJhcmENCg== From nobody Tue Jul 25 10:49:58 2017 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 045E8131E67; Tue, 25 Jul 2017 10:49:57 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YSzQPUltOqG6; Tue, 25 Jul 2017 10:49:55 -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 C33FB131E6B; Tue, 25 Jul 2017 10:49:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9FA4E2009E; Tue, 25 Jul 2017 13:51:18 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AEB2A80243; Tue, 25 Jul 2017 13:49:53 -0400 (EDT) From: Michael Richardson To: IPv6 Ops WG , 6man WG Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.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.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:49:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >> TR-124 RG requirements (referenced by TR-187) do require support for= IA_PD and the unnumbered model. RFC 7084 does not require support for the = unnumbered model; there it's optional. An ISP procuring CE routers can use = TR-124 for an RFP. But such an ISP cannot depend on "retail" CE routers sup= porting the unnumbered model. This is because CableLabs eRouters do not sup= port the unnumbered model, and eRouters needed to be compliant with RFC 708= 4. I'm not sure of the status of the unnumbered model in non-eRouter "retai= l" CE routers. >>=20 >>> Part of the problem is that one can't necessarily >>> depend upon the CPE to do DHCPv6 (-PD) at all! Erik Kline wrote: > Is this because it might actually just be a host that's connecting? Exactly. It could be the case that it's just one host! The thing is that you can't tell at PPP auth time, nor can you tell at RA time. You can tell at DHCPv6 time if a PD it asked for. But, by that time it's too late for the BMS to change it's mind and not offer an address via SLAAC, or offer a prefix that is within the PD. Running PPPoE from your laptop/desktop is still readily supported under Linux, OSX and Windows. (I think that early PPPoE assumed that there would be multiple PPPoE sessions to get multiple PCs online in the home.) It would be nice if we could have perhaps three (maybe 4) flavours of PPPoE= /IPv6. Vanilla, Chocolate and Strawberry (and Neopolitan). Vanilla =3D=3D unnumbered, device does PD and picks an address. Chocolate =3D=3D number link with SLAAC (prefix is not excludable with 66= 03) Strawberry =3D=3D number link with DHCPv6=20 Neopolitan =3D=3D offer all of the above I wouldn't mind if the router told the BMS of it's intentions during PPP IP6CP time!=20=20=20 While you can pick a flavour via construction and RFP, that doesn't help if the customer provides his own router, or if the ISP is small enough to have supplier of the month problems. (All might be compliant, yet require different configurations. The customers could have more than one brand of device as well, because maybe one device is suspected to be flaky) In my BMS product, what exactly is done/offered is entirely determined by t= he Radius options that are provided. All I've really done is push the problem back up a level :-) Worse case you have to inject a /64 for the numbered link along with a /60 (or whatever) for the PD that was non-overlapping into the routing fabric, when a single /60 would have done. Having the PPP link unnumbered has some small security advantage in that it removes a small surface for attack. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll3hMEACgkQgItw+93Q 3WUyzAgAiLsZ3+jRCYuYRYyamgUcPzp8WmbOL2GKBQUpFgtfLzW2ZUmjt8FfT5pX hG8oxDAnMpIhsXoM+Jto7c2tHhtXa8Yi1pWsYn8yPBDVRRBs7oPxu3Zc+Rt2VLC/ 08Wl5U5rHmGnV9djJ/6F8rdgDe5K+Pn/iYBgnNojtI+OSolJJ9xQ0kfnZVqudE23 euvnmKO6+Lms3tj5rtpiOyVHIX0SgnH0Ah+zIeE4LAcgkmjZaGD3c7XZ0SOTQf8J 7YF7a+Qc6ad9rUbJKXUEFtI4uQ1xE/JpnFQcOAl/6FurQeQperaDWRfYmp32e7Vv jUK4Q0dMZi+zeEz2DBXIkPyCOEYbBA== =0llg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 25 10:56:37 2017 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 B9C4A131E6B; Tue, 25 Jul 2017 10:56:27 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sf-sA9Weqfmd; Tue, 25 Jul 2017 10:56: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 567C31241FC; Tue, 25 Jul 2017 10:56:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7741BE211; Tue, 25 Jul 2017 13:57:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 88A7A8070B; Tue, 25 Jul 2017 13:56:21 -0400 (EDT) From: Michael Richardson To: "STARK\, BARBARA H" cc: Erik Kline , IPv6 Ops WG , 6man WG Subject: Re: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.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.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:56:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable STARK, BARBARA H wrote: >> recommend the ISP pick a single method to use.=20 >>=20 >> You don't need DAD to deal for link-local addresses? > No. On PPP you don't need DAD for LLA. But in the context of "offerin= g" > addresses via RA and DHCPv6 using the same prefix...=20 > Well, of course, you can't actually "offer" a specific address via > RA. But if you envision a CE Router that used the EUI-64 to derive a > SLAAC address from a prefix and then offering that identical address > via DHCPv6...=20 > No. It's just too horrible. I don't want to think about it. The LL address "created" in PPP is well known at both ends. (They can be derived from other addresses, or can be random) It's created during IP6CP. It's not hard to code at all, although I haven= 't done that.=20=20 The router can otherwise wind up with a SLAAC (self-assigned) address, and= =20=20 then also a DHCPv6 address. The BMS chews up two neighbour cache entries. It would be nice to avoid thi= s.=20=20 >> Is this because it might actually just be a host that's connecting? > The population of people wanting to do PPPoE from a (non router) host > to get IPv6 just to that host is going to be really, really, really > small. Jumping through hoops to create an access network architecture > that supports both CE routers and hosts isn't worth the trouble. If an > ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my > suggestion would be to supply special PPPoE software (for download on= to > hosts) that will look to the access network like a CE router (i.e., a= sk > for IA_PD, etc.). Don't expect the PPPoE client native to your OS to > work.=20 But, it does work. Just like that. While routers are ubiquitous in the first world, they are *not* ubiquitous = in the developing world. Further, there are all sorts of interesting deployments in some places where there are open wifi mesh networks that cross entire communities and offer walled-garden access to local resources for free, but one can use PPPoE over these rather slow (500kbps) links with a provider (sometimes of your choice) for a public IP.=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAll3hkUACgkQgItw+93Q 3WVh5Af/YO8pZ1K8JO4Nee08eh8a17qr0jN52/Jfi1RXvS++eDgW9849NVAIMC4X 7QBeQCZ9IuSncaXuB7wXDn3PHiV3KvJXZ5ziVBEMAAb1G/SYdPP+LxSM3o8Y+HB7 icOkibZfvhisHbYoyGX9BTnjQ3Efr6qYt5xuFNe+Ei1LoUKaSbvlVIfcGr2aJLx5 ML7LwYWNSNavfD831N7Ew32CYOkc3GltBIpY41DOW2fw20WS6EB2VqmK932pSg9Z /kHGWrjrnL1js8HQ6AxbIDVBidzFASZolzaW7y/pOydaIBKppkWCkfwc6coZWenJ 4JSDkAO4XZiLlw4EHiughA/MwJDL6g== =GI0Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 26 14:44:16 2017 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 E0C21131D1E; Wed, 26 Jul 2017 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nbr6W6dpAcvY; Wed, 26 Jul 2017 14:44:06 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 7A761127601; Wed, 26 Jul 2017 14:44:06 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 80so126899687uas.0; Wed, 26 Jul 2017 14:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zZ3Ov/56Ah65Gzs4uTvD7PzNseoAOYdy+j9tWgQdNfg=; b=VnYPNR199q4V06cJYCQussjZFbUqoo9kNvcWwy/qHs2OwV76of7AMYzS/6PvJMyB35 5I2VoF+ZIDHo3amVc1wzECZdHRmn4aDQJn+2/FC76F/AM+QHBhh2PlAotFSEeMJCyG20 nyftw/hFcZPPcTWUeh/wFwGA/kRi5WqrB2ePopKD7zUKf0kciu8IpCxDfRR2GumsoMd/ swfvavbVl8mI2gUX2+4j6E/SR5nNycVKhXsJ46HQfeOMoZAo5/QO5p79XT5Zey0/r/QU j0P+YVO0BVCFgCCZpUQ500JTYe4V+QMe2i35M0bZQsBrBWRc9zGupHAHx/L1G/ZCAOD+ QuXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zZ3Ov/56Ah65Gzs4uTvD7PzNseoAOYdy+j9tWgQdNfg=; b=Ml9//as0pLHXIcK/Aqs5e1+I1H8LysLdLmvFFmepeLeVTk5Emwr/wfCE3xSXI4gCVN Z5hEw6eS0n1Y7PSn7k6TNPmzS+qt55eNnMf3CP3A8pDYi4MEh/zaESxHNBWo549pAVq+ Z1D597hVR7y3ikeY6OFmCwQJ5StxrKgRE1a3HGnuOpUXkdnRUyYLfPPnNzW7nu/kFdXj B7V7Na7laLd7Ek8tApNkHkYU0e7MUzdGd9AKBsHD5LxLcYEdSVSQhbKcjGc/hSBJmwfd v8/V/qr/jwE1Us96Z1o7ykg8WSYUdighsXYaIsAzsNs/feHZH/yoO04hsXRmyTtRFPLy qM4Q== X-Gm-Message-State: AIVw113MIMRV/pDlwM+/JNV7KDpGzHUuhiF6vfseOn5kr+Cn4o1flZfu 98SXb7PHBrvlqhnPPea9O0afihxR5w== X-Received: by 10.176.79.201 with SMTP id t9mr1572392uah.176.1501105445583; Wed, 26 Jul 2017 14:44:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Wed, 26 Jul 2017 14:44:04 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Wed, 26 Jul 2017 14:44:04 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Mark Smith Date: Thu, 27 Jul 2017 07:44:04 +1000 Message-ID: Subject: RE: [v6ops] PPPoE requirements (was Turning on IPv6 Routers) To: "STARK, BARBARA H" Cc: Michael Richardson , Erik Kline , 6man WG , IPv6 Ops WG Content-Type: multipart/alternative; boundary="f4030436501edabe1c05553f5815" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 21:44:09 -0000 --f4030436501edabe1c05553f5815 Content-Type: text/plain; charset="UTF-8" On 25 Jul. 2017 22:56, "STARK, BARBARA H" wrote: > >> For instance: *SHOULD* a PPPoE access router provide an address for the > >> CPE router link via RA or via DHCPv6? > >> If it does both, should it offer the same > >> address? > > > > I would recommend against configuring the BNG to use the same prefix for > SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would really > be needed. And I don't understand why anyone would want to. I would > recommend the ISP pick a single method to use. > > You don't need DAD to deal for link-local addresses? No. On PPP you don't need DAD for LLA. I think you now do per RFC8064/RFC7217. I don't really understand the motivation for avoiding DAD. It's a very marginal saving (1 packet) in comparison to the problems and time involved in troubleshooting duplicate addresses. In the scenario described, it can be much worse because there is likely a non-technical end-user and a helpdesk involved in what can be an intermittent and obscure fault (Helpdesks can be motivated to get the customer off the phone by saying "reboot the modem and call us back if you have more problems", which doesn't prevent the fault re-occurring.) I think absolute and consistent failure is much better and easier to troubleshoot than partial and intermittent failure when the cause is simple to determine and discover. But in the context of "offering" addresses via RA and DHCPv6 using the same prefix... Well, of course, you can't actually "offer" a specific address via RA. But if you envision a CE Router that used the EUI-64 to derive a SLAAC address from a prefix and then offering that identical address via DHCPv6... No. It's just too horrible. I don't want to think about it. > >> It would be rather better if one *knew* the CPE would do PD > >> and then assign itself an address out of one of the /64s. That would > >> eliminate a bunch of routes. > > > > TR-124 RG requirements (referenced by TR-187) do require support for > IA_PD and the unnumbered model. RFC 7084 does not require support for > the unnumbered model; there it's optional. An ISP procuring CE routers can > use TR-124 for an RFP. But such an ISP cannot depend on "retail" CE routers > supporting the unnumbered model. This is because CableLabs eRouters do > not support the unnumbered model, and eRouters needed to be compliant > with RFC 7084. I'm not sure of the status of the unnumbered model in non- > eRouter "retail" CE routers. > > > >> Part of the problem is that one can't necessarily > >> depend upon the CPE to do DHCPv6 (-PD) at all! > > Is this because it might actually just be a host that's connecting? The population of people wanting to do PPPoE from a (non router) host to get IPv6 just to that host is going to be really, really, really small. Jumping through hoops to create an access network architecture that supports both CE routers and hosts isn't worth the trouble. If an ISP wants to supply IPv6 over PPPoE for both hosts and CE routers, my suggestion would be to supply special PPPoE software (for download onto hosts) that will look to the access network like a CE router (i.e., ask for IA_PD, etc.). Don't expect the PPPoE client native to your OS to work. Barbara -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f4030436501edabe1c05553f5815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 25 Jul. 2017 22:56, "STARK, BARBARA H" <bs7652@att.com> wrote:
> >> For= instance: *SHOULD* a PPPoE access router provide an address for the
> >> CPE router link via RA or via DHCPv6?
> >> If it does both, should it o= ffer the same
> >> address?
> >
> > I would recommend against configuring the BNG to use the same pre= fix for
> SLAAC and IA_NA or IA_PD, or for IA_NA and IA_PD. Then DAD would reall= y
> be needed. And I don't understand why anyone would want to. I woul= d
> recommend the ISP pick a single method to use.
>
> You don't need DAD to deal for li= nk-local addresses?

No. On PPP you don't need DAD for LLA.

I think you now do per RF= C8064/RFC7217.

I don'= ;t really understand the motivation for avoiding DAD. It's a very margi= nal saving (1 packet) in comparison to the problems and time involved in tr= oubleshooting duplicate addresses.

In the scenario described, it can be much worse because there is= likely a non-technical end-user and a helpdesk involved in what can be an = intermittent and obscure fault (Helpdesks can be motivated to get the custo= mer off the phone by saying "reboot the modem and call us back if you = have more problems", which doesn't prevent the fault re-occurring.= )

I think absolute and c= onsistent failure is much better and easier to troubleshoot than partial an= d intermittent failure when the cause is simple to determine and discover.<= /div>

But in the context = of "offering" addresses via RA and DHCPv6 using the same prefix..= .
Well, of course, you can't actually "offer" a specific addres= s via RA. But if you envision a CE Router that used the EUI-64 to derive a = SLAAC address from a prefix and then offering that identical address via DH= CPv6...
No. It's just too horrible. I don't want to think about it.

> >> It would be rather better if one *knew* the CPE would do PD > >> and then assign itself an address out of one of the /64s.=C2= =A0 That would
> >> eliminate a bunch of routes.
> >
> > TR-124 RG requirements (referenced by TR-187) do require support = for
> IA_PD and the unnumbered model. RFC 7084 does not require support for<= br> > the unnumbered model; there it's optional. An ISP procuring CE rou= ters can
> use TR-124 for an RFP. But such an ISP cannot depend on "retail&q= uot; CE routers
> supporting the unnumbered model. This is because CableLabs eRouters do=
> not support the unnumbered model, and eRouters needed to be compliant<= br> > with RFC 7084. I'm not sure of the status of the unnumbered model = in non-
> eRouter "retail" CE routers.
> >
> >> Part of the problem is that one can't necessarily
> >> depend upon the CPE to do DHCPv6 (-PD) at all!
>
> Is this because it might actually just be a host that's connecting= ?

The population of people wanting to do PPPoE from a (non router) host= to get IPv6 just to that host is going to be really, really, really small.= Jumping through hoops to create an access network architecture that suppor= ts both CE routers and hosts isn't worth the trouble. If an ISP wants t= o supply IPv6 over PPPoE for both hosts and CE routers, my suggestion would= be to supply special PPPoE software (for download onto hosts) that will lo= ok to the access network like a CE router (i.e., ask for IA_PD, etc.). Don&= #39;t expect the PPPoE client native to your OS to work.
Barbara
-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

--f4030436501edabe1c05553f5815-- From nobody Thu Jul 27 10:01:58 2017 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 308ED131D1C for ; Thu, 27 Jul 2017 10:01:56 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 QoVb1xjOJtXa for ; Thu, 27 Jul 2017 10:01:48 -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 8D69E131D05 for <6man@ietf.org>; Thu, 27 Jul 2017 10:01:48 -0700 (PDT) Received: from [192.168.1.17] (unknown [84.47.113.16]) (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 2957681DA2; Thu, 27 Jul 2017 19:03:18 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Francis Dupont , Brian E Carpenter Cc: Tim Chown , Suresh Krishnan , "6man@ietf.org" <6man@ietf.org> References: <201707210740.v6L7edWt004994@givry.fdupont.fr> From: Fernando Gont Message-ID: <59632753-972a-f98c-a968-4a6365386844@si6networks.com> Date: Thu, 27 Jul 2017 19:46:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201707210740.v6L7edWt004994@givry.fdupont.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 17:01:56 -0000 On 07/21/2017 10:40 AM, Francis Dupont wrote: > When following a number it can get a specific meaning: in a postal > address bis (and ter) means something was inserted between two > numbers (usually between N and N + 2 as streets have an even side > and an odd side). > > In the IETF context I agree "bis" means more a revamp and major > changes come from consolidation with other related documents > published after. > > So in the RFC4941bis particular case the name is really arguable > and IMHO if the new mechanism is not backward compatible the bis > name should not be used. > > Now the I-D name is temporary so it should be more important to > discuss about its content... Fully agreed. At the end of the day, if the wg decides to adopt the document as a wg item, the filename can be renamed along with the rename to draft-ietf. 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 27 10:02:05 2017 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 60B93131D1C for ; Thu, 27 Jul 2017 10:01:57 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 RiNdbv_1GhQ0 for ; Thu, 27 Jul 2017 10:01:47 -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 9EA35131D01 for <6man@ietf.org>; Thu, 27 Jul 2017 10:01:47 -0700 (PDT) Received: from [192.168.1.17] (unknown [84.47.113.16]) (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 8D2858252A; Thu, 27 Jul 2017 19:03:14 +0200 (CEST) Subject: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids To: Francis Dupont Cc: "6man@ietf.org" <6man@ietf.org> References: <201707201234.v6KCYeup033384@givry.fdupont.fr> From: Fernando Gont Message-ID: <2c2f34aa-9900-52d5-5438-f3f6043de0a9@si6networks.com> Date: Thu, 27 Jul 2017 19:37:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <201707201234.v6KCYeup033384@givry.fdupont.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 17:01:57 -0000 On 07/20/2017 03:34 PM, Francis Dupont wrote: > In your previous mail you wrote: > >> On 07/19/2017 02:17 PM, Francis Dupont wrote: >> >> Among the list of RFCs to be progressed to full std is/was RFC4941 >> >> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"). >> > >> > => I even published a document explaining what I thought about the >> > whole idea (and I didn't change my mind). >> >> COuld you please provide a reference? > > => https://tools.ietf.org/html/draft-dupont-ipv6-rfc3041harmful-05 > Note my concerns were integrated into RFC 4941 so they should look > like pretty basic/old now. I simpatize with some of the comments. That said, temp addresses tend to be disabled in enterprise environments (for some of the reasons you note in your I-D)... and when it comes to DoS attacks, in the IPv6 world you'd fan a whole /64 as opposed to a single /128. >> > Now RFC4941bis is currently heavily deployed so it is far too soon >> > to try to obsolete it. >> >> I'm not necessarily thinking about obsoleting it. This is, say, an open >> question. I do think that you cannot move RFC4941 to STD, though. > > => I understand well it is a different question but IMHO your > ultimate goal is to obsolete RFC 4941 (with other words I should not > believe you if you answer you never had this idea :-). It certainly wasn't the original idea. Then it was an open question. And now I'd say that we should probably obsolete rfc4941, but of course that's up to the wg. >> > When I went to the mic at a previous IETF meeting some years ago >> > to ask the IPv6 specs to be raise to full standard with at first >> > the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left >> > at the border of the road I shan't be sad... >> >> I don't think RFC4941 meet the criteria for elevating a document to STD, >> though. > > => so at least we don't disagree... ;-) Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jul 28 02:23:37 2017 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 3D9AC129461 for ; Fri, 28 Jul 2017 02:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 o8P7zYcu9heH for ; Fri, 28 Jul 2017 02:23:32 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C66126E64 for ; Fri, 28 Jul 2017 02:23:32 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E1CE958C4BC for ; Fri, 28 Jul 2017 11:23:28 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C6262B0C6FC; Fri, 28 Jul 2017 11:23:28 +0200 (CEST) Date: Fri, 28 Jul 2017 11:23:28 +0200 From: Toerless Eckert To: ipv6@ietf.org Subject: rfc6164 vs rfc4291 question Message-ID: <20170728092328.GA4567@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 09:23:36 -0000 Why if rfc6164 not tracked as an update to rfc4291 given how it explicitly refers to not complying to RFC4291 specification (eg: non /64 interface identifiers) ? I also think to remember that one of the co-authors of rfc4291 said during praue 6man that documents that do this should be tracked as updates of rfc4291. Cheers Toerless From nobody Fri Jul 28 07:30:16 2017 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 C8A21131C9D for ; Fri, 28 Jul 2017 07:30:15 -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 tNHxRHRUjufy for ; Fri, 28 Jul 2017 07:30:14 -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 49AA113201E for ; Fri, 28 Jul 2017 07:30:09 -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 v6SEU7pj008146; Fri, 28 Jul 2017 07:30:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SEU2R4008082 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 28 Jul 2017 07:30:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 07:30:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 07:30:01 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFg== Date: Fri, 28 Jul 2017 14:30:01 +0000 Message-ID: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:30:16 -0000 Hi, I am seriously considering the use of fe80::/16 on a specific link laye= r so that the network part is 16 bits and the "host" part is 112 bits. Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the corresponding LL address is fe80:2001:db8:1:2::/16. The question is what would break if we did this? The link layer would know how to deal with it, but would the IPv6 layer be able to handle it? And, what about apps that deal with IPv6 LL's? Thanks - Fred From nobody Fri Jul 28 07:33:19 2017 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 DA4D3131D32 for ; Fri, 28 Jul 2017 07:33:16 -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 oB_xbJk8fXKN for ; Fri, 28 Jul 2017 07:33:15 -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 6A907131C9D for ; Fri, 28 Jul 2017 07:33:15 -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 v6SEXESJ037955; Fri, 28 Jul 2017 07:33:14 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SEX4q1037863 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 28 Jul 2017 07:33:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 07:33:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 07:33:04 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: fe80:: Thread-Topic: fe80:: Thread-Index: AdMHrhuWNQXHNxKxSiCCnKvkHd01Pw== Date: Fri, 28 Jul 2017 14:33:04 +0000 Message-ID: <8bf15e7af3b04edb8e678d40ea4ba38b@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:33:17 -0000 I don't think we ever reached conclusion as to what "fe80::" is. Is it a subnet router anycast address for the link-local prefix? Is it simply an ordinary LL unicast address? Is it a "nothing" that should be flagged as a bogon? Whatever the answer, RFC4291bis should say something about it. Thanks - Fred From nobody Fri Jul 28 08:09:27 2017 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 44076131566 for ; Fri, 28 Jul 2017 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wL41B4WyU1dS for ; Fri, 28 Jul 2017 08:09:23 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 A436D132030 for ; Fri, 28 Jul 2017 08:09:23 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 80so165363950uas.0 for ; Fri, 28 Jul 2017 08:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YIxPbTJ4uxCjyz8eCokZ05W9qacnx0dsTuuLP2sN1Mo=; b=EmgF1Oix3ftB96hQTaY8B2O4gkmSG+4H9oSJDCIUf2urUFCqOCLCUuH3qYlbDokx4M 5HchSb58s8F6YgvdVsE6mlGJNIurOrV6vCKBgJivUN1pos9PKag8dbpM2HkNJvkUOtjd Wn2T5kJ5JSYKeSiteeEysLvOlkYo1VY6xAdvylj8hHkbniN8U+uapylgh1qb5YVgCSxL lBwUY03aTJ2guJVkawdSfqSd1Cbu5OlWc1yQNgh1Ln05V3fSx7H13y04qNPZG6GipuEn Alh4t/2gx510wgyPja1x/YdlTNtT6/4kDdqRlBsO/COtRiPN+k7pLonTmGJp9vsfRC6y xGig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YIxPbTJ4uxCjyz8eCokZ05W9qacnx0dsTuuLP2sN1Mo=; b=XKnhKvzskXZhOV3SYGDq4mrKT+phHp8RCH6OGdbpysi1jDgiaxYCC2lX1NY6Z0vzhM IiN/Jflw57Wv54xJdnkzPaSQ97YR/IvlcYBZl3vbNjGIocgrx7F+exM0TG6UKntbd1sZ n/3UtRNdYo5sMvnCApx7P9z4U1uHzE45RWRLsPLIgVyIHEuxH/09VyqTntcksnj7NK1a BcykbaYBScblE0XJOsq8LJDdLMm93L1UGx945YfE5bIzb5YHzqIYIVmYzMhkkq48S8my 7yPPEg9n1lmOmefK6p0S59NU1myKLZVtLdzmBCDddP6sYQFidS15E19josc2u4H5vP+r PAZg== X-Gm-Message-State: AIVw11008md8NAa54VfT32QcsmXEHQhUAh4qJX+t91+P8PZ/U3zR2JVn 7527SLSSYRIBmkEctVkmAPYooxGNqF7f X-Received: by 10.159.59.89 with SMTP id j25mr5990689uah.155.1501254562648; Fri, 28 Jul 2017 08:09:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 28 Jul 2017 08:08:52 -0700 (PDT) In-Reply-To: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Sat, 29 Jul 2017 01:08:52 +1000 Message-ID: Subject: Re: fe80::/16 on specific link layers To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:09:25 -0000 Hi Fred, On 29 July 2017 at 00:30, Templin, Fred L wrote: > Hi, I am seriously considering the use of fe80::/16 on a specific link layer > so that the network part is 16 bits and the "host" part is 112 bits. > > Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the > corresponding LL address is fe80:2001:db8:1:2::/16. > > The question is what would break if we did this? The link layer would > know how to deal with it, but would the IPv6 layer be able to handle it? > And, what about apps that deal with IPv6 LL's? > I'll think a bit more about fe80::/16. To start with, here a draft which includes what I summarised about LLs. I think that fe80::/16 would conflict with both the current IANA fe80::/10, RFC4291 LL assignments and the fe80::/64 IPv6-over-foo link conventions we have. (I'd think it might be useful to keep the /10 through /64 for a random subnet ID like we have for ULAs i.e. globally unique link-local addresses, to avoid the scope/interface index requirement when using LL addresses within API sockets) "How to use IPv6 Link-Local Addresses in Applications" https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 Regards, Mark. From nobody Fri Jul 28 08:44:55 2017 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 B5AB3131C58 for ; Fri, 28 Jul 2017 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nMIJCHHz8hsm for ; Fri, 28 Jul 2017 08:44:47 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 4EECE131945 for ; Fri, 28 Jul 2017 08:44:47 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id w45so166484230uac.5 for ; Fri, 28 Jul 2017 08:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AY/ziBxN7NwwpQ3RkLiHg7Ja6mxu/D2pRsgwyk5Snk8=; b=MDQ8ep7MD/AliOXQP1g1lOfBQrVYB1SsL7MhuJxYeTP22ZADRX6rmJr0oZynXST4RI 0PitYcO4+4AHNIg8sLBdnvjZQWCGz36fTuIUTFSY3vL8OK05Tniev0TFfhPWUQcPYEFX 6AicuGHkvNaopI1F7r3CR83urahUh3ZBwRu4iyDEBHsCmgKQnRhn1lZB9dMeWutY1kty DKQ85lLDvnyB1mRZc2Zjvega3TTwv7w1W6QJGBvMm/VVL5KLVwOd6CN/moqP2+nN3pso kYt6bQW918c/i2YkqYwavhpiBpKNBonAo1DuPG/abbOyrOfcpgYsvvipMYG4OBkQNEcK qrJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AY/ziBxN7NwwpQ3RkLiHg7Ja6mxu/D2pRsgwyk5Snk8=; b=hGZMwkhMlz0mqXHKRWSIYWDF4FqQfmsfhqYPrB63/r7ySyMoidbnw3csMbR4i0N6JX veeGaAEXu+x7rjjre3wuwZZmQzJy4epjGzmov8apPW/kqMDxvnO8mGXa/rfq3+eaCQ9S QnGnnn9afVxc36MhzwXFVgBASRH//iXtPWypz8Jdv751ZMhh3gSNl0LZSW+kUF6YYkK7 kWsLRneYrhgX23wJbOSbiDuCONaDvP5OWnK3DO8BNrw9OKGcH0VaEK1Zf5uIaea19LfX IV+Z+VTVZq1fCpfdqciF954mmffO83uHMV2G3SFCCQrJyNRCELOSd+qwspE2HMNkGw9f HzrA== X-Gm-Message-State: AIVw112FHyBCX4Y1p0m3NFWIZkTdp9EriVu6pqbSgJhSgCX/xUDM0PFT e5mNpq2YeXH9UGaLE8XU/RJiueDBKQ== X-Received: by 10.31.84.130 with SMTP id i124mr4849625vkb.41.1501256686335; Fri, 28 Jul 2017 08:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 28 Jul 2017 08:44:15 -0700 (PDT) In-Reply-To: <8bf15e7af3b04edb8e678d40ea4ba38b@XCH15-06-08.nw.nos.boeing.com> References: <8bf15e7af3b04edb8e678d40ea4ba38b@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Sat, 29 Jul 2017 01:44:15 +1000 Message-ID: Subject: Re: fe80:: To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:44:49 -0000 On 29 July 2017 at 00:33, Templin, Fred L wrote: > I don't think we ever reached conclusion as to what "fe80::" is. Is it a > subnet router anycast address for the link-local prefix? Is it simply an > ordinary LL unicast address? Is it a "nothing" that should be flagged > as a bogon? > I think it is a subnet router anycast address. fe80::/64 (or perhaps fe80::/10) is only special because it is autoconfigured on every link, and therefore is an "anycast prefix" that happens to be present on every link. It is not special from the perspective of the sender. A sender to destination fe80::(/128) would expect the "closest" on-link router to be the one that responds, which is the one that responds to the ND NS quickest. I think one of the differences between IPv4 and IPv6 is that IPv4 only inadvertently supported "off-link anycast", meaning that the forwarding domain supported choosing the closest off-link destination, and it was possible to announce multiple versions of that destination into the forwarding domain, where as IPv6 supports both formal "on-link anycast" as well as "off-link anycast". Formal "on-link" anycast support means preferring the first rather than the last received ND NA (indicated by the Override flag), and not performing DAD for addresses that are flagged as anycast addresses. > Whatever the answer, RFC4291bis should say something about it. > A reference to RFC7094, "Architectural Considerations of IP Anycast", with a bit of referential or context setting text might do. Regards, Mark. From nobody Fri Jul 28 09:09:28 2017 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 233FC131C4F for ; Fri, 28 Jul 2017 09:09:27 -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 L1LWWaeDfvcO for ; Fri, 28 Jul 2017 09:09:25 -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 92393127869 for ; Fri, 28 Jul 2017 09:09:25 -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 v6SG9OYA064609; Fri, 28 Jul 2017 09:09:24 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SG9MCt064572 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 09:09:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 09:09:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 09:09:21 -0700 From: "Templin, Fred L" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFgAQRtEAAA5iobA= Date: Fri, 28 Jul 2017 16:09:21 +0000 Message-ID: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:09:27 -0000 SGkgTWFyaywNCg0KVGhhbmtzIGZvciB0aGUgZHJhZnQgcG9pbnRlci4gSSB0aGluayB0aGVyZSBp cyB2YWx1ZSBpbiBkb2N1bWVudGF0aW9uIHRoYXQNCmRpc2N1c3NlcyBMTHMuDQoNCkFib3V0IGZl ODA6Oi8xNiwgdGhhdCB3YXMgbXkgbW9kaWZpY2F0aW9uIG9mIFRvbSBIZXJiZXJ0J3MgcHJvcG9z YWwgYW5kDQp3YXMgbW90aXZhdGVkIGJ5IGEgZGVzaXJlIHRvIGhhdmUgZW1iZWRkZWQgcHJlZml4 ZXMgaW4gYSByZWFkYWJsZSBmb3JtLg0KVG9tJ3MgcHJvcG9zYWwgd2FzIHRvIHVzZSBmZTgwOjov MTAgYnV0IGluIHRoYXQgY2FzZSB0aGUgZW1iZWRkZWQgcHJlZml4DQppcyB1bnJlYWRhYmxlIHRv IGh1bWFucyBhbmQgbW9yZSBkaWZmaWN1bHQgdG8gcGFyc2UgZm9yIGltcGxlbWVudGF0aW9ucy4N Cg0KU28sIGFzIGxvbmcgYXMgZmU4MDo6LzE2IGlzIGNvcnJlY3RseSByZWNvZ25pemVkIGJ5IHRo ZSBzcGVjaWZpYyBsaW5rIGxheWVyLA0KSSB0aGluayB0aGUgcXVlc3Rpb24gYmVjb21lcyBvbmUg b2Ygd2hldGhlciB0aGUgSVB2NiBsYXllciBhbmQgYXBwcw0KY2FuIGhhbmRsZSBpdC4gQlRXLCB0 d28gYXBwcyB0aGF0IGNvbWUgdG8gbWluZCB0aGF0IGRlYWwgd2l0aCBMTHMgYXJlDQpwaW5nNiBh bmQgZGhjcHY2IGJ1dCBJIGFtIHN1cmUgdGhlcmUgYXJlIG1hbnkgb3RoZXJzLg0KDQpUaGFua3Mg LSBGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBTbWl0 aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAy OCwgMjAxNyA4OjA5IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQo+IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBmZTgwOjovMTYg b24gc3BlY2lmaWMgbGluayBsYXllcnMNCj4gDQo+IEhpIEZyZWQsDQo+IA0KPiBPbiAyOSBKdWx5 IDIwMTcgYXQgMDA6MzAsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bT4gd3JvdGU6DQo+ID4gSGksIEkgYW0gc2VyaW91c2x5IGNvbnNpZGVyaW5nIHRoZSB1c2Ugb2Yg ZmU4MDo6LzE2IG9uIGEgc3BlY2lmaWMgbGluayBsYXllcg0KPiA+IHNvIHRoYXQgdGhlIG5ldHdv cmsgcGFydCBpcyAxNiBiaXRzIGFuZCB0aGUgImhvc3QiIHBhcnQgaXMgMTEyIGJpdHMuDQo+ID4N Cj4gPiBUYWtpbmcgQUVSTyBmb3IgZXhhbXBsZSwgZm9yIHRoZSBJUHY2IHByZWZpeCAyMDAxOmRi ODoxOjI6Oi82NCB0aGUNCj4gPiBjb3JyZXNwb25kaW5nIExMIGFkZHJlc3MgaXMgZmU4MDoyMDAx OmRiODoxOjI6Oi8xNi4NCj4gPg0KPiA+IFRoZSBxdWVzdGlvbiBpcyB3aGF0IHdvdWxkIGJyZWFr IGlmIHdlIGRpZCB0aGlzPyBUaGUgbGluayBsYXllciB3b3VsZA0KPiA+IGtub3cgaG93IHRvIGRl YWwgd2l0aCBpdCwgYnV0IHdvdWxkIHRoZSBJUHY2IGxheWVyIGJlIGFibGUgdG8gaGFuZGxlIGl0 Pw0KPiA+IEFuZCwgd2hhdCBhYm91dCBhcHBzIHRoYXQgZGVhbCB3aXRoIElQdjYgTEwncz8NCj4g Pg0KPiANCj4gDQo+IEknbGwgdGhpbmsgYSBiaXQgbW9yZSBhYm91dCBmZTgwOjovMTYuDQo+IA0K PiBUbyBzdGFydCB3aXRoLCBoZXJlIGEgZHJhZnQgd2hpY2ggaW5jbHVkZXMgd2hhdCBJIHN1bW1h cmlzZWQgYWJvdXQNCj4gTExzLiBJIHRoaW5rIHRoYXQgZmU4MDo6LzE2IHdvdWxkIGNvbmZsaWN0 IHdpdGggYm90aCB0aGUgY3VycmVudCBJQU5BDQo+IGZlODA6Oi8xMCwgUkZDNDI5MSBMTCBhc3Np Z25tZW50cyBhbmQgdGhlIGZlODA6Oi82NCBJUHY2LW92ZXItZm9vIGxpbmsNCj4gY29udmVudGlv bnMgd2UgaGF2ZS4gKEknZCB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgdG8ga2VlcCB0aGUgLzEw DQo+IHRocm91Z2ggLzY0IGZvciBhIHJhbmRvbSBzdWJuZXQgSUQgbGlrZSB3ZSBoYXZlIGZvciBV TEFzIGkuZS4gZ2xvYmFsbHkNCj4gdW5pcXVlIGxpbmstbG9jYWwgYWRkcmVzc2VzLCB0byBhdm9p ZCB0aGUgc2NvcGUvaW50ZXJmYWNlIGluZGV4DQo+IHJlcXVpcmVtZW50IHdoZW4gdXNpbmcgTEwg YWRkcmVzc2VzIHdpdGhpbiBBUEkgc29ja2V0cykNCj4gDQo+ICJIb3cgdG8gdXNlIElQdjYgTGlu ay1Mb2NhbCBBZGRyZXNzZXMgaW4gQXBwbGljYXRpb25zIg0KPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc21pdGgtaXB2Ni1saW5rLWxvY2Fscy1hcHBzLTAwDQo+IA0KPiANCj4g UmVnYXJkcywNCj4gTWFyay4NCg0K From nobody Fri Jul 28 09:20:27 2017 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 D12E3131CCF for ; Fri, 28 Jul 2017 09:20:25 -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 iK2cfiisA8Zg for ; Fri, 28 Jul 2017 09:20:22 -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 CD54A124217 for ; Fri, 28 Jul 2017 09:20:18 -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 v6SGKHxj061586; Fri, 28 Jul 2017 09:20:18 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SGKEUB061557 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 09:20:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 09:20:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 09:20:14 -0700 From: "Templin, Fred L" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: fe80:: Thread-Topic: fe80:: Thread-Index: AdMHrhuWNQXHNxKxSiCCnKvkHd01PwARO5qAAA2MiuA= Date: Fri, 28 Jul 2017 16:20:14 +0000 Message-ID: References: <8bf15e7af3b04edb8e678d40ea4ba38b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:20:26 -0000 SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5 IDI4LCAyMDE3IDg6NDQgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4NCj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGZlODA6Og0K PiANCj4gT24gMjkgSnVseSAyMDE3IGF0IDAwOjMzLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+IEkgZG9uJ3QgdGhpbmsgd2UgZXZlciByZWFj aGVkIGNvbmNsdXNpb24gYXMgdG8gd2hhdCAiZmU4MDo6IiBpcy4gSXMgaXQgYQ0KPiA+IHN1Ym5l dCByb3V0ZXIgYW55Y2FzdCBhZGRyZXNzIGZvciB0aGUgbGluay1sb2NhbCBwcmVmaXg/IElzIGl0 IHNpbXBseSBhbg0KPiA+IG9yZGluYXJ5IExMIHVuaWNhc3QgYWRkcmVzcz8gSXMgaXQgYSAibm90 aGluZyIgdGhhdCBzaG91bGQgYmUgZmxhZ2dlZA0KPiA+IGFzIGEgYm9nb24/DQo+ID4NCj4gDQo+ IEkgdGhpbmsgaXQgaXMgYSBzdWJuZXQgcm91dGVyIGFueWNhc3QgYWRkcmVzcy4gZmU4MDo6LzY0 IChvciBwZXJoYXBzDQo+IGZlODA6Oi8xMCkgaXMgb25seSBzcGVjaWFsIGJlY2F1c2UgaXQgaXMg YXV0b2NvbmZpZ3VyZWQgb24gZXZlcnkgbGluaywNCj4gYW5kIHRoZXJlZm9yZSBpcyBhbiAiYW55 Y2FzdCBwcmVmaXgiIHRoYXQgaGFwcGVucyB0byBiZSBwcmVzZW50IG9uDQo+IGV2ZXJ5IGxpbmsu DQoNCkkgY2FuIGxpdmUgd2l0aCB0aGF0LCBidXQgc29tZSBkb2N1bWVudGF0aW9uIG5lZWRzIHRv IHNheSBzb21ldGhpbmcNCnNvbWV3aGVyZSBhYm91dCBmZTgwOjovMTI4Lg0KDQpEb2VzIHRoaXMg bWF0Y2ggd2l0aCB3aGF0IGV2ZXJ5b25lIGVsc2UgaXMgdGhpbmtpbmc/DQoNClRoYW5rcyAtIEZy ZWQNCg0KPiBJdCBpcyBub3Qgc3BlY2lhbCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgc2Vu ZGVyLiBBIHNlbmRlciB0bw0KPiBkZXN0aW5hdGlvbiBmZTgwOjooLzEyOCkgd291bGQgZXhwZWN0 IHRoZSAiY2xvc2VzdCIgb24tbGluayByb3V0ZXIgdG8NCj4gYmUgdGhlIG9uZSB0aGF0IHJlc3Bv bmRzLCB3aGljaCBpcyB0aGUgb25lIHRoYXQgcmVzcG9uZHMgdG8gdGhlIE5EIE5TDQo+IHF1aWNr ZXN0Lg0KPiANCj4gSSB0aGluayBvbmUgb2YgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gSVB2NCBh bmQgSVB2NiBpcyB0aGF0IElQdjQgb25seQ0KPiBpbmFkdmVydGVudGx5IHN1cHBvcnRlZCAib2Zm LWxpbmsgYW55Y2FzdCIsIG1lYW5pbmcgdGhhdCB0aGUNCj4gZm9yd2FyZGluZyBkb21haW4gc3Vw cG9ydGVkIGNob29zaW5nIHRoZSBjbG9zZXN0IG9mZi1saW5rIGRlc3RpbmF0aW9uLA0KPiBhbmQg aXQgd2FzIHBvc3NpYmxlIHRvIGFubm91bmNlIG11bHRpcGxlIHZlcnNpb25zIG9mIHRoYXQgZGVz dGluYXRpb24NCj4gaW50byB0aGUgZm9yd2FyZGluZyBkb21haW4sIHdoZXJlIGFzIElQdjYgc3Vw cG9ydHMgYm90aCBmb3JtYWwNCj4gIm9uLWxpbmsgYW55Y2FzdCIgYXMgd2VsbCBhcyAib2ZmLWxp bmsgYW55Y2FzdCIuDQo+IA0KPiBGb3JtYWwgIm9uLWxpbmsiIGFueWNhc3Qgc3VwcG9ydCBtZWFu cyBwcmVmZXJyaW5nIHRoZSBmaXJzdCByYXRoZXINCj4gdGhhbiB0aGUgbGFzdCByZWNlaXZlZCBO RCBOQSAoaW5kaWNhdGVkIGJ5IHRoZSBPdmVycmlkZSBmbGFnKSwgYW5kIG5vdA0KPiBwZXJmb3Jt aW5nIERBRCBmb3IgYWRkcmVzc2VzIHRoYXQgYXJlIGZsYWdnZWQgYXMgYW55Y2FzdCBhZGRyZXNz ZXMuDQo+IA0KPiA+IFdoYXRldmVyIHRoZSBhbnN3ZXIsIFJGQzQyOTFiaXMgc2hvdWxkIHNheSBz b21ldGhpbmcgYWJvdXQgaXQuDQo+ID4NCj4gDQo+IEEgcmVmZXJlbmNlIHRvIFJGQzcwOTQsICJB cmNoaXRlY3R1cmFsIENvbnNpZGVyYXRpb25zIG9mIElQIEFueWNhc3QiLA0KPiB3aXRoIGEgYml0 IG9mIHJlZmVyZW50aWFsIG9yIGNvbnRleHQgc2V0dGluZyB0ZXh0IG1pZ2h0IGRvLg0KPiANCj4g UmVnYXJkcywNCj4gTWFyay4NCg0K From nobody Fri Jul 28 09:44:08 2017 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 5FDEB131CDC for ; Fri, 28 Jul 2017 09:44:06 -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 RO7O-fXY6Xtd for ; Fri, 28 Jul 2017 09:44:04 -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 6469D12EC4B for ; Fri, 28 Jul 2017 09:44:04 -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 v6SGi31u034579; Fri, 28 Jul 2017 09:44:03 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SGht1e034374 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 09:43:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 09:43:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 09:43:54 -0700 From: "Templin, Fred L" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFgAQRtEAAAt5VXA= Date: Fri, 28 Jul 2017 16:43:54 +0000 Message-ID: <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:44:06 -0000 SGkgYWdhaW4gTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBN YXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5 LCBKdWx5IDI4LCAyMDE3IDg6MDkgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGZl ODA6Oi8xNiBvbiBzcGVjaWZpYyBsaW5rIGxheWVycw0KPiANCj4gSGkgRnJlZCwNCj4gDQo+IE9u IDI5IEp1bHkgMjAxNyBhdCAwMDozMCwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPiB3cm90ZToNCj4gPiBIaSwgSSBhbSBzZXJpb3VzbHkgY29uc2lkZXJpbmcgdGhl IHVzZSBvZiBmZTgwOjovMTYgb24gYSBzcGVjaWZpYyBsaW5rIGxheWVyDQo+ID4gc28gdGhhdCB0 aGUgbmV0d29yayBwYXJ0IGlzIDE2IGJpdHMgYW5kIHRoZSAiaG9zdCIgcGFydCBpcyAxMTIgYml0 cy4NCj4gPg0KPiA+IFRha2luZyBBRVJPIGZvciBleGFtcGxlLCBmb3IgdGhlIElQdjYgcHJlZml4 IDIwMDE6ZGI4OjE6Mjo6LzY0IHRoZQ0KPiA+IGNvcnJlc3BvbmRpbmcgTEwgYWRkcmVzcyBpcyBm ZTgwOjIwMDE6ZGI4OjE6Mjo6LzE2Lg0KPiA+DQo+ID4gVGhlIHF1ZXN0aW9uIGlzIHdoYXQgd291 bGQgYnJlYWsgaWYgd2UgZGlkIHRoaXM/IFRoZSBsaW5rIGxheWVyIHdvdWxkDQo+ID4ga25vdyBo b3cgdG8gZGVhbCB3aXRoIGl0LCBidXQgd291bGQgdGhlIElQdjYgbGF5ZXIgYmUgYWJsZSB0byBo YW5kbGUgaXQ/DQo+ID4gQW5kLCB3aGF0IGFib3V0IGFwcHMgdGhhdCBkZWFsIHdpdGggSVB2NiBM TCdzPw0KPiA+DQo+IA0KPiANCj4gSSdsbCB0aGluayBhIGJpdCBtb3JlIGFib3V0IGZlODA6Oi8x Ni4NCg0KQWN0dWFsbHksIEkgdGhpbmsgd2UgZG9uJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBmZTgw OjovMTYuIEkganVzdCByZWFsaXplZA0KdGhhdCB3ZSBjYW4gdXNlIGZlODA6Oi8xMCBhbmQgdGhl biB3aGVuIHdlIGVtYmVkIHRoZSBJUHY2IHByZWZpeCB3ZQ0KY2FuIHNpbXBseSBwcmVwZW5kIDYg JzAnIGJpdHMgc28gdGhhdCB0aGUgYWN0dWFsIHByZWZpeCBiZWdpbnMgYXQgYml0IDE2IHNvDQp0 aGF0IGl0IHByaW50cyBhbmQgcGFyc2VzIG5pY2VseS4gU28sIHdlIHdvdWxkIGhhdmU6DQoNCmZl ODA6OjIwMDE6ZGI4OjE6MTo6LzEwDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBUbyBzdGFydCB3aXRo LCBoZXJlIGEgZHJhZnQgd2hpY2ggaW5jbHVkZXMgd2hhdCBJIHN1bW1hcmlzZWQgYWJvdXQNCj4g TExzLiBJIHRoaW5rIHRoYXQgZmU4MDo6LzE2IHdvdWxkIGNvbmZsaWN0IHdpdGggYm90aCB0aGUg Y3VycmVudCBJQU5BDQo+IGZlODA6Oi8xMCwgUkZDNDI5MSBMTCBhc3NpZ25tZW50cyBhbmQgdGhl IGZlODA6Oi82NCBJUHY2LW92ZXItZm9vIGxpbmsNCj4gY29udmVudGlvbnMgd2UgaGF2ZS4gKEkn ZCB0aGluayBpdCBtaWdodCBiZSB1c2VmdWwgdG8ga2VlcCB0aGUgLzEwDQo+IHRocm91Z2ggLzY0 IGZvciBhIHJhbmRvbSBzdWJuZXQgSUQgbGlrZSB3ZSBoYXZlIGZvciBVTEFzIGkuZS4gZ2xvYmFs bHkNCj4gdW5pcXVlIGxpbmstbG9jYWwgYWRkcmVzc2VzLCB0byBhdm9pZCB0aGUgc2NvcGUvaW50 ZXJmYWNlIGluZGV4DQo+IHJlcXVpcmVtZW50IHdoZW4gdXNpbmcgTEwgYWRkcmVzc2VzIHdpdGhp biBBUEkgc29ja2V0cykNCj4gDQo+ICJIb3cgdG8gdXNlIElQdjYgTGluay1Mb2NhbCBBZGRyZXNz ZXMgaW4gQXBwbGljYXRpb25zIg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c21pdGgtaXB2Ni1saW5rLWxvY2Fscy1hcHBzLTAwDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gTWFy ay4NCg0K From nobody Fri Jul 28 10:00:57 2017 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 CA82412EB5D for ; Fri, 28 Jul 2017 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yO7Y3l9SBdf2 for ; Fri, 28 Jul 2017 10:00:53 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 25AED131CDD for ; Fri, 28 Jul 2017 10:00:48 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id f9so168345652uaf.4 for ; Fri, 28 Jul 2017 10:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UtYiyd7NmUrfoz5dUjP5fTnPT1pqu8HI6yt5jnm1gHs=; b=mQzNDqsRIbAhpSuq9+RZzDcrueLQEcyw9/vPFuZCXIsdYdmo3ANJSJ30/FJKZGmiOh d+9BFtO9jgy7XEyHwavQOpPQ/K5zv2TgH+9mnk+gt3ub5neG8YjfdT0OEK3VFatWYbfg uXougDyRdKfXld2a/vSRot2pUNFSekEqib22ROWpQy5FC4oZRd8qtKEenycisuxCPBEG PpcMiyjEpSfMGKU/cM+gmVSIgFSVviJ+yz1n+GBljrpCDnRFd6aGcf0wB9Oj4t804vv8 l0QhSEtH+6DoZbWe5yd5tVY3VgJ151biLvEMRXHaaa2/KiLFhannnFF5zdi/pJaiPcWC 3U/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UtYiyd7NmUrfoz5dUjP5fTnPT1pqu8HI6yt5jnm1gHs=; b=QMW3bMUjEtSVCCec6f3aXdnfz2eoJb3NzuYLPOscyRW8PGFzUsWexVNzO8krFUhU/Y +R4iAXA34SeN8U5fT8bAAFaoiqU96SAUI3Ajytz1A5aWmLBysDXTYu0fZBBRB6kILhcz t1GoRqWSBs+MzlDNnNF9aCpyZl2Or80g7Rct9WEjBc837+CluJskwMLfmWIIU8AZBKgJ pdazgYPhDOC4ZxqflBRAdcEkQVTHYmmi3ETlZNKy52hZwM8dILUC31xnzPk7XnjZ+vEC gFYUsNprpCfNgN2JrkYCfbgBI12ZZeJg3t8zcxh7U7gDC9eFROVkTUkX89HdyVh5opua L+uQ== X-Gm-Message-State: AIVw113WvwXVGZBc4+GqLWjMAV8jkTrRKjKGu7C9all4/hQE2mDykid+ DLs2Dwpg/WbuuJZF8IU9msGZIv9Jjg== X-Received: by 10.159.53.36 with SMTP id o33mr6086017uao.95.1501261247267; Fri, 28 Jul 2017 10:00:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 28 Jul 2017 10:00:16 -0700 (PDT) In-Reply-To: <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Sat, 29 Jul 2017 03:00:16 +1000 Message-ID: Subject: Re: fe80::/16 on specific link layers To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:00:55 -0000 On 29 July 2017 at 02:43, Templin, Fred L wrote: > Hi again Mark, > >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Friday, July 28, 2017 8:09 AM >> To: Templin, Fred L >> Cc: ipv6@ietf.org >> Subject: Re: fe80::/16 on specific link layers >> >> Hi Fred, >> >> On 29 July 2017 at 00:30, Templin, Fred L wrote: >> > Hi, I am seriously considering the use of fe80::/16 on a specific link layer >> > so that the network part is 16 bits and the "host" part is 112 bits. >> > >> > Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the >> > corresponding LL address is fe80:2001:db8:1:2::/16. >> > >> > The question is what would break if we did this? The link layer would >> > know how to deal with it, but would the IPv6 layer be able to handle it? >> > And, what about apps that deal with IPv6 LL's? >> > >> >> >> I'll think a bit more about fe80::/16. > > Actually, I think we don't have to worry about fe80::/16. I just realized > that we can use fe80::/10 and then when we embed the IPv6 prefix we > can simply prepend 6 '0' bits so that the actual prefix begins at bit 16 so > that it prints and parses nicely. So, we would have: > > fe80::2001:db8:1:1::/10 > The trouble is that per RFC4291, the bits between FE80::/10 and FE80::/64 are to currently be all zeros. https://tools.ietf.org/html/rfc4291#section-2.5.6 Admittedly I'm not sure where're you're putting 2001:db8:1:1, because there are multiple "::'s. If it is after /64, then it's fine. Regards, Mark. > Thanks - Fred > >> To start with, here a draft which includes what I summarised about >> LLs. I think that fe80::/16 would conflict with both the current IANA >> fe80::/10, RFC4291 LL assignments and the fe80::/64 IPv6-over-foo link >> conventions we have. (I'd think it might be useful to keep the /10 >> through /64 for a random subnet ID like we have for ULAs i.e. globally >> unique link-local addresses, to avoid the scope/interface index >> requirement when using LL addresses within API sockets) >> >> "How to use IPv6 Link-Local Addresses in Applications" >> https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 >> >> >> Regards, >> Mark. > From nobody Fri Jul 28 10:04:54 2017 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 3A654131CC0 for ; Fri, 28 Jul 2017 10:04: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, 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 f5cV9jQ3rv33 for ; Fri, 28 Jul 2017 10:04:51 -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 856E1131748 for ; Fri, 28 Jul 2017 10:04:51 -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 v6SH4oWw003713; Fri, 28 Jul 2017 10:04:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SH4i7c003229 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 10:04:44 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 10:04:43 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 10:04:43 -0700 From: "Templin, Fred L" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFgAQRtEAAAt5VXD//8NVAIAAdJow Date: Fri, 28 Jul 2017 17:04:43 +0000 Message-ID: <54876ee10ca2468bb493bb497a8bdcc9@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:04:53 -0000 SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5 IDI4LCAyMDE3IDEwOjAwIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBmZTgwOjov MTYgb24gc3BlY2lmaWMgbGluayBsYXllcnMNCj4gDQo+IE9uIDI5IEp1bHkgMjAxNyBhdCAwMjo0 MywgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4g PiBIaSBhZ2FpbiBNYXJrLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPiA+ PiBTZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgODowOSBBTQ0KPiA+PiBUbzogVGVtcGxpbiwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+PiBDYzogaXB2NkBpZXRmLm9y Zw0KPiA+PiBTdWJqZWN0OiBSZTogZmU4MDo6LzE2IG9uIHNwZWNpZmljIGxpbmsgbGF5ZXJzDQo+ ID4+DQo+ID4+IEhpIEZyZWQsDQo+ID4+DQo+ID4+IE9uIDI5IEp1bHkgMjAxNyBhdCAwMDozMCwg VGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPj4g PiBIaSwgSSBhbSBzZXJpb3VzbHkgY29uc2lkZXJpbmcgdGhlIHVzZSBvZiBmZTgwOjovMTYgb24g YSBzcGVjaWZpYyBsaW5rIGxheWVyDQo+ID4+ID4gc28gdGhhdCB0aGUgbmV0d29yayBwYXJ0IGlz IDE2IGJpdHMgYW5kIHRoZSAiaG9zdCIgcGFydCBpcyAxMTIgYml0cy4NCj4gPj4gPg0KPiA+PiA+ IFRha2luZyBBRVJPIGZvciBleGFtcGxlLCBmb3IgdGhlIElQdjYgcHJlZml4IDIwMDE6ZGI4OjE6 Mjo6LzY0IHRoZQ0KPiA+PiA+IGNvcnJlc3BvbmRpbmcgTEwgYWRkcmVzcyBpcyBmZTgwOjIwMDE6 ZGI4OjE6Mjo6LzE2Lg0KPiA+PiA+DQo+ID4+ID4gVGhlIHF1ZXN0aW9uIGlzIHdoYXQgd291bGQg YnJlYWsgaWYgd2UgZGlkIHRoaXM/IFRoZSBsaW5rIGxheWVyIHdvdWxkDQo+ID4+ID4ga25vdyBo b3cgdG8gZGVhbCB3aXRoIGl0LCBidXQgd291bGQgdGhlIElQdjYgbGF5ZXIgYmUgYWJsZSB0byBo YW5kbGUgaXQ/DQo+ID4+ID4gQW5kLCB3aGF0IGFib3V0IGFwcHMgdGhhdCBkZWFsIHdpdGggSVB2 NiBMTCdzPw0KPiA+PiA+DQo+ID4+DQo+ID4+DQo+ID4+IEknbGwgdGhpbmsgYSBiaXQgbW9yZSBh Ym91dCBmZTgwOjovMTYuDQo+ID4NCj4gPiBBY3R1YWxseSwgSSB0aGluayB3ZSBkb24ndCBoYXZl IHRvIHdvcnJ5IGFib3V0IGZlODA6Oi8xNi4gSSBqdXN0IHJlYWxpemVkDQo+ID4gdGhhdCB3ZSBj YW4gdXNlIGZlODA6Oi8xMCBhbmQgdGhlbiB3aGVuIHdlIGVtYmVkIHRoZSBJUHY2IHByZWZpeCB3 ZQ0KPiA+IGNhbiBzaW1wbHkgcHJlcGVuZCA2ICcwJyBiaXRzIHNvIHRoYXQgdGhlIGFjdHVhbCBw cmVmaXggYmVnaW5zIGF0IGJpdCAxNiBzbw0KPiA+IHRoYXQgaXQgcHJpbnRzIGFuZCBwYXJzZXMg bmljZWx5LiBTbywgd2Ugd291bGQgaGF2ZToNCj4gPg0KPiA+IGZlODA6OjIwMDE6ZGI4OjE6MTo6 LzEwDQo+ID4NCj4gDQo+IFRoZSB0cm91YmxlIGlzIHRoYXQgcGVyIFJGQzQyOTEsIHRoZSBiaXRz IGJldHdlZW4gRkU4MDo6LzEwIGFuZA0KPiBGRTgwOjovNjQgYXJlIHRvIGN1cnJlbnRseSBiZSBh bGwgemVyb3MuDQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI5MSNzZWN0 aW9uLTIuNS42DQoNCkJ1dCwgY2FuIHRoYXQgYmUgb3ZlcnJpZGRlbiBieSBhbiBJUHY2LW92ZXIt Zm9vIGRvY3VtZW50Pw0KIA0KPiBBZG1pdHRlZGx5IEknbSBub3Qgc3VyZSB3aGVyZSdyZSB5b3Un cmUgcHV0dGluZyAyMDAxOmRiODoxOjEsIGJlY2F1c2UNCj4gdGhlcmUgYXJlIG11bHRpcGxlICI6 OidzLiBJZiBpdCBpcyBhZnRlciAvNjQsIHRoZW4gaXQncyBmaW5lLg0KDQpNeSBtaXN0YWtlIC0g aXQgc2hvdWxkIGhhdmUgc2FpZCBmZTgwOjIwMDE6ZGI4OjE6MTo6LzEwIChpLmUuLCBvbmx5IG9u ZSAiOjoiKS4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IA0KPiBSZWdhcmRzLA0KPiBNYXJrLg0KPiAN Cj4gDQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4+IFRvIHN0YXJ0IHdpdGgsIGhlcmUgYSBk cmFmdCB3aGljaCBpbmNsdWRlcyB3aGF0IEkgc3VtbWFyaXNlZCBhYm91dA0KPiA+PiBMTHMuIEkg dGhpbmsgdGhhdCBmZTgwOjovMTYgd291bGQgY29uZmxpY3Qgd2l0aCBib3RoIHRoZSBjdXJyZW50 IElBTkENCj4gPj4gZmU4MDo6LzEwLCBSRkM0MjkxIExMIGFzc2lnbm1lbnRzIGFuZCB0aGUgZmU4 MDo6LzY0IElQdjYtb3Zlci1mb28gbGluaw0KPiA+PiBjb252ZW50aW9ucyB3ZSBoYXZlLiAoSSdk IHRoaW5rIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBrZWVwIHRoZSAvMTANCj4gPj4gdGhyb3VnaCAv NjQgZm9yIGEgcmFuZG9tIHN1Ym5ldCBJRCBsaWtlIHdlIGhhdmUgZm9yIFVMQXMgaS5lLiBnbG9i YWxseQ0KPiA+PiB1bmlxdWUgbGluay1sb2NhbCBhZGRyZXNzZXMsIHRvIGF2b2lkIHRoZSBzY29w ZS9pbnRlcmZhY2UgaW5kZXgNCj4gPj4gcmVxdWlyZW1lbnQgd2hlbiB1c2luZyBMTCBhZGRyZXNz ZXMgd2l0aGluIEFQSSBzb2NrZXRzKQ0KPiA+Pg0KPiA+PiAiSG93IHRvIHVzZSBJUHY2IExpbmst TG9jYWwgQWRkcmVzc2VzIGluIEFwcGxpY2F0aW9ucyINCj4gPj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNtaXRoLWlwdjYtbGluay1sb2NhbHMtYXBwcy0wMA0KPiA+Pg0KPiA+ Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBNYXJrLg0KPiA+DQoNCg== From nobody Fri Jul 28 10:31:37 2017 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 2A94713229B for ; Fri, 28 Jul 2017 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3gDb8-cYEpsE for ; Fri, 28 Jul 2017 10:31:35 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 7E9D61321AB for ; Fri, 28 Jul 2017 10:31:35 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k43so132011067uaf.3 for ; Fri, 28 Jul 2017 10:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9gAYjvwuuXzc1fTj1mbLSEYo/BLtxucHN7I5McHMiO4=; b=rLNQYRn4UwybH8kqAaKsFk4qjwCEWcEEsWMNnXjA0vb6WBH46RyS2Jx0THW7/Q4vxJ Fe1cOTZ5PViC7iuqxVevi6U1758BqtMlh66ccMn79Hu7BUAQjYfhHU0sevdiT/HYwO8U RaM5ZNNsEA6DebvhaeYrp0n82wC1wIQVODLudwQvesPBnDZ+flz9YHdl8z4tsm0LgCgh tr31WgbaRcNFWnZTykODkjQel4axFq45wLHZGvnSHGpVf6j+pOoo86gqxU1bMaUWQnpa oEjXWwGUfIyJwgHtAAI3OQzEgO9bF7V5z7KURKJI1ZGZOk3wzY/hLwaltdfektm9Wv1A DQdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9gAYjvwuuXzc1fTj1mbLSEYo/BLtxucHN7I5McHMiO4=; b=r/jbR8dNyGr/PO4rX0IRo76Oqlup0MDYumcPwsgdW8FUyR5tZSJm5efNn6rOTRgaFY Y5dwpm6UQWnz9Yd6LwiEGvLyF8z56HYsii7goys5gK0Fz42CfL0ByDS3dP0mtk3LG6if 6OLYH1PWVUpEWJblBbQqKM4zPSSQUeo8addNCb15HTjvyUqBkP/K6ikbcTvcQgHdtQQa gDDOr2QGqNyz2WiGRTl0w9ppY/cesYRcFlMBxgsPEflO2htVX09/LTIfowy4Lsq2GsJu pfCegB+vbciu58Jq/N0SkrEme++QKz8BLws+Lc7NFKYovs3+/dipHZeeoyorBArosEf0 LoAw== X-Gm-Message-State: AIVw110xLB2UiGW+nbzTDvSCR+r4gTuRFJiCzd4XHduillkOwP5OOOpO QGTwGx+ybp7fRCiHnPNXlRtUashSYQ== X-Received: by 10.176.79.201 with SMTP id t9mr5818479uah.176.1501263094477; Fri, 28 Jul 2017 10:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 28 Jul 2017 10:31:04 -0700 (PDT) In-Reply-To: <54876ee10ca2468bb493bb497a8bdcc9@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> <54876ee10ca2468bb493bb497a8bdcc9@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Sat, 29 Jul 2017 03:31:04 +1000 Message-ID: Subject: Re: fe80::/16 on specific link layers To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:31:37 -0000 On 29 July 2017 at 03:04, Templin, Fred L wrote: > Hi Mark, > >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Friday, July 28, 2017 10:00 AM >> To: Templin, Fred L >> Cc: ipv6@ietf.org >> Subject: Re: fe80::/16 on specific link layers >> >> On 29 July 2017 at 02:43, Templin, Fred L wrote: >> > Hi again Mark, >> > >> >> -----Original Message----- >> >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> >> Sent: Friday, July 28, 2017 8:09 AM >> >> To: Templin, Fred L >> >> Cc: ipv6@ietf.org >> >> Subject: Re: fe80::/16 on specific link layers >> >> >> >> Hi Fred, >> >> >> >> On 29 July 2017 at 00:30, Templin, Fred L wrote: >> >> > Hi, I am seriously considering the use of fe80::/16 on a specific link layer >> >> > so that the network part is 16 bits and the "host" part is 112 bits. >> >> > >> >> > Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the >> >> > corresponding LL address is fe80:2001:db8:1:2::/16. >> >> > >> >> > The question is what would break if we did this? The link layer would >> >> > know how to deal with it, but would the IPv6 layer be able to handle it? >> >> > And, what about apps that deal with IPv6 LL's? >> >> > >> >> >> >> >> >> I'll think a bit more about fe80::/16. >> > >> > Actually, I think we don't have to worry about fe80::/16. I just realized >> > that we can use fe80::/10 and then when we embed the IPv6 prefix we >> > can simply prepend 6 '0' bits so that the actual prefix begins at bit 16 so >> > that it prints and parses nicely. So, we would have: >> > >> > fe80::2001:db8:1:1::/10 >> > >> >> The trouble is that per RFC4291, the bits between FE80::/10 and >> FE80::/64 are to currently be all zeros. >> >> https://tools.ietf.org/html/rfc4291#section-2.5.6 > > But, can that be overridden by an IPv6-over-foo document? I don't think it can be, the text says nothing about exceptions being allowed via IPv6-over-foo documents. I don't think there is any ambiguity or room for link specific formats in "Link-Local addresses have the following format". I'd think a link-type-specific RFC would have trouble reaching consensus on updating that text. A more general RFC that is not link type specific would probably have a better chance. Regards, Mark. > >> Admittedly I'm not sure where're you're putting 2001:db8:1:1, because >> there are multiple "::'s. If it is after /64, then it's fine. > > My mistake - it should have said fe80:2001:db8:1:1::/10 (i.e., only one "::"). > > Thanks - Fred > >> >> Regards, >> Mark. >> >> >> > Thanks - Fred >> > >> >> To start with, here a draft which includes what I summarised about >> >> LLs. I think that fe80::/16 would conflict with both the current IANA >> >> fe80::/10, RFC4291 LL assignments and the fe80::/64 IPv6-over-foo link >> >> conventions we have. (I'd think it might be useful to keep the /10 >> >> through /64 for a random subnet ID like we have for ULAs i.e. globally >> >> unique link-local addresses, to avoid the scope/interface index >> >> requirement when using LL addresses within API sockets) >> >> >> >> "How to use IPv6 Link-Local Addresses in Applications" >> >> https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 >> >> >> >> >> >> Regards, >> >> Mark. >> > > From nobody Fri Jul 28 10:44:46 2017 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 510D0131FEC for ; Fri, 28 Jul 2017 10:44:44 -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 UP0Oq7JNiC80 for ; Fri, 28 Jul 2017 10:44:42 -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 39435131CF0 for ; Fri, 28 Jul 2017 10:44:42 -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 v6SHifof021365; Fri, 28 Jul 2017 10:44:41 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SHidaR020977 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 10:44:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 10:44:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 10:44:39 -0700 From: "Templin, Fred L" To: Mark Smith CC: "ipv6@ietf.org" Subject: RE: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFgAQRtEAAAt5VXD//8NVAIAAdJow//+UAQCAAHKiYA== Date: Fri, 28 Jul 2017 17:44:38 +0000 Message-ID: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> <31a1f50786da43c3862bf5c33cffc910@XCH15-06-08.nw.nos.boeing.com> <54876ee10ca2468bb493bb497a8bdcc9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:44:44 -0000 SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5 IDI4LCAyMDE3IDEwOjMxIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBmZTgwOjov MTYgb24gc3BlY2lmaWMgbGluayBsYXllcnMNCj4gDQo+IE9uIDI5IEp1bHkgMjAxNyBhdCAwMzow NCwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4g PiBIaSBNYXJrLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPiA+PiBTZW50 OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgMTA6MDAgQU0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogUmU6IGZlODA6Oi8xNiBvbiBzcGVjaWZpYyBsaW5rIGxheWVycw0KPiA+Pg0K PiA+PiBPbiAyOSBKdWx5IDIwMTcgYXQgMDI6NDMsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+ID4gSGkgYWdhaW4gTWFyaywNCj4gPj4gPg0K PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBNYXJrIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gPj4gPj4gU2VudDogRnJpZGF5 LCBKdWx5IDI4LCAyMDE3IDg6MDkgQU0NCj4gPj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPj4gPj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gPj4g Pj4gU3ViamVjdDogUmU6IGZlODA6Oi8xNiBvbiBzcGVjaWZpYyBsaW5rIGxheWVycw0KPiA+PiA+ Pg0KPiA+PiA+PiBIaSBGcmVkLA0KPiA+PiA+Pg0KPiA+PiA+PiBPbiAyOSBKdWx5IDIwMTcgYXQg MDA6MzAsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6 DQo+ID4+ID4+ID4gSGksIEkgYW0gc2VyaW91c2x5IGNvbnNpZGVyaW5nIHRoZSB1c2Ugb2YgZmU4 MDo6LzE2IG9uIGEgc3BlY2lmaWMgbGluayBsYXllcg0KPiA+PiA+PiA+IHNvIHRoYXQgdGhlIG5l dHdvcmsgcGFydCBpcyAxNiBiaXRzIGFuZCB0aGUgImhvc3QiIHBhcnQgaXMgMTEyIGJpdHMuDQo+ ID4+ID4+ID4NCj4gPj4gPj4gPiBUYWtpbmcgQUVSTyBmb3IgZXhhbXBsZSwgZm9yIHRoZSBJUHY2 IHByZWZpeCAyMDAxOmRiODoxOjI6Oi82NCB0aGUNCj4gPj4gPj4gPiBjb3JyZXNwb25kaW5nIExM IGFkZHJlc3MgaXMgZmU4MDoyMDAxOmRiODoxOjI6Oi8xNi4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+ IFRoZSBxdWVzdGlvbiBpcyB3aGF0IHdvdWxkIGJyZWFrIGlmIHdlIGRpZCB0aGlzPyBUaGUgbGlu ayBsYXllciB3b3VsZA0KPiA+PiA+PiA+IGtub3cgaG93IHRvIGRlYWwgd2l0aCBpdCwgYnV0IHdv dWxkIHRoZSBJUHY2IGxheWVyIGJlIGFibGUgdG8gaGFuZGxlIGl0Pw0KPiA+PiA+PiA+IEFuZCwg d2hhdCBhYm91dCBhcHBzIHRoYXQgZGVhbCB3aXRoIElQdjYgTEwncz8NCj4gPj4gPj4gPg0KPiA+ PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBJJ2xsIHRoaW5rIGEgYml0IG1vcmUgYWJvdXQgZmU4MDo6 LzE2Lg0KPiA+PiA+DQo+ID4+ID4gQWN0dWFsbHksIEkgdGhpbmsgd2UgZG9uJ3QgaGF2ZSB0byB3 b3JyeSBhYm91dCBmZTgwOjovMTYuIEkganVzdCByZWFsaXplZA0KPiA+PiA+IHRoYXQgd2UgY2Fu IHVzZSBmZTgwOjovMTAgYW5kIHRoZW4gd2hlbiB3ZSBlbWJlZCB0aGUgSVB2NiBwcmVmaXggd2UN Cj4gPj4gPiBjYW4gc2ltcGx5IHByZXBlbmQgNiAnMCcgYml0cyBzbyB0aGF0IHRoZSBhY3R1YWwg cHJlZml4IGJlZ2lucyBhdCBiaXQgMTYgc28NCj4gPj4gPiB0aGF0IGl0IHByaW50cyBhbmQgcGFy c2VzIG5pY2VseS4gU28sIHdlIHdvdWxkIGhhdmU6DQo+ID4+ID4NCj4gPj4gPiBmZTgwOjoyMDAx OmRiODoxOjE6Oi8xMA0KPiA+PiA+DQo+ID4+DQo+ID4+IFRoZSB0cm91YmxlIGlzIHRoYXQgcGVy IFJGQzQyOTEsIHRoZSBiaXRzIGJldHdlZW4gRkU4MDo6LzEwIGFuZA0KPiA+PiBGRTgwOjovNjQg YXJlIHRvIGN1cnJlbnRseSBiZSBhbGwgemVyb3MuDQo+ID4+DQo+ID4+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM0MjkxI3NlY3Rpb24tMi41LjYNCj4gPg0KPiA+IEJ1dCwgY2FuIHRo YXQgYmUgb3ZlcnJpZGRlbiBieSBhbiBJUHY2LW92ZXItZm9vIGRvY3VtZW50Pw0KPiANCj4gSSBk b24ndCB0aGluayBpdCBjYW4gYmUsIHRoZSB0ZXh0IHNheXMgbm90aGluZyBhYm91dCBleGNlcHRp b25zIGJlaW5nDQo+IGFsbG93ZWQgdmlhIElQdjYtb3Zlci1mb28gZG9jdW1lbnRzLiBJIGRvbid0 IHRoaW5rIHRoZXJlIGlzIGFueQ0KPiBhbWJpZ3VpdHkgb3Igcm9vbSBmb3IgbGluayBzcGVjaWZp YyBmb3JtYXRzIGluICJMaW5rLUxvY2FsIGFkZHJlc3Nlcw0KPiBoYXZlIHRoZSBmb2xsb3dpbmcg Zm9ybWF0Ii4NCg0KT0suDQoNCj4gSSdkIHRoaW5rIGEgbGluay10eXBlLXNwZWNpZmljIFJGQyB3 b3VsZCBoYXZlIHRyb3VibGUgcmVhY2hpbmcNCj4gY29uc2Vuc3VzIG9uIHVwZGF0aW5nIHRoYXQg dGV4dC4gQSBtb3JlIGdlbmVyYWwgUkZDIHRoYXQgaXMgbm90IGxpbmsNCj4gdHlwZSBzcGVjaWZp YyB3b3VsZCBwcm9iYWJseSBoYXZlIGEgYmV0dGVyIGNoYW5jZS4NCg0KT0sgLSB0aGVuIG1heWJl IHdlIGNhbiBkbyB0aGF0IHdpdGggbXkgZHJhZnQgb24gIlRoZSBBRVJPIEFkZHJlc3MiOg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLTZtYW4tYWVyb2Fk ZHIvDQoNCk9yLCBpZiB5b3Ugd2FudGVkIGpvaW4gZWZmb3J0cyBpbiBzb21lIHdheSBvbiBhIG1v cmUgZ2VuZXJhbCBkb2MNCm9uIExMJ3MgbWF5YmUgd2UgY291bGQgZGlzY3VzcyB0aGF0Lg0KDQpU aGFua3MgLSBGcmVkDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IE1hcmsuDQo+IA0KPiANCj4gPg0KPiA+ PiBBZG1pdHRlZGx5IEknbSBub3Qgc3VyZSB3aGVyZSdyZSB5b3UncmUgcHV0dGluZyAyMDAxOmRi ODoxOjEsIGJlY2F1c2UNCj4gPj4gdGhlcmUgYXJlIG11bHRpcGxlICI6OidzLiBJZiBpdCBpcyBh ZnRlciAvNjQsIHRoZW4gaXQncyBmaW5lLg0KPiA+DQo+ID4gTXkgbWlzdGFrZSAtIGl0IHNob3Vs ZCBoYXZlIHNhaWQgZmU4MDoyMDAxOmRiODoxOjE6Oi8xMCAoaS5lLiwgb25seSBvbmUgIjo6Iiku DQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4g TWFyay4NCj4gPj4NCj4gPj4NCj4gPj4gPiBUaGFua3MgLSBGcmVkDQo+ID4+ID4NCj4gPj4gPj4g VG8gc3RhcnQgd2l0aCwgaGVyZSBhIGRyYWZ0IHdoaWNoIGluY2x1ZGVzIHdoYXQgSSBzdW1tYXJp c2VkIGFib3V0DQo+ID4+ID4+IExMcy4gSSB0aGluayB0aGF0IGZlODA6Oi8xNiB3b3VsZCBjb25m bGljdCB3aXRoIGJvdGggdGhlIGN1cnJlbnQgSUFOQQ0KPiA+PiA+PiBmZTgwOjovMTAsIFJGQzQy OTEgTEwgYXNzaWdubWVudHMgYW5kIHRoZSBmZTgwOjovNjQgSVB2Ni1vdmVyLWZvbyBsaW5rDQo+ ID4+ID4+IGNvbnZlbnRpb25zIHdlIGhhdmUuIChJJ2QgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVs IHRvIGtlZXAgdGhlIC8xMA0KPiA+PiA+PiB0aHJvdWdoIC82NCBmb3IgYSByYW5kb20gc3VibmV0 IElEIGxpa2Ugd2UgaGF2ZSBmb3IgVUxBcyBpLmUuIGdsb2JhbGx5DQo+ID4+ID4+IHVuaXF1ZSBs aW5rLWxvY2FsIGFkZHJlc3NlcywgdG8gYXZvaWQgdGhlIHNjb3BlL2ludGVyZmFjZSBpbmRleA0K PiA+PiA+PiByZXF1aXJlbWVudCB3aGVuIHVzaW5nIExMIGFkZHJlc3NlcyB3aXRoaW4gQVBJIHNv Y2tldHMpDQo+ID4+ID4+DQo+ID4+ID4+ICJIb3cgdG8gdXNlIElQdjYgTGluay1Mb2NhbCBBZGRy ZXNzZXMgaW4gQXBwbGljYXRpb25zIg0KPiA+PiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc21pdGgtaXB2Ni1saW5rLWxvY2Fscy1hcHBzLTAwDQo+ID4+ID4+DQo+ID4+ID4+ DQo+ID4+ID4+IFJlZ2FyZHMsDQo+ID4+ID4+IE1hcmsuDQo+ID4+ID4NCj4gPg0KDQo= From nobody Fri Jul 28 11:28:00 2017 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 AA892131D1A for ; Fri, 28 Jul 2017 11:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 n7DlDPUiPE8x for ; Fri, 28 Jul 2017 11:27:57 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 088EB131C89 for ; Fri, 28 Jul 2017 11:27:57 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d145so117079944qkc.2 for ; Fri, 28 Jul 2017 11:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Q7GT8lWIDxzJdp5Yasg2kQ6PGe2B+i/12IIk2M4v7TE=; b=G66b28+W1RMdiyf24QXE5zqB+GGJZrkI2JH5+68Ufm9pKg2FQJROxmfL1M7+kjt7aK +h+Gu7Dw0GCTjaW+36dzVMtIBqQfEsNOB78+BjGT6hI3Vwd/dYsnxahi80fOJ6As7W1e iW7Dr7z+XUIrnRouen9itfqmJgwj7CP2WfFi7JFvb1DQwh/3A0ZporA/Bn3pI4d5+cHv sVKRMP7tKk9NTOJTNLxEjS+UeZghL/E2cChi3yXbZZuoRQZg5hY7bjzWsVcmDeyppHTi 0DAjdKe1nrR3U2iFzTBwnyETYpOefrZ4fL9Z+hYcrEOoUvvPKRt/WIgSetFbK4PtFRnY m8kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Q7GT8lWIDxzJdp5Yasg2kQ6PGe2B+i/12IIk2M4v7TE=; b=D9bOSF+EvHA9jm/kIcgmgu2LQIiXK7StdoKU4rOU6IEwa+37hV61OFNWO4qGZ5MINW AzoM+/Xh3S6RqEs/BCNQvx8rgQ0iTH1IZflNzJpDu+NopxXVGIuSoF7bjYBbZ3bmX0vQ hJ7MvTodHL8lasCOD6okK6P4GCfzx5mq4N+sK1t7kfzm/L4Oz/cHdl86Aa6D8t8jc6Et OViNkm3gF3AbhM4rFe2b9l7zZb6708BScvjsfgXV0LZIjPAhFfH4BxcZa4fUaxmXFJj8 76YOtS0XZMVaOgV7L0HQmM7+pqFiINQ0gC6wMa54xONUshpEFaFAo9SKsdi7vvS5gcQ+ lRug== X-Gm-Message-State: AIVw113vDLTTZc6jZFrIp6psCR1W/vgDRWagpgE6TQ6RwMvE+GP1/kw0 yCKYjCIAfA8VfmTjhJbRV+nIagZSnQ== X-Received: by 10.55.144.130 with SMTP id s124mr11956409qkd.136.1501266476086; Fri, 28 Jul 2017 11:27:56 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 28 Jul 2017 11:27:55 -0700 (PDT) In-Reply-To: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 28 Jul 2017 11:27:55 -0700 X-Google-Sender-Auth: 2nPHQFi60OWdUzIhMIvqpNUrrLE Message-ID: Subject: Re: fe80::/16 on specific link layers To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 18:27:59 -0000 At Fri, 28 Jul 2017 14:30:01 +0000, "Templin, Fred L" wrote: > Hi, I am seriously considering the use of fe80::/16 on a specific link layer > so that the network part is 16 bits and the "host" part is 112 bits. > > Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the > corresponding LL address is fe80:2001:db8:1:2::/16. > > The question is what would break if we did this? The link layer would > know how to deal with it, but would the IPv6 layer be able to handle it? > And, what about apps that deal with IPv6 LL's? It would break BSD-variant implementations, which internally use the 2nd 16-bit field of link-local addresses to identify the corresponding link, e.g., fe80:1::abcd means fe80::abcd in link "#1". (It's an internal form and doesn't appear on wire). Yes, that's an ugly implementation-specific hack and you could blame the designer of the idea. But I'm afraid we can't simply ignore the deployment base as a matter of practice. -- JINMEI, Tatuya From nobody Fri Jul 28 11:48:35 2017 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 F0016131C99 for ; Fri, 28 Jul 2017 11:48:33 -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 ALhXoA4VMSnT for ; Fri, 28 Jul 2017 11:48:32 -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 4B705129AD1 for ; Fri, 28 Jul 2017 11:48:32 -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 v6SImVqq064146; Fri, 28 Jul 2017 11:48:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v6SImP96064079 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jul 2017 11:48:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 28 Jul 2017 11:48:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 28 Jul 2017 11:48:24 -0700 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= CC: "ipv6@ietf.org" Subject: RE: fe80::/16 on specific link layers Thread-Topic: fe80::/16 on specific link layers Thread-Index: AdMHrP1SJyK2reD4Q+SZV36IBhKbFgAXOnaAAA5jhtA= Date: Fri, 28 Jul 2017 18:48:24 +0000 Message-ID: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 18:48:34 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogamlubWVpLnRhdHV5 YUBnbWFpbC5jb20gW21haWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m ID8/Pz8NCj4gU2VudDogRnJpZGF5LCBKdWx5IDI4LCAyMDE3IDExOjI4IEFNDQo+IFRvOiBUZW1w bGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBpcHY2QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBmZTgwOjovMTYgb24gc3BlY2lmaWMgbGluayBsYXllcnMNCj4g DQo+IEF0IEZyaSwgMjggSnVsIDIwMTcgMTQ6MzA6MDEgKzAwMDAsDQo+ICJUZW1wbGluLCBGcmVk IEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gDQo+ID4gSGksIEkgYW0g c2VyaW91c2x5IGNvbnNpZGVyaW5nIHRoZSB1c2Ugb2YgZmU4MDo6LzE2IG9uIGEgc3BlY2lmaWMg bGluayBsYXllcg0KPiA+IHNvIHRoYXQgdGhlIG5ldHdvcmsgcGFydCBpcyAxNiBiaXRzIGFuZCB0 aGUgImhvc3QiIHBhcnQgaXMgMTEyIGJpdHMuDQo+ID4NCj4gPiBUYWtpbmcgQUVSTyBmb3IgZXhh bXBsZSwgZm9yIHRoZSBJUHY2IHByZWZpeCAyMDAxOmRiODoxOjI6Oi82NCB0aGUNCj4gPiBjb3Jy ZXNwb25kaW5nIExMIGFkZHJlc3MgaXMgZmU4MDoyMDAxOmRiODoxOjI6Oi8xNi4NCj4gPg0KPiA+ IFRoZSBxdWVzdGlvbiBpcyB3aGF0IHdvdWxkIGJyZWFrIGlmIHdlIGRpZCB0aGlzPyBUaGUgbGlu ayBsYXllciB3b3VsZA0KPiA+IGtub3cgaG93IHRvIGRlYWwgd2l0aCBpdCwgYnV0IHdvdWxkIHRo ZSBJUHY2IGxheWVyIGJlIGFibGUgdG8gaGFuZGxlIGl0Pw0KPiA+IEFuZCwgd2hhdCBhYm91dCBh cHBzIHRoYXQgZGVhbCB3aXRoIElQdjYgTEwncz8NCj4gDQo+IEl0IHdvdWxkIGJyZWFrIEJTRC12 YXJpYW50IGltcGxlbWVudGF0aW9ucywgd2hpY2ggaW50ZXJuYWxseSB1c2UgdGhlDQo+IDJuZCAx Ni1iaXQgZmllbGQgb2YgbGluay1sb2NhbCBhZGRyZXNzZXMgdG8gaWRlbnRpZnkgdGhlIGNvcnJl c3BvbmRpbmcNCj4gbGluaywgZS5nLiwgZmU4MDoxOjphYmNkIG1lYW5zIGZlODA6OmFiY2QgaW4g bGluayAiIzEiLiAgKEl0J3MgYW4NCj4gaW50ZXJuYWwgZm9ybSBhbmQgZG9lc24ndCBhcHBlYXIg b24gd2lyZSkuDQoNCkkgY2FuIHNlZSBob3cgaXQgbWlnaHQgYmUgYXR0cmFjdGl2ZSB0byBtYWtl IHVzZSBvZiB1bnVzZWQgYml0cywgYnV0Li4uDQoNCj4gWWVzLCB0aGF0J3MgYW4gdWdseSBpbXBs ZW1lbnRhdGlvbi1zcGVjaWZpYyBoYWNrIGFuZCB5b3UgY291bGQgYmxhbWUNCj4gdGhlIGRlc2ln bmVyIG9mIHRoZSBpZGVhLiANCg0KLi4udGhlIGltcGxlbWVudGF0aW9uIHdpbGwgaGF2ZSB0byBi ZSB1cGRhdGVkIGFzIHRoZSBzcGVjcyBhcmUNCnVwZGF0ZWQuDQoNCj4gQnV0IEknbSBhZnJhaWQg d2UgY2FuJ3Qgc2ltcGx5IGlnbm9yZSB0aGUNCj4gZGVwbG95bWVudCBiYXNlIGFzIGEgbWF0dGVy IG9mIHByYWN0aWNlLg0KDQpJIHRoaW5rIHlvdSBoYXZlIHRoaXMgYmFja3dhcmRzIC0gaXQgaXMg dGhlIGltcGxlbWVudGF0aW9uIHRoYXQNCmlzIGlnbm9yaW5nIHRoZSBzcGVjcywgYW5kIG5vdCB0 aGUgb3RoZXIgd2F5IGFyb3VuZC4NCg0KVGhhdCB0aGVyZSBtYXkgYmUgaW1wbGVtZW50YXRpb25z IHRoYXQgaWdub3JlIHRoZSBzcGVjcyBkb2VzDQpub3QgbWVhbiB0aGF0IHRoZSBzcGVjcyBjYW5u b3QgYmUgdXBkYXRlZC4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tDQo+IEpJTk1FSSwgVGF0dXlh DQoNCg== From nobody Fri Jul 28 13:22:55 2017 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 9A3A4129562 for ; Fri, 28 Jul 2017 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 KI-tTzusrh3x for ; Fri, 28 Jul 2017 13:22:47 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1F912426E for ; Fri, 28 Jul 2017 13:22:47 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d145so118576847qkc.2 for ; Fri, 28 Jul 2017 13:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Q5XQSl1HTHxAW+Jq2f0JgrpI9r+gczervWBw/OlTOxU=; b=Ef4zd3b4E70EnALL3vGTYaGfaANYzRWEBMvt2laV0YOA3jxeH3gR+r0/DC693sLNuu flgV5zCyGub9DlLKu58dmvlSrlltYBcAjCZDXlJJCpXC6ZpO/L2m3SFVECrtsj46C/3P Wa7PwQDgoZZ0cqegagPpiZx1a41/Clk9MwffjxhC4RiTjW/TBe2yi+XK3J2rt64iOoQI iC/CdDFAJqp0/JTX8ySbKDmOIKtQCLqOrGp3OzW9g6AVrpdBRUUVGoFyRyBY/kKbkxNw 2y0T2+qxnt6zU1wXPRRi6xXKIkXYZz965JirHfiJMMMS8yxi7iLvFk/ilOvgJnBknTCg jEGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Q5XQSl1HTHxAW+Jq2f0JgrpI9r+gczervWBw/OlTOxU=; b=ceM+FiT5pQw/nC7BCJlCvZBsxH9+Mj5r9O47O6b+ehrRI4IZVBsQdDa3hwk8WRZ460 ChJlDMX/31fHbI7A/OO5Tt8hrTScRTQVBzTmrTt7kTHXfXYB1xuP42S3P1SNrVDxYkfM CrB3yi5oiC1Ov0wMGCrNWjKtuLwVDAzLlA4JDRaWr0eehU3BBngvgcVoR6/Es2YzxDMt vAqf/TBYxJnfhWBJgLBELL6UtiVTUKnq6RpgqXtUVXYz/G+fdoHRPmfaQ7Sem/CPHOzc dM6Gd/ePiXH1ElB/VdZq8tlEQyxAn6hzCYcQSD36jrzv4By84nW+jYkpIhXyqF9jh1Cf z0EA== X-Gm-Message-State: AIVw113rcgb/r4KcrDOSIFmz2rkxHJU6H8SZpB37/jcBchekLELxYxou DmfiMCtQMNOgmDDDRmKLEpHSumDSlGy66Qw= X-Received: by 10.55.40.194 with SMTP id o63mr11087156qko.310.1501273366839; Fri, 28 Jul 2017 13:22:46 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 28 Jul 2017 13:22:46 -0700 (PDT) In-Reply-To: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 28 Jul 2017 13:22:46 -0700 X-Google-Sender-Auth: xM6ent51sLViMRAJrY8vNHk86jU Message-ID: Subject: Re: fe80::/16 on specific link layers To: "Templin, Fred L" Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 20:22:50 -0000 At Fri, 28 Jul 2017 18:48:24 +0000, "Templin, Fred L" wrote: > > Yes, that's an ugly implementation-specific hack and you could blame > > the designer of the idea. > > ...the implementation will have to be updated as the specs are > updated. > > > But I'm afraid we can't simply ignore the > > deployment base as a matter of practice. > > I think you have this backwards - it is the implementation that > is ignoring the specs, and not the other way around. > > That there may be implementations that ignore the specs does > not mean that the specs cannot be updated. I don't disagree in principle. I just provided a data point that you can't just ignore or dismiss in practice, i.e., just saying implementations should be updated doesn't automagically make it happen. If we make the decision with full understanding of the expected interoperability problem with the existing large deployment base and the corresponding delay of the deployment of the updated protocol spec due to the necessary upgrade (if it ever happens satisfactorily), that's the wg's call. -- JINMEI, Tatuya From nobody Sun Jul 30 19:38:10 2017 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 D62DE131D21 for ; Sun, 30 Jul 2017 19:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wfVdAdT0MIgA for ; Sun, 30 Jul 2017 19:38:07 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 40E52131D1E for ; Sun, 30 Jul 2017 19:38:07 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id n125so30653896vke.1 for ; Sun, 30 Jul 2017 19:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hQGeOdJuVmYTZNz3+CnHxGM/q4rqxpt0J0tQk8swckA=; b=mM59Y58lyEibpBIobJcV1j/fHYfHsaPKZkYJi/oMFOmKEc93izI99mWtok7r2RQ35F gQtEzIR9S9aNDNQU4MXC4o1acSUaAYmRuicOXlC3ey5n01bOILlUvO+m9elZyQqyqxWo nb+/kgTdx/+mDADBkC/QY1P8sTguOdUvuMV9WDWJ9iqm+32bhQ9/Ukd4YxOrtD4yzrAl PXaurprVdzO4eSWJibUQqXN7osXT8/6dOD39wS/0V+/HPNLEB4I0923IcV6DsD3Lx1yY 17ZnEkCksdowkLZkZFJ+qvzUxEc3dkR1WvMIii/xpNVy57UnlyZ3jSuHos4bHh7uLPBV 7NVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hQGeOdJuVmYTZNz3+CnHxGM/q4rqxpt0J0tQk8swckA=; b=X/oHT6txiSASViqW5QmH7ZSrtB6LfinZMmsrfPEUNUkYcQc0FMbO8O3ACMD/npi3ZO wzCni/IDu9BeT1WZ38nkH0nF5ytCqZHuGPlAJoY2qLPvg+BMR9zbjF02Yx7zaHuT8mfJ 5/xoLMFizrZFJKD99R2iXf6DHcgE+Mw5ZUyxXps+zSxrcEtKCir+sOfH97TWZRBcnwgc PWYthAl0dUrUJSalv9UcbPSo+++AkHdcVPd0JPgwYKfH3gXh7+ka9/SOUCS3dskAMsVW UuUjjKPMzaCxB4b4e08ljmf4GQAyN2ZL/O8aXeI38sSrVqVvpYmdH+TG1iPrRshhppU2 mohA== X-Gm-Message-State: AIVw110uOtl5tWpy4UMsd2zIFvey9C7EAxGyBoYW2VTwtE4pxqjok2X2 PHUbadRhCglUgUPxRRpOmoUZNA5wjg== X-Received: by 10.31.232.7 with SMTP id f7mr9422753vkh.32.1501468686228; Sun, 30 Jul 2017 19:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Sun, 30 Jul 2017 19:37:35 -0700 (PDT) In-Reply-To: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Mon, 31 Jul 2017 12:37:35 +1000 Message-ID: Subject: Re: fe80::/16 on specific link layers To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: "Templin, Fred L" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 02:38:09 -0000 On 29 July 2017 at 04:27, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 28 Jul 2017 14:30:01 +0000, > "Templin, Fred L" wrote: > >> Hi, I am seriously considering the use of fe80::/16 on a specific link l= ayer >> so that the network part is 16 bits and the "host" part is 112 bits. >> >> Taking AERO for example, for the IPv6 prefix 2001:db8:1:2::/64 the >> corresponding LL address is fe80:2001:db8:1:2::/16. >> >> The question is what would break if we did this? The link layer would >> know how to deal with it, but would the IPv6 layer be able to handle it? >> And, what about apps that deal with IPv6 LL's? > > It would break BSD-variant implementations, which internally use the > 2nd 16-bit field of link-local addresses to identify the corresponding > link, e.g., fe80:1::abcd means fe80::abcd in link "#1". (It's an > internal form and doesn't appear on wire). > > Yes, that's an ugly implementation-specific hack and you could blame > the designer of the idea. But I'm afraid we can't simply ignore the > deployment base as a matter of practice. > I'm curious what the consequences would be of making BSD-variants compliant? Are any user space applications relying on it? Does BSD support the Sockets API and therefore applications should be using the scope_id field for zone (ifindex) information rather than using this link ID in the reserved LL address field? I appreciate it would be a change in behaviour, however I wonder whether it would really just be a cosmetic one, only visible in the output of utilities such as 'ifconfig'? Regards, Mark. > -- > JINMEI, Tatuya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jul 31 02:56:17 2017 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 ED78A132046 for ; Mon, 31 Jul 2017 02:56: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 (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuC_sx35FMNW for ; Mon, 31 Jul 2017 02:56:13 -0700 (PDT) Received: from forward2o.cmail.yandex.net (forward2o.cmail.yandex.net [37.9.109.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601E1131FFD for ; Mon, 31 Jul 2017 02:56:13 -0700 (PDT) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward2o.cmail.yandex.net (Yandex) with ESMTP id ED9B120747; Mon, 31 Jul 2017 12:56:10 +0300 (MSK) Received: from smtp3o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 377962940FBE; Mon, 31 Jul 2017 12:55:53 +0300 (MSK) Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id tQB6Hwv177-tqj8Mq90; Mon, 31 Jul 2017 12:55:52 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1501494952; bh=hPBnjMhOOJGGVw2V9bMkIPiEdbAKU61tbFqCGR4GKTI=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=JFXvxRGDex/VyXdMLZv5qy3BTtaGqlCi+diwTJ3Nh5j5uciE9urZx1siULxLZ5K9B 8Om676yVIb43C4xXopsgENgcEmWXuQedQU79O+928asfVB1iuhdyfZnLUYVoA1Sn+g KVurXTIGyo4ntZIAH6kteyH6AK6h0iAyl+bDT7ug= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: fe80::/16 on specific link layers To: Mark Smith , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: "ipv6@ietf.org" References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <2d8252d8-530e-e63f-fd9c-91eac96fc16c@yandex.ru> Date: Mon, 31 Jul 2017 12:53:07 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Lb3K8cKPFmrhold1ui0XuxxihI2sn5XwP" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 09:56:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lb3K8cKPFmrhold1ui0XuxxihI2sn5XwP Content-Type: multipart/mixed; boundary="5eIBH3GxIxcAbLgLNcLFeSnpCgOPsMoue"; protected-headers="v1" From: "Andrey V. Elsukov" To: Mark Smith , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: "ipv6@ietf.org" Message-ID: <2d8252d8-530e-e63f-fd9c-91eac96fc16c@yandex.ru> Subject: Re: fe80::/16 on specific link layers References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: --5eIBH3GxIxcAbLgLNcLFeSnpCgOPsMoue Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 31.07.2017 05:37, Mark Smith wrote: >> Yes, that's an ugly implementation-specific hack and you could blame >> the designer of the idea. But I'm afraid we can't simply ignore the >> deployment base as a matter of practice. >> >=20 > I'm curious what the consequences would be of making BSD-variants > compliant? Are any user space applications relying on it? Does BSD > support the Sockets API and therefore applications should be using the > scope_id field for zone (ifindex) information rather than using this > link ID in the reserved LL address field? >=20 > I appreciate it would be a change in behaviour, however I wonder > whether it would really just be a cosmetic one, only visible in the > output of utilities such as 'ifconfig'? It is not visible for application, but when you will use the second u16 word of the address like in the 'fe80:2001:db8:1:2::/16', the kernel can not save it internally, because the scope zone id is stored here. I.e. 2001 will be overwritten by interface index. However, I did already the most of work to drop this hack from FreeBSD kernel. But I can't say this for others. --=20 WBR, Andrey V. Elsukov --5eIBH3GxIxcAbLgLNcLFeSnpCgOPsMoue-- --Lb3K8cKPFmrhold1ui0XuxxihI2sn5XwP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAll+/gMACgkQAcXqBBDI oXra+Af5AVrEwwts/0Nzok6MozM3SWOmMUN4FtUA0rcVmvsL0y/0tgo2GogJVcvF GCUx1Iff4vS37/HL1rP+++F2RWvY1tQ6HThoG6p2PaMzTbYClv3JgoiqVyiYNPpP 6SNS6SIV2/UzoYYJH88pcExKFw2oqZraa92lVx84tDn3Jl3oJdVgo0pNGfZ/vNjW 4ffX3C6+3mbLwGcNfE34UWiv+YwvmJjrHlXxFxvQZM1ULx5raR5if2WOZVOrsm4W W56CTrxOTEkaWTd4GHgTfFeZfUuYMkhTmt4REcXvMirJzwDhWZgpPS9r1iwP63zl xiGq24TVAk1HZ/drNC1dCvizRFg2GQ== =R5ff -----END PGP SIGNATURE----- --Lb3K8cKPFmrhold1ui0XuxxihI2sn5XwP-- From nobody Mon Jul 31 10:09:17 2017 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 C7FC21326B8 for ; Mon, 31 Jul 2017 10:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iXCkHkLuw5FG for ; Mon, 31 Jul 2017 10:09:13 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 045E71326D2 for ; Mon, 31 Jul 2017 10:09:09 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id s6so121724320qtc.1 for ; Mon, 31 Jul 2017 10:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Cl1Hahgqk+lfKg1rfy4qiNU+hj9jYLW3FkcHExkiM6M=; b=gJ8YQdgc55See3Zsw45THE2oXBf5+f9UhV95KPuvTPfokEPR01q7FHBwmoQs7RY428 wa0i79I/uzlSobbCCgLOPHl2WKOm+Zfszq7PrhQc1jlaYRLZ/z6LXyS6m2wU9a25pU8S lxOm5TtvcP6+zsM5mF/wabWQAyrgoll8F3pqtOT+LRwLsPECOOsLpPEko/4Fdu3GyAY4 MBBnq0zti4QlWLpN64h6GWxO9j8DhYOtzO8Uk9WhyoBZumDahv6FUAeQ/Lsi5gpnX1EW JA7wgB32Lj3qqgO0qFHGphs1PJa+LwknNPW5AdYOD9ux/HOV9sniP2Fxb0GAU2OUGZV2 sznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Cl1Hahgqk+lfKg1rfy4qiNU+hj9jYLW3FkcHExkiM6M=; b=PWyz1C34NUSzGhpAdlSWwBqv99fW2/lVH10yVE/1xFhwsCGJD37x46l7WQ3ZLQnv3S 6JKGwEAfvG7KL3OoRy0I2XGUZxh1KoHlVMtPrykv6eLFPyBE+ij5ZZCGnR4W7AtmVlfr B0/yl5IYLlnEJqPvXRljTUcH88zy1KYRvIJP6g4NLbJWunD5s1NLrgwxGPRQDvvHK78o 8mhG4npTfXtpTsZdjmfApzbJXFF+3uTtoyHYyAriOrCqmqgjYDbwJ38LJXx+NqkETwtT BFIQP8g160T+Lw/7PyD6st6X2HQu2r8zCPeD/Z32ggDiiNGjPnFuUdOYmY62mrSKKb45 1dww== X-Gm-Message-State: AIVw1131+sH3fmQLPzr9aoVdy0PDUqBwHYZoew1aGGq+851YutwV0/1x rPjro+UvswEV8hOvvhhCvd+wKhLpWg== X-Received: by 10.237.60.57 with SMTP id t54mr24433495qte.281.1501520948822; Mon, 31 Jul 2017 10:09:08 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Mon, 31 Jul 2017 10:09:08 -0700 (PDT) In-Reply-To: References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 31 Jul 2017 10:09:08 -0700 X-Google-Sender-Auth: RaHLlGcxNT21BNQZGHsa4vhnX8g Message-ID: Subject: Re: fe80::/16 on specific link layers To: Mark Smith Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:09:15 -0000 At Mon, 31 Jul 2017 12:37:35 +1000, Mark Smith wrote: > > It would break BSD-variant implementations, which internally use the > > 2nd 16-bit field of link-local addresses to identify the corresponding > > link, e.g., fe80:1::abcd means fe80::abcd in link "#1". (It's an > > internal form and doesn't appear on wire). > > > > Yes, that's an ugly implementation-specific hack and you could blame > > the designer of the idea. But I'm afraid we can't simply ignore the > > deployment base as a matter of practice. > > I'm curious what the consequences would be of making BSD-variants > compliant? Are any user space applications relying on it? Does BSD > support the Sockets API and therefore applications should be using the > scope_id field for zone (ifindex) information rather than using this > link ID in the reserved LL address field? The hack is largely hidden from applications. Most ordinary applications using the standard socket API won't see the embedded link-zone ID in the address. Also, they are supposed to use the standard sin6_scope_id field when specifying a link-local address rather than manually embedding the link-zone ID in the address. Actually, most of the apps should even be agnostic about the address scope - they use text-to-address conversion library functions, such as getaddrinfo(), which understands the extended textual format as defined in RFC4007 and sets the sin6_scope_id field appropriately; same for the address-to-text conversion. So, even if the kernel is updated to get rid of the hack that won't affect most user-level applications. Some special purpose applications still deal with the hack themselves, though. They include network statistics apps (that read the kernel memory directly) and routing protocol apps (these tend to use non-standard APIs to get access to the kernel's routing table, where the raw in-memory representation is exchanged between the kernel and apps). -- JINMEI, Tatuya From nobody Mon Jul 31 15:32:41 2017 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 C9549131EDD for ; Mon, 31 Jul 2017 15:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avzaN_82udw0 for ; Mon, 31 Jul 2017 15:32:37 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 7A71E1327E4 for ; Mon, 31 Jul 2017 15:32:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id B9110BF9 for ; Mon, 31 Jul 2017 22:32:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aerkxSXTHgp for ; Mon, 31 Jul 2017 17:32:36 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 59574BB9 for ; Mon, 31 Jul 2017 17:32:36 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id g189so39006237vke.9 for ; Mon, 31 Jul 2017 15:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=Ede2FVdOh5KK3gH8B/NbI3KOlvaVt+OZLBirgypSZOY=; b=MWHoZBcgYG7MKxzOmTbd2k70BzVPoqv7owfOAPSfrL1QkA7A0BfIQE0dKRHdhrjTWt atyODIdbOpju7PBCC0jl2QfmHbwQIguKEtY8d/chpqq6mjRhnc0+oMMy02GTaLpJALt5 xTsXn4FluHC4BQE+A5+dlHIlWe0d4bNOmMFYNDwvha8ywvNk46T3LLcA1YcmzmJJycMD j75Gf+qVAiDr9VMc2FkenP7JNQ4T/mg4y/Ma2RUMhEKrKCVumGV6vQxR70fpjQJFTnx2 YUFstOFl6n4iWFJjiC/ORMH5JLROyXC8g/ah1fzydV1nYlj83OBZsbThs4kw2TXoQf58 2oaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ede2FVdOh5KK3gH8B/NbI3KOlvaVt+OZLBirgypSZOY=; b=OmrEm5kcZo7j2O2RllfVQIxALy3uloB2F9cShncK1yoirYh6NzG/dqjZEaOJmqXbhb /9HZ6SEl8I7he2BG5AfeYzbiDC68vYkyVZF92LR5WRdUJAUnrUbU0njwOLzIb1wsqjwk v/9yw2Y2cWrjS7ibtMrxD7kYI72E95vFiVPLq1RkJaVN7BRdoIJGpoHcE6XF93/wtIXj f0RSUKojBCgMwusGpDOZ/M3ung9itxlu4LMjkRtVWF2ToF8iUvyB8jdTfjS23pjWYNEI R/CLb+oPMBvbF+oXoIKPpPa3Dri2mNFGYf7JsG4sJEweuzAli7Z+scR4Gc0ZRWOYR9d6 pi1A== X-Gm-Message-State: AIVw113e6EgOpT4xeo9HlU6ht4fDYtnhSNUiJuPxsgSTbjyWonL0Gcuh NMrXaAUVfY2lsmdC7g/R5mcsyE9bRS+OsKSf6gYyyMk8WBr1vKSK7DvMDSqZL7scX3VfY6XfUVb LiGl2s8bTxeKDgyc= X-Received: by 10.159.60.4 with SMTP id u4mr11351421uah.1.1501540355575; Mon, 31 Jul 2017 15:32:35 -0700 (PDT) X-Received: by 10.159.60.4 with SMTP id u4mr11351413uah.1.1501540355264; Mon, 31 Jul 2017 15:32:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 31 Jul 2017 15:32:34 -0700 (PDT) From: David Farmer Date: Mon, 31 Jul 2017 17:32:34 -0500 Message-ID: Subject: Section 2.4 of rfc4291bis To: 6man WG Content-Type: multipart/alternative; boundary="f403043ed54c7e41530555a49bfe" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 22:32:40 -0000 --f403043ed54c7e41530555a49bfe Content-Type: text/plain; charset="UTF-8" Recent discussion on the list have convinced me that section 2.4 really needs to discuss on-link prefixes in some detail. It needs to describe their format similar to how the format of subnet prefixes are described, and describe how on-link prefixes are used by nodes. Also, a description of how subnet prefixes are used is needed to differentiate the two types of prefixes are used. Several other changes were needed to integrate these major changes with the rest of the text, with other additional editorial changes. In my opinion the current text gives the false impression that there is always a common prefix for address assignment and on-link determination, or the subnet prefix and the on-link prefix are the same, which they frequently are, but are not require to be. I have use Interface Identifier as the right-hand side of the on-link prefix, but this could have a different name if that is the consensus of the work group, but I think Interface Identifier makes the most sense. A few additional points; - Section 2.1 is quite clear "IPv6 addresses of all types are assigned to interfaces, not nodes." So, I think the "node address" in the first diagram should be renamed to "interface address". - Include are changes to the 4th paragraph of section 2.4.1, based on this rewrite of section 2.4, scoping the definition of 64 bit Interface Identifiers to "When automatically assigning a unicast address to an interface". with that most of exceptions are not needed any longer. - Include is an additional paragraph for the Link-Local section 2.4.6, based on his rewrite of section 2.4, saying that "by definition all nodes are aware of the Link-Local prefix and used it as if it is a subnet and on-link prefix". I suggest the following text for section 2.4, use as you see fit; IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing. IPv6 unicast routing and on-link determination are based on prefixes of any valid length up to 128 bits[BCP198], which are typically, but not necessarily, the same as the subnet prefixes used to automatically assign an address to an interface. There are several types of unicast addresses in IPv6, in particular, Global Unicast, Local unicast, and Link-Local unicast. There are also some special-purpose subtypes of Global Unicast, such as IPv6 addresses with embedded IPv4 addresses. Additional address types or subtypes can be defined in the future. IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). Further, the internal structure of a unicast address varies subtly based how the address is being used (for instance, when automatically assigning an address to an interface versus delivering packets). Except as described below, and at a minimum, a node will consider that unicast addresses (including those for its own interfaces) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | interface address | +-----------------------------------------------------------------+ A node may be aware of subnet prefix(es) for the link(s) it is attached to. By default such nodes will automatically assign unicast addresses to the interface(s) that are attached to those link(s), by prepending the subnet prefix(es) to the Interface Identifier(s) for those link(s). Where different link(s) may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ A node may also be aware of on-link prefix(es) for the link(s) it is attached to. Such nodes may use the on-link prefix(es) to determine the unicast addresses for which packets may be locally delivered on the attached link(s). Where different link(s) may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | on-link prefix | interface ID | +-------------------------------+---------------------------------+ A node may be aware of router(s) available on the link(s) it is attached to. Such nodes may send packets to the router(s) for delivery, especially for the unicast address for which packets cannot be locally delivered on a node's attached link(s). A router may have no more knowledge of the internal structure of unicast addresses than any other node. However, generally routers are attached to more links than other nodes and will usually have knowledge of one or more hierarchical boundaries through the operation of routing protocols. The known boundaries will differ from router to router, depending on what position the router holds in the routing hierarchy. Nodes should not make any assumptions about the structure of an address. Unicast addresses have no internal structure, except for knowledge of subnet prefixes, when automatically assigning an address to an interface, or knowledge of on-link prefixes and other routing boundaries, when delivering packets, as discussed in the previous paragraphs. ---- I also suggest the following text for 4th paragraph of section 2.4.1; When automatically assigning a unicast address to an interface, Interface Identifiers are 64 bits long except if the first three bits of the address are 000. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. ----- And that the following is added as the 3rd paragraph of section 2.4.6; Link-Local addresses are different than other types of Unicast addresses, in that by definition all nodes are aware of the Link-Local prefix and used it as if it is a subnet and on-link prefix for each link a node has, as described in section 2.4. Therefore, by default all nodes automatically assign Link-Local addresses on each interface and always treat Link-Local address as on-link for each interface. What do others think? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403043ed54c7e41530555a49bfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Recent discussion on the list have convinced me that secti= on 2.4 really needs to discuss on-link prefixes in some detail.=C2=A0 It ne= eds to describe their format similar to how the format of subnet prefixes a= re described, and describe how on-link prefixes are used by nodes. Also, a = description of how subnet prefixes are used is needed to differentiate the = two types of prefixes are used.=C2=A0 Several other changes were needed to = integrate these major changes with the rest of the text, with other additio= nal editorial changes.=C2=A0

In my opinion the current t= ext gives the false impression that there is always a common prefix for add= ress assignment and on-link determination, or the subnet prefix and the on-= link prefix are the same, which they frequently are, but are not require to= be.

I have use Interface Identifier as the right-= hand side of the on-link prefix, but this could have a different name if th= at is the consensus of the work group, but I think Interface Identifier mak= es the most sense.
=C2=A0
A few additional points;
- Sectio= n 2.1 is quite clear "IPv6 addresses of all types are assigned to interfaces, not nodes.&quo= t; So, I think the=C2=A0"node address" in the first diagra= m should be renamed to "interface address".=C2=A0

<= /div>
- =C2=A0Include are changes to the 4th paragraph of section 2.4.1= , based on this rewrite of section 2.4, scoping the definition of 64 bit In= terface Identifiers to "Wh= en automatically assigning a unicast address to an interface". with th= at most of exceptions=C2=A0are not needed any longer.

- =C2=A0Inclu= de is an additional paragraph for the Link-Local section 2.4.6, based on hi= s rewrite=C2=A0of section 2.4, saying that "by definition all nodes are aware of=C2=A0the=C2=A0
Link-Local prefix a= nd used it as if it is a subnet and on-link=C2=A0prefix".
=


I suggest the following text for section 2.4, = use as you see fit;

IPv6 unic= ast addresses are aggregatable with prefixes of arbitrary
bit-length, similar to= IPv4 addresses under Classless Inter-Domain
Routing.

IPv6 unicast routing and on-link determination ar= e based on prefixes=C2=A0
of any valid length up to 128 bits[BCP198], which are typica= lly, but=C2=A0
not necessarily, the same as the subnet prefixes used to=C2=A0
automatically=C2= =A0assign an=C2=A0address to an interfac= e.=C2=A0
There ar= e several types of unicast addresses in IPv6, in particular,
Global Unicast, Local uni= cast, and Link-Local unicast.=C2=A0 There are
<= font face=3D"monospace, monospace">also some special-purpose subtypes of Gl= obal Unicast, such as IPv6
addresses with embedded IPv4 addresses.=C2=A0 Additional ad= dress types or
subtypes can be defined in the future.

IPv6 nodes may have considerable or little knowle= dge of the internal
structure of the IPv6 address, depending on the role the node play= s
(for inst= ance, host versus router). Further, the internal=C2=A0structure=C2=A0
of a unicast address varies subtly = based how the address=C2=A0is be= ing=C2=A0
used (for in= stance, when=C2=A0au= tomatically=C2=A0ass= igning an address=C2=A0to an=C2=A0
interface versus delivering packets).=C2=A0

Except as described below, and at a minimum= , a node will consider=C2=A0
that unicast addresses (including those for its own inter= faces) have=C2=A0
no internal structure:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 128 bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-------------= ----------------------------------------------------+
| =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface address = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |

A node may b= e aware of subnet prefix(es) for the link(s) it is=C2=A0
=
attached to. By default such = nodes will automatically assign unicast
addresses to the interface(s) that are attache= d to those link(s), by
prepending the subnet prefix(es) to the Interface Identifier(s)= for=C2=A0
= those link(s). Where different link(s) may have different values for=C2=A0<= /font>
n:

| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 128-n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
+-------------------------------+-------------------------------= --+
| =C2= =A0 =C2=A0 =C2=A0 =C2=A0subnet prefix =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
+-= ------------------------------+---------------------------------+=

A node may also be aware of on-link prefix(es) for the link= (s) it is
a= ttached to. Such nodes may use the on-link prefix(es) to determine=C2=A0
the unicast a= ddresses for which packets may be locally delivered on
the attached link(s). Where dif= ferent link(s) may have different=C2=A0
values for n:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 128-n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+------------------------= -------+---------------------------------+
| =C2=A0 =C2=A0 =C2=A0 on-link pr= efix =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= interface ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+------------------------------= -+---------------------------------+

A node may be aware of router(s) available on the= link(s) it is=C2=A0
attached to. Such nodes may send packets to the router(s) for=C2= =A0
deliver= y, especially for the unicast address for which packets cannot
=
be locally delivered on= a node's attached link(s).

A router may have no more knowledge of the internal structur= e of=C2=A0
= unicast addresses than any other node. However, generally routers=C2=A0
are attached t= o more links than other nodes and will usually have=C2=A0
knowledge of one or more hie= rarchical boundaries through the=C2=A0
operation of routing protocols.=C2=A0 The known= boundaries will differ=C2=A0
from router to router, depending on what position the ro= uter holds=C2=A0
in the routing hierarchy.

N= odes should not make any assumptions about the structure of an=C2=A0= 
address. Unicast=C2=A0addresses have no=C2=A0internal=C2=A0structure,=C2=A0except for
knowledge of=C2=A0subnet prefixes,=C2=A0when=C2=
=A0automatically=C2=A0<=
/span>assigning an 
address to an interface, =
or=C2=A0knowledge=C2=A0of=C2=A0on-link=C2=A0prefixes and other 
routing=C2=A0boundaries,=C2=A0when=C2=A0deliverin=
g=C2=A0packets, as discussed in the 
previous paragraphs.

----

I also sugg= est the following text for 4th paragraph of section 2.4.1;
When auto= matically assigning a unicast address to an interface,
Interface Identifiers are 64 bi= ts long except if the first three bits
of the address are 000. The rationale for using= 64 bit Interface=C2=A0
Identifiers can be found in [RFC7421].=C2=A0

-----

And that the following is added as the 3rd paragraph of section 2.4.6= ;


Link-Local add= resses are different=C2=A0than other types=C2=A0of Unicast=C2=A0
addresses, in that by definition all n= odes are aware of=C2=A0the=C2=A0
Link-Local prefix and used it as if it is a subnet and on-link=C2=A0= prefix
for each link a node has,=C2=A0as described in section 2.4.=C2= =A0Therefore, by=C2=A0
default all=C2=A0nodes=C2=A0automatically assign Link-Local=C2=A0addresses on each=C2=A0
interface and always treat=C2=A0Link-Local address as=C2=A0on-link=C2=A0f= or each=C2=A0
interfac= e.

What do others think?=

Thanks

=C2=A0--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Email:fa= rmer@umn.edu
Networking & Telecommunication Services
Office o= f Information Technology
University of Minnesota=C2=A0=C2=A0
2218 Un= iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403043ed54c7e41530555a49bfe-- From nobody Mon Jul 31 16:27:38 2017 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 D1550132157 for ; Mon, 31 Jul 2017 16:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 i3LxNnq3gf3q for ; Mon, 31 Jul 2017 16:27:33 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 3D7F0131473 for ; Mon, 31 Jul 2017 16:27:33 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 80so329817uas.0 for ; Mon, 31 Jul 2017 16:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xZhfjihRQDBkHGzAsyVvcPXJEcm6yiut4YBsTgPhxQA=; b=K2WzbmEadAabB8Q5h/kumt7rpl2Jj4nWbF1rwpUARD++U5ngdb8tnRm8cf+j3fhr3D qgfAY4iMcmcnYvaRoakfJargSzY8j77JxBHGrjCtP762PIschhjJMZVOvqL8duTHqbRb uqIK9qxhbeF+zd8Sx5ZnU72gOwPGjO85lRpzTlgPp1obdg5Hj3fLRNObPLGcy5z/xPjb g490lqQFKZnBLCgdLLmHw+jaYD7mSScjRCF+qwiIZfzm35nwaCANgIVmgBuKJoUOq6RY nu4tnhGIurvVJjtbPYnHgkG24v7cWkl4xqcSB4MeexRDisYPiEBCbSwUQIG6/BBrMKN+ LD+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xZhfjihRQDBkHGzAsyVvcPXJEcm6yiut4YBsTgPhxQA=; b=q+3toxShQq7ZUJg1qz2A6ymASWGC0KySJ6CdCNzeR6Fn93Y+H3hVkfxc526Y27WmVB SOI9PUfzPa2Sxu2N582wT5niIT6QIGoAyItmbUXDDV7gzjrbMyk0EhZ+VNPAU87RADlW 52ElmUhxJiS5vptyIeAKgjfoFtuf0H8UbS2GA+pQ5JRTey2ysl65vzwRYoB1RUrFO9sC wcYUnk7h80NdHwJaldxqutL4neLxX7mjgcwwK/9eLqo2vHw2qMlIAHhYesItXjnQ4qGA H68VcVc+pdCEU7KsHZGpXfGBn0cKVrVJurZGmCHnaqQSo2NpFUskG0dV2qub7Pt27cq5 GD2g== X-Gm-Message-State: AIVw111J8gA21h82Y7KNVyn7Qg0JDmbxT4iqYH1eo6vpDeyPe8XkmULO izxwmHjUe/zWfy9j+NiLBJ6UgR+cyA== X-Received: by 10.159.59.89 with SMTP id j25mr13671046uah.155.1501543652122; Mon, 31 Jul 2017 16:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Mon, 31 Jul 2017 16:27:31 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Mon, 31 Jul 2017 16:27:31 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 1 Aug 2017 09:27:31 +1000 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: David Farmer Cc: 6man WG Content-Type: multipart/alternative; boundary="f403043ed734ffe3a30555a55fa0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:27:36 -0000 --f403043ed734ffe3a30555a55fa0 Content-Type: text/plain; charset="UTF-8" I still don't understand what your "on-link prefix" is. "on-link" is a bit that is only significant to the decision as to whether a device believes the destination is directly reachable over the link or via a router. Different devices can have a different opinion of this, even if they were attached to the same link. Unlikely if the on-link state is expressed via RA PIOs, however there is no requirement that all devices have the same on-link belief about a range of addresses covered by a prefix. It is only significant to ND and forwarding operation, which is why it is defined in RFC4861, rather than RFC4291. A more accurate name of 'on-link' and 'off-link' would really be 'directly link reachable' or 'remotely reachable via router'. The exception is Link Local destinations, which default to on-link/directly link reachable. That cannot currently be overridden. https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00 proposed how LL destinations could be flipped to being considered remotely reachable for cases where it would be useful. Your text below is making it sound far more significant and also sounds a bit like something different to an ND related operational bit. It sounds like you're describing something different. Regards, Mark. On 1 Aug. 2017 08:32, "David Farmer" wrote: > Recent discussion on the list have convinced me that section 2.4 really > needs to discuss on-link prefixes in some detail. It needs to describe > their format similar to how the format of subnet prefixes are described, > and describe how on-link prefixes are used by nodes. Also, a description of > how subnet prefixes are used is needed to differentiate the two types of > prefixes are used. Several other changes were needed to integrate these > major changes with the rest of the text, with other additional editorial > changes. > > In my opinion the current text gives the false impression that there is > always a common prefix for address assignment and on-link determination, or > the subnet prefix and the on-link prefix are the same, which they > frequently are, but are not require to be. > > I have use Interface Identifier as the right-hand side of the on-link > prefix, but this could have a different name if that is the consensus of > the work group, but I think Interface Identifier makes the most sense. > > A few additional points; > - Section 2.1 is quite clear "IPv6 addresses of all types are assigned to > interfaces, not nodes." So, I think the "node address" in the first > diagram should be renamed to "interface address". > > - Include are changes to the 4th paragraph of section 2.4.1, based on > this rewrite of section 2.4, scoping the definition of 64 bit Interface > Identifiers to "When automatically assigning a unicast address to an > interface". with that most of exceptions are not needed any longer. > > - Include is an additional paragraph for the Link-Local section 2.4.6, > based on his rewrite of section 2.4, saying that "by definition all nodes > are aware of the > Link-Local prefix and used it as if it is a subnet and on-link prefix". > > > I suggest the following text for section 2.4, use as you see fit; > > IPv6 unicast addresses are aggregatable with prefixes of arbitrary > bit-length, similar to IPv4 addresses under Classless Inter-Domain > Routing. > > IPv6 unicast routing and on-link determination are based on prefixes > of any valid length up to 128 bits[BCP198], which are typically, but > not necessarily, the same as the subnet prefixes used to > automatically assign an address to an interface. > > There are several types of unicast addresses in IPv6, in particular, > Global Unicast, Local unicast, and Link-Local unicast. There are > also some special-purpose subtypes of Global Unicast, such as IPv6 > addresses with embedded IPv4 addresses. Additional address types or > subtypes can be defined in the future. > > IPv6 nodes may have considerable or little knowledge of the internal > structure of the IPv6 address, depending on the role the node plays > (for instance, host versus router). Further, the internal structure > of a unicast address varies subtly based how the address is being > used (for instance, when automatically assigning an address to an > interface versus delivering packets). > > Except as described below, and at a minimum, a node will consider > that unicast addresses (including those for its own interfaces) have > no internal structure: > > | 128 bits | > +-----------------------------------------------------------------+ > | interface address | > +-----------------------------------------------------------------+ > > A node may be aware of subnet prefix(es) for the link(s) it is > attached to. By default such nodes will automatically assign unicast > addresses to the interface(s) that are attached to those link(s), by > prepending the subnet prefix(es) to the Interface Identifier(s) for > those link(s). Where different link(s) may have different values for > n: > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ > > A node may also be aware of on-link prefix(es) for the link(s) it is > attached to. Such nodes may use the on-link prefix(es) to determine > the unicast addresses for which packets may be locally delivered on > the attached link(s). Where different link(s) may have different > values for n: > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | on-link prefix | interface ID | > +-------------------------------+---------------------------------+ > > A node may be aware of router(s) available on the link(s) it is > attached to. Such nodes may send packets to the router(s) for > delivery, especially for the unicast address for which packets cannot > be locally delivered on a node's attached link(s). > > A router may have no more knowledge of the internal structure of > unicast addresses than any other node. However, generally routers > are attached to more links than other nodes and will usually have > knowledge of one or more hierarchical boundaries through the > operation of routing protocols. The known boundaries will differ > from router to router, depending on what position the router holds > in the routing hierarchy. > > Nodes should not make any assumptions about the structure of an > > address. Unicast addresses have no internal structure, except for > > knowledge of subnet prefixes, when automatically assigning an > > address to an interface, or knowledge of on-link prefixes and other > > routing boundaries, when delivering packets, as discussed in the > > previous paragraphs. > > > ---- > > I also suggest the following text for 4th paragraph of section 2.4.1; > > When automatically assigning a unicast address to an interface, > Interface Identifiers are 64 bits long except if the first three bits > of the address are 000. The rationale for using 64 bit Interface > Identifiers can be found in [RFC7421]. > > > ----- > > And that the following is added as the 3rd paragraph of section 2.4.6; > > > Link-Local addresses are different than other types of Unicast > addresses, in that by definition all nodes are aware of the > Link-Local prefix and used it as if it is a subnet and on-link prefix > for each link a node has, as described in section 2.4. Therefore, by > default all nodes automatically assign Link-Local addresses on each > interface and always treat Link-Local address as on-link for each > interface. > > > What do others think? > > Thanks > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --f403043ed734ffe3a30555a55fa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I still don't understand what your "on-link pref= ix" is.=C2=A0

"on-li= nk" is a bit that is only significant to the decision as to whether a = device believes the destination is directly reachable over the link or via = a router.

Different devi= ces can have a different opinion of this, even if they were attached to the= same link. Unlikely if the on-link state is expressed via RA PIOs, however= there is no requirement that all devices have the same on-link belief abou= t a range of addresses covered by a prefix.

It is only significant to ND and forwarding operation, = which is why it is defined in RFC4861, rather than RFC4291. A more accurate= name of 'on-link' and 'off-link' would really be 'dire= ctly link reachable' or 'remotely reachable via router'.=C2=A0<= /div>

The exception is Link Lo= cal destinations, which default to on-link/directly link reachable. That ca= nnot currently be overridden.=C2=A0https://tools.ietf.org/html/draft-= smith-6man-link-locals-off-link-00 proposed how LL destinations could b= e flipped to being considered remotely reachable for cases where it would b= e useful.

Your text belo= w is making it sound far more significant and also sounds a bit like someth= ing different to an ND related operational bit. It sounds like you're d= escribing something different.

Regards,
Mark.

On 1 Aug. 2017 08:32, "David Fa= rmer" <farmer@umn.edu> wro= te:
Recent discussion on the list have convinced me that section 2.4 really ne= eds to discuss on-link prefixes in some detail.=C2=A0 It needs to describe = their format similar to how the format of subnet prefixes are described, an= d describe how on-link prefixes are used by nodes. Also, a description of h= ow subnet prefixes are used is needed to differentiate the two types of pre= fixes are used.=C2=A0 Several other changes were needed to integrate these = major changes with the rest of the text, with other additional editorial ch= anges.=C2=A0

In my opinion the current text gives the fa= lse impression that there is always a common prefix for address assignment = and on-link determination, or the subnet prefix and the on-link prefix are = the same, which they frequently are, but are not require to be.
<= br>
I have use Interface Identifier as the right-hand side of the= on-link prefix, but this could have a different name if that is the consen= sus of the work group, but I think Interface Identifier makes the most sens= e.
=C2=A0
A few additional points;
- Section 2.1 is quite c= lear "IPv6 addres= ses of all types are assigned to interfaces, not nodes." So, I think t= he=C2=A0"node address" in the first diagram should be rena= med to "interface address".=C2=A0

- =C2= =A0Include are changes to the 4th paragraph of section 2.4.1, based on this= rewrite of section 2.4, scoping the definition of 64 bit Interface Identif= iers to "When automaticall= y assigning a unicast address to an interface". with that most of exce= ptions=C2=A0are not needed any longer.

- =C2=A0Include is an additi= onal paragraph for the Link-Local section 2.4.6, based on his rewrite=C2=A0= of section 2.4, saying that &qu= ot;by definition all nodes are aware of=C2=A0the=C2=A0
Link-Local prefix and used it as i= f it is a subnet and on-link=C2=A0prefix".

<= br>
I suggest the following text for section 2.4, use as you see = fit;

<= /div>
=
IPv6 unicast addresses a= re aggregatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses= under Classless Inter-Domain
Routing.

IPv6 unicast routing and on-link determination are based on pref= ixes=C2=A0
= of any valid length up to 128 bits[BCP198], which are typically, but=C2=A0<= /font>
not necessa= rily, the same as the subnet prefixes used to=C2=A0
automatically=C2=A0assign an=C2=A0address to an interface.=C2=A0<= /div>

<= /div>
There are several types = of unicast addresses in IPv6, in particular,
Global Unicast, Local unicast, and Link-L= ocal unicast.=C2=A0 There are
also some special-purpose subtypes of Global Unicast, su= ch as IPv6
= addresses with embedded IPv4 addresses.=C2=A0 Additional address types or
subtypes can= be defined in the future.

IPv6 nodes may have considerable or little knowledge of the inter= nal
structu= re of the IPv6 address, depending on the role the node plays
(for instance, host versu= s router). Further, the internal=C2=A0structure=C2=A0
of a unicast address varies subtly based how the ad= dress=C2=A0is being=C2=A0=
used (for instance, when=C2= =A0automatically=C2= =A0assigning an addr= ess=C2=A0to an=C2=A0=
interface= versus delivering packets).=C2=A0

Except as described below, and at a minimum, a node wil= l consider=C2=A0
that unicast addresses (including those for its own interfaces) have= =C2=A0
no i= nternal structure:

+------------------------= -----------------------------------------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface address =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
+---------= --------------------------------------------------------+<= /div>

<= /div>
A node may be aware of s= ubnet prefix(es) for the link(s) it is=C2=A0
attached to. By default such nodes will a= utomatically assign unicast
addresses to the interface(s) that are attached to those l= ink(s), by
= prepending the subnet prefix(es) to the Interface Identifier(s) for=C2=A0
those link(s= ). Where different link(s) may have different values for=C2=A0
=
n:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 128-n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-------------= ------------------+---------------------------------+
| =C2=A0 =C2=A0 =C2=A0= =C2=A0subnet prefix =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0interface ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+------------------= -------------+---------------------------------+

A= node may also be aware of on-link prefix(es) for the link(s) it is<= /div>
attached to. Such = nodes may use the on-link prefix(es) to determine=C2=A0
<= div>
the unicast addresses for whic= h packets may be locally delivered on
the attached link(s). Where different link(s) ma= y have different=C2=A0
values for n:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 128-n bits = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-------------------------------+-----= ----------------------------+
| =C2=A0 =C2=A0 =C2=A0 on-link prefix =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface ID = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------------------------+-----------= ----------------------+

A node may be aware of router(s) available on the link(s) it is= =C2=A0
atta= ched to. Such nodes may send packets to the router(s) for=C2=A0
delivery, especially f= or the unicast address for which packets cannot
be locally delivered on a node's a= ttached link(s).

= A router may have no more knowledge of the internal structure of=C2=A0
unicast address= es than any other node. However, generally routers=C2=A0
=
are attached to more links th= an other nodes and will usually have=C2=A0
knowledge of one or more hierarchical bound= aries through the=C2=A0
operation of routing protocols.=C2=A0 The known boundaries wil= l differ=C2=A0
from router to router, depending on what position the router holds=C2= =A0
in the = routing hierarchy.

Nodes should n= ot make any assumptions about the structure of an=C2=A0
address. Unicast=C2=A0addresses have no=C2=A0internal=C2=A0structure,=C2=A0except for
kn=
owledge of=C2=A0subnet =
prefixes,=C2=A0when=C2=A0automatically=C2=A0assigning an 
address to an interface, or=C2=A0knowledge=C2=A0of=C2=A0on-link=C2=A0prefixes and other 
routing=C2=A0boundaries,=C2=A0when=C2=A0<=
/span>d=
elivering=C2=A0packets, as discussed in the 
previous paragra=
phs.

----


When automatically assigning a unicast address to= an interface,
Interface Identifiers are 64 bits long except if the first three bits
of the addre= ss are 000. The rationale for using 64 bit Interface=C2=A0
Identifiers can be found in= [RFC7421].=C2=A0

-----

And that the following is added as= the 3rd paragraph of section 2.4.6;


Link-Local addresses are different=C2=A0than other typ= es=C2=A0of Unicast= =C2=A0
add= resses, in that by definition all nodes are aware of=C2=A0the=C2=A0
Link-Local prefix and used it as if it i= s a subnet and on-link=C2=A0pref= ix
for each= link a node has,=C2=A0as described in section 2.4.=C2=A0Therefore, by=C2=A0
default all=C2=A0= nodes=C2=A0automatically assign Link-Loc= al=C2=A0addresses on= each=C2=A0
interface and always treat=C2=A0Link-Local address= as=C2=A0on-link=C2=A0for each=C2=A0
interface.
What do others think?

Thanks

=C2=A0--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David = Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
N= etworking & Telecommunication Services
Office of Information Technol= ogy
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0= =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

--f403043ed734ffe3a30555a55fa0-- From nobody Mon Jul 31 20:25:41 2017 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 DF6B0131CE5 for ; Mon, 31 Jul 2017 20:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxNYaeV-thM8 for ; Mon, 31 Jul 2017 20:25:38 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 D62D5127ABE for ; Mon, 31 Jul 2017 20:25:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 5B81EB48 for ; Tue, 1 Aug 2017 03:25:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2WCobhVhZ0G for ; Mon, 31 Jul 2017 22:25:37 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 0AAB6B4C for ; Mon, 31 Jul 2017 22:25:36 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id y23so1591519uah.15 for ; Mon, 31 Jul 2017 20:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aCmevjRW7yK1fhh9BByb2jyfN3gLVNXM0D6H/ULx9ho=; b=WL2ecmkyR5sgTvkPT0t3AqcyrUoCvRfiEM/2Pi3TzSxQ/Vjqx0rzhjFVDyTaqqXj38 S1zBQsfTZc5+rzdwiEpfYKUwgpzGrX4iySgvYP3CAm3u2NOJCFpDT7yMHhjsj77joaeK PZjd5HoWiAtbAxb2tmpwHntFz7z5CDTp9o1btrkaD5vzttdCFA4diVkiXeFRv02KDYjv xvHRqYrRPi2DLYvHqL2/qFG+XqemAajKRj+VIPoJDwtxQlLZtE0UJ3xJfTByMLHkNpIw 1ckbErdyzIEEugIs6obOrhVhWoIFpD/jMc/MOdofPIFMtuFEz6I2DnbDxWB8a0nnGfe2 pRXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aCmevjRW7yK1fhh9BByb2jyfN3gLVNXM0D6H/ULx9ho=; b=b0PinwGurkllYDJ6NRtRuflsT0HOC4hZAOd6gW3+8V5nL9zSLFgi3iLehwthqWT7qa YQ5XONyq+mw58KW3S2ummmr91K1qru9ioUReXCT7AoE2lu+xZKmJFlWO1b4uIKaLdH2q j7BIjjqnPbbIMf01M8JzoHg0dUx4BKhQuAd0bH/OV+O/IHLUYBGcYl73INpeSyA1K1/e 8TW1JQAqaVBOE+2fIblLGjk1ObxcyIJOVbEWeHrA+RjIyXY7wBKgT3j31W2rJC9VNAcN aIi9OpFu1YE5LpAKa/6Yy4uJtRJVuKPhFRp93lXTnLVZ/i8DOHc9OxfyrNTzWdenyYGo wuyA== X-Gm-Message-State: AIVw111LXneCOzwQ+KrwOt2iKUifWJVcY/0aVMJrmx+QFTY7kP6OK5pi xFFKdwYhiF2n8rAtm9woVEzlDV6Vwn9JPYCj68h+7AODOHZMMuttfLUWLZArFH+gSpoDRTewqtS zKd6+bg7k1G1XRio= X-Received: by 10.159.60.4 with SMTP id u4mr11763338uah.1.1501557936235; Mon, 31 Jul 2017 20:25:36 -0700 (PDT) X-Received: by 10.159.60.4 with SMTP id u4mr11763334uah.1.1501557935952; Mon, 31 Jul 2017 20:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 31 Jul 2017 20:25:35 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 31 Jul 2017 22:25:35 -0500 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Mark Smith Cc: 6man WG Content-Type: multipart/alternative; boundary="f403043ed54c61e9bc0555a8b34c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 03:25:40 -0000 --f403043ed54c61e9bc0555a8b34c Content-Type: text/plain; charset="UTF-8" On Mon, Jul 31, 2017 at 6:27 PM, Mark Smith wrote: > I still don't understand what your "on-link prefix" is. > Oh, come on, you seem to understand me just fine. > "on-link" is a bit that is only significant to the decision as to whether > a device believes the destination is directly reachable over the link or > via a router. > No, it is only a bit within a PIO, hosts maintain a Prefix List, which it seems quite logical to call a member of this list a "on-link prefix". >From Section 5.1 or RFC 4861; Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement. Or, from Section 3 of RFC 5942; Any node attached to the link can send a datagram directly to an on-link address without forwarding the datagram through a router. However, in order for a node to know that a destination is on-link, it must obtain configuration information to that effect. In IPv6, there are two main ways of maintaining information about on-link destinations. First, a host maintains a Prefix List that identifies ranges of addresses that are to be considered on-link. Second, Redirects can identify individual destinations that are on-link; such Redirects update the Destination Cache. The Prefix List is populated via the following means: * Receipt of a valid Router Advertisement (RA) that specifies a prefix with the L-bit set. Such a prefix is considered on-link for a period specified in the Valid Lifetime and is added to the Prefix List. (The link-local prefix is effectively considered a permanent entry on the Prefix List.) * Indication of an on-link prefix (which may be a /128) via manual configuration, or some other yet-to-be-specified configuration mechanism. A Redirect can also signal whether an address is on-link. If a host originates a packet, but the first-hop router routes the received packet back out onto the same link, the router also sends the host a Redirect. If the Target and Destination Address of the Redirect are the same, the Target Address is to be treated as on-link as specified in Section 8 of [RFC4861]. That is, the host updates its Destination Cache (but not its Prefix List -- though the impact is similar). > Different devices can have a different opinion of this, even if they were > attached to the same link. Unlikely if the on-link state is expressed via > RA PIOs, however there is no requirement that all devices have the same > on-link belief about a range of addresses covered by a prefix. > > It is only significant to ND and forwarding operation, which is why it is > defined in RFC4861, rather than RFC4291. A more accurate name of 'on-link' > and 'off-link' would really be 'directly link reachable' or 'remotely > reachable via router'. > RFC 4291bis is talking about routing in section 2.4 (section 2.5 in RFC 4291) and implying that is based on the subnet prefix. Further, by using the term "subnet prefix" it is also implying that on-link determination is based on this prefix, which is not necessarily the case. Continued below; > The exception is Link Local destinations, which default to > on-link/directly link reachable. That cannot currently be overridden. > https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00 > proposed how LL destinations could be flipped to being considered remotely > reachable for cases where it would be useful. > Your document seem to acknowledge that hosts maintain an "Prefix List" of on-link prefixes, and you are removing things from this list of on-link prefixes. > Your text below is making it sound far more significant and also sounds a > bit like something different to an ND related operational bit. It sounds > like you're describing something different. > Further if you believe that a subnet prefix must be 64 bits long because an IID is defined as 64 bits, and at least for SLAAC I believe that is true. However, even SLAAC is quit clear that on-link determination is any length, and therefore the prefix used for on-link determination needs to be distinguished from a subnet prefix some how, that's what I'm trying to do. Otherwise you need to be explicit a subnet prefixes can be any length when used for on-link determination. If you want to go that route, I'd be fine with that, but you and others have objected to that. >From Section 5.5.3. of RFC 4862; If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2). It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. > Regards, > Mark. > Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403043ed54c61e9bc0555a8b34c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 31, 2017 at 6:27 PM, Mark Smith <markzzzsmith@gmail.c= om> wrote:
I still don't understand what your "on-link p= refix" is.=C2=A0

Oh, come on, yo= u seem to understand me just fine.
=C2=A0
"= on-link" is a bit that is only significant to the decision as to wheth= er a device believes the destination is directly reachable over the link or= via a router.

No, it is only a= bit within a PIO, hosts maintain a Prefix List, which it seems quite logic= al to call a member of this list a "on-link prefix".=C2=A0
<= div>
From Section 5.1 or RFC 4861;

<= div>=C2=A0 =C2=A0 =C2=A0 Prefix List =C2=A0- A list of the prefixes that de= fine a set of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses that are on-link.=C2=A0 Prefix List en= tries
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0are created from information received in Router
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Advertisements.=C2=A0 Each entry has an associated
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0invalidat= ion timer value (extracted from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertisement) used to expi= re prefixes when they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0become invalid.=C2=A0 A special "inf= inity" timer value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specifies that a prefix remains valid fo= rever,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0unless a new (finite) value is received in a
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0subsequent advertisement.

Or, from Sectio= n 3 of RFC 5942;

=C2=A0 =C2=A0 =C2=A0 =C2=A0A= ny node attached to the link can send a datagram directly
=C2=A0 = =C2=A0 =C2=A0 =C2=A0to an on-link address without forwarding the datagram t= hrough a
=C2=A0 =C2=A0 =C2=A0 =C2=A0router.=C2=A0 However, in ord= er for a node to know that a destination
=C2=A0 =C2=A0 =C2=A0 =C2= =A0is on-link, it must obtain configuration information to that
= =C2=A0 =C2=A0 =C2=A0 =C2=A0effect.=C2=A0 In IPv6, there are two main ways o= f maintaining
=C2=A0 =C2=A0 =C2=A0 =C2=A0information about on-lin= k destinations.=C2=A0 First, a host maintains
=C2=A0 =C2=A0 =C2= =A0 =C2=A0a Prefix List that identifies ranges of addresses that are to be<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0considered on-link.=C2=A0 Second, Redi= rects can identify individual
=C2=A0 =C2=A0 =C2=A0 =C2=A0destinat= ions that are on-link; such Redirects update the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0Destination Cache.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0The Prefix List is populated via the following means:
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0Receipt of a valid Router = Advertisement (RA) that specifies a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 prefix with the L-bit set.=C2=A0 Such a prefix is considered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on-link for a period specified in the= Valid Lifetime and is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 added t= o the Prefix List. =C2=A0(The link-local prefix is
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 effectively considered a permanent entry on the Prefix= List.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0Indicat= ion of an on-link prefix (which may be a /128) via
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 manual configuration, or some other yet-to-be-specifie= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration mechanism.

=C2=A0 =C2=A0 =C2=A0 =C2=A0A Redirect can also signal= whether an address is on-link.=C2=A0 If a
=C2=A0 =C2=A0 =C2=A0 = =C2=A0host originates a packet, but the first-hop router routes the
=C2=A0 =C2=A0 =C2=A0 =C2=A0received packet back out onto the same link, = the router also
=C2=A0 =C2=A0 =C2=A0 =C2=A0sends the host a Redir= ect.=C2=A0 If the Target and Destination Address
=C2=A0 =C2=A0 = =C2=A0 =C2=A0of the Redirect are the same, the Target Address is to be trea= ted
=C2=A0 =C2=A0 =C2=A0 =C2=A0as on-link as specified in Section= 8 of [RFC4861].=C2=A0 That is, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0ho= st updates its Destination Cache (but not its Prefix List --
=C2= =A0 =C2=A0 =C2=A0 =C2=A0though the impact is similar).
=C2= =A0
Different devices can have a different opinion of this,= even if they were attached to the same link. Unlikely if the on-link state= is expressed via RA PIOs, however there is no requirement that all devices= have the same on-link belief about a range of addresses covered by a prefi= x.

It is only significan= t to ND and forwarding operation, which is why it is defined in RFC4861, ra= ther than RFC4291. A more accurate name of 'on-link' and 'off-l= ink' would really be 'directly link reachable' or 'remotely= reachable via router'.=C2=A0

RFC 4291bis is talking about routing in section 2.4 (section 2.5 in RFC = 4291) and implying that is based on the subnet prefix. Further, by using th= e term "subnet prefix" it is also implying that on-link determina= tion is based on this prefix, which is not necessarily the case. Continued = below;
=C2=A0
The exception is Link Local destina= tions, which default to on-link/directly link reachable. That cannot curren= tly be overridden.=C2=A0https://tools.ietf.org= /html/draft-smith-6man-link-locals-off-link-00 proposed how LL des= tinations could be flipped to being considered remotely reachable for cases= where it would be useful.

Your= document seem to acknowledge that hosts maintain an "Prefix List"= ; of on-link prefixes, and you are removing things from this list of on-lin= k prefixes.
=C2=A0=C2=A0
Your text below is m= aking it sound far more significant and also sounds a bit like something di= fferent to an ND related operational bit. It sounds like you're describ= ing something different.

Furthe= r if you believe that a subnet prefix must be 64 bits long because an IID i= s defined as 64 bits, and at least for SLAAC I believe that is true. Howeve= r, even SLAAC is quit clear that on-link determination is any length, and t= herefore the prefix used for on-link determination needs to be distinguishe= d from a subnet prefix some how, that's what I'm trying to do.=C2= =A0 Otherwise you need to be explicit a subnet prefixes can be any length w= hen used for on-link determination. If you want to go that route, I'd b= e fine with that, but you and others have objected to that. =C2=A0

From Section=C2=A05.5.3. of RFC 4862;

=
=C2=A0 =C2=A0 =C2=A0 If the sum of the prefix length and interfac= e identifier length
=C2=A0 =C2=A0 =C2=A0 does not equal 128 bits,= the Prefix Information option MUST be
=C2=A0 =C2=A0 =C2=A0 ignor= ed.=C2=A0 An implementation MAY wish to log a system management
= =C2=A0 =C2=A0 =C2=A0 error in this case.=C2=A0 The length of the interface = identifier is
=C2=A0 =C2=A0 =C2=A0 defined in a separate link-typ= e specific document, which should
=C2=A0 =C2=A0 =C2=A0 also be co= nsistent with the address architecture [RFC4291] (see
=C2=A0 =C2= =A0 =C2=A0 Section 2).

=C2=A0 =C2=A0 =C2=A0 It is = the responsibility of the system administrator to ensure
=C2=A0 = =C2=A0 =C2=A0 that the lengths of prefixes contained in Router Advertisemen= ts
=C2=A0 =C2=A0 =C2=A0 are consistent with the length of interfa= ce identifiers for that
=C2=A0 =C2=A0 =C2=A0 link type.=C2=A0 It = should be noted, however, that this does not mean
=C2=A0 =C2=A0 = =C2=A0 the advertised prefix length is meaningless.=C2=A0 In fact, the
=C2=A0 =C2=A0 =C2=A0 advertised length has non-trivial meaning for on= -link
=C2=A0 =C2=A0 =C2=A0 determination in [RFC4861] where the s= um of the prefix length and
=C2=A0 =C2=A0 =C2=A0 the interface id= entifier length may not be equal to 128.=C2=A0 Thus, it
=C2=A0 = =C2=A0 =C2=A0 should be safe to validate the advertised prefix length here,= in
=C2=A0 =C2=A0 =C2=A0 order to detect and avoid a configuratio= n error specifying an
=C2=A0 =C2=A0 =C2=A0 invalid prefix length = in the context of address autoconfiguration.
=C2=A0
Regards,
Mark.

Thanks.
=C2=A0
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommuni= cation Services
Office of Information Technology
University of Minnes= ota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone= : 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--f403043ed54c61e9bc0555a8b34c-- From nobody Mon Jul 31 23:10:23 2017 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 AF12E131C24 for ; Mon, 31 Jul 2017 23:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.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 rq9a60Y7dXU9 for ; Mon, 31 Jul 2017 23:10:18 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF48131748 for ; Mon, 31 Jul 2017 23:10:18 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id r199so2403335vke.4 for ; Mon, 31 Jul 2017 23:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2sMcS19pbHlUvl/180O84QdCwYxl3AoZE7L3RHdBK+4=; b=ctT37bCTLyNWV+vVQlKrmh0GB9ny7Emf+q40aZm0G0i75+OttYJy18/duAiiDIcGKJ Pw8BcH2pGmzWBDwymtu0BgrNqpZBeTxR43kgble/v/B4fhrAh4AdJMGbPaUb658BaNmG V91x55WVEFQ5ZGYl/OAQ/jIfJ0JN1ht3BlFV3KYn2yQ2wWhBM8RMmYQiqCcFSvCHCpGC HPM1uOx386fA/2a5MJvM0DOh6IguG7ybxTLC6olVsxE8+Zrr5pi5VihZRSuggr/Zm01K qjJE76rVguJZ1P7A/1/QWJJ/Lx94CD/fMrNOLhj3vo3z7AeoWGLamIO44m2RCNLlMFxk R3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2sMcS19pbHlUvl/180O84QdCwYxl3AoZE7L3RHdBK+4=; b=nM4jF9NsnBWEJuFcBc+OLvdtOcJHo5daAAw5mKZCzd8+QuvvO6RoYsns9rCAKisI2T TVF20M9K81d9VrcRthdetUY8++M9TUak0Z3oAe2D3S+8Nvg3ygVVHckkaQ3mPuHbkD7p IrANOd3DbeOsfrFRpWqbyU7ncr+ly+sS6NQUrht9EPeOKB4g8UgN2ff+GUIZeqF+sNjh XTHmBJ47+QHHhb+RW+y9mWuG7wrMm0UhLakYwm54RS6HuSmy8mkiC+doDLqz3WaPuaSQ WbnKxucO8Ofl8WAWUSHRYTMv5YVhEi5EDdp1KsWPepwrwCQuEQc71nEcQEwZaBU1qqDV hb4g== X-Gm-Message-State: AIVw1121g5VYNtKFUnisNsOYdmzzri35cPEPi8HDgUOp4ZFxRjSjyL7h XCrYVm1m9GeD7WAmXH4T+tRiCTc6jA== X-Received: by 10.31.84.130 with SMTP id i124mr11282493vkb.41.1501567817026; Mon, 31 Jul 2017 23:10:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Mon, 31 Jul 2017 23:10:16 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Mon, 31 Jul 2017 23:10:16 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 1 Aug 2017 16:10:16 +1000 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: David Farmer Cc: 6man WG Content-Type: multipart/alternative; boundary="001a114e5bfc570fa00555ab0019" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 06:10:22 -0000 --001a114e5bfc570fa00555ab0019 Content-Type: text/plain; charset="UTF-8" Ok, going back to your original email. On 1 Aug. 2017 08:32, "David Farmer" wrote: Recent discussion on the list have convinced me that section 2.4 really needs to discuss on-link prefixes in some detail. It needs to describe their format What is this format? I can't guess what it is. As RFC5942 says, On-link or offlink is a property associated with a subnet prefix. It doesn't change the format of the subnet prefix. If anything, "on-link prefix" is short for "on-link subnet prefix". >similar to how the format of subnet prefixes are described, and describe how on-link prefixes are used by nodes. Also, a description of how subnet prefixes are used is needed to differentiate the two types of prefixes are used. Several other changes were needed to integrate these major changes with the rest of the text, with other additional editorial changes. RFC5942 does all that, reference it. In my opinion the current text gives the false impression that there is always a common prefix for address assignment and on-link determination, or the subnet prefix and the on-link prefix are the same, which they frequently are, but are not require to be. This is confusing. What address generation and configuration method is being used? DHCPv6, SLAAC or manual configuration? I don't understand how the subnet prefix and the onlink (subnet) prefix can be different. I have use Interface Identifier as the right-hand side of the on-link prefix, but this could have a different name if that is the consensus of the work group, but I think Interface Identifier makes the most sense. I can't guess what property is being described that could have a different name. If stateful DHCPv6 is the unstated context, is what you and others describing the range of addresses the DHCPv6 server hands out? That is a parameter of the DHCPv6 server's config, not something more abstract to addresses regardless of how they're configured. It could be given a DHCPv6 specific name in rfc3315bis if necessary. The lower portions of those addresses are still interface identifiers, because they identify interfaces attached to a link. That is a generic property of an address regardless of if it was configured using SLAAC, DHCPV6 or manually configured. In these emails that I find confusing, I think people are sometimes not stating necessary context, and are conflating concepts and properties that are generic to addresses, regardless of how they're generated and configured with things that are specific to how addresses are generated and configured. There are properties of addresses that are generic, regardless of how the address is generated, configured and used. The location of the boundary between subnet prefix and IID portions is an examples. The place for their definition is RFC4291. There are properties specific to how addresses are generated. There are properties specific to how addresses are configured. Sometimes they'll be tightly coupled together because the generation method depends on properties of the configuration method. The range of addresses a DHCPv6 server hands out is a property specific to DHCPv6 based address configuration. It means nothing to SLAAC, SLAAC uses the full IID space in the subnet prefix. For these properties, they're best described in address generation/configuration specific RFCs, e.g., 4862, 3315, 4941. There are properties of addresses that are specific to where the address is used, yet not related to how it was generated or configured. On-link/off-link is a specific example, described in RFC4862 and RFC5942. Regards, Mark. A few additional points; - Section 2.1 is quite clear "IPv6 addresses of all types are assigned to interfaces, not nodes." So, I think the "node address" in the first diagram should be renamed to "interface address". - Include are changes to the 4th paragraph of section 2.4.1, based on this rewrite of section 2.4, scoping the definition of 64 bit Interface Identifiers to "When automatically assigning a unicast address to an interface". with that most of exceptions are not needed any longer. - Include is an additional paragraph for the Link-Local section 2.4.6, based on his rewrite of section 2.4, saying that "by definition all nodes are aware of the Link-Local prefix and used it as if it is a subnet and on-link prefix". I suggest the following text for section 2.4, use as you see fit; IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing. IPv6 unicast routing and on-link determination are based on prefixes of any valid length up to 128 bits[BCP198], which are typically, but not necessarily, the same as the subnet prefixes used to automatically assign an address to an interface. There are several types of unicast addresses in IPv6, in particular, Global Unicast, Local unicast, and Link-Local unicast. There are also some special-purpose subtypes of Global Unicast, such as IPv6 addresses with embedded IPv4 addresses. Additional address types or subtypes can be defined in the future. IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). Further, the internal structure of a unicast address varies subtly based how the address is being used (for instance, when automatically assigning an address to an interface versus delivering packets). Except as described below, and at a minimum, a node will consider that unicast addresses (including those for its own interfaces) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | interface address | +-----------------------------------------------------------------+ A node may be aware of subnet prefix(es) for the link(s) it is attached to. By default such nodes will automatically assign unicast addresses to the interface(s) that are attached to those link(s), by prepending the subnet prefix(es) to the Interface Identifier(s) for those link(s). Where different link(s) may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ A node may also be aware of on-link prefix(es) for the link(s) it is attached to. Such nodes may use the on-link prefix(es) to determine the unicast addresses for which packets may be locally delivered on the attached link(s). Where different link(s) may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | on-link prefix | interface ID | +-------------------------------+---------------------------------+ A node may be aware of router(s) available on the link(s) it is attached to. Such nodes may send packets to the router(s) for delivery, especially for the unicast address for which packets cannot be locally delivered on a node's attached link(s). A router may have no more knowledge of the internal structure of unicast addresses than any other node. However, generally routers are attached to more links than other nodes and will usually have knowledge of one or more hierarchical boundaries through the operation of routing protocols. The known boundaries will differ from router to router, depending on what position the router holds in the routing hierarchy. Nodes should not make any assumptions about the structure of an address. Unicast addresses have no internal structure, except for knowledge of subnet prefixes, when automatically assigning an address to an interface, or knowledge of on-link prefixes and other routing boundaries, when delivering packets, as discussed in the previous paragraphs. ---- I also suggest the following text for 4th paragraph of section 2.4.1; When automatically assigning a unicast address to an interface, Interface Identifiers are 64 bits long except if the first three bits of the address are 000. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. ----- And that the following is added as the 3rd paragraph of section 2.4.6; Link-Local addresses are different than other types of Unicast addresses, in that by definition all nodes are aware of the Link-Local prefix and used it as if it is a subnet and on-link prefix for each link a node has, as described in section 2.4. Therefore, by default all nodes automatically assign Link-Local addresses on each interface and always treat Link-Local address as on-link for each interface. What do others think? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a114e5bfc570fa00555ab0019 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, going back to your original email.

On 1 Aug. 2017 08:32, "= ;David Farmer" <farmer@umn.edu> wrote:
Recent discussion on the list h= ave convinced me that section 2.4 really needs to discuss on-link prefixes = in some detail.=C2=A0 It needs to describe their format
=

What is thi= s format? I can't guess what it is.


As RFC5942 says, On-link or off= link is a property associated with a subnet prefix. It doesn't change t= he format of the subnet prefix.

If anything, "on-link prefix" is short for "on-lin= k subnet prefix".

<= br>
>similar to how the format of subnet prefixes= are described, and describe how on-link prefixes are used by nodes. Also, = a description of how subnet prefixes are used is needed to differentiate th= e two types of prefixes are used.=C2=A0 Several other changes were needed t= o integrate these major changes with the rest of the text, with other addit= ional editorial changes.=C2=A0


RFC5942 does all that, reference it.

=
<= div dir=3D"ltr">

In my opinion the current text gives th= e false impression that there is always a common prefix for address assignm= ent and on-link determination, or the subnet prefix and the on-link prefix = are the same, which they frequently are, but are not require to be.

This is confusing. What address generation and configuration method i= s being used? DHCPv6, SLAAC or manual configuration?

I don't understand how the subnet prefix a= nd the onlink (subnet) prefix can be different.

=
I have use Interface Identifier as the right-hand side of the o= n-link prefix, but this could have a different name if that is the consensu= s of the work group, but I think Interface Identifier makes the most sense.=


I can't guess what property i= s being described that could have a different name.
=
If stateful DHCPv6 is the unstated context, is = what you and others describing the range of addresses the DHCPv6 server han= ds out?

That is a parame= ter of the DHCPv6 server's config, not something more abstract to addre= sses regardless of how they're configured. It could be given a DHCPv6 s= pecific name in rfc3315bis if necessary.

<= div dir=3D"auto">The lower portions of those addresses are still interface = identifiers, because they identify interfaces attached to a link. That is a= generic property of an address regardless of if it was configured using SL= AAC, DHCPV6 or manually configured.


In these emails that I find confusi= ng, I think people are sometimes not stating necessary context, and are con= flating concepts and properties that are generic to addresses, regardless o= f how they're generated and configured with things that are specific to= how addresses are generated and configured.

There are properties of addresses that are generic, re= gardless of how the address is generated, configured and used. The location= of the boundary between subnet prefix and IID portions is an examples. The= place for their definition is RFC4291.

There are properties specific to how addresses are generate= d. There are properties specific to how addresses are configured. Sometimes= they'll be tightly coupled together because the generation method depe= nds on properties of the configuration method. The range of addresses a DHC= Pv6 server hands out is a property specific to DHCPv6 based address configu= ration. It means nothing to SLAAC, SLAAC uses the full IID space in the sub= net prefix.

For these pr= operties, they're best described in address generation/configuration sp= ecific RFCs, e.g., 4862, 3315, 4941.

There are properties of addresses that are specific to where t= he address is used, yet not related to how it was generated or configured. = On-link/off-link is a specific example, described in RFC4862 and RFC5942.

Regards,
Mark.


<= div dir=3D"auto">
=C2= =A0
A few additional points;
- Section 2.1 is quite clear "= ;IPv6 addresses of all= types are assigned to interfaces, not nodes." So, I think the=C2=A0"node address" in the first diagram should be renamed to &qu= ot;interface address".=C2=A0

- =C2=A0Include = are changes to the 4th paragraph of section 2.4.1, based on this rewrite of= section 2.4, scoping the definition of 64 bit Interface Identifiers to "When automatically assigning= a unicast address to an interface". with that most of exceptions=C2= =A0are not needed any longer.

- =C2=A0Include is an additional para= graph for the Link-Local section 2.4.6, based on his rewrite=C2=A0of sectio= n 2.4, saying that "by def= inition all nodes are aware of=C2=A0the=C2=A0
Link-Local prefix and used it as if it is= a subnet and on-link=C2=A0prefix".


I suggest the following text for section 2.4, use as you see fit;

IPv6 unicast addresses are aggr= egatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses under = Classless Inter-Domain
Routing.

IPv6 unicast routing and on-link determination are based on prefixes=C2= =A0
of any = valid length up to 128 bits[BCP198], which are typically, but=C2=A0<= /div>
not necessarily, t= he same as the subnet prefixes used to=C2=A0
automatically=C2=A0assign an=C2=A0address to an interface.=C2=A0
=

=
There are several types of un= icast addresses in IPv6, in particular,
Global Unicast, Local unicast, and Link-Local = unicast.=C2=A0 There are
also some special-purpose subtypes of Global Unicast, such as= IPv6
addre= sses with embedded IPv4 addresses.=C2=A0 Additional address types or=
subtypes can be d= efined in the future.

IPv6 nodes may have considerable or little knowledge of the internal
structure of= the IPv6 address, depending on the role the node plays
<= div>
(for instance, host versus rou= ter). Further, the internal=C2=A0structure=C2=A0
of a unicast address varies subtly based how the address= =C2=A0is being=C2=A0
used (for instance, when=C2=A0automatically=C2=A0assigning an address=C2= =A0to an=C2=A0
interface versu= s delivering packets).=C2=A0

Except as described below, and at a minimum, a node will consid= er=C2=A0
th= at unicast addresses (including those for its own interfaces) have=C2=A0
no internal s= tructure:
<= br>
| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 128 bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------------------------------------------------------------+
<= font face=3D"monospace, monospace">| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface address =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
+----------------= -------------------------------------------------+

A node may be aware of subnet p= refix(es) for the link(s) it is=C2=A0
attached to. By default such nodes will automati= cally assign unicast
addresses to the interface(s) that are attached to those link(s),= by
prepend= ing the subnet prefix(es) to the Interface Identifier(s) for=C2=A0
those link(s). Wher= e different link(s) may have different values for=C2=A0
<= div>
n:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 128-n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------------------= -----------+---------------------------------+
=
| =C2=A0 =C2=A0 =C2=A0 =C2=A0= subnet prefix =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0interface ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------------------= ------+---------------------------------+
=

A node m= ay also be aware of on-link prefix(es) for the link(s) it is
attached to. Such nodes m= ay use the on-link prefix(es) to determine=C2=A0
the unicast addresses for which packe= ts may be locally delivered on
the attached link(s). Where different link(s) may have = different=C2=A0
values for n:

+-------------------------------+-----------= ----------------------+
| =C2=A0 =C2=A0 =C2=A0 on-link prefix =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface ID =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------------------------+------------------= ---------------+

A node may be aware of router(s) available on the link(s) it is=C2=A0<= /font>
attached to= . Such nodes may send packets to the router(s) for=C2=A0
=
delivery, especially for the = unicast address for which packets cannot
be locally delivered on a node's attached= link(s).
<= br>
A route= r may have no more knowledge of the internal structure of=C2=A0
unicast addresses than= any other node. However, generally routers=C2=A0
are attached to more links than othe= r nodes and will usually have=C2=A0
knowledge of one or more hierarchical boundaries = through the=C2=A0
operation of routing protocols.=C2=A0 The known boundaries will diff= er=C2=A0
fr= om router to router, depending on what position the router holds=C2=A0
in the routing = hierarchy.

= Nodes should not make = any assumptions about the structure of an=C2=A0
address. Unicast=C2=A0addresses have no=C2=A0internal=C2=A0structure,=C2=A0except for
= knowledge of=C2=A0subnet prefixes,=C2=A0when=C2=A0automatically=C2=A0assigning an = 
address to an interface, or=C2=A0knowledge=C2=A0of=
=C2=A0on-link=C2=A0prefixes and other 
routing=C2=A0boundaries,=C2=A0wh=
en=C2=A0delivering=C2=A0packets, as discussed in the 
previous paragraphs.
<= br>
----

I also suggest the f= ollowing text for 4th paragraph of section 2.4.1;

When automatically= assigning a unicast address to an interface,
<= font face=3D"monospace, monospace">Interface Identifiers are 64 bits long e= xcept if the first three bits
of the address are 000. The rationale for using 64 bit I= nterface=C2=A0
Identifiers can be found in [RFC7421].=C2=A0

-----

And= that the following is added as the 3rd paragraph of section 2.4.6;


=
Link-Local addresses ar= e different=C2=A0than other types=C2=A0of Unicast=C2=A0
addresses, in that by definition all nodes are aw= are of=C2=A0the=C2= =A0
Link-Loca= l prefix and used it as if it is a subnet and on-link=C2=A0prefix
for each link a node has,=C2=A0as described in section 2.4.=C2=A0= Therefore, by=C2=A0
default all=C2=A0nodes=C2=A0automatically assign Link-Local=C2=A0addresses on each=C2=A0
interface and always treat=C2=A0Link-Local address as=C2=A0on-link=C2=A0for each=C2= =A0
interface.<= /div>

What do others think?

Thanks

=C2=A0--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecom= munication Services
Office of Information Technology
University of Mi= nnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-81= 2-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

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


--001a114e5bfc570fa00555ab0019--