From nobody Mon Sep 3 00:51:58 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22C130E0C for ; Mon, 3 Sep 2018 00:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 Q-UJKs1fpVz2 for ; Mon, 3 Sep 2018 00:51:56 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9060B12DD85 for <6man@ietf.org>; Mon, 3 Sep 2018 00:51:56 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id j8-v6so8245183pll.12 for <6man@ietf.org>; Mon, 03 Sep 2018 00:51:56 -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=hUKLwI+uSRie2dcbpdQnBpqcwBtwVo3z3sDSWtijFWQ=; b=n4FyyKArkwzUHLx9xngQT20HRIOPUbubRKOX8zqUqxI3/CgQQXrDZCCjoTfKdzlqE0 yz6Uyc++TpzuYca4C6tXuA0VCF9AtTwQDlELVqSDDQCpJcsirXOt9oHvKy2LqDLjOBuA JRfctRE+sKqLdvIWRGGloMnCBHzznX2ir4ROaK/23o9NXsIolLuW4c+WoIG8qGV5fOpK 941c1S2abHQO+kAZsc2sge1g7a5m/EPNkq0ujRTnJAwaetoOXmlLoK7TJlzXEasnuZMr EiGjxj0+lHD3Co8XstvQhfPmHg97GpECz1pQlFjZGza0+y4Avhq+NmabVmKvTe+VzLEE 7WGw== 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=hUKLwI+uSRie2dcbpdQnBpqcwBtwVo3z3sDSWtijFWQ=; b=czv6F2Ryv4zv9z3QwSN+VBG6pxW4wwJrCmuvCmvBF3H8h2H63f4zIl0FrUurF75xFS ky48mRn1I58i4gVTghpQVmhTkoDK5ZpmdSgt6OZJFcFQqTGFSsxu7rqY2Zsqq3Y+FZi4 /adXPWS43evdKeFDfiHFF2GQfR7z1YH2GE79uLmtYZUUi4n+4aLVkM1Jv8z2R8FVt1OX xLSZykVJFFjTzl5EFiamrFYAp/I4zsgc1v/VP5y96KH/ebNzhtrlYvAkF6FhlowZsjoA g2YhpFs3unAAgYW0bHRWRNtjTR04cqJy96IVVZilE7BFcbzpdmF2s5mP12yngh3GaT3q 0zDg== X-Gm-Message-State: APzg51DPUTsHqCjXre8SRvUiBakc1ZOTwt+DHknDnFGffEa8DAlXYHZB 1H8Vhmb4Ihi5kC/8gzOk+z9HF3gq X-Google-Smtp-Source: ANB0VdYu3Vs8v23JSrPfuEOMg/e6awT9oPDUx5CTOLyohf3yIbJ7I+Qj07Dnva5p8K4RDECqivQUuA== X-Received: by 2002:a17:902:8a90:: with SMTP id p16-v6mr27417801plo.106.1535961115833; Mon, 03 Sep 2018 00:51:55 -0700 (PDT) Received: from [59.29.43.14] ([59.29.43.14]) by smtp.gmail.com with ESMTPSA id v22-v6sm28181101pfi.60.2018.09.03.00.51.53 for <6man@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 00:51:54 -0700 (PDT) From: DY Kim Content-Type: multipart/alternative; boundary="Apple-Mail=_D64515C5-923B-4F55-9AE6-B8E128BA0F93" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Fwd: New Version Notification for draft-dykim-6man-sid6-00.txt Message-Id: <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> To: 6man <6man@ietf.org> Date: Mon, 3 Sep 2018 16:51:51 +0900 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 07:51:58 -0000 --Apple-Mail=_D64515C5-923B-4F55-9AE6-B8E128BA0F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve reposted a draft, this time to 6man, which was posted to = 6ops about a year ago but fell out of scope there since it involves some = changes to NDv6/DAD with added texts. I=E2=80=99d like to see whether there should be any interest in this = draft within the 6man group, possibly enough to justify the modification = of NDv6/DAD as suggested in this draft. Your comments are solicited. --- DY > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dykim-6man-sid6-00.txt > Date: 3 September 2018 at 16:46:04 GMT+9 > To: "DY Kim" >=20 >=20 > A new version of I-D, draft-dykim-6man-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. >=20 > Name: draft-dykim-6man-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2018-09-03 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt > Status: = https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-dykim-6man-sid6 >=20 >=20 > Abstract: > Deprecation of the subnet ID in IPv6 networking is proposed; the > subnet ID is set to zero so that all nodes in a site carry the same > prefix. While the procedures for neighbor discovery and duplicate > address detection have to be changed, possible simplification gains > in IPv6 networking including that of intra-site host- and subnet- > mobility might be worth the modification. Site-external behaviors > don't change through this modification, enabling incremental > deployment of the proposal. Sites of manageable sizes for which > scalability is not much a critical issue might consider the mode of > operation proposed in this document. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_D64515C5-923B-4F55-9AE6-B8E128BA0F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99ve reposted a draft, this time to 6man, which was posted to 6ops = about a year ago but fell out of scope there since it involves some = changes to NDv6/DAD with added texts.

I=E2=80=99d like to see whether there = should be any interest in this draft within the 6man group, possibly = enough to justify the modification of NDv6/DAD as suggested in this = draft.

Your = comments are solicited.

---
DY








Begin forwarded message:

Subject: = New Version = Notification for draft-dykim-6man-sid6-00.txt
Date: = 3 September 2018 at 16:46:04 = GMT+9
To: = "DY Kim" <dykim6@gmail.com>

A new version of I-D, draft-dykim-6man-sid6-00.txt
has been successfully submitted by DY Kim and posted to = the
IETF repository.

Name: = draft-dykim-6man-sid6
Revision: 00
Title:= = Subnet ID Deprecation for IPv6
Document date: = 2018-09-03
Group: Individual Submission
Pages:= = 17
URL: =            https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/
Htmlized:       https://tools.ietf.org/html/draft-dykim-6man-sid6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dykim-6man-sid6=


Abstract:
=   Deprecation of the subnet ID in IPv6 networking is proposed; = the
  subnet ID is set to zero so that all = nodes in a site carry the same
  prefix. =  While the procedures for neighbor discovery and duplicate
  address detection have to be changed, possible = simplification gains
  in IPv6 networking = including that of intra-site host- and subnet-
=   mobility might be worth the modification. =  Site-external behaviors
  don't change = through this modification, enabling incremental
=   deployment of the proposal.  Sites of manageable sizes = for which
  scalability is not much a critical = issue might consider the mode of
  operation = proposed in this document.



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


= --Apple-Mail=_D64515C5-923B-4F55-9AE6-B8E128BA0F93-- From nobody Mon Sep 3 01:09:38 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A01252B7 for ; Mon, 3 Sep 2018 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 yydvS716dMqn for ; Mon, 3 Sep 2018 01:09:35 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 C2284130DE2 for <6man@ietf.org>; Mon, 3 Sep 2018 01:09:34 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id b19-v6so164519wme.3 for <6man@ietf.org>; Mon, 03 Sep 2018 01:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zLGCaC5uKFJNj0hgruDFeswgz1mGujxJ6sLYIVhlIdg=; b=o7UkvACZQZyt5UZWniqss9cega0y+5qidnWnOLbapI3EIwEhv91uEN0CWX51W+SALm EoXw/fETFckXoTvDyAcjTtXM3iaamouu7TP5kIfuJfWs2vUcUxz8817xp5m7LWyeIE05 umMntFg/y0LpUZtFC6vdARNvzAsza4OY4Nr3itOvowsDc9tIVnaeVS2ZB6Hw50moEMdz 1HOLJiOU89d8546WwoQwkLc2PI5Y4lh7a2E1CPAPg79Z/c85ST+v1H2VTuKAxOFlS4I4 Pq8/GIQw6e8RW0so88MapeFs9t7caiPIXUfAqi9hNj31R28ICeSLnVVksojwcV+WGrMk LgTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zLGCaC5uKFJNj0hgruDFeswgz1mGujxJ6sLYIVhlIdg=; b=p0umubaivuSlMUEE9dU3jN3zc87e9iQ4rXhqcv6TdTnb0r485HIqTJmFoOzsak57JY 30rQGWikCukQhW4E5MRBTswdSP1Lvnw2YWYxvyF2b6FoP7s2MW5SQIutFsgTSLaQ+Sdx dk+Le1FprktQ5s+SNcylTCazP0QCwg33MwmidG1Fi6IiKzFAGm15Tt//So49iH+jbdvg t8dk+X9j3J1vno8OYEaU8fESTUSEF8T48WkpxC8uqXVZhwBx3mAvkxrvwkXBOKu9jJLN t8jx13pViECv3Ro6Vms+zWEs4xTgLQ9wh7HhizSgx+ash/+3RVerwit69LvlmqaYb227 pNuw== X-Gm-Message-State: APzg51AedCR9wKKjI6ocQndUmzxeX204L37LN7f8CIrEHzZsp7ICJ3z7 fAQEozSXRKEjt/2OYDvgnwok6rLuXtIYGYqP03iqHw== X-Google-Smtp-Source: ANB0VdZ/uZq0T3ZFydRHSKCFir1vYsnTstuz1CTeLccWI/GRvvu3mauBS79YbG7V3Omfj5rhCcLUZWb4akzt9je3MWE= X-Received: by 2002:a1c:1943:: with SMTP id 64-v6mr4202337wmz.89.1535962172492; Mon, 03 Sep 2018 01:09:32 -0700 (PDT) MIME-Version: 1.0 References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> In-Reply-To: <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> From: Erik Kline Date: Mon, 3 Sep 2018 17:09:20 +0900 Message-ID: Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: DY Kim Cc: 6man <6man@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000bd22050574f30f1f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 08:09:37 -0000 --000000000000bd22050574f30f1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Section 4.7: No. Please just no. Furthermore, I fail to see how any of this makes practical sense. The SubnetID wasn't ever anything explicitly communicated to clients, at least where SLAAC was involved -- they just received a /64 in the PIO an that was that. 3.3: Site-wide DAD? This seems like a potentially huge self-DDOS vector. On Mon, 3 Sep 2018 at 16:52, DY Kim wrote: > > Hi, > > I=E2=80=99ve reposted a draft, this time to 6man, which was posted to 6op= s about a year ago but fell out of scope there since it involves some chang= es to NDv6/DAD with added texts. > > I=E2=80=99d like to see whether there should be any interest in this draf= t within the 6man group, possibly enough to justify the modification of NDv= 6/DAD as suggested in this draft. > > Your comments are solicited. > > --- > DY > > > > > > > > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dykim-6man-sid6-00.txt > Date: 3 September 2018 at 16:46:04 GMT+9 > To: "DY Kim" > > > A new version of I-D, draft-dykim-6man-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. > > Name: draft-dykim-6man-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2018-09-03 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-dykim-6man-sid= 6-00.txt > Status: https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dykim-6man-si= d6 > > > Abstract: > Deprecation of the subnet ID in IPv6 networking is proposed; the > subnet ID is set to zero so that all nodes in a site carry the same > prefix. While the procedures for neighbor discovery and duplicate > address detection have to be changed, possible simplification gains > in IPv6 networking including that of intra-site host- and subnet- > mobility might be worth the modification. Site-external behaviors > don't change through this modification, enabling incremental > deployment of the proposal. Sites of manageable sizes for which > scalability is not much a critical issue might consider the mode of > operation proposed in this document. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --000000000000bd22050574f30f1f 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMPipSifuL4Tx7dmsbMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDcxNTA2MzcxOFoXDTE5MDEx MTA2MzcxOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALkHIP2fSFudoue2xAkNBouFm2EulKm/RKnsxmEw4dSbxQC2Mt72Ga/t ySyn6PMSAgsyjgP0bKJZf/NHBzDGuSKpY09UgBupEUEejwR4d5vrHk8IJNfIDTQ+Ygv4krlQmkO0 Qh/GB1y4PxtIn0tVfGfB7s3Z7wWyYbN1JrUrxAhKTpvkbJLRF1n/fKgv1nfUYyY9se4cZE3XQbJV 2biA0ATE8hw55TPa9FTv+QuWbAWXlTfsvz8SxdL8cs1HXVzBwi7kpzm2LbLictqUYotBdrCk2JQ9 ZkICHIpunwWnfTfNJ1Vt7MYL8worV+Y0TfBP0Uw1IG8qQ1Fdie3quVfdAoUCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBQw12fRZdlCj/XWgp08Ky/Ct82W7DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAsH2eOQwQDXJ145YZFyjaTxqiVS9t F3F65BSt739euYxmyoYFAFgBVwRLXBjD0eTRqz6W6O9FC3ZPzsIup/DXZZlPNPitbqGA391usTKN YHYsBchdjOocgO8gNokf3H4yvjUv6699ncUQXX+d0deUo38jOa4+OujSIQbz+PUicageFuFcraDO MV5VMHYtn/1Ngkrw4JSaf2nv1WTfUBQyRRorMCPXVJZLEm8K0apTK2RHaxnFvXHJjFPkLLsJSwmQ RCeC98jyQdFHPQank0x8KmEo+nlu2d0X0n/aLibqG7rRSVKINpvLv6C3j8P4b1t1Fu23J6OYkWUx Rz/Rs1hfPTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDD4qUon7i+E8e3ZrGzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgk6VN8mlzMFk7Rve5NQ0BHr9+DgobbSOo N1FG1i0kFdIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwOTAz MDgwOTMzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJ78xE6GAEdJVQ3oxnc7iG+edT598mnTgdZ4ko4D3hm4sXEkUxED /u4tdOIZM/iOLTnlJkUS4rIoqf3G9hJRo33L6yEfSl1BdpkWM7xtwAl+ozgTb1bQLFFsmd5nApNY YkVxB6gHVXC4HCJoYl7sDuIgYbs0+SvULOuxzXJpMr6ZqfLWPIAej3NUL9Be2sQNz5UOzZu046s5 F4OlcJH1rwrFezZAy0hP5Tup8f05djxHveqgVF2XurS6t3coXDg2JM7uStE2cbSOD68yQdpxakF1 RWOAMQizaZCvpqIDSeQ1DdgdytgjDmSfdFoSlD5fWI9iZ385bm8IMkcotLzRgS8= --000000000000bd22050574f30f1f-- From nobody Mon Sep 3 01:19:13 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD0F130DD3 for ; Mon, 3 Sep 2018 01:19:12 -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 90UqwYLJXQL4 for ; Mon, 3 Sep 2018 01:19:11 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B54130E0C for <6man@ietf.org>; Mon, 3 Sep 2018 01:19:11 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id g23-v6so8290579plq.9 for <6man@ietf.org>; Mon, 03 Sep 2018 01:19:11 -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=nzHiebr7jNBR3V3OMySADg6wugf30mt7pvBeoIaRzw8=; b=JQG0zEp1vVIeCe805sOyGgKpmROR0HcayNX1jSTqctof07d6NmY3UJsB1XPQj+AU64 YwGc+tXh4JeMeEwPjP99e4dsfQUnqkjff3Rgalm7vCSjWaMfJkCubRGdif/vA/n9wedO HjOMxAQ2d3EY6jQACumHiK6Kw3oQRu7wpPxUTTf2N8CCxznA85ErWy708IjMWF2U4ilj OLMmKjWNo8tHpcH3L1vI0lCT0635GkF6wpiqGjLmtyQ4x0dAC5EHskgw1LUOE0EFJGPb MFNmxOS8/Xq67Fy4JLqEAgCLAiavt9+A0Stv3Q9S0a81nW2vtIQG1cc8lVGWepMt91ix SKtg== 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=nzHiebr7jNBR3V3OMySADg6wugf30mt7pvBeoIaRzw8=; b=XIojAuE+npwCMg4GhI8Nlqs/uIEcQE4iPKMpjv08dOeRu4+I6KcRgbZdFMkHGpWNGT o+STjDHACc/Xl/8vGp4IuJ6eXpjE8aedeSLusiGO0rej5t7mfmZgm/C76u2HEiEOHvw/ pBbp7Xpt2pcNxGN2WXl88PQ16dza2RHLQoaBP045u4vU6GBobAR9ByfsKFgwuQr7qu68 lGd1VBDt0l2wbdXNcSeU6/mFRlPaZevrmSeMTBA4YlgzE3T0VHPQOIrKICqHiJLM18/X gkBhFzzZeSw9TCTt+ehRjwlarhuaxQWQWolVBlw5csCcXTsu8VEHWgU5JVHv06UKSN4e 7YfA== X-Gm-Message-State: APzg51BI43X0YJc/M39P6V2EZNkqn0JQSJIuQI7T9Ji2jc1KHX4pSIgV 7n1cWDK45C0aIpNbPOf2lyd0JFn7 X-Google-Smtp-Source: ANB0VdbunrM/90e2xKmS7rBCboCxgWV7PyBQBQ46uz7chsqFbnkc7qfTfA1ZgXdh7/wzaCUZ3PB3Yw== X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr27540681plf.126.1535962751096; Mon, 03 Sep 2018 01:19:11 -0700 (PDT) Received: from [59.29.43.14] ([59.29.43.14]) by smtp.gmail.com with ESMTPSA id g6-v6sm33736674pfb.11.2018.09.03.01.19.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 01:19:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Mon, 3 Sep 2018 17:19:07 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: 7bit Message-Id: <26799356-4062-4841-91E5-35905642E55D@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: Erik Kline X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 08:19:12 -0000 in-line. --- DY > On 3 Sep 2018, at 17:09, Erik Kline wrote: > > Section 4.7: No. Please just no. > > Furthermore, I fail to see how any of this makes practical sense. The > SubnetID wasn't ever anything explicitly communicated to clients, at > least where SLAAC was involved -- they just received a /64 in the PIO > an that was that. Taken. > 3.3: Site-wide DAD? This seems like a potentially huge self-DDOS vector. Would like to see more opinion on this. From nobody Mon Sep 3 01:36:09 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C90F130DD3 for ; Mon, 3 Sep 2018 01:36:07 -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 yyqZfAr9QqiM for ; Mon, 3 Sep 2018 01:36:03 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E0312DD85 for <6man@ietf.org>; Mon, 3 Sep 2018 01:36:03 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id d4-v6so8406945pfn.0 for <6man@ietf.org>; Mon, 03 Sep 2018 01:36:03 -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=wLoHx5zYNwEfbsAx3vp3iTfPYrFi6w1EQhapfHrh3js=; b=dvH6l9Hpk1N5OxPv5lRdCQVf9x9TxGsOU9t2rmO5al8HvsKqLQITKHMWKATb+f9dt3 o3fkk4iigbSBTrWz7kTiOuWH5IZlVgtl5va7gDqqPbu1xJrQigS3SiYvaUs+AsS4ql+0 T0Fc+V1U8yt7MeOugnFuzA2k0KmkoyHe89yIIct3+WK8z0SQYpPL2xsUTtrhg7VNkeeZ os/meJZL+Ov6xVQXLOVg+qyaVZ8232/3LvBIo7DGXuU0MCyPzzu0/KGSlacy3Q6Nmrgx FttQx7+Qswk2mTNMIXZmACNFFtWBIDkRniCE1oo3hgFI3kpl+qyrOzSqd+Z/z5vdXP2t vzRw== 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=wLoHx5zYNwEfbsAx3vp3iTfPYrFi6w1EQhapfHrh3js=; b=j/f6h91LlkQI4bwtrfJMW1bpgPQxpcEsL8kpIpInoReMCbL7Gb9kzF8R9SiJF8bYfm ubBbQvVjKg8ldimDFYpcGGlow53sWHfEUUCX/w/ebFIv2eohQVNUiJESwD2OO9iqGVUY lPjvi8A8SQDr617CWcgb33vx5m4OMdCAKYZQaly2JvWKIYDaO+NFGPDEJ7vd4nMm4TZx FvFcTrroqBE+TZdi8oPSPyXU7AmdTrnYKmSLK17ODl+qFFXpM2k1L+UwoIBpINVDQmVY Q3rvfHFzw1yVkm7lDNBmGU+KE2sviv7/Bbo0D7wFUCl0xh8HLCH7ErIBMMD3V3yvIPkh /juw== X-Gm-Message-State: APzg51DIQQczKkQgdycFpeZV0lkjg4gYrwGY8Fh+BpbC6Jnzo8yvX8XV n3h6oj4acKQJlSAA4jrDSOY= X-Google-Smtp-Source: ANB0VdYlS1tuvkVf0C6M3eRDSpDotSmN+yRR8ViPBn5kilG+OZQE2Mlc/j6fflRkiMfwOOHS932tbg== X-Received: by 2002:a62:fcd2:: with SMTP id e201-v6mr28519122pfh.101.1535963763257; Mon, 03 Sep 2018 01:36:03 -0700 (PDT) Received: from [59.29.43.14] ([59.29.43.14]) by smtp.gmail.com with ESMTPSA id x23-v6sm4450989pge.61.2018.09.03.01.36.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 01:36:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Mon, 3 Sep 2018 17:35:58 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: Erik Kline X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 08:36:07 -0000 --- DY > On 3 Sep 2018, at 17:09, Erik Kline wrote: Perhaps, you=E2=80=99ve made two independent comments below. > Section 4.7: No. Please just no. Taken. > Furthermore, I fail to see how any of this makes practical sense. The > SubnetID wasn't ever anything explicitly communicated to clients, at > least where SLAAC was involved -- they just received a /64 in the PIO > an that was that. Not explicitly, but implicitly. All nodes on the on-link prefix (as = ascribed by PIO) are assumed to be on-link, directly reachable on the = same =E2=80=98subnet(link)' as the host involved resides in. The host=E2=80=99s address changes as it moves to a different link, = whereas it doesn=E2=80=99t in the scheme proposed in this draft. This invariance of the host=E2=80=99s address over mobility across links = within a site is the essence of the scheme proposed. From nobody Mon Sep 3 12:47:46 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DF2130DE7 for ; Mon, 3 Sep 2018 12:47: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 9lUfm45qTAAF for ; Mon, 3 Sep 2018 12:47:43 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9872C130DE0 for <6man@ietf.org>; Mon, 3 Sep 2018 12:47:43 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id v66-v6so534810pgb.10 for <6man@ietf.org>; Mon, 03 Sep 2018 12:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=80bFhVNlHiL1rXQrxNw1lXjo0y0Z3H8vIDcfPr+gQEA=; b=W7/IkQR2H1obGhBeooq7w9Dz/oY7c6IUr1sAPQJVgnWUZgJCdT+jOajAp9YpwfT72J yLAJPxJnwl9jG5KWduMGByeatarrumt1Ih73+4puQ4Pc9QZ4en44ZBJCZau/1zSnxkiL Cy5wPfDurt8e+F8aEP8sKmuVyBSu6Y7VcgBjY8HZA2draywF67FAdex2mautAKzDyZ1V HbGFKgPobnYHZv8r4Zc/ZZa0Tr846qS01PFgG2QW0Vjr4Lg5kMRYJzr9QoEFoOvkSp4K dszsEQKct7CjpUkEFDJ52GZpedkhs4MQflgecQOtmLUuf6dg7tu6YqWKIxuOiLq3mrn7 2L4Q== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=80bFhVNlHiL1rXQrxNw1lXjo0y0Z3H8vIDcfPr+gQEA=; b=p8niGtZGitjEM+KcoIYgJKOJH9GeC1Km+N6omPAPqRYB2YJb6iwW0fO6q41HDzCYFO mWeFe9+LnE0WGJnNu/G1atS9BdsXUuIveQCXpvIFDV/xjjCWTdsYvhl8GABW65aJNgKa n4VyjSvqN4WzZhPZ/M7HyHqPjAQl0ogFtaXRwvjdVZUVN/Y6T3kbNbRbpuFcmQ1k9nuw ckQgbdg8UBo5V4HvrG+s2uWzgHYP2SH6WYGtc/0vSlyFrunCbPrqa7Fh5t9Nb+sUsktq 46jfZtEIROPg0z1Tyf9JK1BLpsxbfNgETIZ4VEJqIAY+Bds2WbausDa0Ya8hQnFWbkPk wAfA== X-Gm-Message-State: APzg51AevVCpsJsqIgI8WpkS8tbgNYf0nmn5B+JVbOsYboiWrmGgLQCB QKrQYIxs/xhjNLC4E1AXFbDbrAO3 X-Google-Smtp-Source: ANB0VdayR/JcAN7F0izThew72DhwMBydhTyRo+77895r0VfrpEZ7qTlKtXR1iSsS/Ff6848p5sE06w== X-Received: by 2002:a63:ee56:: with SMTP id n22-v6mr27893569pgk.402.1536004062984; Mon, 03 Sep 2018 12:47:42 -0700 (PDT) Received: from [10.100.96.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id d24-v6sm20199082pgv.23.2018.09.03.12.47.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 12:47:42 -0700 (PDT) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: DY Kim Cc: 6man <6man@ietf.org> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> From: Brian E Carpenter Message-ID: <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> Date: Tue, 4 Sep 2018 07:47:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.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.27 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 Sep 2018 19:47:45 -0000 On 2018-09-03 20:35, DY Kim wrote: =2E.. > This invariance of the host=E2=80=99s address over mobility across link= s within a site is the essence of the scheme proposed. Why is that useful? Brian From nobody Mon Sep 3 13:45:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF42130DE7 for ; Mon, 3 Sep 2018 13:45:16 -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 VxlsW5mCae80 for ; Mon, 3 Sep 2018 13:45:13 -0700 (PDT) Received: from bugle.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 E2CFC12D7F8 for <6man@ietf.org>; Mon, 3 Sep 2018 13:45:13 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 40180FECBBD6; Mon, 3 Sep 2018 20:45:13 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B6A73507BAD; Mon, 3 Sep 2018 22:45:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: Ole Troan In-Reply-To: <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> Date: Mon, 3 Sep 2018 22:45:10 +0200 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: DY Kim X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 20:45:16 -0000 > I=E2=80=99ve reposted a draft, this time to 6man, which was posted to = 6ops about a year ago but fell out of scope there since it involves some = changes to NDv6/DAD with added texts. >=20 > I=E2=80=99d like to see whether there should be any interest in this = draft within the 6man group, possibly enough to justify the modification = of NDv6/DAD as suggested in this draft. >=20 > Your comments are solicited. =46rom a quick glance it looks like you have re-invented multilink = subnet routing. Which of one flavous is described in = https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00 That particular proposal didn=E2=80=99t go anywhere, for the reasons = described in RFC4903. The basic idea was to share a /64 across multiple IPv6 links. Steve never wrote down the details, but today, we=E2=80=99d probably do = a combination of ND with ARO and an IGP. Possibly with some modifications. Detecting movement and whenever = someone leaves the link is the tricky part. I would certainly be interested in work in this area. Cheers, Ole >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-dykim-6man-sid6-00.txt >> Date: 3 September 2018 at 16:46:04 GMT+9 >> To: "DY Kim" >>=20 >>=20 >> A new version of I-D, draft-dykim-6man-sid6-00.txt >> has been successfully submitted by DY Kim and posted to the >> IETF repository. >>=20 >> Name: draft-dykim-6man-sid6 >> Revision: 00 >> Title: Subnet ID Deprecation for IPv6 >> Document date: 2018-09-03 >> Group: Individual Submission >> Pages: 17 >> URL: = https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ >> Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-dykim-6man-sid6 >>=20 >>=20 >> Abstract: >> Deprecation of the subnet ID in IPv6 networking is proposed; the >> subnet ID is set to zero so that all nodes in a site carry the same >> prefix. While the procedures for neighbor discovery and duplicate >> address detection have to be changed, possible simplification gains >> in IPv6 networking including that of intra-site host- and subnet- >> mobility might be worth the modification. Site-external behaviors >> don't change through this modification, enabling incremental >> deployment of the proposal. Sites of manageable sizes for which >> scalability is not much a critical issue might consider the mode of >> operation proposed in this document. >>=20 >>=20 >>=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 >> The IETF Secretariat >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Sep 3 16:30:20 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF239130DF2 for ; Mon, 3 Sep 2018 16:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 XeBHq9ahJciA for ; Mon, 3 Sep 2018 16:30:17 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA9F130DEE for <6man@ietf.org>; Mon, 3 Sep 2018 16:30:17 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id s17-v6so710651plp.7 for <6man@ietf.org>; Mon, 03 Sep 2018 16:30:17 -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=U32ql8sHfMxQ8gVWYTcbsnC06jyAAbPQZakoq7xJR3I=; b=CpVv9H/Z9hnaA3qY/Kd+3YiclWG2jcIgZIk7tFGP+Hj9K00+prjycwFOmYYcC9pkiA EvtnUQZQsItVcMBxSIW7klEicHrhmFJJx3GJ3nm6eszjX1wU06Sn4/1B8BvHPYBnochV gMJAKnDSYoibEiuCbTkwjT0pGmCOOfDavf5qtTgSHWOaUJ13GcIoCw0gAIrYc8R64MTS iY8AS2MwFiT/aiUBOspVge4H8qMXLNhsDkHQBRvZejDtzffj4OYsnVxsl5IKS2GFvfiI e4tsgx5sbch633OjKuXeeZoLLMWotgDeyx9ZAoWgKhL5oOOUHevLv163G9jVI76EC1Qi /ydg== 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=U32ql8sHfMxQ8gVWYTcbsnC06jyAAbPQZakoq7xJR3I=; b=OEsX9wBuIdY+Rp0+g9LudeEGgEwvx9LSbHwPqYrQL8btmFCpc2Y1hGvpYoJP0mC5MX S57lPq85JwLMUMeSb0TwQi6TuWDjzMZXe3PYBr6ufM5ASF8ODEFskZWt6+U+iVchpzVL 8G99tnKoQaYTlfWbc82+vRELiL3xvoxnVISJKL+u1DqiYIOoOe6YYaC323SxqkTnuVZQ 6WY09bm/Cmg77w0uRdv07WLTNppV4/VtDTGuJ3TF8blJLthGwsH1afIO4t3d9W/Dcrm5 kyHduKQxSBDtBEXVEG3U6zf3aZDPZrhQN+teLPwnPRF0zO1LU+AVQw4HvmMgwFOdfgbM EBEA== X-Gm-Message-State: APzg51BmXaxJMkWzxiR7YkqxAGHLgGLti/ufz3T3mmoIX/zrZg7Jcp/L mUTOGc2ImnhocpfXKoNfffMT4rvO X-Google-Smtp-Source: ANB0Vdahf2rUVVjnYpNedx0zhE4YyjSgW4DWdM4uQtgY+FcLloFyWrDEK9+3EbmsOjyi4SPhUG9n3g== X-Received: by 2002:a17:902:28aa:: with SMTP id f39-v6mr31228843plb.150.1536017416927; Mon, 03 Sep 2018 16:30:16 -0700 (PDT) Received: from [102.160.23.101] ([39.7.53.232]) by smtp.gmail.com with ESMTPSA id e190-v6sm43422175pfc.81.2018.09.03.16.30.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 16:30:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6347C543-BDD7-4092-BA46-A3362A4B3A7A Mime-Version: 1.0 (1.0) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DaeYoung KIM X-Mailer: iPhone Mail (15G77) In-Reply-To: <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> Date: Tue, 4 Sep 2018 08:30:12 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: 7bit Message-Id: <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 23:30:19 -0000 --Apple-Mail-6347C543-BDD7-4092-BA46-A3362A4B3A7A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable May I repeat the text of 4.10 as a first response?: 4.10.=20 o Transport connection resilience for intra-site mobile nodes can be provid= ed with no extra infrastructure like mapping servers found in most LIS proto= cols [HIP][ILNP][LISP], resulting in a significant resource saving.=20 o An equivalent incentive in comparison with the legacy IPv6 networking wou= ld be that intra-site mobility, and that faster, can be provided inherently b= y any interior link-state protocols, with no hassle of installing MIPv6 func= tionalities on every router in a site. Considering that a site can be arbitr= arily large, this can be a considerable additional resource saving in terms o= f network operation. Sent from my iPhone > On 4 Sep 2018, at 04:47, Brian E Carpenter w= rote: >=20 >> On 2018-09-03 20:35, DY Kim wrote: >> ... >> This invariance of the host=E2=80=99s address over mobility across links w= ithin a site is the essence of the scheme proposed. >=20 > Why is that useful? >=20 > Brian >=20 --Apple-Mail-6347C543-BDD7-4092-BA46-A3362A4B3A7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable May I repeat the text of 4.10 as a first re= sponse?:
4.10. 
o  Transport connection r=
esilience for intra-site mobile nodes can be provided
   with no extra infrastructure like mapping servers found in most LIS
   protocols [HIP][ILNP][LISP], resulting in a significant resource
   saving. 
o  An equivalent incentive in com=
parison with the legacy IPv6
   networking would be that intra-site mobility, and that faster, can be
   provided inherently by any interior link-state protocols, with no
   hassle of installing MIPv6 functionalities on every router in a site.
   Considering that a site can be arbitrarily large, this can be a
   considerable additional resource saving in terms of network
   operation.

Sent fro= m my iPhone

On 4 Sep 2018, at 04:47, Brian E Carpenter <brian.e.carpenter@gmail.com&g= t; wrote:

On 2018-09-03 20= :35, DY Kim wrote:
...
<= span>This invariance of the host=E2=80=99s address over mobility across link= s within a site is the essence of the scheme proposed.

Why is that useful?

  Brian

= --Apple-Mail-6347C543-BDD7-4092-BA46-A3362A4B3A7A-- From nobody Mon Sep 3 16:42:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57C8130DF2 for ; Mon, 3 Sep 2018 16:42:40 -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 c4KoDzBaRvgW for ; Mon, 3 Sep 2018 16:42:39 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78141130DF6 for <6man@ietf.org>; Mon, 3 Sep 2018 16:42:39 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id 7-v6so727948pgf.2 for <6man@ietf.org>; Mon, 03 Sep 2018 16:42:39 -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=RqIceop7dR96swPN0L6oT0IiWdlubBe3sniT2sAH2xw=; b=jd7WXHZQGv5JrnxqisCj70RxO7lKo5JA5aeL+Kk2mThTyxUQth8FWqmjiIjyIFMPw9 M9u3N8wNPClpXGDAu0IIkTQMUbCT37IMpQvaK+W8MGqFSbHdtngdigZ2ZZEqh0iPZd/h OZERHFEVnIyGtFoY/ddBDzrOGzfPyHzGRE/2iOkYu4Fn5rZMAi69emLLFiSRCvhrhPxn 4juB8InC4O6JEAS39/OHJKkw842YCDfaF/EatKHga6xD8zYd3NtdnOfCfNPkw27SuMHv zz7fpmXxYUsXP3FcwHi1FCAtVuv4EHYOOByKFJicalf/tpekRGzTsdKkIhSbikteX+g8 8F2A== 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=RqIceop7dR96swPN0L6oT0IiWdlubBe3sniT2sAH2xw=; b=OUaTduekK2rH6u9PJzj2/NDNb3eE3s1B9fJsqvgLPagqH6yCuLybOPde013VoPvnr9 Xu2gMzJ+3Btwzm+tCo/et9gkKzMsdArJLUEgQyFpC5bSrvmd/j6Ymvg1pLmafwRg9RZs 6JetwfranXGozS8/9su/mcHoroQBtzKSrEymkiVue+cH1dtMVTj1fKrsWn562mgxGhoL BIFzDJqCqap0brXP/eb/oX0deHAckw3ADVIIMHQ+G1qeoG7xeFFdQfrOQ5dTMH26mlT1 9ptUi/sf4rAEwnrjvmcybremW/iE+W/lpUVG3xc/mfN4bnV3ZoVZcgBjhuCtL7wBbFN2 hXGQ== X-Gm-Message-State: APzg51DDNzyNzuzrjzD2MO7kRlV52bClnvQeXJw3wIvNmzkl7Tc7eyKe 9FMCNoNif6ujOKoAHF6NccYyUO4W X-Google-Smtp-Source: ANB0VdZpvyS2m2vjCUJYDI6DJKEHj3Y4ML4q3vRtlwRYKSK50/is5JbHXg8FmOOxwNytI+5BlM370w== X-Received: by 2002:a63:1516:: with SMTP id v22-v6mr28219313pgl.150.1536018158654; Mon, 03 Sep 2018 16:42:38 -0700 (PDT) Received: from [102.160.23.101] ([39.7.53.232]) by smtp.gmail.com with ESMTPSA id b126-v6sm29327220pga.49.2018.09.03.16.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 16:42:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DaeYoung KIM X-Mailer: iPhone Mail (15G77) In-Reply-To: <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> Date: Tue, 4 Sep 2018 08:42:35 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <2223C0BF-C578-40A4-9C3D-3C8833564036@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> To: Ole Troan Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 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 Sep 2018 23:42:41 -0000 On 4 Sep 2018, at 05:45, Ole Troan wrote: > =46rom a quick glance it looks like you have re-invented multilink subnet r= outing. > Which of one flavous is described in https://tools.ietf.org/html/draft-iet= f-ipv6-multilink-subnets-00 > That particular proposal didn=E2=80=99t go anywhere, for the reasons descr= ibed in RFC4903. I didn=E2=80=99t know of the two documents. I=E2=80=99ll have a look and pro= vide more detailed opinion. Offhand response would be... > The basic idea was to share a /64 across multiple IPv6 links. ... in contrast to my sharing it across the whole site...? As for me, extend= ing the idea across the whole site might have to be justified if any. > Steve never wrote down the details, but today, we=E2=80=99d probably do a c= ombination of ND with ARO and an IGP. > Possibly with some modifications. Would, of course, be best if we don=E2=80=99t have to change any existing sp= ecs to do the job. > Detecting movement and whenever someone leaves the link is the tricky part= . Yes. > I would certainly be interested in work in this area. Happy to hear that. > Cheers, > Ole From nobody Mon Sep 3 18:57:58 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3202130DFE for ; Mon, 3 Sep 2018 18:57:54 -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 zNSp_Y7JkzoJ for ; Mon, 3 Sep 2018 18:57:51 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDED130E71 for <6man@ietf.org>; Mon, 3 Sep 2018 18:57:51 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r1-v6so822793pgp.11 for <6man@ietf.org>; Mon, 03 Sep 2018 18:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=O7pkxio0BRIM22dJzZ0uAsbsOA4MGb3XL6BrkzMe9HI=; b=QhRJP0lYHC5er6s523MOCmfQg1H6GJISWMa4NWolXUjwXMDhm/ACD6mW4Abs2X6DVy 4ATlFOjO4XZjLfSmBwE/7uUBgag18GkuwGXC8M2hUmwdD4SAeeVlOmBLNzEnEMUvAYWM bZebHXEk0R9GGtUWS9yLebIKgbes+bBKTVejf6anTkkxrUF7O0VPxPOqJuDsfEvusJ6U L53P4CMVxUIDkYt9kN+3iCWBLj0BOIFO+Wj+0jnaQpH+/EqRgRe5FMK2efLU4sMOrhCQ +rDNHLytVaqoqRvwP9rjx5WFFBmBVPnhSkv6nIaWD85XVe/ucoCHRyADx67m4Fia26ck u4iQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=O7pkxio0BRIM22dJzZ0uAsbsOA4MGb3XL6BrkzMe9HI=; b=Vp5f85rLyv1UsuO0F/srTygU71VuM3E+ZU328moEFoAUnxbFEaOVFTr2TgVYv141iF F02jefLnwbXaYL10U7Vv2fPMCPytUSE9JNaePbBRmz/JotB95kAsjP041mrgBhAaHP8z smZLIdeVNRT0iNVSrYCcFENaQNG7LV/DtSXqj6r+Q9katq4xnvLQf9Kq3kLIPwRvjQZ8 PBscVCeKSj2VLgQST9rQko6rQZP1Vl/1OlGfbXQ8gy5RQ3cht0eMR/gf+t6YS5flZDbd +4BbgULjDVX9Gw6eb+FX0cDGeNcajpAiQK2+pdWjLWQuiNV6EsKsj7ViJb9rXRGJzB23 OOwA== X-Gm-Message-State: APzg51DGIfxIVdjnLpywkjnzFTqptTChbEQT9Opn7vFOTNfk3fmNKKIy V2g7RSY/Pk5WDTnTJFSQXLtF82o5 X-Google-Smtp-Source: ANB0VdZYy7YCwiq8y0ctmaz9aoaFPU09CRXAtuE5szGzVvXr1qE7I+/7ERsU48RH4c51CBpn1xjqsg== X-Received: by 2002:a63:e841:: with SMTP id a1-v6mr14193027pgk.126.1536026270475; Mon, 03 Sep 2018 18:57:50 -0700 (PDT) Received: from [10.100.96.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id t15-v6sm41728735pfa.158.2018.09.03.18.57.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 18:57:49 -0700 (PDT) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: DaeYoung KIM Cc: 6man <6man@ietf.org> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> From: Brian E Carpenter Message-ID: <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> Date: Tue, 4 Sep 2018 13:57:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.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.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 01:57:55 -0000 On 2018-09-04 11:30, DaeYoung KIM wrote: > May I repeat the text of 4.10 as a first response?: > 4.10.=20 > o Transport connection resilience for intra-site mobile nodes can be p= rovided with no extra infrastructure like mapping servers found in most L= IS protocols [HIP][ILNP][LISP], resulting in a significant resource savin= g.=20 > o An equivalent incentive in comparison with the legacy IPv6 networkin= g would be that intra-site mobility, and that faster, can be provided inh= erently by any interior link-state protocols, with no hassle of installin= g MIPv6 functionalities on every router in a site. Considering that a sit= e can be arbitrarily large, this can be a considerable additional resourc= e saving in terms of network operation. Since current reality is that applications need to be agile with respect to address changes, and even IP version changes, I find it increasingly hard to justify effort on address stability for mobile nodes. (See the recent v6ops thread: https://mailarchive.ietf.org/arch/msg/v6ops/-5DaSE41dmqLVkOWEbUoUtRCS3A )= Brian >=20 > Sent from my iPhone >=20 >> On 4 Sep 2018, at 04:47, Brian E Carpenter wrote: >> >>> On 2018-09-03 20:35, DY Kim wrote: >>> ... >>> This invariance of the host=E2=80=99s address over mobility across li= nks within a site is the essence of the scheme proposed. >> >> Why is that useful? >> >> Brian >> >=20 From nobody Mon Sep 3 19:15:18 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373BC12785F for ; Mon, 3 Sep 2018 19:15:17 -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 HINg55xrPJ5N for ; Mon, 3 Sep 2018 19:15:16 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5A0127333 for <6man@ietf.org>; Mon, 3 Sep 2018 19:15:16 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id r1-v6so841210pgp.11 for <6man@ietf.org>; Mon, 03 Sep 2018 19:15:16 -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=F5w0Ynu1OQf5yNs7EIFlHiR9wUPx5yo9EVgujZp7kHo=; b=UthZMJ07efJXdMVPmjBQWS9RGYZZP54qfAr1DNpEM88AXaWYJ881yrH7W1+NrJAwWK ES/xd5gESFxyDub77xOcx8LCYJXty5Omsx/GIs1yYrbHBioY1MdBSSPp2HFrVwGzJurm XARSOfqpM1lnPvLFvJclAJh4ML3oMCnyChBryObHKsdc7LFnA6fp6VcLITbRWpTed30J Kze0OuqfYBF8foU9wwf1N76YXSvVy+8ZsuV5Tascdvx//o0xVhUxsxrtc8KnmdEEWEq3 8mHqp4V5pMLGAfmxu+T7HEhpCGOReQzPgxM3+lk/Di3e5EIjDh8fEpD2N4oixVGdw8qJ MR0A== 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=F5w0Ynu1OQf5yNs7EIFlHiR9wUPx5yo9EVgujZp7kHo=; b=D7LA21X97B6UpXwNPbfvWMPEVe17D0lhiUTXs766dRRG6ORc55X5YUKEZikZwNm3nQ JDGgARvQZW+gGIdhryDIP6DoO/sv7hpfbH3+G1wCtaU1t8/C6APkgnSW0mOT0hxOQY9t CVNuqBM6wshHR3JjVGR2BfCivqnV190ozvj8x1n/CvdYjIxlqTh551FXGRMk/+lApeQc 7fDNcGyIbWBz03i7ptpGihNQv4qFvsnzWMjGfH/HK/NXqeu9gRw12Xp4GjN0hT6rFvt6 Zjesko+LebRUevSnbV3E5BXm7SX+Eo4Q3JN5z3P0naVtu6tt2KWoakcA8A7O5Rku2eee RClw== X-Gm-Message-State: APzg51DL2twBS/9AZR3+b+8RKS/gxu86Xekit4p+kzSj3ZWnwG2eDS1g xZQJQ4Z8+zcETJkmOEAgM/T8m71X X-Google-Smtp-Source: ANB0VdZ3yZk1Ay4hDcG6tojbkEevHqoq1h5DhvMe6BmMr6FVGmYQhrR97fzLFaT+XWJtim147ZSUfA== X-Received: by 2002:a63:d857:: with SMTP id k23-v6mr29171420pgj.106.1536027316015; Mon, 03 Sep 2018 19:15:16 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id 87-v6sm34191732pfn.103.2018.09.03.19.15.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 19:15:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> Date: Tue, 4 Sep 2018 11:15:11 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <1BD54E16-D2A8-4266-B6DC-61693E765CA6@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 02:15:17 -0000 How about this?: =E2=80=9CTransport connection resilience for intra-site mobile nodes can = be provided with no extra infrastructure like mapping servers found in = most LIS protocols [HIP][ILNP][LISP], resulting in a significant = resource saving.=E2=80=9D With changing addresses, a hype of proposals (in the class of ID/Locator = Separation protocols) deal with separate Transport Connection IDs to = ensure transport connection resilience. The current scheme provides that transport connection resilience, at = least within a site, without employing an extra number space of = Transport Connection IDs. --- DY > On 4 Sep 2018, at 10:57, Brian E Carpenter = wrote: >=20 > Since current reality is that applications need to be agile with > respect to address changes, and even IP version changes, I find it > increasingly hard to justify effort on address stability for mobile > nodes. From nobody Mon Sep 3 19:42:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9312F1AB for ; Mon, 3 Sep 2018 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 bS1XC7pjdXul for ; Mon, 3 Sep 2018 19:41:56 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E32C127333 for <6man@ietf.org>; Mon, 3 Sep 2018 19:41:56 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id z125-v6so1454974qkb.12 for <6man@ietf.org>; Mon, 03 Sep 2018 19:41:56 -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=k3Kg0D7s6Z5UYwMMt41dH0tAhUXCfkifKRekG9Ity8g=; b=MoTnDsZl17UF2hr9j1IOLDk/M3bILLl9SreHhmoVhfbqtLdMpfTMNgvBqn9dWYzB5I 7Rkn0fZeaD3QRE+N21ItFB5LKJR9V1bDbW9QQe6IxD7QuB7Z9ssn8NhOmy1nTCh1jcti aYkk3iaJ3nNRfPHToRw+dtOiNQZgM8xQuy9RHTBuA2ag3Ezwod46c3d6n4R5FVXY18uI RZ2/1dgLIrHY7Ov0kk23oE8nx5Hpy2Q4UrOYwbxLDQ4GScunnC9ExJil/PxUGFYKKSzA IybYmAcZttqFwBa2T57YlN4GLXZPJhX/tpkbC/HrrMewt11QrPCnykD6qdnh3RNOItiL gwIA== 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=k3Kg0D7s6Z5UYwMMt41dH0tAhUXCfkifKRekG9Ity8g=; b=Qh1TMRRwS9bBwPA0T47FXJUXLH00dN7nkHsqg+mpljJMIWBGS+HJwr7l822Dp0V4Sw 7y/fdaFR4W7gxzacek9JLCtSWmlpVEm9h19Vpx6kdcXbEl1+fFLpgxk8FAVdNgUkh//I vjCkjouZ/vdBqPApHrLqatnjQlcg0ed4OMLvDReItnDXKpuIl/OQdkONrBji1hD6BpL0 VRI2cOc5HmjSfecNxtvihFx2Jerr6kdOs1ScIBvYNGqb3vKdqZGm9Ghxc/J6k+8wkXK1 h68RIJjr3oWtuLNARQiyIzetYOgQ5Tcfbfok4nCbqnrR2ENRGcrDmLZgCKqIXgncXomA +lyA== X-Gm-Message-State: APzg51BeFHq58XbzMuuD9tkXO9W5QNZ8GvY8zvohZnzl0oqoYv+vrhkf RDgMH08nIhTaeaEEvV7eyfSLjdfMDdZsEpocrobhxw== X-Google-Smtp-Source: ANB0VdbjZADT66mT4BN+SL1Mjw6Znca/uwTTFOYd5nw57RKYTddexLZBNOyV2EKMPmx/XZAqJtwPAti98hBKHnho0Jc= X-Received: by 2002:a37:d0c:: with SMTP id 12-v6mr26675290qkn.148.1536028915394; Mon, 03 Sep 2018 19:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:22b8:0:0:0:0:0 with HTTP; Mon, 3 Sep 2018 19:41:54 -0700 (PDT) In-Reply-To: <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> From: Tom Herbert Date: Mon, 3 Sep 2018 19:41:54 -0700 Message-ID: Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: Brian E Carpenter Cc: DaeYoung KIM , 6man <6man@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.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 02:41:59 -0000 On Mon, Sep 3, 2018 at 6:57 PM, Brian E Carpenter wrote: > On 2018-09-04 11:30, DaeYoung KIM wrote: >> May I repeat the text of 4.10 as a first response?: >> 4.10. >> o Transport connection resilience for intra-site mobile nodes can be pr= ovided with no extra infrastructure like mapping servers found in most LIS = protocols [HIP][ILNP][LISP], resulting in a significant resource saving. >> o An equivalent incentive in comparison with the legacy IPv6 networking= would be that intra-site mobility, and that faster, can be provided inhere= ntly by any interior link-state protocols, with no hassle of installing MIP= v6 functionalities on every router in a site. Considering that a site can b= e arbitrarily large, this can be a considerable additional resource saving = in terms of network operation. > > Since current reality is that applications need to be agile with > respect to address changes, and even IP version changes, I find it > increasingly hard to justify effort on address stability for mobile > nodes. > Brian, I'm not sure I would agree with that. If mobility is a very rare event then maybe this is true, but there are also cases where a mobile device might be doing handover to different cell sites every few seconds (consider a smartphone on a high speed train). Overhead to reestablish all connections constantly and renegotiate security could very well adversely impact user experience. Also, not all applications and devices will handle and address change event gracefully, for instance there could be devices tethered downstream to mobile devices that aren't "mobile devices" and aren't prepared to deal with high rate of address change. Eliminating the subnet-ID may also have a positive effect on security and privacy. Again, consider the mobile case where each cell has a subnet-ID and each time a device connects it gets an address in that subnet. Problem is that the network prefix in devices addresses may reveal specific geo-location of a device (and hence a person in case of personal device). Eliminating the sub-net prefix and assigning addresses out of a larger pool of a provider prefix should be better for privacy. This privacy issue is discussed in some depth in https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00-- I think the mobile addressing model there is similar to what is being proposed in this draft. Tom > (See the recent v6ops thread: > https://mailarchive.ietf.org/arch/msg/v6ops/-5DaSE41dmqLVkOWEbUoUtRCS3A ) > > Brian > >> >> Sent from my iPhone >> >>> On 4 Sep 2018, at 04:47, Brian E Carpenter wrote: >>> >>>> On 2018-09-03 20:35, DY Kim wrote: >>>> ... >>>> This invariance of the host=E2=80=99s address over mobility across lin= ks within a site is the essence of the scheme proposed. >>> >>> Why is that useful? >>> >>> Brian >>> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Sep 4 00:23:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5A130DEF for ; Tue, 4 Sep 2018 00:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8JgZ29ourxf5 for ; Tue, 4 Sep 2018 00:22:57 -0700 (PDT) Received: from bugle.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 78E31130DE3 for <6man@ietf.org>; Tue, 4 Sep 2018 00:22:57 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [173.38.220.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 60885FECBC6B; Tue, 4 Sep 2018 07:22:56 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 96C4351014D; Tue, 4 Sep 2018 09:22:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: Ole Troan In-Reply-To: <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> Date: Tue, 4 Sep 2018 09:22:51 +0200 Cc: DaeYoung KIM , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 07:22:59 -0000 > Since current reality is that applications need to be agile with > respect to address changes, and even IP version changes, I find it > increasingly hard to justify effort on address stability for mobile > nodes. Applications need to, perhaps, but doesn=E2=80=99t that require a = fundamental change in transport too? Can you name any applications that are? I can think of mosh, but I=E2=80=99m hard pressed to find other good = examples. Cheers, Ole= From nobody Tue Sep 4 01:29:57 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AEC130E14 for ; Tue, 4 Sep 2018 01:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 PgmEifD5EIXz for ; Tue, 4 Sep 2018 01:29:54 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A3D130DEF for <6man@ietf.org>; Tue, 4 Sep 2018 01:29:54 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id i190-v6so1303708pgc.6 for <6man@ietf.org>; Tue, 04 Sep 2018 01:29:54 -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=hG5AWxu9wdRebJ/if4Z6itFldDJNBF09IvZnn0LQ1Z0=; b=PrsPTmL9DpoY49tr4T+/0XPTewJper5UL5Ls6eKazPl1mVPYJZ4xoIn9I1MaSLEvLk gQpIW56IyN+bs17IxaVRVa3NDybnIvvnwTWdprSqkl9EqZ3HzP6pikWVP4rqgkJ/SsF2 tp51btBLIwyJWwplFv1SOCvhnC09XSAZ3k9T9DX0dx5R2ohBYiijonRZA4Hr9ZDXeg3a 5hrELbUNlXBiHpw8WFN7ZIu3gYzMwmZ71P+xiCrL3oB6M4y1fg5nYl4HJ6fJsE88YMRP KYD7qqKPcBaCohubN6VBF9JaW1yyC+2P8eV+XY9KwJhI8+ES7N4OxIX8PqGxVTsuM66c LvAA== 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=hG5AWxu9wdRebJ/if4Z6itFldDJNBF09IvZnn0LQ1Z0=; b=H4rIG9NXIH+lbI5hIr0pbwmwc25+i0auEBZc682ScTzQjcQv2EJ847fvHuGJshWrEH LBTbE3WrfBxLfUGxTYaOQz+Eb59rhSdkZfXVNBfrk+ItvYlcrjutGbv0Iu/KobMlrGVq 0sW7kJ5yCeyLfS6KdBhJbNwQztH3ZxANChlySQt5nCPg68ThTAnC0ZWkxvZnQgwlePhM QjPfQ1ZHfSUZf+n9NVpZJgBdzFxpnoAxQ3IE1noRX9tce1w34ujMj1vpWT9tgmVzJVh3 7ZAqu2cT5JUsD4Ph5/fKIABnpN+89Sh4d98ELzkyjg8NbjfIdDBeX9jClgvvqNHjKiST LFvA== X-Gm-Message-State: APzg51Ci93o9k3DKYl6OAwyrBEl88kGXYfYFGu9WTqWDI5SEK9rdsnfP GPNzgMx0DK166ZsVM+eVayU= X-Google-Smtp-Source: ANB0VdY1t27J2QtWTIC3g+mZySNLlRfgd+cTq/F9yGAGyXDf+wMiwYiHdBuoZQE9Ur3VSgZ9TwiSpw== X-Received: by 2002:a63:2106:: with SMTP id h6-v6mr29684816pgh.161.1536049794272; Tue, 04 Sep 2018 01:29:54 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id h69-v6sm44656443pfh.13.2018.09.04.01.29.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 01:29:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> Date: Tue, 4 Sep 2018 17:29:49 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 08:29:56 -0000 in-line. --- DY > On 4 Sep 2018, at 05:45, Ole Troan wrote: >=20 > =46rom a quick glance it looks like you have re-invented multilink = subnet routing. > Which of one flavous is described in = https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00. If a site consists of a single subnet, SID6 (my model) should basically = reduce to the multi-link subnet (MLS?) model. A difference might be that = SID6 explicitly talks about deprecation of the subnet ID whereas MLS is = silent about that. To retain that difference, SID might have to successfully justify the = additional benefit of having the subnet ID deprecated. > That particular proposal didn=E2=80=99t go anywhere, for the reasons = described in RFC4903. RFC4930 comes quite discouraging. > The basic idea was to share a /64 across multiple IPv6 links. > Steve never wrote down the details, but today, we=E2=80=99d probably = do a combination of ND with ARO and an IGP. > Possibly with some modifications. Is it possible that we get more elaboration of your updated idea, = please? Is there a possibility for your updated idea to converge with = SID6 in some way? > Detecting movement and whenever someone leaves the link is the tricky = part. As for a node emerging on a link, I=E2=80=99ve =E2=80=98naively?=E2=80=99 = assumed that such a =E2=80=98link-up=E2=80=99 detection is already part = of IGP (OSPF or IS-IS) protocols. As for a node leaving a link, it might be tricky to detect as you point = out. I=E2=80=99m not quite sure whether this =E2=80=98leave=E2=80=99 = detection is a necessity. Until all router host routes are updated by = the =E2=80=98link-up=E2=80=99 detection that should ensue in a short = while, the knowledge of a node having left a specific link might not be = of any significant help in retaining the e2e transport connection. Lost = packets in the intermittent =E2=80=98dark=E2=80=99 period should be = recovered by a usual transport operation. On the other hand, one can also argue that prompt knowledge of a node = having left a link should still help if the router implements an = additional function of storing the packets destined to the very node = until its location be identified by a later link-state update by the = router observing the link-up by a visiting node. However, this = additional functionality on the part of routers might be too far = stretched. Anyway, before going into any more details, we might first come to a = consensus whether tackling again on the issue of multi-link subnet in a = form similar to SID6 or any other should be a worthwhile 6man WG work. Thanks. From nobody Tue Sep 4 01:38:20 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11B2130E8B for ; Tue, 4 Sep 2018 01:38:12 -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 xQ7tnpExnRw8 for ; Tue, 4 Sep 2018 01:38:11 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3196A130E9E for <6man@ietf.org>; Tue, 4 Sep 2018 01:38:08 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id j26-v6so1333011pfi.10 for <6man@ietf.org>; Tue, 04 Sep 2018 01:38:08 -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=GSnGD3AHPSgGK+117PVbLzdRB08AHeIs3T8g58tuhiM=; b=Lthp6Ib8B6V5YpF+jbktNJE5OCbbiam5qhUlg3KNTKi3uOxRjeBxN7UHonxPJ2Z0p4 K4n/7uwZ4l4OkHtYzQnLrr+gYbWhDyMpbtWbf/ms/B5o+ZU4VmxweRlJjmuaEhZSZFdD k64YKyU19EqXLYw2ROP6abWaMvOCIYS6i11T6xAhLRbMrbzf95CwdGPX7/SB+wW3vCyN 5IiW62ytmnEcSFy+3KX5yE/SoHKfvwWHqonIOH7x6901TJRLH3LIblrYUyUYJyiM0Ua5 jMc8vJYiNx47vrEoWCAERNOecY0fqLtbjk4nXichXCJIrTTDaBiRVPCulJgEggg2+gjx nccA== 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=GSnGD3AHPSgGK+117PVbLzdRB08AHeIs3T8g58tuhiM=; b=Vi3p60QxRHYgIRZggnet5ZzZWcLm7j2Qr9orT2PJQkUG4wOu/h6nOMfv3F3xCP2CVP 7Sr0hr9XNXnHty2DIhTyhAvGm2dhfnofQtPfx+nFthcM+eBKPtozG97UTuh09OT/BGXx yiHo4BslI7HXHKIyreAbuI+CmyQOXbCh59CKF3vvgjDSYFkxAlF+dVYHLUDsIYfSKErw 45wuz57bqNO+KrWBfRhhQG3J6lTGuROMFiR1cTJLpo4lqujBQGGsFcNZQf9DaW1zZYrs x46nCDqvSiHUI6MTcX+juStehsGZZKniO+Ij5BnNlknztHpIwCMPHSFVZYs4XgCPgFS5 +cmg== X-Gm-Message-State: APzg51D/HZ3I3CD3ygmGqr+n+YVyzgcLRZsbI0+AkCwv8dMSSCZIgQkn UQa9btNfQZU74KEK7JP+NKK7c/R8 X-Google-Smtp-Source: ANB0VdYsth35Rh4ESVqJgezOv8q+WD76cllGOTvHFJhVqhUMBLucBK47AoOdW54NyO2GwTvcdVTrUQ== X-Received: by 2002:a65:464b:: with SMTP id k11-v6mr930967pgr.448.1536050287855; Tue, 04 Sep 2018 01:38:07 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id k126-v6sm35080698pgk.26.2018.09.04.01.38.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 01:38:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Tue, 4 Sep 2018 17:38:03 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 08:38:19 -0000 > On 4 Sep 2018, at 17:29, DY Kim wrote: >=20 > we might first come to a consensus whether =E2=80=A6 we might first have to come to ... From nobody Tue Sep 4 12:47:48 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C07130F7E for ; Tue, 4 Sep 2018 12:47:46 -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 hmCcmf1o1cvy for ; Tue, 4 Sep 2018 12:47:45 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDC2130DC9 for <6man@ietf.org>; Tue, 4 Sep 2018 12:47:44 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id d1-v6so2179622pgo.3 for <6man@ietf.org>; Tue, 04 Sep 2018 12:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SIpYXF5OUeg9mqoY1TdlP6maVRN5CT9kMJiOFVGbPtw=; b=MVOfarIGXZMyky8mczsmm9MG5z04ROX5sjxr5L7o7i3j4mZb9xGe0Pcawr9Hweje65 9aKdJzKMw9s/KgKKuFZEb9ZI5F2ySaWboO8GHz7IcTZ/QU129pc04KP0HkoXfxZOgoMd a+pq5sGo72ueF30GcgH0V5MLEBS6k6BVPBiIqH8469ecujHrfydJDUiApgziPrdcmlgD qpvmkXGhaqfdyZASFTxh0Tb7ReOo15EpAdNJhdchWuoDhLNwk7jIdTI76Kun1b6A+Anx 9eJAG2pMcSsuDVwftsbEqfl74fEuYzcOsb7x5G5TOweLp2tdG6L5g2qBIFPRHgebLLk8 4qHQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SIpYXF5OUeg9mqoY1TdlP6maVRN5CT9kMJiOFVGbPtw=; b=BKhalnVP9BuFt+R+YHNTLk8JFZ+8xG6H+seGBN06KVO8/fd2CDBKYBtqZJhETkP5Jo QC8Wm1FhVsgMzrCztE686d6172GNLvgwaWzt0RUsHmpOCtOsZDp/Xnpsrkkn/tDdNWT1 CF7sVDbWJRzYYGjYrTRw0lY3gVqLOjAiBW+Dz63wGY08zOhJ1wbEliK4PLKGpL/BveBm VsSPxTVBtZBAAv3863EggT/5smjS74Y9dYX5sxT+yirOKjXT2JjO/6HCToZWclVeG+3K qoLgXJfcZJrYAnh4uCyZavro/k/c1r435JLil+9Nj8uHmZKZ7j/B9OZXK8VRlX1cQICj 4G5g== X-Gm-Message-State: APzg51DKzvuWY0jyVQrFllEbDEly2jd7GgT+I0CLokmnuOzFuMGIzGe6 7/NEU6nPdXcWCU5bHSuNKk+IR4aU X-Google-Smtp-Source: ANB0VdYLk9V9EeCSRdt2XgQSW5M4JdprhEEfG9mtefIjCRWUBdzt5wc07GvMWpai7dUlThHedmf/9w== X-Received: by 2002:a62:cac5:: with SMTP id y66-v6mr36377519pfk.187.1536090464204; Tue, 04 Sep 2018 12:47:44 -0700 (PDT) Received: from [10.100.96.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id s3-v6sm45395031pgj.84.2018.09.04.12.47.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 12:47:43 -0700 (PDT) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: Ole Troan Cc: DaeYoung KIM , 6man <6man@ietf.org> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> From: Brian E Carpenter Message-ID: <54d9d4a3-8050-e5e1-0f46-d33d6f0c48ef@gmail.com> Date: Wed, 5 Sep 2018 07:47:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 19:47:47 -0000 On 2018-09-04 19:22, Ole Troan wrote: >> Since current reality is that applications need to be agile with >> respect to address changes, and even IP version changes, I find it >> increasingly hard to justify effort on address stability for mobile >> nodes. >=20 > Applications need to, perhaps, but doesn=E2=80=99t that require a funda= mental change in transport too? > Can you name any applications that are? > I can think of mosh, but I=E2=80=99m hard pressed to find other good ex= amples. Well, maybe this is an ART area discussion, but isn't the basic reason for RESTfulness really that both IP and transport layers are liable to unexpected disconnects? Brian From nobody Tue Sep 4 13:04:13 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1C130F58 for ; Tue, 4 Sep 2018 13:04:12 -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 SC2UiFbfVXwP for ; Tue, 4 Sep 2018 13:04:10 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1CF127332 for <6man@ietf.org>; Tue, 4 Sep 2018 13:04:10 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id s17-v6so2123823plp.7 for <6man@ietf.org>; Tue, 04 Sep 2018 13:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8/jPVmD/HyMz/S2rbjWyCYx4M8ZeAchXEklfS28E6Fk=; b=gOD2koOooasBohM1AzFwJXDfRpjaU/NQQwUSTLxuLTnXx6G5hXjA67VCl4U3D4hkua zJeytFTsRGJWe5dGwl7XhCFO9qntkkBvVlf9M2DSBKgM3itdHNs4ya7CJe6VBCDxLZaL XOior95GfZO8ZOqwcveb3c2aGsTMHVPCJzSqCyk9TSTok1FM+AngdvZ8UachTDUsXYVT hpeuQAe0zkMvbn4FT+LVpeN3SYjzKuCR11ROHT1eK/PwO4EXqyJSVT5+anw+yWgYmlfb 3GNemfOs7YUbm+l2zS9BAykwa+mmWcqfuuhpTxXe7SNUZD9uZgyXYo4BJT2zNVsfKZFi yqmw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8/jPVmD/HyMz/S2rbjWyCYx4M8ZeAchXEklfS28E6Fk=; b=Tvq3Q5F0o2vUHaM2G1dzgeMgCGY+aCJbOnbiOCfRn/7hs2Zn2G2OgmWXRh1dqXqRGi jKtHo8zHaUSfzyoF8LMvggDRJSj4P/Rnm0iJXBewDsyAn1Um5dEZ2UxfLVHc5ckPSEUl H+qxobRJ/90kIzcRLOpwAayI63yeBWL8qXE2opq65CUIBpEfTxsO/N9kidEhX+GbD8Kk V3VuNnXamN3hOoLTxxbJi46GWS4IMn8OIpKYwjwjkfg9CdQDOLEcPdqDE3yCKnM+psSm DpQG1tXV3npnKcmQFSHC6jn7B+lofu0e67IJiw65+vXTs3gjWolsHYHkgawRGiral0YV 1voQ== X-Gm-Message-State: APzg51BlPIZXrWTEvJr1ZilHwf18CLZ1egy4gD7RTMfgdMG/pk/Rp+ht P1sEGrK3oIQSIJcWGeox2oXyimGZ X-Google-Smtp-Source: ANB0VdZ8PpbOUiQ2ArsGa41OR55/ZkYGD/2h9Quxj5We7antNJ7iMlFw4YgkipjqrSDj5b3TYnVsaw== X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr34861228plc.270.1536091449353; Tue, 04 Sep 2018 13:04:09 -0700 (PDT) Received: from [10.100.96.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id y7-v6sm38481482pff.181.2018.09.04.13.04.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 13:04:08 -0700 (PDT) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: Tom Herbert Cc: DaeYoung KIM , 6man <6man@ietf.org> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 5 Sep 2018 08:04:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:04:12 -0000 On 2018-09-04 14:41, Tom Herbert wrote: > On Mon, Sep 3, 2018 at 6:57 PM, Brian E Carpenter > wrote: >> On 2018-09-04 11:30, DaeYoung KIM wrote: >>> May I repeat the text of 4.10 as a first response?: >>> 4.10. >>> o Transport connection resilience for intra-site mobile nodes can be= provided with no extra infrastructure like mapping servers found in most= LIS protocols [HIP][ILNP][LISP], resulting in a significant resource sav= ing. >>> o An equivalent incentive in comparison with the legacy IPv6 network= ing would be that intra-site mobility, and that faster, can be provided i= nherently by any interior link-state protocols, with no hassle of install= ing MIPv6 functionalities on every router in a site. Considering that a s= ite can be arbitrarily large, this can be a considerable additional resou= rce saving in terms of network operation. >> >> Since current reality is that applications need to be agile with >> respect to address changes, and even IP version changes, I find it >> increasingly hard to justify effort on address stability for mobile >> nodes. >> > Brian, >=20 > I'm not sure I would agree with that. If mobility is a very rare event > then maybe this is true, but there are also cases where a mobile > device might be doing handover to different cell sites every few > seconds (consider a smartphone on a high speed train). Overhead to > reestablish all connections constantly and renegotiate security could > very well adversely impact user experience. Yes, although I'm not sure the present proposal will fix that problem. In any case the routing system has to respond very quickly. > Also, not all applications > and devices will handle and address change event gracefully, for > instance there could be devices tethered downstream to mobile devices > that aren't "mobile devices" and aren't prepared to deal with high > rate of address change. Yes, but natural selection will tend to eliminate such apps and devices if this becomes a common scenario. > Eliminating the subnet-ID may also have a positive effect on security > and privacy. Again, consider the mobile case where each cell has a > subnet-ID and each time a device connects it gets an address in that > subnet. Problem is that the network prefix in devices addresses may > reveal specific geo-location of a device (and hence a person in case > of personal device). Eliminating the sub-net prefix and assigning > addresses out of a larger pool of a provider prefix should be better > for privacy. This privacy issue is discussed in some depth in > https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-0= 0-- > I think the mobile addressing model there is similar to what is being > proposed in this draft. Sure. You're trading locator bits that have topological significance against hidden dynamic state in the routing system. It takes me right back to memories of site-wide bridged networks 25 years ago. Brian >=20 > Tom >=20 >> (See the recent v6ops thread: >> https://mailarchive.ietf.org/arch/msg/v6ops/-5DaSE41dmqLVkOWEbUoUtRCS3= A ) >> >> Brian >> >>> >>> Sent from my iPhone >>> >>>> On 4 Sep 2018, at 04:47, Brian E Carpenter wrote: >>>> >>>>> On 2018-09-03 20:35, DY Kim wrote: >>>>> ... >>>>> This invariance of the host=E2=80=99s address over mobility across = links within a site is the essence of the scheme proposed. >>>> >>>> Why is that useful? >>>> >>>> Brian >>>> >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > . >=20 From nobody Tue Sep 4 13:15:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE65130F58 for ; Tue, 4 Sep 2018 13:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 WvVspoDVk6-q for ; Tue, 4 Sep 2018 13:15:46 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 0EFE9127332 for <6man@ietf.org>; Tue, 4 Sep 2018 13:15:45 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id g53-v6so5514825qtg.10 for <6man@ietf.org>; Tue, 04 Sep 2018 13:15:45 -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=u9QxjtKfiNRsJ093B6iWP2orf9vMFaRYrwSVRDZ1bvY=; b=NjbnhlS1qn2/cm+FMiX1GOBb1v1tWjijCdyXvTdDi8valvrY3lTD2ok741LiFkInAa uviViXL4mIFmr/NrDfP1Z0Jq5nbMstDyiJTclkzuPCIdPtVeLomZ+sTRsgO01hWDcx65 TDBFVjTYCO9snkSw2PsDFWKhKDmVZuKRVPiPP9JqeMFBnLqglBa21I5p29BacN3WVDQB xVh2Siqg7ztdWIoSGIKrkVxR13alsnYQvfnR48/1PHMQPPNuEHVmKHIMtfBkt/FFNIyt O5zyU0HP1YnTrveMp/+UoL2xH30UHLYyWjCR9/seylUxlPHGc+rodOpZR2dzvSZoTLAW 7/uA== 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=u9QxjtKfiNRsJ093B6iWP2orf9vMFaRYrwSVRDZ1bvY=; b=ENiXwtDUkP0z2LQra+YiCjpTkCnOEortwQonrqbjN2PjECmFgTOHxXiw2HlGoThXMM /Z7/S/O7RF0BcWvH12boptr2DXtvoTz8HAb9TpnIz0YHsBOc4PqMuGvDq4lU8NtSPTWE +OHPove2a9D1Ucdir2ORbcJOT8DeSz0XPKTyYGvvkI0MGXO5eOCmqBCJtnELzs+Lo2iz X8GI3LuyEV9W3FE2yEGp7bOCCXJ6G6ujk978ogJyM4Kp7BFZul5H4Q/RrgjbiaeBUm98 B89QjqFq3JIjwcJZV3gsrNgr+X1b50jmGE/WWxZ+BcCuQmD2Hk7w+wjCDZq9ZuNYpaVR 9ukg== X-Gm-Message-State: APzg51Af5d9HU/W8FaqMZLPq/R4v5ZB6ucqfTtu0TsL8r4fRKxAzcgvA rsYFMT8z7h9lhKnBoUGvcl0EdvqpRqba7xmdAoSl5hfK X-Google-Smtp-Source: ANB0VdYmFNzgwZygpbEfryi49SA8bF26TH8AvUfhxp3wY5mUvQWu8X3g9uOaXXts1Z7ni7yc5H1Aqb4tPJmaLaN3bqQ= X-Received: by 2002:ac8:505:: with SMTP id u5-v6mr32168939qtg.114.1536092144864; Tue, 04 Sep 2018 13:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:22b8:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 13:15:44 -0700 (PDT) In-Reply-To: <54d9d4a3-8050-e5e1-0f46-d33d6f0c48ef@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6C1E6DBC-CC20-4647-8F40-CABC6F593867@gmail.com> <0b15fe3f-62e6-a42d-3c72-52f6f1466c87@gmail.com> <966C0FF0-57BC-45BD-AEF2-9A412301614C@gmail.com> <582739e7-b02d-c2a7-da36-561d9d0dee6d@gmail.com> <54d9d4a3-8050-e5e1-0f46-d33d6f0c48ef@gmail.com> From: Tom Herbert Date: Tue, 4 Sep 2018 13:15:44 -0700 Message-ID: Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: Brian E Carpenter Cc: Ole Troan , 6man <6man@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.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:15:47 -0000 On Tue, Sep 4, 2018 at 12:47 PM, Brian E Carpenter wrote: > On 2018-09-04 19:22, Ole Troan wrote: >>> Since current reality is that applications need to be agile with >>> respect to address changes, and even IP version changes, I find it >>> increasingly hard to justify effort on address stability for mobile >>> nodes. >> >> Applications need to, perhaps, but doesn=E2=80=99t that require a fundam= ental change in transport too? >> Can you name any applications that are? >> I can think of mosh, but I=E2=80=99m hard pressed to find other good exa= mples. > > Well, maybe this is an ART area discussion, but isn't the basic reason > for RESTfulness really that both IP and transport layers are liable to > unexpected disconnects? Brian, Hopefully, newer applications will properly reconnect when a host is disconnected and an address goes away, or maybe they are behind an API that does that transparently for them. Regardless, it's unlikely that all applications do this properly (there's no requirement that I aware of as to what they have to do in this case). But, the bigger is issue is _how_ hosts gets notified so that it knows addresses have gone away it should close its connections. For a directly attached device, like a smartphone attached to a cell for instance, when the link is disconnected the system will detect that and can remove the addresses and close any connections that are no longer viable. But, there may also be downstream devices to which the mobile device delegated addresses (e.g. by DHCP). All of those devices must be informed somehow that their addresses are no defunct. I assume there's protocol to do this, like DHCP revoking a lease, but it doesn't sound super trivial to me to get this right. Tom > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Sep 4 16:03:22 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508D2130E43 for ; Tue, 4 Sep 2018 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 BqZWetu-3F7a for ; Tue, 4 Sep 2018 16:03:18 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 225B4130DD0 for <6man@ietf.org>; Tue, 4 Sep 2018 16:03:18 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id x7-v6so6025633qtk.5 for <6man@ietf.org>; Tue, 04 Sep 2018 16:03:17 -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=Ou5XvYvQkjZgXmwJotwDk+9mb8igHwM81quixklImCc=; b=CxoUdA4z6IuKxbtkFqv2OIqC0Gtj0dTdb32m9on+oRov23wW97DomwcX8TwBgGcpT3 V2YmkEWbPD1BXP4SnxEPGLbW8Z+Tn52LqipvImKzyFLlUECh/Qxya9B7RezXb7vCfpRC QGUj1RVVrHZcmm27H8DZsqPm8EiArvb78v6n9Bzf6repfO9rayL3MZaSLONxXycf+sT5 vfuVZxyD1xGuCWIlybsBbscxmbOBcdDT8a51Hw9dHAqhu9tetxpQYdvu0QzkFm0W04zV h9VXs+FJ0ezG+rmcpQpaQc2dSxiBhqEIrWkCL2Wv/dAZHpKrdi6co+xOPYWicCG7gzHl WE/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:content-transfer-encoding; bh=Ou5XvYvQkjZgXmwJotwDk+9mb8igHwM81quixklImCc=; b=JtFLDG9ihsia4+25oBsAgDn/EjXs2vGN0aR/bp4rd9a8h/gzhiuAZazpdizFcmb0Il W/ap3hkEeaBqdi/qI2ITPk23+P1/jSYJUZrOHzqIwBKaqyk/ZgoDqvGIb+wvjFU4m8J/ XwA15Y6ZKvRnzhCApxNro1g/Q2wwrgO/2i3Agz64YQVcldnFWdNd9GqhAyds5TIiQCR5 pkpzgRolP4zLNWsdM7yZ9q6wMLepwU437gY7wY8VhDtLaGcUNcoEG/168nEFV9zy4IFA yKHzxnCR+W5PNXAVYyT2n8IM43HRiEKpPwVTofLAgD/8chQ+nw1PRN18ZCsKk1fmp7mw 7Ffw== X-Gm-Message-State: APzg51CbhmBLahMhrBgUCxhFW7CWHkBAbehD37CFVkFX3r8laNj1b5Np oS4MHP4xrzhE9ggIS4CGBz39kEADcwWXogyn5Byw7yHFAI8= X-Google-Smtp-Source: ANB0Vdb5ksluk26Sj0lg6vP+XGQM5jwi2uWFpsJps7adMqehA5YXo4vBzQmp1gJRA9epS8F8h5r5O1ViCnztyzIDjCc= X-Received: by 2002:a0c:f685:: with SMTP id p5-v6mr30728861qvn.22.1536102197043; Tue, 04 Sep 2018 16:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 16:03:16 -0700 (PDT) In-Reply-To: <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> From: Tom Herbert Date: Tue, 4 Sep 2018 16:03:16 -0700 Message-ID: Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: DY Kim Cc: 6man <6man@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.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 23:03:20 -0000 A few comments: >From the draft: "This document proposes to change the operation of IPv6 networking by deprecating the SID. That is, the value of SID shall be set to zero." Specifying that part of the IP address is always zero seems like an incredible waste of a resource. I think the more compelling idea is alluded to later (section 3.6) which is for a site to reclaim those bits to use for other purposes. I don't follow the description of recursive networking. It sounds like this either describing hierarchical routing or identifier/locator separation in addresses somehow. If I'm reading section 4.3 correctly, mobility happens by host routes in the routing system. Not sure that can scale. In any case, if this draft is poposing a new mobility mechansim it probably should be described in its own draft. Tom On Mon, Sep 3, 2018 at 12:51 AM, DY Kim wrote: > Hi, > > I=E2=80=99ve reposted a draft, this time to 6man, which was posted to 6op= s about a > year ago but fell out of scope there since it involves some changes to > NDv6/DAD with added texts. > > I=E2=80=99d like to see whether there should be any interest in this draf= t within > the 6man group, possibly enough to justify the modification of NDv6/DAD a= s > suggested in this draft. > > Your comments are solicited. > > --- > DY > > > > > > > > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dykim-6man-sid6-00.txt > Date: 3 September 2018 at 16:46:04 GMT+9 > To: "DY Kim" > > > A new version of I-D, draft-dykim-6man-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. > > Name: draft-dykim-6man-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2018-09-03 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt > Status: https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dykim-6man-si= d6 > > > Abstract: > Deprecation of the subnet ID in IPv6 networking is proposed; the > subnet ID is set to zero so that all nodes in a site carry the same > prefix. While the procedures for neighbor discovery and duplicate > address detection have to be changed, possible simplification gains > in IPv6 networking including that of intra-site host- and subnet- > mobility might be worth the modification. Site-external behaviors > don't change through this modification, enabling incremental > deployment of the proposal. Sites of manageable sizes for which > scalability is not much a critical issue might consider the mode of > operation proposed in this document. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Sep 4 17:01:51 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715F3130FDE for ; Tue, 4 Sep 2018 17:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 r1Uwq_PgzhU1 for ; Tue, 4 Sep 2018 17:01:48 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3933C126DBF for <6man@ietf.org>; Tue, 4 Sep 2018 17:01:48 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id d19-v6so2460477pgv.1 for <6man@ietf.org>; Tue, 04 Sep 2018 17:01:48 -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=QiE9JvRgGpsAscIcszxrYKU0kLcDIHVjXcv8WJb5WNw=; b=iPJHDEJ/hB1ZpacyZxZzS2TZ78JMoCVa9U4GypK4tX01k2GKz5sTgQJduDLUQ52Jwo CRby+XmcFzLV/UVCVjFKYuhjVf3D9UvSVEcwpOF90fmPi0Fnm58GTo5cwmayavRi70Rf rCM0o4nxWMVmrJpL2vRsEO8wZtWQyfvTtW+YdxhePZD9POdg8zIsENHmkMeGKKFZxasX MsxRL0+h5SbdlyLtsTYcUinCUBB9Sbs3zHkvTCu/03ZNl6PviuoGcNfRK0HRaGrJ6xa6 SR1E9joN8ndrUFJaKTxDIztYnbcmjkUd6K3CEfERawM7+WCyECUwaQpWTcXOk+jYMHQ7 6Gxg== 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=QiE9JvRgGpsAscIcszxrYKU0kLcDIHVjXcv8WJb5WNw=; b=haOx5HUa5npRFG3ZWEfNJcyepebDbg7JrsEKwbPlXhYfjImdAxN7JzrPqgr6t50pxY WMEntFlLBopuNNYLaYWxxXxW4gC1OWZmFQHgEgcAAn2VZv9GRI8Oob+75MI15UWI4rnR dra/gH9vy46oa5AzASFMXLSiBRblwSGjWhlan/wtH5sWTOxm5qKBNp5yEpIGRzpHFmXB m/q7VZ7jn9obhFQZEWDgmlol3NjXSsw5sJ6O6W6++mIii7uecLG0SIY8dLP7PfErtWAs jDSasL/nys72fpT155FZN/l1WLIO3wq30nshUECAAtKdf/AGAalohl+tVm6vyiEt/6E+ 1kKA== X-Gm-Message-State: APzg51Crqy4hSUaL1V0jigdYl769dZHJpvPfVl2qFC/LKz3t1UqIOU96 gXrVg+Olr9JWWG6dBZ6k9gM= X-Google-Smtp-Source: ANB0VdYUGe+VMMmULc3wYxNKPEjpAGnnBkV06cbe71YsZAMBNGx64EGltGFrmOEeaxNwxDbP3FJ3/w== X-Received: by 2002:a62:1c7:: with SMTP id 190-v6mr37206190pfb.1.1536105707709; Tue, 04 Sep 2018 17:01:47 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id w81-v6sm203628pfk.92.2018.09.04.17.01.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 17:01:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Wed, 5 Sep 2018 09:01:42 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <83B4D494-5657-400D-84D3-0A1462FB7682@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 00:01:50 -0000 in-line. --- DY > On 5 Sep 2018, at 08:03, Tom Herbert wrote: >=20 > =46rom the draft: "This document proposes to change the operation of > IPv6 networking by deprecating the SID. That is, the value of SID > shall be set to zero." >=20 > Specifying that part of the IP address is always zero seems like an > incredible waste of a resource. I think the more compelling idea is > alluded to later (section 3.6) which is for a site to reclaim those > bits to use for other purposes. Well taken. Something to note: If the field is used for Unique IPv6 Prefix for Host, = then the number of hosts in a site will be limited to 2**16, assuming = the site gets /48 from the provider. If it is desired to accommodate = more hosts, the site might get a shorter provider prefix, say /32. > I don't follow the description of recursive networking. It sounds like > this either describing hierarchical routing or identifier/locator > separation in addresses somehow. In fact, the major motivation for this draft is to provide transport = connection resilience without resorting to identifier/locator = separation. The draft is not about identifier/locator separation, I=E2=80=99= d say. Description on recursive networking should be more of an academic = exploration. The related text, and possibly also other =E2=80=98stretched=E2= =80=99 academic claims, could be removed to leave only technical essence = of the proposal. > If I'm reading section 4.3 correctly, mobility happens by host routes > in the routing system. Not sure that can scale. In any case, if this > draft is poposing a new mobility mechansim it probably should be > described in its own draft. The draft starts with saying it is for =E2=80=98sites of manageable = sizes for which scalability is not much a critical issue.=E2=80=99 The = technical idea is to be applied only as far as the scale doesn=E2=80=99t = break the system. I don=E2=80=99t mean to claim the technology would replace the legacy = IPv6 operation in a global scale. It is only for those application areas = wherein the network owner finds the technology useful for their = purposes. In the era of IoT, there might arise various networks where different = application requirements might justify different mode of operation, = e.g., as suggested by this draft. From nobody Tue Sep 4 17:07:15 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B706130DD7 for ; Tue, 4 Sep 2018 17:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 LZkfpvpSa1L0 for ; Tue, 4 Sep 2018 17:07:13 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD82126DBF for <6man@ietf.org>; Tue, 4 Sep 2018 17:07:13 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id u24-v6so2474342pfn.13 for <6man@ietf.org>; Tue, 04 Sep 2018 17:07:13 -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=mrtPVn64C0JMbMGXNzn2mfVbYT2XncpakzuVcKxoTW4=; b=q9wfnHgQzqdAd5zUwmN8MkadAk2MupidvI+JKPHrq3bK7LLnrDpyVbiafxvMfUe/xj aRG+vM3zv3rdF+5FKTQtWW2e7Fy2uLq+y7GiN1mfN0o8J1Ns8j9gJZNfkgMYCNDwFxAh damFHLE/hg54ygy7y69XS6LcDfvChD/Ad/Ca9MveRHcfJJ9bzTnKoJYRCHIJYwMw6MeR aNOPGnCV1k+C8kSp0v7TFKLi69KfbAUwdfMtswhkEExWSl4WuMqRO0HjrGxaQiZ+1Xat GLyXdltiDQQkEXFNqfqZbEWIZaM4sv7V3sLzczHUR/NfB1HZIbWorrUYxlDj6M6NiR66 zL6A== 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=mrtPVn64C0JMbMGXNzn2mfVbYT2XncpakzuVcKxoTW4=; b=O+BUiijdXhUZZA2dxie3zfU3lMQo42/HZ3bXGDG94cVLkQUmwxywnsrDOA8DUleGh8 KPDKcKPFuy9XZjokRdse/vvQpNwrhkJIoTHYrhc9uADtkiqemtMpK+/60wzUvRwKh8m4 Dpbk5vAZMFb8o8T7hkoZbeNKFw9S0hdOvUkJHO94djQyk/c/KphduRVv5QT5S6MSWrdi noFbtFFGmnNj6mwO065pGrE7Lkrox30mlt+6N6nhURYnpcJNXSPoprKhahMSLAtJCCEy Gu01GqYz+kMmzX1ftxVzOtmXLQQ9a2aMJCtzwv5yBJmkbJfhkYdk663Kk1fJurLOduIU /kAg== X-Gm-Message-State: APzg51De0w0OR2GBuwy2RrOuw6XiZ8/6iy+PLIi59O7ojhS6McaDcRkj h5HQFW510covGW4Mk9L3AIfsaIio X-Google-Smtp-Source: ANB0VdYcxpFYEeEBo/ZMGdmJarfIRSl85GT9KkceJ2ne8HV+LD+A/r04YTmEGkz5VSbPzTZ25+wXUA== X-Received: by 2002:a63:d54e:: with SMTP id v14-v6mr34206516pgi.264.1536106032827; Tue, 04 Sep 2018 17:07:12 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id r23-v6sm248151pfj.5.2018.09.04.17.07.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 17:07:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Wed, 5 Sep 2018 09:07:09 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <7E5688A6-8913-4CD2-AC32-36A823DCFB62@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 00:07:14 -0000 --- DY > On 5 Sep 2018, at 08:03, Tom Herbert wrote: >=20 > If I'm reading section 4.3 correctly, mobility happens by host routes > in the routing system. Not sure that can scale. In any case, if this > draft is poposing a new mobility mechansim it probably should be > described in its own draft. One more word to this. A new mobility mechanism to propose was not the = major intention of the draft. As said, provision of intra-site transport = connection resilience without resorting to identifier/locator separation = was the main object. In doing that, I just relied on the routing system = for intra-site mobility.=20 From nobody Tue Sep 4 17:25:02 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29011130DEE for ; Tue, 4 Sep 2018 17:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 4v_DzDZRSIEA for ; Tue, 4 Sep 2018 17:24:59 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEDD130DD7 for <6man@ietf.org>; Tue, 4 Sep 2018 17:24:59 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id b11-v6so2515341pfo.3 for <6man@ietf.org>; Tue, 04 Sep 2018 17:24:59 -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=W6aadXtVzAj91X3phY8ISq5Ld8HNxvYvowfi8DgL+YY=; b=f9p4qqM3vyJ4a5HC6jQNyrDq6liFeFdnkAv9wR73LtPwy/zlLPKVPEFWpZT6qIUFVT BEqwdpdnq1YkUWan+WpBE7DiXibQ6wAhxWgG5Le34CGiTOl0Znmj88tmbWJyXfASk4Ek zueQn2/WuDos+sNGhlEaR2ieadnWHZ3l2ZH4gEnc5OlOh0psZ9GPy3+pE0CrWkJjhIME 7ROpw3JnWwPeWNGgVyEUMICLK1byZChCnuKbKJxxqnzzsyg/oKjG0vssmIuAEW8tUlgx cP/Wy9GF8JUdZAPfD5aq59fk45Uw5bU8iKhe2QZAxi5M+R+zmLJ8T0BPmtUe1baU1DQy b/Dw== 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=W6aadXtVzAj91X3phY8ISq5Ld8HNxvYvowfi8DgL+YY=; b=Yf75NJ5KYD0vFe8WhaxbrCoJm8KNV0WpkUrkgiaTLN1rRDUKqS/aGdXkGtR9/6STOc BjyozWih1T3Ww2NbCaEtkkkSLha4liRABuqRMAEOteF1J0UXRX1EIsrS+mpQhveu1LTz +X0S5owGoVAysA7WkrMh49hwznjuLBaSkyB0HCcOQNUFDd46G9sjzXUzItrWa33atE+K PHEqAbEatd4VuXpay9USJWFvjY/9CjGY5+ZcGxriDkWMLIniUYPiVljxo7DCko038nFa 21MFASb2793gNHEcjiwYrWoWSVKdutkD6gVgXxSkmJvx7WY9yF4nWkDYQgoFmYuZJFJf c9aQ== X-Gm-Message-State: APzg51BATz695lKvHHwf9UjGqiG/TL9ctCPkr+JUOjQIGQc3VSbePds6 Y7BjixtJNSMrkm+WppxeRI9sB1MF X-Google-Smtp-Source: ANB0VdYiwLueOLW0C7jJK7pxARxKYxGfmVmiZjeqTQ6JZ7r+jRSD4pZpMs2lJRjMX3dU8jKYEiqIwA== X-Received: by 2002:a62:d8c4:: with SMTP id e187-v6mr132791pfg.113.1536107098677; Tue, 04 Sep 2018 17:24:58 -0700 (PDT) Received: from [222.113.135.42] ([222.113.135.42]) by smtp.gmail.com with ESMTPSA id k1-v6sm211455pfi.62.2018.09.04.17.24.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 17:24:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> Date: Wed, 5 Sep 2018 09:24:55 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <5D95818C-73E7-47D2-8CDE-9F691F05375B@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> <6D793393-97D0-43ED-8DDF-55DDFB0811B8@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 00:25:01 -0000 --- DY > On 4 Sep 2018, at 05:45, Ole Troan wrote: >=20 > =46rom a quick glance it looks like you have re-invented multilink = subnet routing. > Which of one flavous is described in = https://tools.ietf.org/html/draft-ietf-ipv6-multilink-subnets-00 On my second thought, I=E2=80=99m not sure whether SID6 is a kind of = multi-link subnet, although it might be that the two attempt to achieve = similar things. In SID6, each link bordered by a router is seen as a subnet which, = however, is not identified by the Subnet Prefix but by the NID(node ID), = i.e., the IP address of the router. In this view, each subnet consists = of a single link. If a link is bordered by more than one routers, the = link belongs to more than one subnets of which each is identified by a = different NID of the associated router. Sharing /64 across multiple links might be the same for the two. = However, if we utilize the subnet prefix (64 - site prefix) for Unique = IPv6 Prefix for Host (Sec. 3.6 of SID6), we=E2=80=99re effectively = sharing the site prefix across all intra-site nodes. From nobody Wed Sep 5 10:41:02 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E42130DDA; Wed, 5 Sep 2018 10:41:00 -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, 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 3PphhP2Ogknx; Wed, 5 Sep 2018 10:40:58 -0700 (PDT) Received: from bugle.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 8DB2A12426A; Wed, 5 Sep 2018 10:40:58 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 8B596FECBB26; Wed, 5 Sep 2018 17:40:57 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 95E335354C9; Wed, 5 Sep 2018 19:40:55 +0200 (CEST) From: Ole Troan Content-Type: multipart/alternative; boundary="Apple-Mail=_93D1EBAF-B017-4076-B99C-50E6A5C74E92" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: WGLC: draft-ietf-6man-ipv6only-flag-02 Message-Id: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> Date: Wed, 5 Sep 2018 19:40:55 +0200 Cc: 6man Chairs <6man-chairs@ietf.org> To: 6man WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 17:41:00 -0000 --Apple-Mail=_93D1EBAF-B017-4076-B99C-50E6A5C74E92 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii This message starts a two week 6MAN Working Group Last Call on advancing: Title : IPv6 Router Advertisement IPv6-Only Flag Authors : R. Hinden, B. Carpenter Filename : draft-ietf-6man-ipv6only-flag-02.txt Pages : 11 Date : 2018-08-14 https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 as a Proposed Standard. Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 19 September 2018. An issue tracker will be setup to track issues raised on this document. Thanks, Ole --Apple-Mail=_93D1EBAF-B017-4076-B99C-50E6A5C74E92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This message starts a two week 6MAN = Working Group Last Call on advancing:

Title =        : IPv6 Router Advertisement = IPv6-Only Flag
Authors      : R. Hinden, B. = Carpenter
Filename     : = draft-ietf-6man-ipv6only-flag-02.txt
Pages   =      : 11
Date         = : 2018-08-14

   https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02

as a Proposed Standard. Substantive = comments and statements of support
for publishing this = document should be directed to the mailing list.
Editorial = suggestions can be sent to the author. This last call will
end on 19 September 2018.

An = issue tracker will be setup to track issues raised on this document.

Thanks,
Ole


= --Apple-Mail=_93D1EBAF-B017-4076-B99C-50E6A5C74E92-- From nobody Thu Sep 6 15:56:55 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F210F127148; Thu, 6 Sep 2018 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mQg8hxBRpnt2; Thu, 6 Sep 2018 15:56:50 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 7B7A8130F50; Thu, 6 Sep 2018 15:56:50 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w86MqG5E015860; Thu, 6 Sep 2018 15:56:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=zfVcG6EysOeOey7dSmawpW7e2i0ACntdtZEcDShMubY=; b=fc+AbqaTRuWpsq3yeJk2OU+ZNq4GzLPusliyCYrAoVYTQKLISosgZ+b/eTOU/HPfoni5 /8BC98VH0SG1YB/xz1gnZ4vWlvz/Jm+Fds2qUw7Lbw0P0Q0689Gso+HFBoXA/rDZqFK7 B82PZZiD+rexaDtIGXYKAQ/SPC8vFwTiX0WFzPmKEo/MeKQnNWuZxRKdEec7KCNnd8kJ lwF6QdBuRpudVi+WNgYHbWCq2WgBvVzHpLNgO+Nq0d6gLepFAcHRTHV0NoUUTlmi+QP+ fpuivCzNmzV+NBrm4b71RUO7egoBerndAl7U2ObOHZ/K2wanWm4i1AMRhNS1SLigapYd tA== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2m7ss11qp3-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Sep 2018 15:56:48 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PJRO5kz7/7uRxl/nwLoW4g)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEN00HT4P2IRHD0@ma1-mtap-s01.corp.apple.com>; Thu, 06 Sep 2018 15:56:46 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEN00D00OV8CH00@nwk-mmpp-sz10.apple.com>; Thu, 06 Sep 2018 15:56:45 -0700 (PDT) X-Va-A: X-Va-T-CD: 5ad60cfbcecc094e31500e3a3dc020d6 X-Va-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-Va-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-Va-CD: 0 X-Va-ID: 96cb3dfb-ea6b-4d65-8eb1-22172973081d X-V-A: X-V-T-CD: 5ad60cfbcecc094e31500e3a3dc020d6 X-V-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-V-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-V-CD: 0 X-V-ID: 2e62930a-02c1-483d-8b66-9a42560c0187 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEN00E00P0AIL00@nwk-mmpp-sz10.apple.com>; Thu, 06 Sep 2018 15:56:45 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-06_11:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEN007JOP2KI660@nwk-mmpp-sz10.apple.com>; Thu, 06 Sep 2018 15:56:45 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Date: Thu, 06 Sep 2018 15:56:43 -0700 In-reply-to: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> To: Ole Troan References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-06_11:, , signatures=0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:56:54 -0000 --Boundary_(ID_PJRO5kz7/7uRxl/nwLoW4g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello 6man, I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard. The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can be solved simply by having the router drop all IPv4 traffic. The document even tries to claim that it improves security by reducing malicious IPv4 traffic. That is simply false as hosts are free to ignore the flag, and malicious ones will. This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. Again, the correct solution is to have routers drop IPv4 traffic. This document is also harmful with regards to future developments of the Internet Protocol. What happens when the next version of IP is standardized? Does this flag prevent using the new version on "IPv6-only networks"? So do operators now need to disable this flag and end up with triple stacked hosts? I think the problems described in this document would be better solved by having routers drop all IPv4 traffic and potentially having a mechanism to let the clients know of this policy - but that mechanism should live either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the small number of RA flags we have left. While I can't comment on future products, the odds of us deploying this are very low. And since this option is not useful without most client devices supporting it, network operators will not get the improvements they seek. For all these reasons, I think this proposal does not adequately solve the problem it describes, and is harmful to future developments of IP. It is therefore premature to promote this draft to Proposed Standard. I would rather see this problem solved elsewhere, potentially in DHCPv4. Thank you, David Schinazi > On Sep 5, 2018, at 10:40, Ole Troan wrote: > > This message starts a two week 6MAN Working Group Last Call on advancing: > > Title : IPv6 Router Advertisement IPv6-Only Flag > Authors : R. Hinden, B. Carpenter > Filename : draft-ietf-6man-ipv6only-flag-02.txt > Pages : 11 > Date : 2018-08-14 > > https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 > > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 19 September 2018. > > An issue tracker will be setup to track issues raised on this document. > > Thanks, > Ole > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Boundary_(ID_PJRO5kz7/7uRxl/nwLoW4g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hello= 6man,

I am strongly = opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed = Standard.

The = first motivation defined in this document is that it reduces resources = used by IPv4. But to do that it requires all client devices to support = it, which will take many years. This motivation can be solved simply by = having the router drop all IPv4 traffic.

The document even tries to claim that = it improves security by reducing malicious IPv4 traffic. That is simply = false as hosts are free to ignore the flag, and malicious ones will. = This doesn't even protect hosts that implement this flag as a malicious = node can send an RA without this flag to make them use IPv4. Again, the = correct solution is to have routers drop IPv4 traffic.

This document is also = harmful with regards to future developments of the Internet Protocol. = What happens when the next version of IP is standardized? Does this flag = prevent using the new version on "IPv6-only networks"? So do operators = now need to disable this flag and end up with triple stacked = hosts?

I think = the problems described in this document would be better solved by having = routers drop all IPv4 traffic and potentially having a mechanism to let = the clients know of this policy - but that mechanism should live either = at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the = small number of RA flags we have left.

While I can't comment on future = products, the odds of us deploying this are very low. And since this = option is not useful without most client devices supporting it, network = operators will not get the improvements they seek.

For all these reasons, I = think this proposal does not adequately solve the problem it describes, = and is harmful to future developments of IP. It is therefore premature = to promote this draft to Proposed Standard. I would rather see this = problem solved elsewhere, potentially in DHCPv4.

Thank you,
David = Schinazi



This message starts a two week 6MAN Working Group Last = Call on advancing:

Title =        : IPv6 Router Advertisement = IPv6-Only Flag
Authors      : R. Hinden, B. = Carpenter
Filename     : = draft-ietf-6man-ipv6only-flag-02.txt
Pages   =      : 11
Date         = : 2018-08-14

   https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02

as a Proposed Standard. Substantive = comments and statements of support
for publishing this = document should be directed to the mailing list.
Editorial = suggestions can be sent to the author. This last call will
end on 19 September 2018.

An = issue tracker will be setup to track issues raised on this document.

Thanks,
Ole


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

= --Boundary_(ID_PJRO5kz7/7uRxl/nwLoW4g)-- From nobody Thu Sep 6 16:43:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22163130F13 for ; Thu, 6 Sep 2018 16:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (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 jEbS8D83guYo for ; Thu, 6 Sep 2018 16:43:13 -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 AFDE8130F1C for <6man@ietf.org>; Thu, 6 Sep 2018 16:43:13 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 439761172 for <6man@ietf.org>; Thu, 6 Sep 2018 23:43:13 +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 myAAcsyMmASf for <6man@ietf.org>; Thu, 6 Sep 2018 18:43:12 -0500 (CDT) Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.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 D40BEF41 for <6man@ietf.org>; Thu, 6 Sep 2018 18:43:12 -0500 (CDT) Received: by mail-ua1-f69.google.com with SMTP id y3-v6so5460199uao.7 for <6man@ietf.org>; Thu, 06 Sep 2018 16:43:12 -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=bgJsBECtE7ZMk+FWAyfwUh3rSIBrYHvTzmg5wshwiMU=; b=oz3+04RWPxJv+mYYAlhY1HJcT0hwdzV9taKmfAsyEAWZrpp8Q4hKL5sCyAQdoakYUU zU2yT0wMdkeraa7GaoWNnSmt3nFi+7DRRBrgMGSCqr0+8iJyhMuM6eGdpErf94XeJDKW nt143mTQrlmCq7OUVllarN/NfAge9aqc0l/YpbHSAKk6W4meHDhjSHNLan2xDLPU4dl3 ObRRmJQkXeBLzFenkB6/LN4/skQHWlVJW3nZ3LrNzseDgOA1LohGtjna55B5uRILeZiG mCMTFcT07C151tNMffyZDTagEv6G6p6bXehomxzsj7sEZbYHzJ/+EI1g4OBjAW9YWXjd B+yg== 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=bgJsBECtE7ZMk+FWAyfwUh3rSIBrYHvTzmg5wshwiMU=; b=nNPMvKgqB/xicPaWu1MWjsD/yfxJf/rG5W/zuJZ8iJJZXH5u994qc5spJUNvSKsRrr +F60IbpAN1Akb/wc5TqxSxk/jPeVFd7GGNk4shScPIWWixv9Pur59bwlpwGBIjjc/c7V gndSaBy3BfGtSg8vqB4dUEKacERf5HX3rQ6al7b2WGXK31ifMs87Vw3fCdmSqUkuhrIW 0lS3059OshAX1mDqOl2LPv6lI9edmmbSG6cTnfDPx9oulbGioMTRecJVJOwuMf1D/dcy 5JZ/VxQx7ZZ1kYahk1GiFR5DoN7YJ1cXQPvRMxnPDsmmAr0YgNmIgym9u0XFoTaNt8/S OFdQ== X-Gm-Message-State: APzg51CrAd7NEQ/rhdPW4niTcKBMrutgq3KTyRehNJwgkyf3Wgs8sCoB Mq0oQVEcCPrXkKUPC6iXQU3xEU2VyWV6ZddlXgM3Mle2LIna0oDql0GfVNebibUkCDVD1DR7zrF O1e4DMSEqeRCUkhv4DJUNsbht X-Received: by 2002:a67:3ec6:: with SMTP id a67-v6mr1966797vsi.58.1536277391661; Thu, 06 Sep 2018 16:43:11 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb7M6fIECMZGfcWkAvgkAh4EfipbNSwZ0W6tzjMKD0sUOeY/9kEsMeVLUHF8DtgYO18EZxGIXzR89fqJpKh9AY= X-Received: by 2002:a67:3ec6:: with SMTP id a67-v6mr1966793vsi.58.1536277391287; Thu, 06 Sep 2018 16:43:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:6042:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 16:43:10 -0700 (PDT) In-Reply-To: <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> From: David Farmer Date: Thu, 6 Sep 2018 18:43:10 -0500 Message-ID: Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: DY Kim Cc: 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000002f3f2905753c7433" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:43:16 -0000 --0000000000002f3f2905753c7433 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure this is an IP layer problem, v4 or v6, some of it might not be an IETF problem either. If you want hosts to have the same IP address as it moves around a site this is possible today with things like 802.1x, you put the host in the same VLAN whatever port or AP it attaches too. If you are worried about stretching layer 2 everywhere in a site then look at abstractions like VXLAN or MPLS with EVPN as your control plane with the right hardware can scale to extremely large sites. There are other options too like TRILL, shorted path bridging, even LISP, etc... Basically, you end up with control plane that has every MAC address, IPv4 /32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you are doing multicast you probably need (S,G) state too. The advantage of this model it is IP version agnostic and ethernet protocol agnostic. Further, this also allows the many simpleton assumptions applications make today about the network to hold true. I'm not sure we need an IPv6-only solution in this problem space. Thanks On Mon, Sep 3, 2018 at 2:51 AM, DY Kim wrote: > Hi, > > I=E2=80=99ve reposted a draft, this time to 6man, which was posted to 6op= s about a > year ago but fell out of scope there since it involves some changes to > NDv6/DAD with added texts. > > I=E2=80=99d like to see whether there should be any interest in this draf= t within > the 6man group, possibly enough to justify the modification of NDv6/DAD a= s > suggested in this draft. > > Your comments are solicited. > > --- > DY > > > > > > > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-dykim-6man-sid6-00.txt* > *Date: *3 September 2018 at 16:46:04 GMT+9 > *To: *"DY Kim" > > > A new version of I-D, draft-dykim-6man-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. > > Name: draft-dykim-6man-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2018-09-03 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-dykim- > 6man-sid6-00.txt > Status: https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dykim-6man > -sid6 > > > Abstract: > Deprecation of the subnet ID in IPv6 networking is proposed; the > subnet ID is set to zero so that all nodes in a site carry the same > prefix. While the procedures for neighbor discovery and duplicate > address detection have to be changed, possible simplification gains > in IPv6 networking including that of intra-site host- and subnet- > mobility might be worth the modification. Site-external behaviors > don't change through this modification, enabling incremental > deployment of the proposal. Sites of manageable sizes for which > scalability is not much a critical issue might consider the mode of > operation proposed in this document. > > > > > 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 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --=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 --0000000000002f3f2905753c7433 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure this is an IP layer problem, v4 or v6, so= me of it might not be an IETF problem either. If you want hosts to have the= same IP address as it moves around a site this is possible today with thin= gs like 802.1x, you put the host in the same=C2=A0VLAN whatever port or AP = it attaches too. If you are worried about stretching layer 2 everywhere in = a site then look at abstractions like VXLAN or MPLS with=C2=A0EVPN as your = control plane with the right hardware can scale to extremely large sites. T= here are other options too like TRILL, shorted path bridging, even LISP, et= c...=C2=A0

Basically, you end up=C2=A0with control plane= that has every MAC address, IPv4 /32 and IPv6 /128, probably every IPv4 an= d IPv6 prefix, and if you are doing multicast you probably=C2=A0need (S,G) = state too. The advantage of this model it is IP version agnostic and ethern= et protocol agnostic.=C2=A0 Further, this also allows the many simpleton as= sumptions applications make today about the network to hold true.

I'm not sure we need an IPv6-only solution in this prob= lem space.

Thanks
=
On Mon, Sep 3, 2018 at 2:51 AM, DY Kim <dyki= m6@gmail.com> wrote:
Hi,

I=E2=80=99ve reposted a draft, this time to 6man, which was posted t= o 6ops about a year ago but fell out of scope there since it involves some = changes to NDv6/DAD with added texts.

I=E2=80=99d = like to see whether there should be any interest in this draft within the 6= man group, possibly enough to justify the modification of NDv6/DAD as sugge= sted in this draft.

Your comments are solicited.

-= --
DY








Begin forwarded message:

Subject: <= /b>New Version Notification for draft-dykim-6man-sid6-00= .txt
Date: = 3 September 2018 at 16:46:04 GMT+9
To: "DY Kim" = <dykim6@gmail.com<= /a>>


A new version of I-D, draft-dykim= -6man-sid6-00.txt
has been successfully submitted by DY Kim and posted t= o the
IETF repository.

Name: = draft-dykim-6man-sid6
Revision: 00
Title:= Subnet ID Deprecation for IPv6=
Document date: 2018-09-03
Group:= I= ndividual Submission
Pages: 17
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
https://www.ietf.org/internet-drafts/draft-dykim-6man-sid6-00.txt
Status: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker= .ietf.org/doc/draft-dykim-6man-sid6/
Htmlized: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-d= ykim-6man-sid6-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-dykim-6man-sid6


Abstract:
=C2=A0=C2=A0Deprecation of the subnet I= D in IPv6 networking is proposed; the
=C2=A0=C2=A0subnet ID is set to z= ero so that all nodes in a site carry the same
=C2=A0=C2=A0prefix.=C2= =A0 While the procedures for neighbor discovery and duplicate
=C2=A0=C2= =A0address detection have to be changed, possible simplification gains
= =C2=A0=C2=A0in IPv6 networking including that of intra-site host- and subne= t-
=C2=A0=C2=A0mobility might be worth the modification.=C2=A0 Site-ext= ernal behaviors
=C2=A0=C2=A0don't change through this modification,= enabling incremental
=C2=A0=C2=A0deployment of the proposal.=C2=A0 Sit= es of manageable sizes for which
=C2=A0=C2=A0scalability is not much a = critical issue might consider the mode of
=C2=A0=C2=A0operation propose= d in this document.




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

The IETF Secretariat



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




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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
--0000000000002f3f2905753c7433-- From nobody Thu Sep 6 17:53:48 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6312F295; Thu, 6 Sep 2018 17:53:47 -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 kBlJ62oABYfc; Thu, 6 Sep 2018 17:53:45 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A000F126DBF; Thu, 6 Sep 2018 17:53:44 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id p52-v6so10267948eda.12; Thu, 06 Sep 2018 17:53:44 -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=IeKSYYO12SRox2k6zo7EcVkWwOwYlresm8hVVE40dIg=; b=F87d+PKpZS5R542JviukBItC24YbmsWGDw1jcsuBi5aRNSFo03oD2HF3SyEQghuLie sOYByqbm14dnusDMEd4DU1iHSeLKLaSm41IEoPKA6ALjJ5S0ecXIC3elbq/LT6FAVZvf 5u0ky3n4L9Pce74L7AfkVS+poRuvmujXbzR229ILV8kzl500GAT9sgKV3Sa5UrW2varu 3PHU3E4SfiRzJV6eGUgo/xpTrhIk4HbsyF5HYnidVj3Iy9w1o93MMLt5xaEZc/yiOG+H Dxq37qH0ivxfhBnK/9K8e/QuE8CFslZYZanNnh9240aWCqXlFG2cPUZ9HcGjC+HjamsQ HmsA== 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=IeKSYYO12SRox2k6zo7EcVkWwOwYlresm8hVVE40dIg=; b=cVSiybpjSX/zMHQOi4MQKzS9t3jxGkczdDIwzJIg7mzangP8wNexd4PBKop4Anh70/ 3hJ/LtV50ceOIXvhFba9yqW9aOl1U9jeniRADoNAMCJGt9dK5WVPajI+ZXa9iAHNgfEr NBRN8Fl3DHqjgKYaNoiUHHWtslMcc+MyNHdts0d5s7p16Pqfu73L2geI0tbTvmxj4Rwv /P173HemJgOLjLQ7QA8uoEYVhmdh96CKJJqsGW1Fxib+eSEmz2/PKrHi2mKCoSuMvQ2H KjnQzfM7mxFxrByogbdrSvMyUOyXn0GJmiTn13SfXo4YDnv9qI2N0NVWa4Z0wv8e8xy1 Hvcw== X-Gm-Message-State: APzg51DN0o2VKQ9xw/F06a8Uhuvwqhb7uTta1MBBtTWjPhT2sl3F9BGC AVLDfLZlJ/AG0ONOaEYoMZI= X-Google-Smtp-Source: ANB0VdaLaXvLG5KiemhAq6/yiVMQFjgut6u1Rbv+vFfS5HWyb3dFCIrCbnm8OupKnzjm8Dud9mXrVA== X-Received: by 2002:a50:cb8c:: with SMTP id k12-v6mr6281727edi.171.1536281623262; Thu, 06 Sep 2018 17:53:43 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:101c:8bcb:f:f4ab? ([2601:646:c005:a10:101c:8bcb:f:f4ab]) by smtp.gmail.com with ESMTPSA id y7-v6sm3300477edd.13.2018.09.06.17.53.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 17:53:42 -0700 (PDT) From: Fred Baker Message-Id: <11820FE2-67B7-4D2A-8DD9-5BCF9F78509A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_46046702-929F-4282-BB25-C6E103E315BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Date: Thu, 6 Sep 2018 17:53:38 -0700 In-Reply-To: Cc: Ole Troan , 6man WG , 6man Chairs <6man-chairs@ietf.org> To: David Schinazi References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 00:53:47 -0000 --Apple-Mail=_46046702-929F-4282-BB25-C6E103E315BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In addition, security issues were pointed out when the concept was first = proposed that to my knowledge remain unanswered. Mine were that the fact = that a given IPv6-only router knows of no IPv4 subnet or routers on a = given LAN doesn't mean that they are not there; it only means that the = router in question doesn't know of them and a host that is wondering = such things should probably stop trying after some number of attempts to = get an IPv4 address. If it's an IPv6-only router, that is almost a = given. +1 to your comments, though. > On Sep 6, 2018, at 3:56 PM, David Schinazi = wrote: >=20 > Hello 6man, >=20 > I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to = Proposed Standard. >=20 > The first motivation defined in this document is that it reduces = resources used by IPv4. But to do that it requires all client devices to = support it, which will take many years. This motivation can be solved = simply by having the router drop all IPv4 traffic. >=20 > The document even tries to claim that it improves security by reducing = malicious IPv4 traffic. That is simply false as hosts are free to ignore = the flag, and malicious ones will. This doesn't even protect hosts that = implement this flag as a malicious node can send an RA without this flag = to make them use IPv4. Again, the correct solution is to have routers = drop IPv4 traffic. >=20 > This document is also harmful with regards to future developments of = the Internet Protocol. What happens when the next version of IP is = standardized? Does this flag prevent using the new version on "IPv6-only = networks"? So do operators now need to disable this flag and end up with = triple stacked hosts? >=20 > I think the problems described in this document would be better solved = by having routers drop all IPv4 traffic and potentially having a = mechanism to let the clients know of this policy - but that mechanism = should live either at layer 2, or in IPv4 - it has no place in IPv6. Not = to mention the small number of RA flags we have left. >=20 > While I can't comment on future products, the odds of us deploying = this are very low. And since this option is not useful without most = client devices supporting it, network operators will not get the = improvements they seek. >=20 > For all these reasons, I think this proposal does not adequately solve = the problem it describes, and is harmful to future developments of IP. = It is therefore premature to promote this draft to Proposed Standard. I = would rather see this problem solved elsewhere, potentially in DHCPv4. >=20 > Thank you, > David Schinazi >=20 >=20 >> On Sep 5, 2018, at 10:40, Ole Troan wrote: >>=20 >> This message starts a two week 6MAN Working Group Last Call on = advancing: >>=20 >> Title : IPv6 Router Advertisement IPv6-Only Flag >> Authors : R. Hinden, B. Carpenter >> Filename : draft-ietf-6man-ipv6only-flag-02.txt >> Pages : 11 >> Date : 2018-08-14 >>=20 >> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>=20 >> as a Proposed Standard. Substantive comments and statements of = support >> for publishing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the author. This last call will >> end on 19 September 2018. >>=20 >> An issue tracker will be setup to track issues raised on this = document. >>=20 >> Thanks, >> Ole >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_46046702-929F-4282-BB25-C6E103E315BA 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAluRzBIACgkQEhdRnd2G P+Bt9Q//RLwS6AIV4/P3m6B944X46eYjj7FC8M1emKVzs4VqPnJWb+WS10YG9JYD zAy8hBIfoiZMtKqx7oJVImBdf/R972rTn5++WiQEZairXdYFJVNFlhH68bWWylbo dPma+aLo4HVxd3wiHp3ffHFeBsw9vQCdg0bsIOsXVrcOXFtq94pg9ik6OjEkP1Rx iAAkQUkY6ZPN9cjd0WOuG/QyV0gz7cxadCYPYpsVqeqzcqRebrJQeb9jRNh4d5AS PFUT2xuNVzTPfpwvvGKltElzNLACXAZpyfVcJgpJM1/TjzrlbozEqkUDGge4rnXy Lq5DE0KmqxGAssm4PLsJUnhUVzj8rKcUbnBWXpXUzKAV99haS7rhh9/eiioC2aFN 3C3jgXYq8w3WCK+Dfxpdab+XcN9oWjBGvS/zqwZZtIEjyNmRIZTOugKDB9F/GQGO pTdqY7A4JkYfNQiJluVJim6WjqrfSk77OLFK9PR8ob98UU8zUdHTWYq+vCEpU5iD FFS51qv16Xt5gXm2Ne3aO0LMwhOZfXnpHEHGiuNCWhg0vCf/OpUXxdOX2hP+9eTD FsLlmtar8lZ16vKZGJnXej8IwoSLKyhwtLO5sMSg8xXhHtR1ZFWYZPWDrLvDgs8w oEI7rdavjJh2lQufvar/q4lLjrR3J/srPlxQr9s6IRV8mgaSxsY= =Y+bf -----END PGP SIGNATURE----- --Apple-Mail=_46046702-929F-4282-BB25-C6E103E315BA-- From nobody Thu Sep 6 19:20:41 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFCE130DE7 for ; Thu, 6 Sep 2018 19:20: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 Q-xj4Ob3raUH for ; Thu, 6 Sep 2018 19:20:37 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66012130DC9 for ; Thu, 6 Sep 2018 19:20:37 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id b129-v6so6158893pga.13 for ; Thu, 06 Sep 2018 19:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=nynS4eSNDlAHDD8foPy+BFV3UF7t4YAChh4ivmdc6GQ=; b=pDUCg33slFh9nXgYcuQbWpfxH5Y++/DtJ9wf5KaRQbtOS99NY1bdznxyqHy617hi+Z 7dICo3Dvf/LjXz/gZjCD6wQbJ+IITvo7hJ069DMgp829J+UOZMylUnUyj/+qdvK8+OTA oNVo9zdt4+CIyMqqudExOpXUBXz309TbpcnKM4QD1TpUKe5zxrjDms3Yz0OHNm7eVONW /JNGn9eAIRCjj1uZM/+pFNOyRqkQH0CfT9c/uiLFDeYmO5x8BFT8Cb+bz54k1V1bqSuT N0StMFH+Ls1EeuZn5fEUlbtfVtQiXkJuEiVHh2kw0SQ79dr2LuHmP6dlRxQHythG8Ckn YbPQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nynS4eSNDlAHDD8foPy+BFV3UF7t4YAChh4ivmdc6GQ=; b=D+Slb4uciTUvNxNWZgRWV+GxPMMai5VQ9v8uNPF+nH4sm7tXbRuVUcurFoDY1Rtuhw /LJjGGyxbE6ApJfja4Bb4QGyEmXHNyAhaeal33+1uN1zOQ9RPkZ9JxbomnQDQ6NS3mIL RPiM+rpAxgxQDtTjkWNhA2ySqiuqV4AR0SihJG7jZjPbNLPpQbuoH4C1i6Sll1XBHkkx BDGgWf0Nd4Vs6luqa23R4Rd5Sw7zfgZPe45B4AiLnDzKx38e1G0ozoItv6+qzdWt8K2Q C4upgkxrGE8qjGrhpeaRn8Y/Qcl0fU6rEwHN6G1QeeFdptfgxOk2ytijK7iGl20VTa1v hgeQ== X-Gm-Message-State: APzg51APqPIv5S/qBsxLBNqXPbRVzyRYbxKVVwXIMknhOQceq4CLWsOE ucyaQF3lG9PeG0gBcxBrGJiBf0GB X-Google-Smtp-Source: ANB0VdZLwcMgRKGDSE6C7IW4nklfxh5OvAIqABKO8PhRFkls7wnl4eCO5gcvfrV2CcDz8EoaoYmTnQ== X-Received: by 2002:a62:9645:: with SMTP id c66-v6mr6173053pfe.56.1536286836418; Thu, 06 Sep 2018 19:20:36 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g25-v6sm13331461pfd.23.2018.09.06.19.20.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 19:20:35 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Brian E Carpenter Message-ID: Date: Fri, 7 Sep 2018 14:20:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 02:20:39 -0000 Hi, David has sent his objections before, and the authors updated the draft considerably as a result. I don't really see what more we can do except say that the draft already contains responses to all these objections. Regards Brian On 2018-09-07 10:56, David Schinazi wrote: > Hello 6man, >=20 > I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Pro= posed Standard. >=20 > The first motivation defined in this document is that it reduces resour= ces used by IPv4. But to do that it requires all client devices to suppor= t it, which will take many years. This motivation can be solved simply by= having the router drop all IPv4 traffic. >=20 > The document even tries to claim that it improves security by reducing = malicious IPv4 traffic. That is simply false as hosts are free to ignore = the flag, and malicious ones will. This doesn't even protect hosts that i= mplement this flag as a malicious node can send an RA without this flag t= o make them use IPv4. Again, the correct solution is to have routers drop= IPv4 traffic. >=20 > This document is also harmful with regards to future developments of th= e Internet Protocol. What happens when the next version of IP is standard= ized? Does this flag prevent using the new version on "IPv6-only networks= "? So do operators now need to disable this flag and end up with triple s= tacked hosts? >=20 > I think the problems described in this document would be better solved = by having routers drop all IPv4 traffic and potentially having a mechanis= m to let the clients know of this policy - but that mechanism should live= either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention = the small number of RA flags we have left. >=20 > While I can't comment on future products, the odds of us deploying this= are very low. And since this option is not useful without most client de= vices supporting it, network operators will not get the improvements they= seek. >=20 > For all these reasons, I think this proposal does not adequately solve = the problem it describes, and is harmful to future developments of IP. It= is therefore premature to promote this draft to Proposed Standard. I wou= ld rather see this problem solved elsewhere, potentially in DHCPv4. >=20 > Thank you, > David Schinazi >=20 >=20 >> On Sep 5, 2018, at 10:40, Ole Troan > wrote: >> >> This message starts a two week 6MAN Working Group Last Call on advanci= ng: >> >> Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: IPv6 Router Advertis= ement IPv6-Only Flag >> Authors =C2=A0 =C2=A0 =C2=A0: R. Hinden, B. Carpenter >> Filename =C2=A0 =C2=A0 : draft-ietf-6man-ipv6only-flag-02.txt >> Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0: 11 >> Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-08-14 >> >> =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-6man-ipv6only= -flag-02 >> >> as a Proposed Standard. Substantive comments and statements of support= >> for publishing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the author. This last call will >> end on 19 September 2018. >> >> An issue tracker will be setup to track issues raised on this document= =2E >> >> Thanks, >> Ole >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Thu Sep 6 19:27:30 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB136130DFF; Thu, 6 Sep 2018 19:27: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 Z9Fao7CDqcFe; Thu, 6 Sep 2018 19:27:26 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF6B130DC9; Thu, 6 Sep 2018 19:27:26 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id s17-v6so5853912plp.7; Thu, 06 Sep 2018 19:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+w5DTJ3xYaOR+c9EingRTHF0R74JwUOPwa0w9SO+/+0=; b=RyzeMijZilbJ8Doc0bw14prp6zTX0ZBP3HUvYW/5pIE9iIwuhT/c9uHarNuFvrP58G YehkGtgrHiu9emUQKmtB7C2ukFPnpkj/4oWiLTPhhp+yD3kVjCR/3dzyEWCrIuFffue/ YgL4/dsMZVIo9uKQ+oPB14BTN4XydRp8bOvYbK8hVAizHtVgKlFhfcxjjkehCYjrsRvf LDDNxMcG8AqW3pWqXJkyDRdm2AY53l4fqS9srW3WO0I3yKtRFGQ+Tr7Mme02Q/ktP8IM iaCJX7FhSXV0T3Skk4jccjsZxHRkkGbGLOYOk2MtdWs3W6JPmUypyzPRSlyP+Fyjdoif W9ZQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+w5DTJ3xYaOR+c9EingRTHF0R74JwUOPwa0w9SO+/+0=; b=p7zKKajNirf7asq5bX7I/xPTktljB3ZpP7H7p4szNAKJQw+uDtHUerGOHEwYx79uTF t40jCGyXfn3WVIBq6sqi/Okbjq2f6QlgtMWnLszCTTQutePu6y8cbVwAuYrc6GFkWUg2 nRzV5TxY1YkCPqTZwUZ/plGmWruML/RBTEQAnImQgwEmOoAja3IsdYIPpfm3Z4bk+qha 7G6g+eqJfdh5bJfbb58UK5AiQkvfQA22fpsBCwz2C5m8gvFdTnDclL4F8y0r1Yy/4Chh JUvDXpmfRfhj4PVf98gve6X6uj/WmIY5qWlQXWRhDBlD+WQDBBL4GFoqkT95mmsNgGXA CgjA== X-Gm-Message-State: APzg51Afpr+BRmhnHGydqzHKYo1D9qZAjz0Ufs4WLJUp19p5RXoUIOeB rckNs8E6OjyQiTAGfXkTK0sE8lD7 X-Google-Smtp-Source: ANB0Vda9WntuoBBXB/zVFE80MjLaTnRsK41cT5x3odS2AXpaxPNIqRBHaqTJw9g3u22Tj4CM1TAUDQ== X-Received: by 2002:a17:902:722:: with SMTP id 31-v6mr5623449pli.207.1536287245380; Thu, 06 Sep 2018 19:27:25 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g6-v6sm9441082pfb.11.2018.09.06.19.27.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 19:27:24 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Fred Baker , David Schinazi Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <11820FE2-67B7-4D2A-8DD9-5BCF9F78509A@gmail.com> From: Brian E Carpenter Message-ID: Date: Fri, 7 Sep 2018 14:27:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <11820FE2-67B7-4D2A-8DD9-5BCF9F78509A@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.29 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 Sep 2018 02:27:29 -0000 Fred, On 2018-09-07 12:53, Fred Baker wrote: > In addition, security issues were pointed out when the concept was first proposed that to my knowledge remain unanswered. Mine were that the fact that a given IPv6-only router knows of no IPv4 subnet or routers on a given LAN doesn't mean that they are not there; it only means that the router in question doesn't know of them and a host that is wondering such things should probably stop trying after some number of attempts to get an IPv4 address. If it's an IPv6-only router, that is almost a given. That's how it works. I don't see any way that it's a security issue. It's exactly what we describe in the draft: if the admin has set the bit in all routers, hosts SHOULD avoid IPv4 unless they have a good reason not to. That's really all there is to it. Brian > > +1 to your comments, though. > >> On Sep 6, 2018, at 3:56 PM, David Schinazi wrote: >> >> Hello 6man, >> >> I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard. >> >> The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can be solved simply by having the router drop all IPv4 traffic. >> >> The document even tries to claim that it improves security by reducing malicious IPv4 traffic. That is simply false as hosts are free to ignore the flag, and malicious ones will. This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. Again, the correct solution is to have routers drop IPv4 traffic. >> >> This document is also harmful with regards to future developments of the Internet Protocol. What happens when the next version of IP is standardized? Does this flag prevent using the new version on "IPv6-only networks"? So do operators now need to disable this flag and end up with triple stacked hosts? >> >> I think the problems described in this document would be better solved by having routers drop all IPv4 traffic and potentially having a mechanism to let the clients know of this policy - but that mechanism should live either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the small number of RA flags we have left. >> >> While I can't comment on future products, the odds of us deploying this are very low. And since this option is not useful without most client devices supporting it, network operators will not get the improvements they seek. >> >> For all these reasons, I think this proposal does not adequately solve the problem it describes, and is harmful to future developments of IP. It is therefore premature to promote this draft to Proposed Standard. I would rather see this problem solved elsewhere, potentially in DHCPv4. >> >> Thank you, >> David Schinazi >> >> >>> On Sep 5, 2018, at 10:40, Ole Troan wrote: >>> >>> This message starts a two week 6MAN Working Group Last Call on advancing: >>> >>> Title : IPv6 Router Advertisement IPv6-Only Flag >>> Authors : R. Hinden, B. Carpenter >>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>> Pages : 11 >>> Date : 2018-08-14 >>> >>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>> >>> as a Proposed Standard. Substantive comments and statements of support >>> for publishing this document should be directed to the mailing list. >>> Editorial suggestions can be sent to the author. This last call will >>> end on 19 September 2018. >>> >>> An issue tracker will be setup to track issues raised on this document. >>> >>> Thanks, >>> Ole >>> >>> >>> -------------------------------------------------------------------- >>> 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 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Sep 6 21:18:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD26130E12; Thu, 6 Sep 2018 21:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 jZil7RAPKHgi; Thu, 6 Sep 2018 21:18:00 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBBC126BED; Thu, 6 Sep 2018 21:18:00 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id c190-v6so24858959oig.6; Thu, 06 Sep 2018 21:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rBwfBqZfUOBwZaZ3jPsukqC7JCXPBui345x5MykzW/8=; b=BpeHcXZC9XZNHwN/O/n9vtbBHfIKzt1fvQgMLvePwq53eOhP+91UBaC8IX37rCJwJb aqp2qSTE0KNoDCAjhrjMRMK7P6ByR5A6FdZaMtvM7pude3DxrnBMNxA+++Js8c90E346 y/s0eOCNbiXH0tq71o3SE7/XCy4QM/fRJm4J+Ciynv9szXzcZh6LC38By1Sdg0NMal4F VUugSrh/GhdodnVlc1LPuKDAy0YcmVwOoh8GmrDL7Mz3h3W3f1aGWcLs+KYZ5IIFApl0 TCPdJBKiLuuvzkhlyWc/HpXp2cRTlH279EMXl1FLUul1tb9HvJUyZjZU2jU4gHFwenlJ K9fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rBwfBqZfUOBwZaZ3jPsukqC7JCXPBui345x5MykzW/8=; b=QGeghxoyKf5nQ5An06CRAwBnJRXXIP9Ip+P1aCnzbXZOqAYfJbriMGoQClZRd3djVn cIvrgGWeoHbh+mpKEwzbgJSqAgDSAl04J5Ye+Gz3Jw5lYfJJzVD35P4RciXrBuKT/wKw +ETZv3jTX8IGR+pu8MHwZ51qDVDrvaWBTklpph4NbuVfhj/hbVTKcRfv5XVVeP+UIqRF mX99Jc/eqHiE1WQbzQbZUo67JHIwO5y7amZNeSSrURutEuhD6Gvr+myDU6Blewcpya4W l/KNJUDJqz12uPSl/aAUS94FWGisPUiCB36dIsWrJzTCj6wRF0dURTJyJpzUhn9drCeF 3KmA== X-Gm-Message-State: APzg51DHNqMymXY0nXoEXdtoRs2LlZZ6V/WKgWHktQ3RtnvsqMCxM3tj 4haPLdDioExrtS+u5E28TNTS5HyvOFRBVJahexo= X-Google-Smtp-Source: ANB0VdYrZwUvWhOPtF97LnTHZq3l24IFG50n1B/Ho73pd8a+FFOI6LwQylN8vTEU38M/Sg4enEqJBXIuzb0VMF0VLHU= X-Received: by 2002:aca:3606:: with SMTP id d6-v6mr6558198oia.327.1536293879952; Thu, 06 Sep 2018 21:17:59 -0700 (PDT) MIME-Version: 1.0 References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> In-Reply-To: From: Mark Smith Date: Fri, 7 Sep 2018 14:17:33 +1000 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: David Schinazi Cc: Ole Troan , 6man WG , 6man Chairs <6man-chairs@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.29 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 Sep 2018 04:18:02 -0000 HI David, On Fri, 7 Sep 2018 at 08:57, David Schinazi wrote: > > Hello 6man, > > I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Propo= sed Standard. > > The first motivation defined in this document is that it reduces resource= s used by IPv4. But to do that it requires all client devices to support it= , which will take many years. This motivation can be solved simply by havin= g the router drop all IPv4 traffic. > I don't think it solves the problem, it only mitigates other hosts receiving (typically link-layer broadcast DHCPv4) packets that they're not interested in. The sending hosts still spend effort forming and sending periodic packets, needlessly consuming their own energy doing so, as well as capacity on the link-layer media. The only way to solve the problem is to inform sending hosts that sending those types of packets will never succeed, so they shouldn't waste their resources forming and sending them. This flag is that signal. It may take years for this flag to be widely supported, however that is better than nothing. Layer 2 filters in the network do nothing to prevent hosts creating and sending these useless packets (even layer 2 filters pushed down into the hosts still wouldn't prevent these useless packets being created.) Regards, Mark. > The document even tries to claim that it improves security by reducing ma= licious IPv4 traffic. That is simply false as hosts are free to ignore the = flag, and malicious ones will. This doesn't even protect hosts that impleme= nt this flag as a malicious node can send an RA without this flag to make t= hem use IPv4. Again, the correct solution is to have routers drop IPv4 traf= fic. > > This document is also harmful with regards to future developments of the = Internet Protocol. What happens when the next version of IP is standardized= ? Does this flag prevent using the new version on "IPv6-only networks"? So = do operators now need to disable this flag and end up with triple stacked h= osts? > > I think the problems described in this document would be better solved by= having routers drop all IPv4 traffic and potentially having a mechanism to= let the clients know of this policy - but that mechanism should live eithe= r at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the smal= l number of RA flags we have left. > > While I can't comment on future products, the odds of us deploying this a= re very low. And since this option is not useful without most client device= s supporting it, network operators will not get the improvements they seek. > > For all these reasons, I think this proposal does not adequately solve th= e problem it describes, and is harmful to future developments of IP. It is = therefore premature to promote this draft to Proposed Standard. I would rat= her see this problem solved elsewhere, potentially in DHCPv4. > > Thank you, > David Schinazi > > > On Sep 5, 2018, at 10:40, Ole Troan wrote: > > This message starts a two week 6MAN Working Group Last Call on advancing: > > Title : IPv6 Router Advertisement IPv6-Only Flag > Authors : R. Hinden, B. Carpenter > Filename : draft-ietf-6man-ipv6only-flag-02.txt > Pages : 11 > Date : 2018-08-14 > > https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 > > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 19 September 2018. > > An issue tracker will be setup to track issues raised on this document. > > Thanks, > Ole > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Sep 6 22:42:12 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7C130E3A; Thu, 6 Sep 2018 22:42: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 QI4lfyjT2zFP; Thu, 6 Sep 2018 22:42:09 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6579130DC4; Thu, 6 Sep 2018 22:42:08 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id y4-v6so6402392pgp.9; Thu, 06 Sep 2018 22:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mKNvZpVEQ82L6RCsIHYcm2zQ4+jNA0YuG4IBS14Huok=; b=N6UiHY50H0pg5lqKrXIfieTqtpG6i9aXUguvPqGEWEllPPDdptT7+PwJlsCMbWWaJ1 CjMX9FUol2ICODQuV4CRn9SORt6YaDs7u2loT1Ua6h/xaDzVOuaOKjMC5nd0B+IbyfmX VQEJ9tFFpctYc81RjXi/oq1rKZCU5AvsBySBpbuD8oUH0GMqSjaXIslk6YZjK8KhLjZG xcnzUeVQewbWROCeEyxxW4Y0id4x5vtSx3CGcng0hxFRhFgYI7ps2L+7ZQGYJGPX3by9 yxdZb70r6re/8yu6WmXhcQczle05mx9vcAHknyZejUGl/fHWqn4QZfVKOYmstJCMc8Yb PEmw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mKNvZpVEQ82L6RCsIHYcm2zQ4+jNA0YuG4IBS14Huok=; b=oWilwXFnGVIGPrODUYsvP5Z0lKKa4Xj2bAm0xyaC/Mgpyj/+iR2jp8dRHxpM6Zu1R1 g7E/OMc3IL8O1UMXqM2j10M9yPvDVt8OV3TsaxaHxv79GtO4rCXS0oDf2+T9aTEdDJuu 5n0uGlJ/m1Gnb4/ICyFHlBCF/WCyC6BsosNfOXSsqSrrEcz0SCAOUqm/vXjfqXl2VrTb MZQTYcmwVrLmLI7LGpKusSss79lKvldwbJ2+l/qpkWtF+d0y59P/mUL5N7h53AKfUcCa TvooA9oWtajxAeYK2y9yP2ACPNDo7wrCdUIlyFCN8R+lftX1zKBIrgesVy6pMCY1n3PM AQqQ== X-Gm-Message-State: APzg51D64vYIDFVj3naHKwHiAc825+zZWaez4cm6/ve6PKBbNXwrh+qM yfShKGAHhOqPMCZ/1hWXrxBEeJig X-Google-Smtp-Source: ANB0VdbYypORW6VBvTqdkFINdv6My/ITZTsapX7O4y4KpBtoJiBQrO6TZAKaKiszj6ZO0nIl7jPqkg== X-Received: by 2002:a63:1f55:: with SMTP id q21-v6mr6355320pgm.88.1536298928100; Thu, 06 Sep 2018 22:42:08 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id y86-v6sm10034361pfk.84.2018.09.06.22.42.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 22:42:06 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: David Schinazi , Ole Troan Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Brian E Carpenter Message-ID: Date: Fri, 7 Sep 2018 17:42:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 05:42:11 -0000 Just a few points that I noticed on a second reading: On 2018-09-07 10:56, David Schinazi wrote: ... > The document even tries to claim that it improves security by reducing malicious IPv4 traffic. It does not make that claim. It does observe that malicious IPv4 traffic is a risk and it mentions that the proposed mechanism will mitigate various risks including that one. Please check the meaning of "mitigate": "make (something bad) less severe, serious, or painful." > That is simply false as hosts are free to ignore the flag, and malicious ones will. Of course. We don't claim otherwise. > This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. That point is specifically discussed in the second paragraph of the security considerations. The only case where this could apply is if the one and only IPv6 router on the link is taken over by malicious code, in which case all is lost anyway. > Again, the correct solution is to have routers drop IPv4 traffic. s/routers/routers, switches and bridges/ Of course. But that's a different topic (discussed with respect to Layer 2 filtering in Section 1 of the draft). Brian From nobody Thu Sep 6 22:51:16 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1B3127B92; Thu, 6 Sep 2018 22:51: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, 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 MdD73zQbiHl4; Thu, 6 Sep 2018 22:51:12 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4613C128CE4; Thu, 6 Sep 2018 22:51:12 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A1EBCE604A; Fri, 7 Sep 2018 07:51:09 +0200 (CEST) Date: Fri, 07 Sep 2018 07:51:09 +0200 (CEST) Message-Id: <20180907.075109.15713895.sthaug@nethelp.no> To: otroan@employees.org Cc: ipv6@ietf.org, 6man-chairs@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: sthaug@nethelp.no In-Reply-To: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) 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.29 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 Sep 2018 05:51:15 -0000 > Title : IPv6 Router Advertisement IPv6-Only Flag > Authors : R. Hinden, B. Carpenter > Filename : draft-ietf-6man-ipv6only-flag-02.txt > Pages : 11 > Date : 2018-08-14 > > https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 > > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 19 September 2018. With my ISP hat on: We have no plans to ask our equipment vendors to support this, or to configure it if it was available. We see this as a completely unnecessary change. Not supported. Steinar Haug, AS2116 From nobody Thu Sep 6 23:43:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28241286D9; Thu, 6 Sep 2018 23:43: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, 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 octnWb_jbCpm; Thu, 6 Sep 2018 23:43:26 -0700 (PDT) Received: from bugle.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 F3A8F127333; Thu, 6 Sep 2018 23:43:25 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id CF74EFECBAC2; Fri, 7 Sep 2018 06:43:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180907.075109.15713895.sthaug@nethelp.no> Date: Fri, 7 Sep 2018 08:43:22 +0200 Cc: ipv6@ietf.org, 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> To: sthaug@nethelp.no Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 06:43:28 -0000 On 7 Sep 2018, at 07:51, sthaug@nethelp.no wrote: >> Title : IPv6 Router Advertisement IPv6-Only Flag >> Authors : R. Hinden, B. Carpenter >> Filename : draft-ietf-6man-ipv6only-flag-02.txt >> Pages : 11 >> Date : 2018-08-14 >>=20 >> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>=20 >> as a Proposed Standard. Substantive comments and statements of support >> for publishing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the author. This last call will >> end on 19 September 2018. >=20 > With my ISP hat on: We have no plans to ask our equipment vendors to > support this, or to configure it if it was available. We see this as > a completely unnecessary change. >=20 > Not supported. Right, there probably isn=E2=80=99t much of a use case for an ISP. If consid= ering the PE - CE link, RFC7083 is probably the only thing akin to this. Apa= rt from public WIFI.=20 Cheers=20 Ole= From nobody Fri Sep 7 00:05:59 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F5130DC6; Fri, 7 Sep 2018 00:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hkVkRwYolvZ0; Fri, 7 Sep 2018 00:05:56 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BCA1286D9; Fri, 7 Sep 2018 00:05:56 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 5E466E604A; Fri, 7 Sep 2018 09:05:54 +0200 (CEST) Date: Fri, 07 Sep 2018 09:05:54 +0200 (CEST) Message-Id: <20180907.090554.297825802.sthaug@nethelp.no> To: otroan@employees.org Cc: ipv6@ietf.org, 6man-chairs@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: sthaug@nethelp.no In-Reply-To: <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 07:05:58 -0000 Pj4gV2l0aCBteSBJU1AgaGF0IG9uOiBXZSBoYXZlIG5vIHBsYW5zIHRvIGFzayBvdXIgZXF1aXBt ZW50IHZlbmRvcnMgdG8NCj4+IHN1cHBvcnQgdGhpcywgb3IgdG8gY29uZmlndXJlIGl0IGlmIGl0 IHdhcyBhdmFpbGFibGUuIFdlIHNlZSB0aGlzIGFzDQo+PiBhIGNvbXBsZXRlbHkgdW5uZWNlc3Nh cnkgY2hhbmdlLg0KPj4gDQo+PiBOb3Qgc3VwcG9ydGVkLg0KPiANCj4gUmlnaHQsIHRoZXJlIHBy b2JhYmx5IGlzbqJ0IG11Y2ggb2YgYSB1c2UgY2FzZSBmb3IgYW4gSVNQLiBJZiBjb25zaWRlcmlu ZyB0aGUgUEUgLSBDRSBsaW5rLCBSRkM3MDgzIGlzIHByb2JhYmx5IHRoZSBvbmx5IHRoaW5nIGFr aW4gdG8gdGhpcy4gQXBhcnQgZnJvbSBwdWJsaWMgV0lGSS4gDQoNCldlJ3JlIGFsc28gY29uc2lk ZXJpbmcgbWFuYWdlZCBXaWZpIHNvbHV0aW9ucyBmb3IgY3VzdG9tZXJzIC0gYW5kIHRoZQ0KYW5z d2VyIGlzIHN0aWxsIG5vLg0KDQpTdGVpbmFyIEhhdWcsIEFTMjExNg0K From nobody Fri Sep 7 00:48:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBE41286D9 for ; Fri, 7 Sep 2018 00:48:53 -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 q2zzNfclTzPY for ; Fri, 7 Sep 2018 00:48:52 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487FC12426A for <6man@ietf.org>; Fri, 7 Sep 2018 00:48:52 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id h69-v6so6625107pfd.4 for <6man@ietf.org>; Fri, 07 Sep 2018 00:48:52 -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=BeJ5dy/xYU2ocFws3DqMGi+cp43HECqTqoGfUauKtaY=; b=f0/b9Q4TE0o4aLa20keoHN15xpC7ZN/pSfNhGCQRyWBEvXvdgPXEmbrbYTwXcVd/2G WNI8lbRibqaRVlOJ+eowg5WiLS950KhpypB2ghrNl+eXHx5ah8EYS92YwenmpKPjuV8m UPKMsOBckvD4iDxVp99nHi5WXeSD5Kx/EVtr4EZ12F23MdT0R+EnmIrygsXSae21dAXg mA51CKaUplvMa5h3i3IxoxPMGxAdulwz0A4lYNIs4DFPAfM4nHJ05e/UhAr7HAyizJ5a 0dbqqTr5CGrxTaLO/1VtXeCG8C/yNJvggrOanV7UEuxB/A9iUD4XRhKCr2xxDJpd+Vtb cDBQ== 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=BeJ5dy/xYU2ocFws3DqMGi+cp43HECqTqoGfUauKtaY=; b=gL1BvUjvCYNz2nST4pPsp5OjJg+cGK01yQxHvlYATMqIAAkvkcXXk+0L8E75Q3tCcA wiJIQ+t2y4jMSt1/kjpJzrThGBwbDOhkuZXt7zkoPLSKJ5lTkhG6SdPUPz6quK59M5ye v8nnb36mwKleuplDpbxhh1Dk4eDal0Cb5OB/v/UZMbYR1ZUeZrCzHquCVElwc49y4zUR oRTXFXM4VSJ91WEAVwBXeH1Or2Cfjhp1JJzXxkwKu6K2mUgMWXLz7NHc+R0bLk4dZf2m zqshemYmkUfLZ2C110hKIszQGL7IjiuEWuxQeLArnw/0N3qmU3BIv+zyj8G6tNpNotNy 6NMw== X-Gm-Message-State: APzg51BZrkFI2D8ohOxjvejNrga2J1HdFH/kS6iuBSytHbDgvV6aP1v/ tAdX1k5Uuvxhbs7czoibbxo= X-Google-Smtp-Source: ANB0Vda8ZNCElXtatqzjstUPEyRBYxFdvrH7dnyH64RVrQFLgpN5UYGjxxrk/3twWcowSuSrem52hA== X-Received: by 2002:a62:8186:: with SMTP id t128-v6mr7003613pfd.192.1536306531683; Fri, 07 Sep 2018 00:48:51 -0700 (PDT) Received: from [59.29.39.47] ([59.29.39.47]) by smtp.gmail.com with ESMTPSA id c20-v6sm17843696pfh.143.2018.09.07.00.48.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 00:48:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Fri, 7 Sep 2018 16:48:46 +0900 Cc: 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <4EAB5E3E-4E6F-478C-9AD2-919DA3B060CF@gmail.com> References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 07:48:54 -0000 Well heard. --- DY > On 7 Sep 2018, at 08:43, David Farmer wrote: >=20 > I'm not sure this is an IP layer problem, v4 or v6, some of it might = not be an IETF problem either. If you want hosts to have the same IP = address as it moves around a site this is possible today with things = like 802.1x, you put the host in the same VLAN whatever port or AP it = attaches too. If you are worried about stretching layer 2 everywhere in = a site then look at abstractions like VXLAN or MPLS with EVPN as your = control plane with the right hardware can scale to extremely large = sites. There are other options too like TRILL, shorted path bridging, = even LISP, etc...=20 >=20 > Basically, you end up with control plane that has every MAC address, = IPv4 /32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you = are doing multicast you probably need (S,G) state too. The advantage of = this model it is IP version agnostic and ethernet protocol agnostic. = Further, this also allows the many simpleton assumptions applications = make today about the network to hold true. >=20 > I'm not sure we need an IPv6-only solution in this problem space. From nobody Fri Sep 7 04:13:33 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37C7130DE5 for ; Fri, 7 Sep 2018 04:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=innovationslab-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 Dwch88jqGngW for ; Fri, 7 Sep 2018 04:13:30 -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 10BB2130DDD for ; Fri, 7 Sep 2018 04:13:30 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id t5-v6so15796378qtn.3 for ; Fri, 07 Sep 2018 04:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=innovationslab-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=j4KNZVDBGBMV42PNbN/FKrL+sUl9+TiAf2/2l2LdtRE=; b=pxfJqgP6K3zYwuUeMCdtmAvUjV0JxtXS1+aAPyhtUQK07axUFlJ9uOZuH+kPWXhK0Z jZSIGMBTCcd1kEzE6OGXq/KUPzvDBudnZHtLBGKCTsxCwvKKKEYm2RigXj3UT2NvNtCK dlFLSkA27ahZDL2bPoAF0I5tHpt08HmQFPSnlIE3S4sdhVaUbA2UTK3he1vSNkvdrupE RXZ6yYjBfM8ZFGKFVwxXCRbFiN61C3nHNCe4Akw/9c+Q+WN5jEvRya4JkSv6qqSbiI6w Foiz2Zxn+zZNXtJA2WN6tTN3DeRrtrlcUQq5EqeheWHeZatc+c6S7yO9g2emeZ7nxMvK gfyg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j4KNZVDBGBMV42PNbN/FKrL+sUl9+TiAf2/2l2LdtRE=; b=KZVdjWTlytQo7iobAa8AclogPYJSXS3tyDbEo14y6K5qKCEiW862X8Yj1AevejAH6v NmMezDMxmHfXRrFtT/iUUxphx2u/SusIsv4qrGlG10Gs2vqPS1N8rycuqoE9oQ8PQyMP Nhir0+TEcQdrw+CVkVzWoEVyfSnYYGHZm24z5fiiRVeXDPeMVYIyUVe+R3Ur15BNnJSQ JwNWygbQk1ld4ZxLljoP2WaNfmNT+mWVTjZSaCq3xVHHHogsHAK20OCKVgKPT3qPNwiK oyM+NGoiuj+YcRRpwD5IlNl8YPvgfObOnvkbzO0r69b+JCMgolOadV1Q0MN+qS8nFU6I 8h0A== X-Gm-Message-State: APzg51AQ4tp56MqbepsAHsZ3ZK3I/7NVs58GfQ6OqOMCOVnff9CTAViI YlV9YVgz/bYCqBHDuQWtxRghYfqXJpw= X-Google-Smtp-Source: ANB0VdZRZr8L88IHxtUrXAWMnhXRuw4APx7uRvaWJSuv78HqS6fUaHYgg5rnJ9/XbJm/J1xMEtYO4w== X-Received: by 2002:a0c:9333:: with SMTP id d48-v6mr5304017qvd.121.1536318808913; Fri, 07 Sep 2018 04:13:28 -0700 (PDT) Received: from LakeHartwell.local ([2601:154:c001:f99e:8b5:b565:2488:786d]) by smtp.gmail.com with ESMTPSA id d11-v6sm4450981qkg.14.2018.09.07.04.13.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 04:13:27 -0700 (PDT) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt To: ipv6@ietf.org References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> From: Brian Haberman Message-ID: Date: Fri, 7 Sep 2018 07:13:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.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 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 11:13:32 -0000 There are also mobility-related solutions like PMIP that eliminate the host-based complexities of MIP while still allowing the host to maintain the same IP address as it moves through the site/enterprise. On 9/6/18 7:43 PM, David Farmer wrote: > I'm not sure this is an IP layer problem, v4 or v6, some of it might not be > an IETF problem either. If you want hosts to have the same IP address as it > moves around a site this is possible today with things like 802.1x, you put > the host in the same VLAN whatever port or AP it attaches too. If you are > worried about stretching layer 2 everywhere in a site then look at > abstractions like VXLAN or MPLS with EVPN as your control plane with the > right hardware can scale to extremely large sites. There are other options > too like TRILL, shorted path bridging, even LISP, etc... > > Basically, you end up with control plane that has every MAC address, IPv4 > /32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you are > doing multicast you probably need (S,G) state too. The advantage of this > model it is IP version agnostic and ethernet protocol agnostic. Further, > this also allows the many simpleton assumptions applications make today > about the network to hold true. > > I'm not sure we need an IPv6-only solution in this problem space. > > Thanks > > On Mon, Sep 3, 2018 at 2:51 AM, DY Kim wrote: > >> Hi, >> >> I’ve reposted a draft, this time to 6man, which was posted to 6ops about a >> year ago but fell out of scope there since it involves some changes to >> NDv6/DAD with added texts. >> >> I’d like to see whether there should be any interest in this draft within >> the 6man group, possibly enough to justify the modification of NDv6/DAD as >> suggested in this draft. >> >> Your comments are solicited. >> >> --- >> DY >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for draft-dykim-6man-sid6-00.txt* >> *Date: *3 September 2018 at 16:46:04 GMT+9 >> *To: *"DY Kim" >> >> >> A new version of I-D, draft-dykim-6man-sid6-00.txt >> has been successfully submitted by DY Kim and posted to the >> IETF repository. >> >> Name: draft-dykim-6man-sid6 >> Revision: 00 >> Title: Subnet ID Deprecation for IPv6 >> Document date: 2018-09-03 >> Group: Individual Submission >> Pages: 17 >> URL: https://www.ietf.org/internet-drafts/draft-dykim- >> 6man-sid6-00.txt >> Status: https://datatracker.ietf.org/doc/draft-dykim-6man-sid6/ >> Htmlized: https://tools.ietf.org/html/draft-dykim-6man-sid6-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-dykim-6man >> -sid6 >> >> >> Abstract: >> Deprecation of the subnet ID in IPv6 networking is proposed; the >> subnet ID is set to zero so that all nodes in a site carry the same >> prefix. While the procedures for neighbor discovery and duplicate >> address detection have to be changed, possible simplification gains >> in IPv6 networking including that of intra-site host- and subnet- >> mobility might be worth the modification. Site-external behaviors >> don't change through this modification, enabling incremental >> deployment of the proposal. Sites of manageable sizes for which >> scalability is not much a critical issue might consider the mode of >> operation proposed in this document. >> >> >> >> >> 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 >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Sep 7 09:46:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BA7130E57 for ; Fri, 7 Sep 2018 09:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 znR3NPs62cgg for ; Fri, 7 Sep 2018 09:45:48 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 637EA130E77 for ; Fri, 7 Sep 2018 09:45:48 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w87GgM4d029097; Fri, 7 Sep 2018 09:45:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=MKxcJ8Mr7+iqzXT1ImpXUO8nqmifI92TmayiULtwXDw=; b=IhttNuBxg/syNTC/kkB6hzqtIeA5cM01cdbfDrXZo4DYGkGOiUCJjRDWmU7a3XnG1XaK 7/WaHrjtlJ3L+yQqQrcrA+dpiQdc/TVKIFwToqU3SCk0Lo2MbCvRSz9lKAXThXczFGH7 gGuqAHYMaY7fpH6EzwuZKH41rMglyqh1+Yb0G93ucZSQXVyOFi1+rLXtR5I5DlLJMkl6 Okz7141ZlcuS/R3tvpZgvEonETL1KtxmKzh71p1Fs8hyhR0vOGzGWfmlC47EF857yebr pAUpr3cEWagOJE31JVXbwrf7eTA3vZL+0drulw8eqpC5Vmd1yQqNJj64amUEQFN/WwE2 pQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2m7qeyj92k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 07 Sep 2018 09:45:46 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bG6e0qYz1M+Lfjmlm7UbFQ)" Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEP00IYW2K7VF30@ma1-mtap-s03.corp.apple.com>; Fri, 07 Sep 2018 09:45:44 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEP008001VL8Z00@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:45:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 77c40f669fd41aacbbe5121aa5d6725f X-Va-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-Va-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-Va-CD: 0 X-Va-ID: 00ba1710-d774-4f83-8ee9-e2521e4a6369 X-V-A: X-V-T-CD: 77c40f669fd41aacbbe5121aa5d6725f X-V-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-V-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-V-CD: 0 X-V-ID: 7559fd95-3abf-46ff-acf7-b9eab542cb5a Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEP00C002DPZR00@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:45:43 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-07_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from [17.234.72.189] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEP00CJ82K42470@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:45:42 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Date: Fri, 07 Sep 2018 09:45:38 -0700 In-reply-to: Cc: ipv6@ietf.org To: Brian E Carpenter References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-07_08:, , signatures=0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 16:46:01 -0000 --Boundary_(ID_bG6e0qYz1M+Lfjmlm7UbFQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Brian, The updates to the draft do not address my comments. Saying that the draft contains responses is not sufficient if you want to reach working group consensus. Regards, David > On Sep 6, 2018, at 19:20, Brian E Carpenter wrote: > > Hi, > > David has sent his objections before, and the authors updated the draft > considerably as a result. I don't really see what more we can do except > say that the draft already contains responses to all these objections. > > Regards > Brian > > On 2018-09-07 10:56, David Schinazi wrote: >> Hello 6man, >> >> I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard. >> >> The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can be solved simply by having the router drop all IPv4 traffic. >> >> The document even tries to claim that it improves security by reducing malicious IPv4 traffic. That is simply false as hosts are free to ignore the flag, and malicious ones will. This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. Again, the correct solution is to have routers drop IPv4 traffic. >> >> This document is also harmful with regards to future developments of the Internet Protocol. What happens when the next version of IP is standardized? Does this flag prevent using the new version on "IPv6-only networks"? So do operators now need to disable this flag and end up with triple stacked hosts? >> >> I think the problems described in this document would be better solved by having routers drop all IPv4 traffic and potentially having a mechanism to let the clients know of this policy - but that mechanism should live either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the small number of RA flags we have left. >> >> While I can't comment on future products, the odds of us deploying this are very low. And since this option is not useful without most client devices supporting it, network operators will not get the improvements they seek. >> >> For all these reasons, I think this proposal does not adequately solve the problem it describes, and is harmful to future developments of IP. It is therefore premature to promote this draft to Proposed Standard. I would rather see this problem solved elsewhere, potentially in DHCPv4. >> >> Thank you, >> David Schinazi >> >> >>> On Sep 5, 2018, at 10:40, Ole Troan >> wrote: >>> >>> This message starts a two week 6MAN Working Group Last Call on advancing: >>> >>> Title : IPv6 Router Advertisement IPv6-Only Flag >>> Authors : R. Hinden, B. Carpenter >>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>> Pages : 11 >>> Date : 2018-08-14 >>> >>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>> >>> as a Proposed Standard. Substantive comments and statements of support >>> for publishing this document should be directed to the mailing list. >>> Editorial suggestions can be sent to the author. This last call will >>> end on 19 September 2018. >>> >>> An issue tracker will be setup to track issues raised on this document. >>> >>> Thanks, >>> Ole >>> >>> >>> -------------------------------------------------------------------- >>> 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 > -------------------------------------------------------------------- --Boundary_(ID_bG6e0qYz1M+Lfjmlm7UbFQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Brian,

The updates = to the draft do not address my comments.
Saying = that the draft contains responses is not sufficient if you want to reach = working group consensus.

Regards,
David


On Sep 6, 2018, at 19:20, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Hi,

David has sent his objections = before, and the authors updated the draft
considerably as a result. I don't really see what more we can = do except
say that the = draft already contains responses to all these objections.

Regards
  Brian

On 2018-09-07 10:56, David = Schinazi wrote:
Hello 6man,

I am strongly opposed to advancing = draft-ietf-6man-ipv6only-flag to Proposed Standard.

The first motivation defined in this document is that it = reduces resources used by IPv4. But to do that it requires all client = devices to support it, which will take many years. This motivation can = be solved simply by having the router drop all IPv4 traffic.

The document even tries to claim that it = improves security by reducing malicious IPv4 traffic. That is simply = false as hosts are free to ignore the flag, and malicious ones will. = This doesn't even protect hosts that implement this flag as a malicious = node can send an RA without this flag to make them use IPv4. Again, the = correct solution is to have routers drop IPv4 traffic.

This document is also harmful with regards to future = developments of the Internet Protocol. What happens when the next = version of IP is standardized? Does this flag prevent using the new = version on "IPv6-only networks"? So do operators now need to disable = this flag and end up with triple stacked hosts?

I think the problems described in this document would be = better solved by having routers drop all IPv4 traffic and potentially = having a mechanism to let the clients know of this policy - but that = mechanism should live either at layer 2, or in IPv4 - it has no place in = IPv6. Not to mention the small number of RA flags we have left.

While I can't comment on future products, the = odds of us deploying this are very low. And since this option is not = useful without most client devices supporting it, network operators will = not get the improvements they seek.

For all = these reasons, I think this proposal does not adequately solve the = problem it describes, and is harmful to future developments of IP. It is = therefore premature to promote this draft to Proposed Standard. I would = rather see this problem solved elsewhere, potentially in DHCPv4.

Thank you,
David Schinazi


On Sep 5, 2018, at 10:40, Ole Troan <otroan@employees.org <mailto:otroan@employees.org>> wrote:

This message starts a two week 6MAN Working = Group Last Call on advancing:

Title =        : IPv6 Router Advertisement = IPv6-Only Flag
Authors      : R. Hinden, B. = Carpenter
Filename     : = draft-ietf-6man-ipv6only-flag-02.txt
Pages     =    : 11
Date         : = 2018-08-14

   https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02

as a Proposed Standard. Substantive = comments and statements of support
for publishing this = document should be directed to the mailing list.
Editorial = suggestions can be sent to the author. This last call will
end on 19 September 2018.

An = issue tracker will be setup to track issues raised on this document.

Thanks,
Ole


---------------------------------------------------------------= -----
IETF IPv6 working group mailing list
ipv6@ietf.org <mailto: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
---------------------------------------------------------------= -----

= --Boundary_(ID_bG6e0qYz1M+Lfjmlm7UbFQ)-- From nobody Fri Sep 7 09:52:12 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6A130E02; Fri, 7 Sep 2018 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 DGo_6uUjFZgm; Fri, 7 Sep 2018 09:52:08 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 A1A3C12F1A2; Fri, 7 Sep 2018 09:52:08 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w87Gpe7a043180; Fri, 7 Sep 2018 09:52:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=jYSzoXOA/qqf2wPspbiBFhxA5ix6zlrqISbcExcv/G0=; b=Q8SdYFw+KOeWifYBFiF/kHRe4uZEBT2yVWjPII6JzSIJU3F9i0n8gzibtl50B1A0qWLl kAppDcKj6if6XEKYuOnlmjfyi1b94CYFjBQmdjiKhHv7v5RcwOxCbf91ZYNjcAeo4EUc pMGPkviwblbzbA2+WTUfNU/+zJS4KojnQCBozLyLosDIynG33ZFOb3i5IjBnzUgkmzBc nAm0YaM8cIv7IQ8Uef6mA2OwExilhZzU/4sQluA8+aHCalnXQfowZ7ylRvMSi+aM7BCp HRaXms+U1Z8nqHDST1amWn2nv8sTVvULJrEQyL9PanHkVnoFFWkeiaJn3+Is1dx1dA2S 4Q== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2m7qeyjcs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 07 Sep 2018 09:52:05 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RLi9/o7DuMW+4Si84X1TiQ)" Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEP00GX12USQ1B0@ma1-mtap-s01.corp.apple.com>; Fri, 07 Sep 2018 09:52:05 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEP00H002UEAY00@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:52:05 -0700 (PDT) X-Va-A: X-Va-T-CD: 59b5dad7c2412647e93c0415dd0048e0 X-Va-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-Va-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-Va-CD: 0 X-Va-ID: 332242dc-b9f7-4f7f-9869-74612afc387b X-V-A: X-V-T-CD: 59b5dad7c2412647e93c0415dd0048e0 X-V-E-CD: 8b667cf08853ea869cd44d3fd82d8751 X-V-R-CD: e048761668c8fa92d686daa5eed3f5b9 X-V-CD: 0 X-V-ID: 7cfe627c-f45c-445f-a792-82677cb0b920 Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEP00H002TQAN00@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:52:04 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-07_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.72.189] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEP00CPA2UQ2470@nwk-mmpp-sz13.apple.com>; Fri, 07 Sep 2018 09:52:04 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <1FED2825-195C-411D-9F6C-B8937DE9878D@apple.com> Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Date: Fri, 07 Sep 2018 09:52:00 -0700 In-reply-to: Cc: Ole Troan , 6man WG , 6man Chairs <6man-chairs@ietf.org> To: Mark Smith References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-07_08:, , signatures=0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 16:52:11 -0000 --Boundary_(ID_RLi9/o7DuMW+4Si84X1TiQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Mark, Responses inline. > On Sep 6, 2018, at 21:17, Mark Smith wrote: > > I don't think it solves the problem, it only mitigates other hosts > receiving (typically link-layer broadcast DHCPv4) packets that they're > not interested in. It solves part of the problem - and in my mind those are the most important parts. > The sending hosts still spend effort forming and sending periodic > packets, needlessly consuming their own energy doing so, as well as > capacity on the link-layer media. > > The only way to solve the problem is to inform sending hosts that > sending those types of packets will never succeed, so they shouldn't > waste their resources forming and sending them. This flag is that > signal. As I mentioned in my previous message, there might be value for *a* flag, but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this. > It may take years for this flag to be widely supported, however that > is better than nothing. Layer 2 filters in the network do nothing to > prevent hosts creating and sending these useless packets (even layer 2 > filters pushed down into the hosts still wouldn't prevent these > useless packets being created.) No, this is not better than nothing, it is worse than nothing. It uses up an RA flag and creates pain down the road when we want to update IP again. Regards, David --Boundary_(ID_RLi9/o7DuMW+4Si84X1TiQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Mark,

Responses = inline.

On = Sep 6, 2018, at 21:17, Mark Smith <markzzzsmith@gmail.com> wrote:

I don't think it solves the = problem, it only mitigates other hosts
receiving (typically link-layer broadcast DHCPv4) packets = that they're
not = interested in.

It solves part of the problem - and in my mind = those are the most important parts.

The sending hosts still spend effort forming and sending = periodic
packets, = needlessly consuming their own energy doing so, as well as
capacity on the link-layer = media.

The only way = to solve the problem is to inform sending hosts that
sending those types of packets = will never succeed, so they shouldn't
waste their resources forming and sending them. This flag is = that
signal.

As I mentioned in my previous message, there might = be value for *a* flag,
but not necessarily for *this* flag. = IPv6 RA flags are not the right vehicle for this.

It may take years for this flag = to be widely supported, however that
is better than nothing. Layer 2 filters in the network do = nothing to
prevent hosts = creating and sending these useless packets (even layer 2
filters pushed down into the = hosts still wouldn't prevent these
useless packets being created.)

No, this is not better than nothing, it is worse = than nothing. It uses up an
RA flag and creates pain down the = road when we want to update IP again.
Regards,
David
= --Boundary_(ID_RLi9/o7DuMW+4Si84X1TiQ)-- From nobody Fri Sep 7 10:19:54 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57377130DDB for ; Fri, 7 Sep 2018 10:19:52 -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, SPF_PASS=-0.001] autolearn=unavailable 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 I-hAOpcKm6gO for ; Fri, 7 Sep 2018 10:19: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 24A6A126F72 for ; Fri, 7 Sep 2018 10:19:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9D6781227 for ; Fri, 7 Sep 2018 17:19: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 myuExmatX7lQ for ; Fri, 7 Sep 2018 12:19:49 -0500 (CDT) Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.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 5CA181224 for ; Fri, 7 Sep 2018 12:19:49 -0500 (CDT) Received: by mail-vk1-f198.google.com with SMTP id p129-v6so46263vkd.6 for ; Fri, 07 Sep 2018 10:19: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=BE2QXVoETcFPl6RUZtj7ZntJQSESKr4c3ZRa6qhzUZI=; b=AhPgViQibgd6rxFBXyPXc/BjBpWSHYAiUIakb8B0cIFwPfUSKZh9uDvKWDGKxOuDPW rlr0ANDBTga46b5FUQlUqiBl78i+MVVrnaNdzBUglm3f9SeSMYCEZF/RryD5FaDAy+Hd PWouKFrgHunbDr+kxznTdrqM0je0XoI2Y7xHWCixY9zr1EIzVjE44AJ/0ihdK0uE4bUX 4kW4GMu6f1cu54jnbz4IB+dx3wRtCGcnXEnXI6Ak0VlPj0CtxuJgWZkMu/yG/3i9YTNF ZOQnSFnmMJTvDNSUXEvPoXiTEJNXeYNUgy4R2yWecbv2t3axPdtOH6B3mt9tkT3IdZFW qr3A== 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=BE2QXVoETcFPl6RUZtj7ZntJQSESKr4c3ZRa6qhzUZI=; b=O1sbowXrb0b6FkLKqrdzbSefkqpzTv29s8asKHrq5OxksOn9dUsNMqLCjs+UiK7C9z vee3lL2V1R19nmIXpwPyM2bauGMZXScZpO4Xtz4aDupm7dQbqcTqhtl5CE62uYaYSQob NdXn9pmavrUXoW5jHYAaEmdSI5brv1wJy+D4wO7JAEpKWkMFQd1/H+adbXARJvIPb0yY 2WYOmaq0gfP3IIAnZ39tINkPiQjzgt81QVMESwhlRw1QmKNq0Mz1B0DVD3Y8PJD+uCQZ 1mbUFXNQsITNDWQxKbYDON3YrX8Rq9pC4rWzzNnubUar8THvl1P2ccmkpNsIDT02Yt/r HR1Q== X-Gm-Message-State: APzg51BUefo1dCgD2aef7Lyp2eiQ8dMcQVE6dsWt4bU1OvgNDiZFyTSe qBG7irCol/vjglXmGCIb/raHN/zRlAK71R+Dw4fLiX+lhP91Y2NvdIuyAp7b5CXVnlhJKTeYrTd +agE1FgCS3UHOll08UJDaUBR/ X-Received: by 2002:a67:3ec6:: with SMTP id a67-v6mr3263746vsi.58.1536340788075; Fri, 07 Sep 2018 10:19:48 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZi82jCX0p824BjOxqQ8tqH3uVTRlWow7qqY1eFuCGI7hiHhoJPAn+fhWlFi6Woq/ikk74LiW4Kve6wQ76KIwo= X-Received: by 2002:a67:3ec6:: with SMTP id a67-v6mr3263734vsi.58.1536340787646; Fri, 07 Sep 2018 10:19:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:6042:0:0:0:0:0 with HTTP; Fri, 7 Sep 2018 10:19:46 -0700 (PDT) In-Reply-To: <20180907.090554.297825802.sthaug@nethelp.no> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> From: David Farmer Date: Fri, 7 Sep 2018 12:19:46 -0500 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: sthaug@nethelp.no Cc: Ole Troan , 6man WG , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e7192305754b36fd" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 17:19:53 -0000 --000000000000e7192305754b36fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2018 at 2:05 AM, wrote: > >> With my ISP hat on: We have no plans to ask our equipment vendors to > >> support this, or to configure it if it was available. We see this as > >> a completely unnecessary change. > >> > >> Not supported. > > > > Right, there probably isn=E2=80=99t much of a use case for an ISP. If > considering the PE - CE link, RFC7083 is probably the only thing akin to > this. Apart from public WIFI. > > We're also considering managed Wifi solutions for customers - and the > answer is still no. > > Steinar Haug, AS2116 I have a couple questions for you. When you say "no" to this are you saying no you won't deploy IPv6-only networks? Or, are you saying you will deploy IPv6-only networks but you would never set the flag if it were provided? Or put another way, are you saying it's not useful because you won't ever deploy IPv6-only networks? 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 --000000000000e7192305754b36fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Sep 7, 2018 at 2:05 AM, <sth= aug@nethelp.no> wrote:
>> With my ISP hat on: We have no plans to ask our equ= ipment vendors to
>> support this, or to configure it if it was available. We see this = as
>> a completely unnecessary change.
>>
>> Not supported.
>
> Right, there probably isn=E2=80=99t much of a use case for an ISP. If = considering the PE - CE link, RFC7083 is probably the only thing akin to th= is. Apart from public WIFI.

We're also considering managed Wifi solutions for customers - and the answer is still no.

Steinar Haug, AS2116

I= have a couple questions for you. When you say "no" to this are y= ou saying no you won't deploy IPv6-only networks? Or, are you saying yo= u will deploy IPv6-only networks but you would never set the flag if it wer= e provided?

Or put another w= ay, are you saying it's not useful because you won't ever deploy IP= v6-only networks?

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
--000000000000e7192305754b36fd-- From nobody Fri Sep 7 10:38:31 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741E6130DE4; Fri, 7 Sep 2018 10:38:29 -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 DRNVzSFk-ctm; Fri, 7 Sep 2018 10:38:27 -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 30967130DDB; Fri, 7 Sep 2018 10:38:26 -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 w87GcHDk067792 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2018 17:38:17 +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 Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Mark Smith Cc: David Schinazi , 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Nick Hilliard Message-ID: <9425a676-e966-94d2-4b64-fdf9cfae796b@foobar.org> Date: Fri, 7 Sep 2018 18:38:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: 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.29 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 Sep 2018 17:38:30 -0000 Mark Smith wrote on 07/09/2018 05:17: > On Fri, 7 Sep 2018 at 08:57, David Schinazi wrote: >> The first motivation defined in this document is that it reduces >> resources used by IPv4. But to do that it requires all client >> devices to support it, which will take many years. This motivation >> can be solved simply by having the router drop all IPv4 traffic. > > I don't think it solves the problem, it only mitigates other hosts > receiving (typically link-layer broadcast DHCPv4) packets that > they're not interested in. > > The sending hosts still spend effort forming and sending periodic > packets, needlessly consuming their own energy doing so, as well as > capacity on the link-layer media. fundamentally, this doesn't matter. The only situation where it has any relevance is on wifi networks. If there is no default route on the device, then the only traffic of relevance is link-local traffic. Everything else will be dropped in the o/s kernel because there won't be a route for it. If the AP blocks ARP, then the device will never receive ARP broadcast requests from other hosts, and will never receive ARP replies from the ARP requests that it sends out. This will cause the underlying operating system to block all unicast ipv4 traffic, because the OS will have no ARP mapping for the IP addresses that the device is trying to reach. So immediately, the scope of the problem is reduced from trying to handle lots of random ipv4 background chatter, to rate-limiting or otherwise constraining outbound ARP requests and other broadcast traffic for 169.254.0.0/16, or possibly 0.0.0.0/8 address space. Reminder: outbound broadcast traffic from the station to the access-point is sent via unicast (i.e. not at wifi basic rate), and the OS would easily be able to coalesce arp requests into bursts, instead of issuing them piecemeal at a higher resource cost. However it's handled, the 6man wg should probably assume that the handheld device manufacturers would be better able to assess battery optimisation methodologies in this situation, because that's their day job and they're pretty good at it. Nick From nobody Fri Sep 7 11:12:30 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1DD1252B7; Fri, 7 Sep 2018 11:12: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, 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 3G9vpwsh3rUf; Fri, 7 Sep 2018 11:12:25 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8312008A; Fri, 7 Sep 2018 11:12:24 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B4469E604A; Fri, 7 Sep 2018 20:12:22 +0200 (CEST) Date: Fri, 07 Sep 2018 20:12:22 +0200 (CEST) Message-Id: <20180907.201222.296893196.sthaug@nethelp.no> To: farmer@umn.edu Cc: otroan@employees.org, ipv6@ietf.org, 6man-chairs@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: sthaug@nethelp.no In-Reply-To: References: <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 18:12:29 -0000 Pj4gPiBSaWdodCwgdGhlcmUgcHJvYmFibHkgaXNuonQgbXVjaCBvZiBhIHVzZSBjYXNlIGZvciBh biBJU1AuIElmDQo+PiBjb25zaWRlcmluZyB0aGUgUEUgLSBDRSBsaW5rLCBSRkM3MDgzIGlzIHBy b2JhYmx5IHRoZSBvbmx5IHRoaW5nIGFraW4gdG8NCj4+IHRoaXMuIEFwYXJ0IGZyb20gcHVibGlj IFdJRkkuDQo+Pg0KPj4gV2UncmUgYWxzbyBjb25zaWRlcmluZyBtYW5hZ2VkIFdpZmkgc29sdXRp b25zIGZvciBjdXN0b21lcnMgLSBhbmQgdGhlDQo+PiBhbnN3ZXIgaXMgc3RpbGwgbm8uDQo+Pg0K Pj4gU3RlaW5hciBIYXVnLCBBUzIxMTYNCj4gDQo+IA0KPiBJIGhhdmUgYSBjb3VwbGUgcXVlc3Rp b25zIGZvciB5b3UuIFdoZW4geW91IHNheSAibm8iIHRvIHRoaXMgYXJlIHlvdSBzYXlpbmcNCj4g bm8geW91IHdvbid0IGRlcGxveSBJUHY2LW9ubHkgbmV0d29ya3M/IE9yLCBhcmUgeW91IHNheWlu ZyB5b3Ugd2lsbCBkZXBsb3kNCj4gSVB2Ni1vbmx5IG5ldHdvcmtzIGJ1dCB5b3Ugd291bGQgbmV2 ZXIgc2V0IHRoZSBmbGFnIGlmIGl0IHdlcmUgcHJvdmlkZWQ/DQoNCklQdjYtb25seSBuZXR3b3Jr cyBhcmUgbm90IGluIG91ciBjdXJyZW50IHBsYW5zLiBUaGF0IG1heSBjaGFuZ2Ugb3Zlcg0KdGlt ZSwgb2J2aW91c2x5LiBIb3dldmVyLCBldmVuIHdpdGggSVB2Ni1vbmx5IEkgZG9uJ3Qgc2VlIHVz IHVzaW5nDQp0aGlzIGZsYWcuDQoNClRoZSByZWFzb25zIHRoaXMgZmxhZyBpcyBub3QgYSBnb29k IGlkZWEgaGFzIGJlZW4gd2VsbCBleHBsYWluZWQgYnkNCk5pY2sgSGlsbGlhcmQsIERhdmlkIFNj aGluYXppIGFuZCBvdGhlcnMuDQoNClN0ZWluYXIgSGF1ZywgQVMyMTE2DQo= From nobody Fri Sep 7 12:36:02 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7152B130DCE; Fri, 7 Sep 2018 12:36:00 -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 GsXwbhVEC3t7; Fri, 7 Sep 2018 12:35:59 -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 E4A3D12008A; Fri, 7 Sep 2018 12:35:58 -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 w87JZw0F009101; Fri, 7 Sep 2018 12:35:58 -0700 Received: from XCH15-01-11.nw.nos.boeing.com (xch15-01-11.nw.nos.boeing.com [137.136.239.187]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w87JZrLb009069 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 7 Sep 2018 12:35:53 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-11.nw.nos.boeing.com (137.136.239.187) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 7 Sep 2018 12:35:52 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Fri, 7 Sep 2018 12:35:52 -0700 From: "Manfredi (US), Albert E" To: David Farmer CC: 6man WG , 6man Chairs <6man-chairs@ietf.org> Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURm7G5Ieh5nHO1E6PHkpFno+usqTk1J4AgAAGTACAAKuDAP//r94g Date: Fri, 7 Sep 2018 19:35:52 +0000 Message-ID: <74731298941a4936b1a6e7076ee0ea32@XCH15-01-07.nw.nos.boeing.com> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> 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] x-tm-snts-smtp: B105D34A8C22822FB68CAC37040EAB1A1099CA6C631AA16A309249972E663EA82000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 19:36:00 -0000 RnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGF2aWQgRmFy bWVyDQoNCj4gSSBoYXZlIGEgY291cGxlIHF1ZXN0aW9ucyBmb3IgeW91LiBXaGVuIHlvdSBzYXkg Im5vIiB0byB0aGlzIGFyZSB5b3Ugc2F5aW5nIG5vIHlvdSB3b24ndCBkZXBsb3kgSVB2Ni1vbmx5 IG5ldHdvcmtzPyBPciwgYXJlIHlvdSBzYXlpbmcgeW91IHdpbGwgZGVwbG95IElQdjYtb25seSBu ZXR3b3JrcyBidXQgeW91IHdvdWxkIG5ldmVyIHNldCB0aGUgZmxhZyBpZiBpdCB3ZXJlIHByb3Zp ZGVkPw0KDQo+IE9yIHB1dCBhbm90aGVyIHdheSwgYXJlIHlvdSBzYXlpbmcgaXQncyBub3QgdXNl ZnVsIGJlY2F1c2UgeW91IHdvbid0IGV2ZXIgZGVwbG95IElQdjYtb25seSBuZXR3b3Jrcz8NCg0K Tm90IGFuc3dlcmluZyBmb3IgdGhlIG90aGVyIGd1eXMsIERhdmUsIGJ1dCBpbiB0aGlzIGxhdGVz dCBnby1hcm91bmQsIEkgdGhvdWdodCB0aGUgcG9pbnQgbWFkZSB3YXMgdGhhdCB0byBhY2hpZXZl IHRoZSBnb2FsIG9mIElQdjYtb25seSBuZXR3b3JrcywgYWxsIHJvdXRlcnMgZmlsdGVyaW5nIElQ djQgb3V0IGF0IGxheWVyIDIgd2FzIHRoZSBiZXN0IGFuc3dlci4NCg0KQmVydA0KDQo= From nobody Fri Sep 7 13:33:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0FD128C65 for ; Fri, 7 Sep 2018 13:33:48 -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 txfEMq1LUQG0 for ; Fri, 7 Sep 2018 13:33:45 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FA312F18C for ; Fri, 7 Sep 2018 13:33:45 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id k21-v6so7518684pff.11 for ; Fri, 07 Sep 2018 13:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=i7eC7l2VgzESD354yveIv9ogCxPPe98SD1UG3x4+ahQ=; b=E06R9PWlZ/O8RAQ2LOVmcZKW6KHMr/En2cdZzR49ozlgGNo/BvlY3gU3XalGInBtQK BtVTZzJX112dXqBRFf7yp0hastmG1S8JGJ/jyTH3aXirQsufONZV2xe+Ri+CW2lSseII sgbfv+5MS4s9Xs0J4vC6P5vrGoP9S9aj2RfqheFjXjv5i1ri19pEj2eDqqdP5MOeyy6s kPBQ/wnT9QsZOrQ6Dgvrq6QH8nN1B8rTsKdsZa/Sd9Pay+RVKq1hA0RgAAwrIlp6pCVP BeLhuXCfKqqGToAlyVoJ8HeSSeQYANBKSTjh09h6NAANknDgalDIPHriHfl5mxY9Fhiv Yhgw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i7eC7l2VgzESD354yveIv9ogCxPPe98SD1UG3x4+ahQ=; b=nkxFDHXkeAJqGtakiYxeqwe7f8/QtddcqUtpBbVRJQci3Zh5Aw/CE1FD4R4poAXs+w sqauy9Uy2CgcvgM5hzvdgfrQQ3xtlNApqZUhoSRddWihdRRGA5YNKRqZyapdsZxY2bGy MAc/PWW3SI/FdZxTHPObL09f0Dac5HynxorFIgSfm1DxPiZpVcft+umJtcQQl4PfXhcH 5/4F3hJYOYJIjI1z/l1d7fm+qd0k3ByhZ/rgQESjtrv5uDCYA4YZDKjkHMUmNa4xZK9L eS6VQ/EHpPj6PGoGA/g6OLlkzQ6CzosA92BFRyzaTgWc4jcWnDoKaMIwAqrFgTPUN1em fMaw== X-Gm-Message-State: APzg51BcAKm74kndhBDfc8ym8utPjSOfdHaJxttUue29xYPvGl5f9P+8 U0R/U8vAB74o4sklG2WfYfOrFu9c X-Google-Smtp-Source: ANB0VdYW63+EhUyxbTZDmSWsEZ8M9EIv3ibM7S6KmJm0Cvy12CSZ4YrtKg09VIPv4eC8eqhvMHRiXQ== X-Received: by 2002:a63:da56:: with SMTP id l22-v6mr10202821pgj.179.1536352424660; Fri, 07 Sep 2018 13:33:44 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id e7-v6sm11572451pgc.55.2018.09.07.13.33.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 13:33:43 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> From: Brian E Carpenter Message-ID: <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> Date: Sat, 8 Sep 2018 08:33:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <38566B11-E38B-4C16-896C-8ED084B17949@employees.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.29 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 Sep 2018 20:33:48 -0000 On 2018-09-07 18:43, Ole Troan wrote: >=20 >=20 > On 7 Sep 2018, at 07:51, sthaug@nethelp.no wrote: >=20 >>> Title : IPv6 Router Advertisement IPv6-Only Flag >>> Authors : R. Hinden, B. Carpenter >>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>> Pages : 11 >>> Date : 2018-08-14 >>> >>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>> >>> as a Proposed Standard. Substantive comments and statements of suppor= t >>> for publishing this document should be directed to the mailing list. >>> Editorial suggestions can be sent to the author. This last call will >>> end on 19 September 2018. >> >> With my ISP hat on: We have no plans to ask our equipment vendors to >> support this, or to configure it if it was available. We see this as >> a completely unnecessary change. >> >> Not supported. >=20 > Right, there probably isn=E2=80=99t much of a use case for an ISP. If c= onsidering the PE - CE link, RFC7083 is probably the only thing akin to t= his. Apart from public WIFI.=20 Correct. It's a solution for certain scenarios, and it's a market decisio= n which scenarios justify the cost. Brian From nobody Fri Sep 7 13:38:51 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55969130DDB; Fri, 7 Sep 2018 13:38:49 -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 gudCA9TINK9D; Fri, 7 Sep 2018 13:38:47 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4732E12F18C; Fri, 7 Sep 2018 13:38:44 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id k19-v6so7556754pfi.1; Fri, 07 Sep 2018 13:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/83BexFL4VbHZqw8FRbc5Ton4/I4Zq0/iae1GxapXNE=; b=kcv5e3CpRYuKAbaMIeqM+s8lyl1HAXSkxtc1lCXhlXy+YgdzWurWOc14pXU3WPIp3s yWAxBGjQgSsZ0eqfnDVjR3aaCl3QnT5w+O7zRtfYWjQpLF4Cx2qqqNckEjZ0ofO/drO4 6UpeA5UR9WkWVFBdCAwSRzHS70ag63toUmIilDcX3I/SruXhhac2D90tEpCKljWxyOJ4 p7MmDrJs+N1qbhiMnp1QSaxf4iFMFgRGLH2XhRKm/m5Ijv1vPnW1TEQEpIbeDiJE9Zj5 OAJTqZ3Su14pQNqAu7umCL/kN0WzViHhrOUK4qJArrxtepbQ3r+5O5PvYT05YjmmpuhM 97ig== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/83BexFL4VbHZqw8FRbc5Ton4/I4Zq0/iae1GxapXNE=; b=iFLcViH/MHCdQqUlIEv3r3ojzQItaRfjWOyWoAS3TmbMdDhKUzr6rMe+CzI+QQKlbk QF+QwcJa/jBP0IgntQybURLXGCX5zhcp7fQuvW6vnl5UpLsi8BFTgcxVegegLdBPXY5l SMhqYERBtRvkxL59AKQ5CaLwN1U7bSlPgacdesaI0UAzNCmpZT1996693gMnwymuMPIi 8zdr5yAo9GwTueLCqf0ivI+u6dcyPUuiitsP368CZvZfz3wrtQxIMbbdU8FrAednqct3 xVXBISxNRvldd9kgzCkucbSNZj5Qfa+b7QGIko53Jp5Zr6P3Sozcu+V81D35TmFHi5Z0 238Q== X-Gm-Message-State: APzg51CAgSJRdHuTGw9Pclnp4T83e1OrZjSN/9f7Abgj0DU8uSFGJ/ZT FoKG36DmxdrN7eP7ryuIcKCZRZcP X-Google-Smtp-Source: ANB0Vdbwc7b1f3fe5cfLnAWgmcUkv+337RSbPMr7HSoJjeHpv1YuKrMsi/gVgZ7k1HaYAgqHePIaQQ== X-Received: by 2002:a63:24c4:: with SMTP id k187-v6mr10252835pgk.162.1536352723422; Fri, 07 Sep 2018 13:38:43 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id l79-v6sm15911882pfi.172.2018.09.07.13.38.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 13:38:42 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Nick Hilliard , Mark Smith Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <9425a676-e966-94d2-4b64-fdf9cfae796b@foobar.org> From: Brian E Carpenter Message-ID: Date: Sat, 8 Sep 2018 08:38:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9425a676-e966-94d2-4b64-fdf9cfae796b@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.29 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 Sep 2018 20:38:49 -0000 On 2018-09-08 05:38, Nick Hilliard wrote: > Mark Smith wrote on 07/09/2018 05:17: >> On Fri, 7 Sep 2018 at 08:57, David Schinazi wrote: >>> The first motivation defined in this document is that it reduces >>> resources used by IPv4. But to do that it requires all client >>> devices to support it, which will take many years. This motivation >>> can be solved simply by having the router drop all IPv4 traffic. >> >> I don't think it solves the problem, it only mitigates other hosts >> receiving (typically link-layer broadcast DHCPv4) packets that >> they're not interested in. >> >> The sending hosts still spend effort forming and sending periodic >> packets, needlessly consuming their own energy doing so, as well as >> capacity on the link-layer media. > > fundamentally, this doesn't matter. The only situation where it has any > relevance is on wifi networks. > > If there is no default route on the device, then the only traffic of > relevance is link-local traffic. Everything else will be dropped in the > o/s kernel because there won't be a route for it. > > If the AP blocks ARP, then the device will never receive ARP broadcast > requests from other hosts, and will never receive ARP replies from the > ARP requests that it sends out. > > This will cause the underlying operating system to block all unicast > ipv4 traffic, because the OS will have no ARP mapping for the IP > addresses that the device is trying to reach. > > So immediately, the scope of the problem is reduced from trying to > handle lots of random ipv4 background chatter, to rate-limiting or > otherwise constraining outbound ARP requests and other broadcast traffic > for 169.254.0.0/16, or possibly 0.0.0.0/8 address space. > > Reminder: outbound broadcast traffic from the station to the > access-point is sent via unicast (i.e. not at wifi basic rate), and the > OS would easily be able to coalesce arp requests into bursts, instead of > issuing them piecemeal at a higher resource cost. > > However it's handled, the 6man wg should probably assume that the > handheld device manufacturers would be better able to assess battery > optimisation methodologies in this situation, because that's their day > job and they're pretty good at it. Exactly. This is a tool in the toolkit, but it's their job to figure out if it's useful. For all I know, this is a tool that might sleep for years until engineering tradeoffs change and it becomes useful. Brian From nobody Fri Sep 7 13:44:01 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BB312F18C; Fri, 7 Sep 2018 13:43:58 -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 aBfK_M8F8kfP; Fri, 7 Sep 2018 13:43:56 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94083128C65; Fri, 7 Sep 2018 13:43:56 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id t84-v6so5688515pgb.5; Fri, 07 Sep 2018 13:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YnubSk6I/1F9tjgQMcK9TMHfOLjP3MjOgyGiwIWFOJo=; b=MsdcMI+36cy3bLEMugienMJ2XccJAT3ptRr8raO9BmOfxAspC4aZvCFEHU6nzYiDU7 UxKNehcQUHcXRjMQJkyZPXI8d4CAvPDgDYq9caK2vMAlmQXRDN6YdO0lJiC33f2na88O YHKhVvXsT1eSmcAvISv8FgA+hMXyeTTuQZZspcZVKIZXQxTSDNKV1p8BUT/afTkZck2S l8yGQQ86fLRkSfsUMW3r+uUTXY3lVVnbwOrmPymgld7zJgCR+yj8lMnHFN6IYPWM3Oqs JC3Vp/Kz9KrLGxi5b+ZQW7D9L/vaz/8gIfvrhVNy1+9pqDTwMYoYpiA4P3QzIBAjTf+z TtyA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YnubSk6I/1F9tjgQMcK9TMHfOLjP3MjOgyGiwIWFOJo=; b=M2kIlx0ithVxPWVLayI4Ilg8509KSFEg8KgFSvPwWhX+LjTsr/0iC4FzkgQ6ZJDq9l Xk/dHAkHSUTOSXS/ovq8qj8lZo9iyxf4mr5c6UoJkVMzavxbujT97AV/vVtH2JXURo1I RMn/HL6I53dmwPfkLaZo4CO7UbhLJMD0b9beqK6wrZHJXuMsMtkxUSdIQ4ptmzfpw33K VunSJbCx+bWRY97YwfPkXbuhg0XOT1r0yRE/05di781m1HDnf6+UoJStTQJklDNPomXp Xh1u/QFzCEdbGcsFyljDp2OX2MdOhqEaMcSfDywKbs4SwW4ztKDLQ6DqtP4UaWRcztT9 8q9Q== X-Gm-Message-State: APzg51B/onNGwMuM3TX1uCvvJIDdUpZNwHuU1rG/6gaB9LnbKlkWznT/ 46IshLjPjo1FeIkhL0HnUYQDroLc X-Google-Smtp-Source: ANB0VdaJJzlYAaXwzqN9fjdahGK2vXAk85Wo9QNqDpzQDccrttGH8Cm6LTXzJ0NXJtfILzQZaWrm4Q== X-Received: by 2002:a62:4299:: with SMTP id h25-v6mr10465018pfd.73.1536353035913; Fri, 07 Sep 2018 13:43:55 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id h69-v6sm25440831pfh.13.2018.09.07.13.43.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 13:43:55 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: "Manfredi (US), Albert E" , David Farmer Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> <74731298941a4936b1a6e7076ee0ea32@XCH15-01-07.nw.nos.boeing.com> From: Brian E Carpenter Message-ID: <5fe52556-f88e-06fe-5d71-c788412915c4@gmail.com> Date: Sat, 8 Sep 2018 08:43:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <74731298941a4936b1a6e7076ee0ea32@XCH15-01-07.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.29 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 Sep 2018 20:43:59 -0000 On 2018-09-08 07:35, Manfredi (US), Albert E wrote: > From: ipv6 On Behalf Of David Farmer > >> I have a couple questions for you. When you say "no" to this are you saying no you won't deploy IPv6-only networks? Or, are you saying you will deploy IPv6-only networks but you would never set the flag if it were provided? > >> Or put another way, are you saying it's not useful because you won't ever deploy IPv6-only networks? > > Not answering for the other guys, Dave, but in this latest go-around, I thought the point made was that to achieve the goal of IPv6-only networks, all routers filtering IPv4 out at layer 2 was the best answer. And the proposal recognises that. But it isn't "routers" because routers are at level 3; it's layer 2 devices, *if* they have that capability. As explained in the draft, this solution is for scenarios where that isn't the case. Brian From nobody Fri Sep 7 13:53:39 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3791A12F18C for ; Fri, 7 Sep 2018 13:53:38 -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 H4Z-v55WriD3 for ; Fri, 7 Sep 2018 13:53:36 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A411130DDB for ; Fri, 7 Sep 2018 13:53:35 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id l63-v6so7536809pga.7 for ; Fri, 07 Sep 2018 13:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OeJiGVHF6976IYs7d5Jmu97lHJ4j9YaqAUCOaqvm6io=; b=SGk/9r3ISpXMePrvSUZv84jBstTpgJFgFKYLDyKb7KSX7DpTHrhOA/D2Yof73UoVQR ZN7x/Hm7R+ezZPlBbYG+Pyn7si+qpdMv+iXMaW+4ZjtnGGNG9DFiBO7VYYpyOldyHG6J rsPw9+kFepIUJlEAPmXTSxrzXtfiaUduBnkZ3GianO1g8AxL8PNOkJIDPEFmyyyK12ar ZbuTcwjA1FmxgwU9eGCDB3tKTJSO+OVBwWs6Wchp2zvHQO5t3o4m2EXIo8qevIDtI1bA i4hn0V5U20gBjcNwwDaMBFmh5W4F/PITl/MuiWn0194mkb8odEQr8jsXvEe0nZ9cea2u MK/Q== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OeJiGVHF6976IYs7d5Jmu97lHJ4j9YaqAUCOaqvm6io=; b=H9jy+15cAKx1ammqiKhESq9Sopiomy1FEe/2ObGNBKFrD3Gik8Bl2WD7OTdm1OA1yr A5dIOVsKnPe9EgG/8cJfxDuM7tYnI1ocXJmcgYrUj7XX+XrF6WkA86VriSgXPRDeIwNG bHEBXggU0VNKO0JrtirmFXWbTSwoKbUYhZc6J3dfv5+Y1JJJGg6ixkXlXQHxNVYfGKt3 S9qKoSlFsWgp1IhJhQfG4tcq/ouUNNCtFe3RngGTdOx+6UtgUeBFzLJlNbkMLySCq544 R/XHoENPXfRAbW20o0DcKGq9UYVB8mOGLJDmSypgGU8y98MUtNfTmyxI+hqyewWvLhhy v6qg== X-Gm-Message-State: APzg51DnsQXGbDQ91GLvbBNEThtOQZskzBQmk6AFEnVWRVN9r3e9Dvme 5/O3/24YpWNANpEH7LrqUR1NqI+J X-Google-Smtp-Source: ANB0Vda84NU33Rs7vEBLcWEWJZVdXWPHWC+8jVm9zV1nomvxo8J+mXT9DNUzz+tl15MIjp/1CR4NEQ== X-Received: by 2002:a65:5004:: with SMTP id f4-v6mr10146327pgo.54.1536353615009; Fri, 07 Sep 2018 13:53:35 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id c1-v6sm11240212pfi.142.2018.09.07.13.53.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 13:53:34 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: David Schinazi Cc: ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Brian E Carpenter Message-ID: Date: Sat, 8 Sep 2018 08:53:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 20:53:38 -0000 On 2018-09-08 04:45, David Schinazi wrote: > Hi Brian, > > The updates to the draft do not address my comments. They are intended to explain how this proposal fits in with the alternative (layer 2 solutions). The draft doesn't suggest that it's an exclusive solution; it's entirely complementary to layer 2 solutions, and it *adds* an explicit signal to dual stack nodes telling them that they SHOULD NOT send IPv4 packets. Of course, it's an engineering choice whether that is a win, but like all IETF standards, this would be for the market to decide. Brian > Saying that the draft contains responses is not sufficient if you want to reach working group consensus.> > Regards, > David > > >> On Sep 6, 2018, at 19:20, Brian E Carpenter wrote: >> >> Hi, >> >> David has sent his objections before, and the authors updated the draft >> considerably as a result. I don't really see what more we can do except >> say that the draft already contains responses to all these objections. >> >> Regards >> Brian >> >> On 2018-09-07 10:56, David Schinazi wrote: >>> Hello 6man, >>> >>> I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard. >>> >>> The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can be solved simply by having the router drop all IPv4 traffic. >>> >>> The document even tries to claim that it improves security by reducing malicious IPv4 traffic. That is simply false as hosts are free to ignore the flag, and malicious ones will. This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. Again, the correct solution is to have routers drop IPv4 traffic. >>> >>> This document is also harmful with regards to future developments of the Internet Protocol. What happens when the next version of IP is standardized? Does this flag prevent using the new version on "IPv6-only networks"? So do operators now need to disable this flag and end up with triple stacked hosts? >>> >>> I think the problems described in this document would be better solved by having routers drop all IPv4 traffic and potentially having a mechanism to let the clients know of this policy - but that mechanism should live either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the small number of RA flags we have left. >>> >>> While I can't comment on future products, the odds of us deploying this are very low. And since this option is not useful without most client devices supporting it, network operators will not get the improvements they seek. >>> >>> For all these reasons, I think this proposal does not adequately solve the problem it describes, and is harmful to future developments of IP. It is therefore premature to promote this draft to Proposed Standard. I would rather see this problem solved elsewhere, potentially in DHCPv4. >>> >>> Thank you, >>> David Schinazi >>> >>> >>>> On Sep 5, 2018, at 10:40, Ole Troan >> wrote: >>>> >>>> This message starts a two week 6MAN Working Group Last Call on advancing: >>>> >>>> Title : IPv6 Router Advertisement IPv6-Only Flag >>>> Authors : R. Hinden, B. Carpenter >>>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>>> Pages : 11 >>>> Date : 2018-08-14 >>>> >>>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>>> >>>> as a Proposed Standard. Substantive comments and statements of support >>>> for publishing this document should be directed to the mailing list. >>>> Editorial suggestions can be sent to the author. This last call will >>>> end on 19 September 2018. >>>> >>>> An issue tracker will be setup to track issues raised on this document. >>>> >>>> Thanks, >>>> Ole >>>> >>>> >>>> -------------------------------------------------------------------- >>>> 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 Fri Sep 7 14:09:51 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD48130DDB; Fri, 7 Sep 2018 14:09: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 fWkqgNp4IGda; Fri, 7 Sep 2018 14:09:48 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E21127133; Fri, 7 Sep 2018 14:09:48 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id 2-v6so7564092pgo.4; Fri, 07 Sep 2018 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EkEngVrcoOSRC5zsm/Fp9v2mMrwoEQyilCfp44Q5lCc=; b=Y4PhniNmTA4rDpXtag0nEc6aGaCSNlLSP+Q4KT9yhbaBJWE0raWj3gzYCU7zg6KpZs A5niW29EW4MUB4Eo/K5ZxyeC8znHKgIfk2IVn2rYxnRH2BKUgbjwecj/m+6ju4BPDZzr tfw9NvZi1YFFN1VpRdSy1eSGq9x5qunqp2EOiUiu+zjnt5fdYflra4RgGc6+xgjAgPy7 JRJ1xmhWU5qradf6I3DUG4VlJyHDTJRAGDr40VegrzsdyfSIVV3/sRaBd50ReJbcmNJU Ud6VyjE1iRkGW3zulhS2mNB//ntcjKpF4jlfvZBHsNOBjyc/eEueB7Z+g/u/OW24JrA4 GS2A== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EkEngVrcoOSRC5zsm/Fp9v2mMrwoEQyilCfp44Q5lCc=; b=WSbk61fC1Hrekuxf1yc/dEfGH4Uhxwj5KNv6nWHmSubShDQXMIUYLyjqqIM/+3APEZ 4tGITzpS5RZ8EwBk8e26JC/gt8yLbCF/HLZ3eOBFxCG/jrDGmRxgNuCND1Vf9FXsKivr cNjEzp3wQ3ny4L5qikrzziQAbSE4KjtS3DGZCNTZJ7Fz4dxj1Gkw9H61VS+hKK6QRhoY lE4/gM7ajo5lS3kiOJyvZOm2Y1rfMBf9Q1AnUO4FO0zo729Wx175ObzkBYQbL8By5/k6 uiGZtSlU+8YlvtODK1aaZFvfP9sPC9pmaGZxu/8634vddnn0I1AY7Cbo0YS23PhcHY3k eVCw== X-Gm-Message-State: APzg51DA+wBt+YzukthqN4DYBbfHVQnJobx3/04myPWhd1UDrDMBhSbK iyEAJ6a8Vf46rd4qm0n7XPUamytv X-Google-Smtp-Source: ANB0VdYtiJQC+Mc0qVbzTmG6I2s9qe4w8AjpVkV2VpWz8QYCxUqFghI4VTbuY5jRAHmb/ddY9uRpXw== X-Received: by 2002:a62:1605:: with SMTP id 5-v6mr10673080pfw.11.1536354587401; Fri, 07 Sep 2018 14:09:47 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id g5-v6sm13631309pfc.77.2018.09.07.14.09.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 14:09:46 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: David Schinazi , Mark Smith Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <1FED2825-195C-411D-9F6C-B8937DE9878D@apple.com> From: Brian E Carpenter Message-ID: Date: Sat, 8 Sep 2018 09:09:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1FED2825-195C-411D-9F6C-B8937DE9878D@apple.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.29 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 Sep 2018 21:09:51 -0000 David, On 2018-09-08 04:52, David Schinazi wrote: > Hi Mark, > > Responses inline. > >> On Sep 6, 2018, at 21:17, Mark Smith wrote: >> >> I don't think it solves the problem, it only mitigates other hosts >> receiving (typically link-layer broadcast DHCPv4) packets that they're >> not interested in. > > It solves part of the problem - and in my mind those are the most important parts. > >> The sending hosts still spend effort forming and sending periodic >> packets, needlessly consuming their own energy doing so, as well as >> capacity on the link-layer media. >> >> The only way to solve the problem is to inform sending hosts that >> sending those types of packets will never succeed, so they shouldn't >> waste their resources forming and sending them. This flag is that >> signal. > > As I mentioned in my previous message, there might be value for *a* flag, > but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this. Why not? Just because spare bits are rare? What would be a better vehicle? >> It may take years for this flag to be widely supported, however that >> is better than nothing. Layer 2 filters in the network do nothing to >> prevent hosts creating and sending these useless packets (even layer 2 >> filters pushed down into the hosts still wouldn't prevent these >> useless packets being created.) > > No, this is not better than nothing, it is worse than nothing. It uses up an > RA flag and creates pain down the road when we want to update IP again. I don't see that. Admittedly, the original name ("IPv4 Unavailable flag") was better in this respect, and it might be cleaner to define this one as meaning "No IP with version <6 on this link", but when IPvN comes along, it could choose to signal "No IP with version X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A25130DCF for ; Fri, 7 Sep 2018 15:23:07 -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 drBf9K7RtGoD for ; Fri, 7 Sep 2018 15:23:05 -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 0B53D130DC7 for ; Fri, 7 Sep 2018 15:23: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 w87LMrGF001127 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2018 22:22:54 +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 Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Brian E Carpenter Cc: David Schinazi , ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Nick Hilliard Message-ID: Date: Fri, 7 Sep 2018 23:22:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: 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.29 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 Sep 2018 22:23:07 -0000 Brian E Carpenter wrote on 07/09/2018 21:53: > They are intended to explain how this proposal fits in with the > alternative (layer 2 solutions). The draft doesn't suggest that it's > an exclusive solution; it's entirely complementary to layer 2 solutions, > and it*adds* an explicit signal to dual stack nodes telling them that > they SHOULD NOT send IPv4 packets. Of course, it's an engineering choice > whether that is a win, but like all IETF standards, this would be for > the market to decide. Brian, It's not ok to brush technical critique off with answers along the lines of "you may have a point ... but the market will decide". The IETF has a duty to assess drafts on the basis of whether they solve clearly-defined problems in technically appropriate ways, and any draft going through a WG should be able to withstand reasonable commentary and criticism. There's been a substantial number of serious technical concerns posted in this WG about this draft, both in terms of the problem statement and the proposed solution. Most of these remain fully unaddressed in any reasonable way in terms of either discussion on the mailing list or updates to the document. I can see why the ipv6only flag might seem attractive from an ideological point of view, but from the point of view of production engineering, the problem statement does not withstand scrutiny. Even if it did, the issues identified in the draft could be handled more comprehensively and more simply in several other ways. Sorry to be so brutally utilitarian - if not harsh - but there are fundamental problems here, and these problems must be addressed adequately before the draft progresses. Nick From nobody Fri Sep 7 15:39:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C53130DC7; Fri, 7 Sep 2018 15:39:01 -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 OuIeHDGBicPF; Fri, 7 Sep 2018 15:39: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 442FA1292AD; Fri, 7 Sep 2018 15:38: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 w87McxQ9058170; Fri, 7 Sep 2018 15:38:59 -0700 Received: from XCH15-01-10.nw.nos.boeing.com (xch15-01-10.nw.nos.boeing.com [137.136.239.186]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w87MctH5058145 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 7 Sep 2018 15:38:55 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-10.nw.nos.boeing.com (137.136.239.186) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 7 Sep 2018 15:38:54 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Fri, 7 Sep 2018 15:38:54 -0700 From: "Manfredi (US), Albert E" To: Brian E Carpenter CC: 6man WG , 6man Chairs <6man-chairs@ietf.org> Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURm7G5Ieh5nHO1E6PHkpFno+usqTk1J4AgAAGTACAAKuDAP//r94ggACJJgD//6dsYA== Date: Fri, 7 Sep 2018 22:38:54 +0000 Message-ID: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> <74731298941a4936b1a6e7076ee0ea32@XCH15-01-07.nw.nos.boeing.com> <5fe52556-f88e-06fe-5d71-c788412915c4@gmail.com> In-Reply-To: <5fe52556-f88e-06fe-5d71-c788412915c4@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] x-tm-snts-smtp: 223B118991BC5136AF26F700E7407C4F0C32593D7D11ED3CCEA454749DA52F852000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:39:02 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IA0KDQo+PiBOb3QgYW5zd2VyaW5nIGZvciB0aGUgb3Ro ZXIgZ3V5cywgRGF2ZSwgYnV0IGluIHRoaXMgbGF0ZXN0IGdvLWFyb3VuZCwNCj4+IEkgdGhvdWdo dCB0aGUgcG9pbnQgbWFkZSB3YXMgdGhhdCB0byBhY2hpZXZlIHRoZSBnb2FsIG9mIElQdjYtb25s eQ0KPj4gbmV0d29ya3MsIGFsbCByb3V0ZXJzIGZpbHRlcmluZyBJUHY0IG91dCBhdCBsYXllciAy IHdhcyB0aGUgYmVzdCBhbnN3ZXIuDQo+DQo+IEFuZCB0aGUgcHJvcG9zYWwgcmVjb2duaXNlcyB0 aGF0LiBCdXQgaXQgaXNuJ3QgInJvdXRlcnMiIGJlY2F1c2Ugcm91dGVycw0KPiBhcmUgYXQgbGV2 ZWwgMzsgaXQncyBsYXllciAyIGRldmljZXMsICppZiogdGhleSBoYXZlIHRoYXQgY2FwYWJpbGl0 eS4gQXMNCj4gZXhwbGFpbmVkIGluIHRoZSBkcmFmdCwgdGhpcyBzb2x1dGlvbiBpcyBmb3Igc2Nl bmFyaW9zIHdoZXJlIHRoYXQgaXNuJ3QNCj4gdGhlIGNhc2UuDQoNCk9rYXksIGJ1dCByb3V0ZXJz IGRvIGhhdmUgdGhlIEV0aGVybmV0IGludGVyZmFjZShzKSBhbmQgZHJpdmVyKHMpLCBwcmVzdW1h Ymx5LiBTbyB0aGUgSVNQIHRoYXQgY29uZmlndXJlcyByb3V0ZXJzLCBpbiBwYXJ0aWN1bGFyIHRo ZSBlZGdlIHJvdXRlciBpbiB0aGUgaG9tZSBtb2RlbSwgbGV0J3Mgc2F5LCB3aGljaCB0eXBpY2Fs bHkgaW5jb3Jwb3JhdGVzIHNvbWV0aGluZyBsaWtlIGEgNC1wb3J0IGxheWVyIDIgc3dpdGNoLCBh bmQgc29tZXRpbWVzIGFsc28gYSBXaUZpIGFjY2VzcyBwb2ludCwgY291bGQgcmVhZGlseSBwcmV2 ZW50IGFueSBJUHY0IGZyb20gY3Jvc3Npbmcgb3ZlciBpbnRvIHRoZSBJU1AgbmV0d29yay4NCg0K SW4gZWZmZWN0LCBkb2luZyBxdWl0ZSB3ZWxsIHdoYXQgdGhlIGZsYWcgaG9wZXMgdG8gYWNoaWV2 ZS4NCg0KQmVydA0KDQo= From nobody Fri Sep 7 16:15:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C555130DF4; Fri, 7 Sep 2018 16:15: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 5bOG-tKGTtdj; Fri, 7 Sep 2018 16:15:38 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC01130DC7; Fri, 7 Sep 2018 16:15:38 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id b11-v6so7694305pfo.3; Fri, 07 Sep 2018 16:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ejTeTp4kD76xEkAULa39ui3OXFsdNE2HsuCuLQW0kcI=; b=qVcYMpAzYRJa9Ryj+x9WZ6nmJhMVwB5siR479hIOpTJ7qYAhnvr5WUce7ZNFA/Q1Z8 WJaka9JCnO+5uqt8uiAH2U3uOXwPmoglN98tE56Vjvzapdhp+L6zTY18yJ1U1tr7vpNI 83GaB1wKCY/XXSEbCm//p036VBtHtMjjJWOrM8u4X2BAL9qTVeuev13J/OC/2Tr6q8gf mHGJQmLVLA1kw+KQrergnlUpVXqd4SxgmRmQgxP1pzLu/LbBBC/0GJ2AH8VR3rCNh1ZF 1LvylO6bLoH5rEWOMIzPfuNUDkLDbP4szCJO2Vti0WaAa98v0BsY01MQ8Ea5lkLlAjE5 0dQA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ejTeTp4kD76xEkAULa39ui3OXFsdNE2HsuCuLQW0kcI=; b=dEnbc99WNPsNfbdxYlmMND+Ps1sk5CaefY1ou/M6BCYJ1ntyFOCmZXjitHlY9CTABG BS03/L/yRxgrexXZ8Ac3BZSdeSiULCpiTKBbU6IVU1MYlX7MWC0Mj1JD7NIiZtCiv6gg HtVsX3ZIrv4HtwSQm3q5F/i52iH9jMjiG78MmIP38f82IsQ86C3YPIZ/PavnSNrsEEty AW38J3WQfYSyun7ZPTZEd1pnJD7+7btvstDJrBt9xP/tnTvNdmkQQBneN//tPx+sf5y/ dDqGPp7mASjGRr0/05OqCREqJBXabPwotcAPuvHB4H5BuGy/L1SQ/2J6A1/1HDY96V2Z Qu/A== X-Gm-Message-State: APzg51B+5Fe/7IagvBCzVlUJZOmdIEBqFKOL5h4yYpO+1uiwsXn3Zb4L bL3EH2ZX87ueqWf6bdueXyPG3n/d X-Google-Smtp-Source: ANB0VdbWEL1Z6agzU0QxMmJrB2sjikZnsobGri4QAbIl93mbLIGwArFGDnKkCLkV4ccNif+Bg765nw== X-Received: by 2002:a62:47d1:: with SMTP id p78-v6mr11054691pfi.197.1536362137235; Fri, 07 Sep 2018 16:15:37 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id r1-v6sm17565917pfi.17.2018.09.07.16.15.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 16:15:36 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: "Manfredi (US), Albert E" Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <20180907.090554.297825802.sthaug@nethelp.no> <74731298941a4936b1a6e7076ee0ea32@XCH15-01-07.nw.nos.boeing.com> <5fe52556-f88e-06fe-5d71-c788412915c4@gmail.com> From: Brian E Carpenter Message-ID: <8c22f6d6-e265-a055-7a5c-8dc91bcd270a@gmail.com> Date: Sat, 8 Sep 2018 11:15:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 23:15:40 -0000 On 2018-09-08 10:38, Manfredi (US), Albert E wrote: > -----Original Message----- > From: Brian E Carpenter > >>> Not answering for the other guys, Dave, but in this latest go-around, >>> I thought the point made was that to achieve the goal of IPv6-only >>> networks, all routers filtering IPv4 out at layer 2 was the best answer. >> >> And the proposal recognises that. But it isn't "routers" because routers >> are at level 3; it's layer 2 devices, *if* they have that capability. As >> explained in the draft, this solution is for scenarios where that isn't >> the case. > > Okay, but routers do have the Ethernet interface(s) and driver(s), presumably. So the ISP that configures routers, in particular the edge router in the home modem, let's say, which typically incorporates something like a 4-port layer 2 switch, and sometimes also a WiFi access point, could readily prevent any IPv4 from crossing over into the ISP network. > > In effect, doing quite well what the flag hopes to achieve. But no, because what the flag hopes to achieve is to prevent hosts wasting resource on sending IPv4 packets, or doing anything except discard them if they arrive. There's no way to do that except by sending *something* to the hosts. Brian Brian From nobody Fri Sep 7 16:27:19 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A91130E16 for ; Fri, 7 Sep 2018 16:27:16 -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, 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 NxoJ1D8TvJTE for ; Fri, 7 Sep 2018 16:27:13 -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 8FDCB130DC7 for ; Fri, 7 Sep 2018 16:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1536362831; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C62KT3GpgMuisFbzczcY6HIY/z3SQj4uvBhfPz7o2Eo=; b=TF8NNFcq9xU1umsQnIvpny8HjQjlldsMgHlCMRzBfA9FpiQO9zKzreSJxWlMmgvDk/ibUsHttS0UKJUBJ8xLiQ6ui9lTDDf6cV4rthUnt3xBy0mBAmdlrDJ+AGx4OsAKC7paXFpzJ0/g4JXNqMGRQp17hlgAL07VXFHbYF7R4Lc= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0184.outbound.protection.outlook.com [213.199.180.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-112-vEpl2RZgPymjIMux4cVScQ-1; Sat, 08 Sep 2018 00:27:09 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB3921.eurprd07.prod.outlook.com (52.134.82.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.6; Fri, 7 Sep 2018 23:27:08 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76%5]) with mapi id 15.20.1122.009; Fri, 7 Sep 2018 23:27:08 +0000 From: Tim Chown To: Brian E Carpenter CC: "ipv6@ietf.org" Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURT+5fmxjNPJnAkOJ7cXg3yn1RqTkUw2AgAAOlwCAAOf7AIAAMHUA Date: Fri, 7 Sep 2018 23:27:07 +0000 Message-ID: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> In-Reply-To: <485604f0-21a7-bf85-e500-bde3c47eaf2f@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.3445.9.1) x-originating-ip: [2001:a88:d510:1101:713e:b82d:c6de:2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB3921; 20:c6EuIfnCutE4NId7rKY/eTuBXTGAftJZdE1QL+0xMDPU4xMgT4BJxTR8jlgt+n+pc9mkAUp669l24rNpGQt1VtTAxq3fv8b+6G5+FjdCG4hpMEnDxCa7s8n9YC6wabAp5s10gww0mhDgNCaiES9eXmSHdw3X5LK7Pdd3LFNFz1I= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e7c42fa7-6e24-4121-826c-08d615196dd4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB3921; x-ms-traffictypediagnostic: AM0PR07MB3921: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699050); SRVR:AM0PR07MB3921; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB3921; x-forefront-prvs: 07880C4932 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(136003)(366004)(346002)(376002)(189003)(199004)(6916009)(6246003)(39060400002)(486006)(53936002)(6512007)(6436002)(83716003)(82746002)(76176011)(6306002)(99286004)(6486002)(229853002)(786003)(2616005)(316002)(36756003)(2900100001)(11346002)(446003)(2906002)(86362001)(5250100002)(46003)(5660300001)(6116002)(476003)(93886005)(33656002)(105586002)(106356001)(186003)(72206003)(74482002)(966005)(8676002)(102836004)(81156014)(81166006)(25786009)(8936002)(50226002)(53546011)(6506007)(478600001)(97736004)(68736007)(57306001)(305945005)(7736002)(4326008)(256004)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3921; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-microsoft-antispam-message-info: ubY711pjrD7mFDmANY8rtmIGXdL4bmtQyqVBOEi6LGzqq/lGT8xZHTvXfGbvMrm3gt0S3yhRrKojBiCkAG/eNAhAefctP3dgOuMG2BpdTiFvNIIQnnMgfHY3mB/4eUMi5Ikt8BKbg57kKbqDNzEkxfMuqWGL1E0GXu6n5QNDyzgIKucXxSEFSo+0w/3eQ0r13rcjvPLIfFbof71YQ69ONb0nOkvYKt3/carJRRtuLSzxS8djfkq1IPfFn/Uss1R9XAp2S1s3Sm325PwzAv0xmqI+akw2VRfxIPGjTKKa1ZblYpHwJ8rsXo64mpfTU011UBK1MpdRznIS1/qqnK3kmDWGkV8pf4iBGN/YTAiF6Dw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0E660849C7EA9443B2A08B83E49671FB@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: e7c42fa7-6e24-4121-826c-08d615196dd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2018 23:27:07.9242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3921 X-MC-Unique: vEpl2RZgPymjIMux4cVScQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:27:17 -0000 T24gNyBTZXAgMjAxOCwgYXQgMjE6MzMsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMjAxOC0wOS0wNyAxODo0MywgT2xlIFRy b2FuIHdyb3RlOg0KPj4gDQo+PiANCj4+IE9uIDcgU2VwIDIwMTgsIGF0IDA3OjUxLCBzdGhhdWdA bmV0aGVscC5ubyB3cm90ZToNCj4+IA0KPj4+PiBUaXRsZSAgICAgICAgOiBJUHY2IFJvdXRlciBB ZHZlcnRpc2VtZW50IElQdjYtT25seSBGbGFnDQo+Pj4+IEF1dGhvcnMgICAgICA6IFIuIEhpbmRl biwgQi4gQ2FycGVudGVyDQo+Pj4+IEZpbGVuYW1lICAgICA6IGRyYWZ0LWlldGYtNm1hbi1pcHY2 b25seS1mbGFnLTAyLnR4dA0KPj4+PiBQYWdlcyAgICAgICAgOiAxMQ0KPj4+PiBEYXRlICAgICAg ICAgOiAyMDE4LTA4LTE0DQo+Pj4+IA0KPj4+PiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtNm1hbi1pcHY2b25seS1mbGFnLTAyDQo+Pj4+IA0KPj4+PiBhcyBhIFByb3Bv c2VkIFN0YW5kYXJkLiBTdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgc3RhdGVtZW50cyBvZiBzdXBw b3J0DQo+Pj4+IGZvciBwdWJsaXNoaW5nIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRpcmVjdGVk IHRvIHRoZSBtYWlsaW5nIGxpc3QuDQo+Pj4+IEVkaXRvcmlhbCBzdWdnZXN0aW9ucyBjYW4gYmUg c2VudCB0byB0aGUgYXV0aG9yLiBUaGlzIGxhc3QgY2FsbCB3aWxsDQo+Pj4+IGVuZCBvbiAxOSBT ZXB0ZW1iZXIgMjAxOC4NCj4+PiANCj4+PiBXaXRoIG15IElTUCBoYXQgb246IFdlIGhhdmUgbm8g cGxhbnMgdG8gYXNrIG91ciBlcXVpcG1lbnQgdmVuZG9ycyB0bw0KPj4+IHN1cHBvcnQgdGhpcywg b3IgdG8gY29uZmlndXJlIGl0IGlmIGl0IHdhcyBhdmFpbGFibGUuIFdlIHNlZSB0aGlzIGFzDQo+ Pj4gYSBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5IGNoYW5nZS4NCj4+PiANCj4+PiBOb3Qgc3VwcG9y dGVkLg0KPj4gDQo+PiBSaWdodCwgdGhlcmUgcHJvYmFibHkgaXNu4oCZdCBtdWNoIG9mIGEgdXNl IGNhc2UgZm9yIGFuIElTUC4gSWYgY29uc2lkZXJpbmcgdGhlIFBFIC0gQ0UgbGluaywgUkZDNzA4 MyBpcyBwcm9iYWJseSB0aGUgb25seSB0aGluZyBha2luIHRvIHRoaXMuIEFwYXJ0IGZyb20gcHVi bGljIFdJRkkuIA0KPiANCj4gQ29ycmVjdC4gSXQncyBhIHNvbHV0aW9uIGZvciBjZXJ0YWluIHNj ZW5hcmlvcywgYW5kIGl0J3MgYSBtYXJrZXQgZGVjaXNpb24NCj4gd2hpY2ggc2NlbmFyaW9zIGp1 c3RpZnkgdGhlIGNvc3QuDQoNCkhhdmUgeW91IHNwb2tlbiB0byB2ZW5kb3JzIG9yIElTUHMgLyBl bnRlcnByaXNlIHdobyB3b3VsZCBlaXRoZXIgaW1wbGVtZW50IG9yIHVzZSB0aGlzIGZsYWc/DQoN ClRpbQ== From nobody Fri Sep 7 16:29:43 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93C130E1E for ; Fri, 7 Sep 2018 16:29:41 -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 D-cHFRlHqKbm for ; Fri, 7 Sep 2018 16:29:38 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C875D130DC7 for ; Fri, 7 Sep 2018 16:29:38 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id r1-v6so7675714pgp.11 for ; Fri, 07 Sep 2018 16:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2lnB+MnyXRx24tsQqGVSxAXMjQslipYqiAx7YNE3RVw=; b=ocxgBhotv+dvRZHdqqVi8NO0RY7wVI+p7oFZNkbGoGzEKy6VUjoyNKSl20BkqQnpZH TEeBT0r/vDteQLrPemDyMizsTEVf2bEuPjUHZzTov2D5ED00fXD47ipOd6GiQLwY/k19 5y9eNvbKG6D6NkqjN7/tO5pmNeq/f9/eWjiRmok8a3fXyKOr7HopJBGnJiLDoOcHM3LO iUKCfK78CV4jkof6357iymktGZ7PJWqDuR8HJQ+pF4whsTUYC0eQkZD94wfMPytQJIqt V1JVfe272I+S5iNV7WwLp3sU+vy0av+gwD/HsRqNNrvjB5oJLDhQgk/VXA9RnQTQNJrg 0Mgg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2lnB+MnyXRx24tsQqGVSxAXMjQslipYqiAx7YNE3RVw=; b=raVLkOTfWpTVbaBS1SmDyleZatkHcn8jNCpCv0Iw0F47cieCx2gCP4W52aUaHlKTU+ CyA5wnrxCPix6IbtlPMFtm+FsntWZ/U+gCXIhRwhD58nE0FysRMeo1BDg6Wi6CnmQ/Ck IANxp201ACKTlcBZWWx9I1uCnZFA/vcyLZvXevpW14qFUTLGj4ikLNGcoRVgtl7xlmHM KamgN4jh7Su5GN09jtLDbNGA2wJJXgNn/szVA8UCVwfi6AruVa+WtLb4rVLMRXIHFBSW YfwcMzY6tTFnKPsRXDyojTLt2p6l3Y5sST/4+akP87qFsYKYlrLYO19PPOczrxbNLj8L Lc7Q== X-Gm-Message-State: APzg51B7g3SPvIYqPDVK5sQe9NDPYX7u3SGn41gQq7NXsrdRoAwtgHT0 XuI88HuMwvOKEA5fQGKgUdYZYi6Q X-Google-Smtp-Source: ANB0VdYUiQq6eSF2BGRFfE7Y8x4q49FPc6WcdCmVTAh0bodJB2f6bAPo6gn2PgDg0IgYQQwTpkFiyg== X-Received: by 2002:a63:4826:: with SMTP id v38-v6mr10716965pga.379.1536362977668; Fri, 07 Sep 2018 16:29:37 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id y124-v6sm13006528pfg.63.2018.09.07.16.29.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 16:29:36 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Nick Hilliard Cc: David Schinazi , ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Brian E Carpenter Message-ID: Date: Sat, 8 Sep 2018 11:29:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 23:29:41 -0000 On 2018-09-08 10:22, Nick Hilliard wrote: > Brian E Carpenter wrote on 07/09/2018 21:53: >> They are intended to explain how this proposal fits in with the >> alternative (layer 2 solutions). The draft doesn't suggest that it's >> an exclusive solution; it's entirely complementary to layer 2 solutions, >> and it*adds* an explicit signal to dual stack nodes telling them that >> they SHOULD NOT send IPv4 packets. Of course, it's an engineering choice >> whether that is a win, but like all IETF standards, this would be for >> the market to decide. > > Brian, > > It's not ok to brush technical critique off with answers along the lines > of "you may have a point ... but the market will decide". The IETF has > a duty to assess drafts on the basis of whether they solve > clearly-defined problems in technically appropriate ways, and any draft > going through a WG should be able to withstand reasonable commentary and > criticism. Yes, which is what we're doing here. > There's been a substantial number of serious technical > concerns posted in this WG about this draft, both in terms of the > problem statement and the proposed solution. Most of these remain fully > unaddressed in any reasonable way in terms of either discussion on the > mailing list or updates to the document. I think we've made it clear (on the list and in the draft) that we are proposing something in addition to switch-based solutions, that (as I just wrote to Bert) can only be achieved by sending a signal to the hosts. That said, I really don't know which technical concerns haven't been addressed. Can you be explicit, because we considered all previous comments when producing the current draft? > I can see why the ipv6only flag might seem attractive from an > ideological point of view, but from the point of view of production > engineering, the problem statement does not withstand scrutiny. o Such traffic may drain battery power on wireless hosts that have no interest in link-local IPv4 traffic. [RFC7772] indicates how this risk might be quantified. o Similarly, hosts may waste battery power on futile attempts to access IPv4 services. Those are the problem statements concerning hosts. What's wrong with them? (I agree that the other problems listed can be mitigated by switches. We could reorganise the text to make this clearer.) > Even if > it did, the issues identified in the draft could be handled more > comprehensively and more simply in several other ways. How else could we tell hosts to ignore IPv4 completely? Brian > Sorry to be so > brutally utilitarian - if not harsh - but there are fundamental problems > here, and these problems must be addressed adequately before the draft > progresses. > > Nick > From nobody Fri Sep 7 18:12:30 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C951294D7; Fri, 7 Sep 2018 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 8qf_AIHNMkzj; Fri, 7 Sep 2018 18:12:26 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 2A93C130E26; Fri, 7 Sep 2018 18:12:26 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id 13-v6so30601513ois.1; Fri, 07 Sep 2018 18:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SHNvrEckdhfxyLFm/IJWKEAmGdfTtPsgonKd7twA//o=; b=lvOUFVIuRkO+A5LDYLyKJ8N4ss7NMBic3T8rufB8dgTqM+SC7BDTClgSzd2mHsMkSX NMto2iN6MZQ/n94pWezVEHONyR0kNU4R0It8KI6OSCJHrbdTQ/AI/jyk3+5EJDH0fTuE d4WXZS9q/oln/rS04hBFwfOViV+c36HoLU2nVqkGSO7L4oBQ9v8NM1TS+zqUjozIjhIG H3bWV6GcPDnLIfBX1cf7nvIaB0JN2V3VPM7QXwqeRy1cksEKUY+7Y1rqEs39ZLMQnQPB qnR+bQf5wdw3PjWWlwniCR22DEs73a70Ic4YSWCOOySpmXvgttiuSnLp83s+7aOeE89G aV8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SHNvrEckdhfxyLFm/IJWKEAmGdfTtPsgonKd7twA//o=; b=H9rPfzf5mT0IXjDORfp3ScicHYFg+v2GLvX+7XBirbhSaiaslQknEIasZd239Mwv2k A0lnYw4Blh46UrTUuQ3FPQ1R8zuDnVGIUOM35PnW+0wJnoLZnnAPmNQo+EyirxjabNHb fZSQaMG++WWE2KRfEhEtIY9fCqJXNzRaqGvhHP7XQVLN0p/b5tgWor5JzLBnKApnNNrH iEVNIuxprGy3eF461qttEgBr5+LWJmwUSHujZOtdVunzdGKWc3cHOXo/jceHW/aEqeqh b7XPlJPi3o8KNgLjM24TVYR5bPx7fCB2+Cp8Q/QTe7E6VTDrZupNZGnoLjIGUaYGDDbt rLXA== X-Gm-Message-State: APzg51DnAnRSMOpO1PBQj7xBOPEPJR2oDoJRU03pqO+/1DDssK9FedJo 1dVtMtYvWCJl91EgpWsfOMB4Me9M2O73yyFK8R8= X-Google-Smtp-Source: ANB0VdZNZaLYEPT9IgPPH0g9y5BLaGipasp3CZNK6Ddx9fuyamuuuvWgRrz0Ou4s2b2Y2VqG3pCCx7W12nwn/pfvJ0I= X-Received: by 2002:aca:b2c4:: with SMTP id b187-v6mr10608262oif.160.1536369145481; Fri, 07 Sep 2018 18:12:25 -0700 (PDT) MIME-Version: 1.0 References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <1FED2825-195C-411D-9F6C-B8937DE9878D@apple.com> In-Reply-To: <1FED2825-195C-411D-9F6C-B8937DE9878D@apple.com> From: Mark Smith Date: Sat, 8 Sep 2018 11:11:58 +1000 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: David Schinazi Cc: Ole Troan , 6man WG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 01:12:28 -0000 On Sat, 8 Sep 2018 at 02:52, David Schinazi wrote: > > Hi Mark, > > Responses inline. > > On Sep 6, 2018, at 21:17, Mark Smith wrote: > > I don't think it solves the problem, it only mitigates other hosts > receiving (typically link-layer broadcast DHCPv4) packets that they're > not interested in. > > > It solves part of the problem - and in my mind those are the most important parts. > What do you consider to be the most important parts? I consider both reducing unnecessary link-layer broadcasts on a link and having hosts not expending unnecessary cycles sending useless packets to be equally important as the goals of this flag. Related to saving hosts' energy, we even consider saving battery power on portable devices important enough that we've published a BCP on reducing the energy consumption consequences of RAs - BCP 202 - "Reducing Energy Consumption of Router Advertisements" Micro-savings of individual hosts' energy multiplied by billions of hosts can be a major energy saving. > The sending hosts still spend effort forming and sending periodic > packets, needlessly consuming their own energy doing so, as well as > capacity on the link-layer media. > > The only way to solve the problem is to inform sending hosts that > sending those types of packets will never succeed, so they shouldn't > waste their resources forming and sending them. This flag is that > signal. > > > As I mentioned in my previous message, there might be value for *a* flag, > but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this. > IPv6 RAs can be considered an out-of-band protocol to carry this IPv4 information. Another IPv4 out-of-band protocol such as a link-layer protocol e.g. LLDP could be used to convey this information instead. However, adoption of either a new link-layer protocol, or a modification to one like LLDP and its subsequent widespread adoption, is going to take far longer than adoption of this RA flag in hosts and routers that will already need to and are speaking IPv6. Somebody suggested using ARP for this. Trouble is that ARP is a link-layer broadcast packet, and is also a companion legacy IPv4 protocol that this flag is inherently also trying to disable when it can be. > It may take years for this flag to be widely supported, however that > is better than nothing. Layer 2 filters in the network do nothing to > prevent hosts creating and sending these useless packets (even layer 2 > filters pushed down into the hosts still wouldn't prevent these > useless packets being created.) > > > No, this is not better than nothing, it is worse than nothing. It uses up an > RA flag and creates pain down the road when we want to update IP again. > Everything is a trade off. If the benefit outweighs the cost, then the cost is worth paying. Not that we should be worrying about the next version of IP (and won't need to for in the order of at least 50 years), but how will this create pain to upgrade to the next version of IP? We don't even know what the next version of IP will look like. Regards, Mark. > Regards, > David From nobody Fri Sep 7 19:14:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE90C130DDC for ; Fri, 7 Sep 2018 19:13: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 DAMUu_Gy22wx for ; Fri, 7 Sep 2018 19:13:58 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279A0130DC2 for ; Fri, 7 Sep 2018 19:13:58 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id 2-v6so7818216pgo.4 for ; Fri, 07 Sep 2018 19:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rqMaTgE72T56zjXmnMSTgrBe0vnJtwyE0gOCMj0WLLU=; b=YkqbXqGabMfIkLBVfJU3l5mpKmT45HCoM5icfms1V0vOHNTdUGix1gz09spjwtykrj izgcydMg/NfbvRlmX0jEDDy0xyPqMlFbmCE1GZ6DY1lp5CWVUfi1Fy7FDcdwtNOODFxg 9auAJybMG6W4OYBVfRKkVVkvrrClSxlxzXflAlQUwclxuf4K9VYBihGWoM95hfblw1nu ceurOyKhyZJSPUeI5TYcIqcv6AdNVo7tgXw5/ZY2jNGa5TqYbjiWCcWmwh59qXAdGzdx GrJqM0dFfBKhVt4S+K/9XMyvNYP8gxSm2mYhJP0gtHZm/+pAny9uyW19UTLJYn23V9Y1 4IAw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rqMaTgE72T56zjXmnMSTgrBe0vnJtwyE0gOCMj0WLLU=; b=JbUDB9+MoLafECai9GwsefWjZ/Nx4MTpUDA4TUtZ1lAO6OJGStPpXluULH3nPDFF5v Gg5WtMklnpRaK8V2qi6dI4Mx1YDDMdfTA9FQh5Bt+/9Ay4dxrzQNhggRLU8cpio5ieQ6 EDeAKgw7js2k9ApNqlwt1W2GFQ6OfEsW3atEC3+oaGK8NR1U/x/9aFohVTwER/2NzoV4 7rbGO8dzl+AGIl97wru5+1J9hCEmSDm70ZIkkw+um6ahfsvZRpt4D+44UZTPF8YjoSx+ YQlpPcUjcT0FN+HqBSLOjVezXYiF6CE9t6iCa5SUwsxLbgpZWMOyVmWRMtriN/p8QZbV A+Qg== X-Gm-Message-State: APzg51B/Ok/Zwo17fLFgCEMk7eS3HS1jFm004oYDR4TwIn7YixzqfKYi FthvcXyM3VJQ6GzO99k9WkU= X-Google-Smtp-Source: ANB0Vdb88FFE4oNBNecMtdnCS02+4b6SquTbkyrDGWjPAeIKN9krdR8B+R/36GJpx+2IstiQTZ+C0w== X-Received: by 2002:a65:490e:: with SMTP id p14-v6mr11008668pgs.437.1536372837573; Fri, 07 Sep 2018 19:13:57 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f13-v6sm9799582pgs.92.2018.09.07.19.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 19:13:56 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Tim Chown Cc: "ipv6@ietf.org" , Bob Hinden References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> From: Brian E Carpenter Message-ID: <03faf4e8-d05a-9f74-3ae7-7b9c8c9b049e@gmail.com> Date: Sat, 8 Sep 2018 14:13:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 02:14:00 -0000 On 2018-09-08 11:27, Tim Chown wrote: > On 7 Sep 2018, at 21:33, Brian E Carpenter wrote: >> >> On 2018-09-07 18:43, Ole Troan wrote: >>> >>> >>> On 7 Sep 2018, at 07:51, sthaug@nethelp.no wrote: >>> >>>>> Title : IPv6 Router Advertisement IPv6-Only Flag >>>>> Authors : R. Hinden, B. Carpenter >>>>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>>>> Pages : 11 >>>>> Date : 2018-08-14 >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>>>> >>>>> as a Proposed Standard. Substantive comments and statements of supp= ort >>>>> for publishing this document should be directed to the mailing list= =2E >>>>> Editorial suggestions can be sent to the author. This last call wil= l >>>>> end on 19 September 2018. >>>> >>>> With my ISP hat on: We have no plans to ask our equipment vendors to= >>>> support this, or to configure it if it was available. We see this as= >>>> a completely unnecessary change. >>>> >>>> Not supported. >>> >>> Right, there probably isn=E2=80=99t much of a use case for an ISP. If= considering the PE - CE link, RFC7083 is probably the only thing akin to= this. Apart from public WIFI.=20 >> >> Correct. It's a solution for certain scenarios, and it's a market deci= sion >> which scenarios justify the cost. >=20 > Have you spoken to vendors or ISPs / enterprise who would either implem= ent or use this flag? I'll leave that to Bob, but there were enough positive comments during the WG adoption call that it seemed to me there was real interest. Brian From nobody Fri Sep 7 19:32:28 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4C130DD6; Fri, 7 Sep 2018 19:32:26 -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, 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 ITx-_ggD9IZr; Fri, 7 Sep 2018 19:32:24 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C171E1294D7; Fri, 7 Sep 2018 19:32:24 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id x197-v6so30717374oix.5; Fri, 07 Sep 2018 19:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azkv0VSTWXJIB2jEg6bVUmiUr3y6e9Yj4ZCG5AO2UYc=; b=gDuNr6bW3au4Ei1yv8TPr2Khpf+7MVEtuxw0pF5YuxiOp6gmYdk4IvTUFNU79Bz35Q Z8NFh03DsnYVa+t01nyNsju7dbct6ik+ie+8g08MzTzw1tPCuGZaPMIDQB9MecURQQyf EK/ysuX4f7KcXEh7QvE6Kq+attyc7wgyRepU/ECI4XrFeKklNFftnRHSNyqLOXOgzX2r cmfMGX8tCE8dOD30m0emUSwhZf+AAWzf+Sfep/k0Uc1Sqx5xcfSxLwykDhjN7S/tqro6 7tO4YiiT1lm5cPYlnAGpriB0IHD/ck7U5txFobgJTwzwixvaU4QyCaB21y+uAhmU8h9N PBOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azkv0VSTWXJIB2jEg6bVUmiUr3y6e9Yj4ZCG5AO2UYc=; b=iKgNiEpvi27uNUpnZ2NkLRWZ6g1sRMrbwN4dmnMmM9xyR/89WrFVtM4iAcbKhKw5YV cM2plQP5bDBM4ZFeDtxfS+ZeJUMV9CH8A2pUuHYDfLm+kaqNSijv/RE52gbz6h3TybSW r55SCLcR1gcMzunduSOttTdwqwfBsr9owUiA/fl+Vgmxk1p7HvW8cIexyrav/gjX1y9m 241C2ytnt/sA+SVUgGs2IgOFC9GsO16W4T18eh88e9fz/dL9RQOxqCkxEs5OgSL3XT4J sa3VwSHePPYMC0OiK0zcwQrMfRM6beuZWZHeatDptzSfgmOIigTh9lj9ZXbkV2qOBvIP afeQ== X-Gm-Message-State: APzg51BUwdR5fUDUuUI/02t8CGMgB1NjEbKdMPUUyuj1OHfYO3qCq6pQ OvMAPkreOAgRuF8CYaqDOid2NmY1MATzbe7pwUg= X-Google-Smtp-Source: ANB0VdYB8JKw1g5VuvDeqd+gv7wzc8BrCymBfc20Dxmd9cahq2c42tt9brX0exKhe/GKYTCGNM1/fP+xW/c8sE6D5ZI= X-Received: by 2002:aca:3606:: with SMTP id d6-v6mr11721256oia.327.1536373944000; Fri, 07 Sep 2018 19:32:24 -0700 (PDT) MIME-Version: 1.0 References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <9425a676-e966-94d2-4b64-fdf9cfae796b@foobar.org> In-Reply-To: <9425a676-e966-94d2-4b64-fdf9cfae796b@foobar.org> From: Mark Smith Date: Sat, 8 Sep 2018 12:31:57 +1000 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Nick Hilliard Cc: David Schinazi , 6man WG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 02:32:26 -0000 On Sat, 8 Sep 2018 at 03:38, Nick Hilliard wrote: > > Mark Smith wrote on 07/09/2018 05:17: > > On Fri, 7 Sep 2018 at 08:57, David Schinazi wrote: > >> The first motivation defined in this document is that it reduces > >> resources used by IPv4. But to do that it requires all client > >> devices to support it, which will take many years. This motivation > >> can be solved simply by having the router drop all IPv4 traffic. > > > > I don't think it solves the problem, it only mitigates other hosts > > receiving (typically link-layer broadcast DHCPv4) packets that > > they're not interested in. > > > > The sending hosts still spend effort forming and sending periodic > > packets, needlessly consuming their own energy doing so, as well as > > capacity on the link-layer media. > > fundamentally, this doesn't matter. Fundamentally it does matter. We don't have endless amounts of energy. > The only situation where it has any > relevance is on wifi networks. > There are 100s of millions of them. Nearly every home has one. > If there is no default route on the device, then the only traffic of > relevance is link-local traffic. Everything else will be dropped in the > o/s kernel because there won't be a route for it. > Packets are still being built and not sent == wasted effort. I'm wasting effort repeating these points ... > If the AP blocks ARP, then the device will never receive ARP broadcast > requests from other hosts, and will never receive ARP replies from the > ARP requests that it sends out. > > This will cause the underlying operating system to block all unicast > ipv4 traffic, because the OS will have no ARP mapping for the IP > addresses that the device is trying to reach. > > So immediately, the scope of the problem is reduced from trying to > handle lots of random ipv4 background chatter, to rate-limiting or > otherwise constraining outbound ARP requests and other broadcast traffic > for 169.254.0.0/16, or possibly 0.0.0.0/8 address space. > > Reminder: outbound broadcast traffic from the station to the > access-point is sent via unicast (i.e. not at wifi basic rate), and the > OS would easily be able to coalesce arp requests into bursts, instead of > issuing them piecemeal at a higher resource cost. > > However it's handled, the 6man wg should probably assume that the > handheld device manufacturers would be better able to assess battery > optimisation methodologies in this situation, because that's their day > job and they're pretty good at it. > > Nick From nobody Fri Sep 7 20:11:24 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10EA1294D7 for ; Fri, 7 Sep 2018 20:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 xx7FYvH1obkh for ; Fri, 7 Sep 2018 20:11:20 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AC8126DBF for ; Fri, 7 Sep 2018 20:11:20 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id j26-v6so7863429pfi.10 for ; Fri, 07 Sep 2018 20:11:20 -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=eL4o9+jf6ajf82L07WCTGmYrxJnZUwkHtFRsdS1xVXI=; b=TUMdmY4PzwIQLkLklgNa3RXohDJb9Vi/jkz1iRHB+xPB6sXqurGh6ggnD84XUDcCgG 3wEyrwHLeo15Y3x3spIWwFXR4fT+aHjbFsABohaQ2NzKBaGV84Ei7Y/0CpqAwqz30hWa etgQdOkXQ5nwzz1vxeNzK0ZD6rRDWB8FvymxrctlX5I8QrNWXB7silms4fbzTDdsMtrY W4H0eiEgnvqre+JXa2ZnC/YD78VhZXSRt4rkpBvb3sN59cRwTKaSGh1n1MmQiYTPLiRY rvyXegAedJK3L3oixal/fvICx+Z0eiot9nqi0upKj1rBDigdikozCmQs2m2AHB16jSwY RoFw== 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=eL4o9+jf6ajf82L07WCTGmYrxJnZUwkHtFRsdS1xVXI=; b=C0fWw6cm7yrqEP46b1JNwkB5tZObOB2N9L1IcbNodbtfeZx3y7Typ7pkk6sVh0DUHa LasuiHE2zhmky+teqbIS6vSoW4evgw6HHlO5jkgyyw7DthKV91mHTvjqbc+gIR2fUjui BMRtvO9eUAotL3Gqz2B02OXgKKCMQTizhzVFRROSPI/3R6g2PduaKfFycllAiQxO6RYk fHL6Xitxq52Rokte6imIfhlSvvrYKif9oODbwpY9BwoUbiXGJULbFvpjYX5CcGaxXebh 2A10eO85bp2sXqrmKpDa5K8MaF5RDiS2+bv62OgTM4FHNlLbzVRfoPO6YiJQMPxaaSD+ Sm2A== X-Gm-Message-State: APzg51DKr5Xahck3kGu1KTcBp7hTldsMaq+Bp0ATnA9z/wz0EVZxSgxR fVBdCKwSnYK9ZiLbHIKNJt0= X-Google-Smtp-Source: ANB0VdalN0Vbj5ptp9iWsqH64t1A1QtjTQxD+95Urs95yXWCA7+H1HQvRuI+ctUmOfkKYFpWG9hozA== X-Received: by 2002:a62:8913:: with SMTP id v19-v6mr11795905pfd.127.1536376280232; Fri, 07 Sep 2018 20:11:20 -0700 (PDT) Received: from [59.29.39.47] ([59.29.39.47]) by smtp.gmail.com with ESMTPSA id v20-v6sm17972450pfk.12.2018.09.07.20.11.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 20:11:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: New Version Notification for draft-dykim-6man-sid6-00.txt From: DY Kim In-Reply-To: Date: Sat, 8 Sep 2018 12:11:15 +0900 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153596076430.13392.12146482689462618493.idtracker@ietfa.amsl.com> <74D69781-F02E-4FA1-9FD4-E4597833EA8F@gmail.com> To: Brian Haberman , David Farmer X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 03:11:22 -0000 --- DY So, there are... - PMIP, 802.x + VLAN, VXLAN or MPLS with EVPN, TRILL, shorted path = bridging, LISP, =E2=80=A6. Would it do any fatal harm then to add another to this already long list = of alternative solutions? The arguments seem to me like saying=E2=80=A6 - There are lots of ways to get from place A to B, like trains, trams, = buses, gas automobiles, subways, flights, ships, bikes, horses, and so = forth, and why do you want to talk about electric cars? Moreover, all mentioned by David and Brian require infrastructures extra = to usual plain customer networks, while SID6 attempts to tackle the = problem without introducing such extras, except some updates to ND/DAD = which is one of basic building blocks of legacy IPv6 networking. Rather, I=E2=80=99d like to see comments like - if SID6 is technically viable or not, - if SID6 will break in certain situations. That is, I=E2=80=99d like to see SID6 assessed/criticized in its own = technical merits or on serious technical loopholes if any. > On 7 Sep 2018, at 20:13, Brian Haberman = wrote: >=20 > There are also mobility-related solutions like PMIP that eliminate the = host-based complexities of MIP while still allowing the host to maintain = the same IP address as it moves through the site/enterprise. >=20 > On 9/6/18 7:43 PM, David Farmer wrote: >> I'm not sure this is an IP layer problem, v4 or v6, some of it might = not be >> an IETF problem either. If you want hosts to have the same IP address = as it >> moves around a site this is possible today with things like 802.1x, = you put >> the host in the same VLAN whatever port or AP it attaches too. If you = are >> worried about stretching layer 2 everywhere in a site then look at >> abstractions like VXLAN or MPLS with EVPN as your control plane with = the >> right hardware can scale to extremely large sites. There are other = options >> too like TRILL, shorted path bridging, even LISP, etc... >> Basically, you end up with control plane that has every MAC address, = IPv4 >> /32 and IPv6 /128, probably every IPv4 and IPv6 prefix, and if you = are >> doing multicast you probably need (S,G) state too. The advantage of = this >> model it is IP version agnostic and ethernet protocol agnostic. = Further, >> this also allows the many simpleton assumptions applications make = today >> about the network to hold true. >> I'm not sure we need an IPv6-only solution in this problem space. From nobody Fri Sep 7 23:54:49 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6528212D7EA for ; Fri, 7 Sep 2018 23:54:47 -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 F7yjKRD_-Tr0 for ; Fri, 7 Sep 2018 23:54:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2DCC4126BED for ; Fri, 7 Sep 2018 23:54:45 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2EA401D0B3480 for ; Sat, 8 Sep 2018 07:54:41 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 8 Sep 2018 07:54:42 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Sat, 8 Sep 2018 14:54:31 +0800 From: Xiejingrong To: Fred Baker , Tom Herbert CC: IPv6 IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: RE: Modifiable Destination Options Thread-Topic: Modifiable Destination Options Thread-Index: AQHUDyzCtyJF2GU1mEayThLTBJ+Fi6R27zOAgABPLoCAbu1NQA== Date: Sat, 8 Sep 2018 06:54:31 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] 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.29 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 Sep 2018 06:54:47 -0000 SGkgYWxsLA0KDQpJIHRoaW5rIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIGlzIGRpZmZlcmVudCBm cm9tIEhCSCwgdGhvdWdoIHRoZXkgc2hhcmUgIlRoZSBzYW1lIE9wdGlvbiBUeXBlIG51bWJlcmlu ZyBzcGFjZSIsIGFuZCBoYXZlIHRoZSBzYW1lICJNb2RpZmlhYmxlIG9yIG5vdCIgYml0Lg0KDQpU aGUgZHJhZnQgPGRyYWZ0LXhpZS02bWFuLWJpZXItZW5jYXBzdWxhdGlvbj4gbWVhbnMgdG8gdXNl IHN1Y2ggYSAiTW9kaWZpYWJsZSBEZXN0aW5hdGlvbiBPcHRpb25zIiB3aXRoIGEgTXVsdGljYXN0 IEFkZHJlc3MgaW4gdGhlIElQdjYgREEuDQoNCk15IHVuZGVyc3RhbmRpbmcgYWJvdXQgdGhlICJj aGFuZ2UgZW4gcm91dGUgdG8gdGhlIHBhY2tldCdzIGZpbmFsIGRlc3RpbmF0aW9uIiBpcyB0aGF0 LA0KDQooMSkgRm9yIGEgTXVsdGljYXN0IEFkZHJlc3MgaW4gSVB2NiBEQSwgdGhlICJmaW5hbCBk ZXN0aW5hdGlvbiIgaXMgdGhlIElQdjYgbm9kZShzKSB3aG8gZG9uJ3QgZm9yd2FyZCB0aGUgcGFj a2V0IGFueW1vcmUuIEFuZCB0aHVzIHRoZSAiTW9kaWZpYWJsZSBEZXN0aW5hdGlvbiBPcHRpb25z IiBpcyByZXF1aXJlZC4NCg0KKDIpIElmIGlzIGFsc28gc3VpdGFibGUgZm9yIGNhc2VzIHdoZW4g VW5pY2FzdCBBZGRyZXNzIGluIElQdjYgREEgYW5kIERlc3RpbmF0aW9uIE9wdGlvbnMgaXMgYWhl YWQgb2YgUm91dGluZyBoZWFkZXIuDQoNClRvIHF1b3RlIHR3byBwYXJhZ3JhcGhzIG9mIFJGQzgy MDA6DQogICAgICBub3RlIDE6IGZvciBvcHRpb25zIHRvIGJlIHByb2Nlc3NlZCBieSB0aGUgZmly c3QgZGVzdGluYXRpb24gdGhhdA0KICAgICAgICAgICAgICBhcHBlYXJzIGluIHRoZSBJUHY2IERl c3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgcGx1cw0KICAgICAgICAgICAgICBzdWJzZXF1ZW50IGRl c3RpbmF0aW9ucyBsaXN0ZWQgaW4gdGhlIFJvdXRpbmcgaGVhZGVyLg0KDQogICBUaGUgdGhpcmQt aGlnaGVzdC1vcmRlciBiaXQgb2YgdGhlIE9wdGlvbiBUeXBlIHNwZWNpZmllcyB3aGV0aGVyIG9y DQogICBub3QgdGhlIE9wdGlvbiBEYXRhIG9mIHRoYXQgb3B0aW9uIGNhbiBjaGFuZ2UgZW4gcm91 dGUgdG8gdGhlDQogICBwYWNrZXQncyBmaW5hbCBkZXN0aW5hdGlvbi4NCg0KVGhhbmtzDQpKaW5n cm9uZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXB2NiBbbWFpbHRvOmlw djYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXINClNlbnQ6IFNhdHVy ZGF5LCBKdW5lIDMwLCAyMDE4IDU6MzggQU0NClRvOiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRs YW5kLmNvbT4NCkNjOiBJUHY2IElQdjYgTGlzdCA8aXB2NkBpZXRmLm9yZz47IOelnuaYjumBlOWT iSA8amlubWVpQHdpZGUuYWQuanA+DQpTdWJqZWN0OiBSZTogTW9kaWZpYWJsZSBEZXN0aW5hdGlv biBPcHRpb25zDQoNCg0KDQo+IE9uIEp1biAyOSwgMjAxOCwgYXQgOTo1NCBBTSwg56We5piO6YGU 5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3JvdGU6DQo+IA0KPiBBdCBUaHUsIDI4IEp1biAyMDE4 IDE1OjA5OjA1IC0wNzAwLA0KPiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3Jv dGU6DQo+IA0KPj4gSSBkb24ndCBzZWUgdGhhdCB0aGF0IHNldHRpbmcgdGhpcyBiaXQgZm9yIGEg RGVzdGluYXRpb24gT3B0aW9uIGlzIA0KPj4gcHJvaGliaXRlZC4gU28gd2hhdCBpcyB0aGUgZWZm ZWN0IG9mIHNldHRpbmcgYSBEZXN0aW5hdGlvbiBPcHRpb24gDQo+PiB0eXBlIHRvIGJlIG1vZGlm aWFibGUgZW4gcm91dGU/DQoNCkkgdGhvdWdodCB0aGUgcG9pbnQgb2YgYSBkZXN0aW5hdGlvbiBv cHRpb24gd2FzIHRoYXQgaXQgd2FzIG9ubHkgZXZhbHVhdGVkIGJ5IHRoZSBzeXN0ZW0gaWRlbnRp ZmllZCBieSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcz8gSWYgaXQncyBiZWluZyBtb2RpZmllZCBp biBmbGlnaHQsIHRoYXQgc291bmRzIGxpa2UgaXQgYmVsb25ncyBpbiB0aGUgSEJIIGhlYWRlci4N Cg0KPj4gSXMgc2V0dGluZyBhIERlc3RpbmF0aW9uIE9wdGlvbiB0byBiZSBjaGFuZ2VhYmxlIGVu IHJvdXRlIHZhbGlkPyBJIA0KPj4gc3VwcG9zZSB0aGUgdGV4dCB0aGF0IGV4dGVuc2lvbiBoZWFk ZXJzIGV4Y2VwdCBmb3IgSEJIIGNhbid0IGJlIA0KPj4gcHJvY2Vzc2VkIGluIHRyYW5zaXQgaW1w bGllcyB0aGF0IGEgRE8gY2FuIG5ldmVyIGJlIG1vZGlmaWVkIGVuIHJvdXRlIA0KPj4gYW5kIHRy dW1wcyB0aGUgRE8gY2hhbmdlYWJsZSBiaXQsIGJ1dCBhcmUgdGhlcmUgY2FzZSB3aGVyZSBpdCBj b3VsZCANCj4+IGJlIGxlZ2l0aW1hdGVseSBiZSBjaGFuZ2VkLCBtYXliZSB0aGUgZW5kIGhvc3Qg aXMgYWxsb3dlZCB0byBtb2RpZnkgDQo+PiB0aGUgb3B0aW9uIGJlZm9yZSBkZWxpdmVyeSB0byB0 aGUgYXBwbGljYXRpb24/DQo+IA0KPiBXaGVuIHVzZWQgd2l0aCBhIHJvdXRpbmcgaGVhZGVyPw0K PiANCj4gLS0NCj4gSklOTUVJLCBUYXR1eWENCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Sat Sep 8 00:00:18 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180C512D7EA for ; Sat, 8 Sep 2018 00:00:17 -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 6d8Zf1fuXs1O for ; Sat, 8 Sep 2018 00:00:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 49399126BED for <6man@ietf.org>; Sat, 8 Sep 2018 00:00:14 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A94216524C54C for <6man@ietf.org>; Sat, 8 Sep 2018 08:00:10 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 8 Sep 2018 08:00:05 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Sat, 8 Sep 2018 14:59:54 +0800 From: Xiejingrong To: "6man@ietf.org" <6man@ietf.org> Subject: FW: New Version Notification for draft-xie-6man-bier-encapsulation-02.txt Thread-Topic: New Version Notification for draft-xie-6man-bier-encapsulation-02.txt Thread-Index: AQHURbS4XxRNHWks+kOBfh+z4fs1H6Tl90yw Date: Sat, 8 Sep 2018 06:59:52 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AE8884@nkgeml514-mbs.china.huawei.com> References: <153621951817.11624.6499617694488781790.idtracker@ietfa.amsl.com> In-Reply-To: <153621951817.11624.6499617694488781790.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] 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.29 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 Sep 2018 07:00:17 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IFNlcHRlbWJlciAwNiwgMjAxOCAzOjM5IFBNDQpUbzogWGlheWFuZyAoWW9sYW5kYSkgPHlvbGFu ZGEueGlhQGh1YXdlaS5jb20+OyBYaWVqaW5ncm9uZyA8eGllamluZ3JvbmdAaHVhd2VpLmNvbT47 IE1pa2UgTWNCcmlkZSA8bW1jYnJpZGU3QGdtYWlsLmNvbT47IExpYW5nIEdlbmcgPGdlbmdsaWFu Z0BjaGluYW1vYmlsZS5jb20+OyBZYW5nYW5nIChSb3V0aW5nIERlc2lnbikgPHlhbmdhbmdAaHVh d2VpLmNvbT47IExlaSBXYW5nIDx3YW5nbGVpeWp5QGNoaW5hbW9iaWxlLmNvbT4NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteGllLTZtYW4tYmllci1lbmNhcHN1 bGF0aW9uLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14aWUtNm1hbi1i aWVyLWVuY2Fwc3VsYXRpb24tMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEppbmdyb25nIFhpZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6CQlkcmFmdC14aWUtNm1hbi1iaWVyLWVuY2Fwc3VsYXRpb24NClJldmlzaW9uOgkwMg0KVGl0 bGU6CQlFbmNhcHN1bGF0aW9uIGZvciBCSUVSIGluIE5vbi1NUExTIElQdjYgTmV0d29ya3MNCkRv Y3VtZW50IGRhdGU6CTIwMTgtMDktMDYNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczoJCTExDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXhpZS02bWFuLWJpZXItZW5jYXBzdWxhdGlvbi0wMi50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWUtNm1hbi1i aWVyLWVuY2Fwc3VsYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXhpZS02bWFuLWJpZXItZW5jYXBzdWxhdGlvbi0wMg0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLTZtYW4t Ymllci1lbmNhcHN1bGF0aW9uDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LXhpZS02bWFuLWJpZXItZW5jYXBzdWxhdGlvbi0wMg0KDQpBYnN0 cmFjdDoNCiAgIEJpdCBJbmRleCBFeHBsaWNpdCBSZXBsaWNhdGlvbiAoQklFUikgaW50cm9kdWNl cyBhIG5ldyBtdWx0aWNhc3QtDQogICBzcGVjaWZpYyBCSUVSIEhlYWRlci4gIEN1cnJlbnRseSBC SUVSIGhhcyB0d28gdHlwZXMgb2YgZW5jYXBzdWxhdGlvbg0KICAgZm9ybWF0czogb25lIGlzIE1Q TFMgZW5jYXBzdWxhdGlvbiwgdGhlIG90aGVyIGlzIEV0aGVybmV0DQogICBlbmNhcHN1bGF0aW9u LiAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIEJJRVIgSVB2NiBlbmNhcHN1bGF0aW9uIGZvcg0K ICAgTm9uLU1QTFMgSVB2NiBOZXR3b3JrcyB1c2luZyBhbiBJUHY2IERlc3RpbmF0aW9uIE9wdGlv biBleHRlbnNpb24NCiAgIGhlYWRlci4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Sat Sep 8 01:49:57 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B641286D9 for ; Sat, 8 Sep 2018 01: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, 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 tmJoB1plM4F3 for ; Sat, 8 Sep 2018 01:49:53 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0B2C1126BED for ; Sat, 8 Sep 2018 01:49:53 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AA6E6F1A5C170 for ; Sat, 8 Sep 2018 09:49:48 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 8 Sep 2018 09:49:50 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Sat, 8 Sep 2018 16:49:37 +0800 From: Xiejingrong To: Tom Herbert , 6man Subject: RE: New Version Notification for draft-herbert-ipv6-update-dest-ops-00.txt Thread-Topic: New Version Notification for draft-herbert-ipv6-update-dest-ops-00.txt Thread-Index: AQHUNmCWYo/7uyhvoUC9+9dOS+ujkqTmMN+A Date: Sat, 8 Sep 2018 08:49:36 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AE88B0@nkgeml514-mbs.china.huawei.com> References: <153453353899.18035.16890044816111327001.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 08:49:56 -0000 Hi Tom,=20 For the below description: If a Destination Option is marked to be changeable (the third-highest order bit of the option type is set) and is in a Destination Options header that follows a Routing header, or there is no Routing header present, then the Option Data cannot be changed en route. There are no nodes in the path that are permitted to change the Option Data. I think it did not consider the Destination Option when IPv6 DA being Multi= cast Address. Multicast routing is also a kind of routing and one can find many 'multicas= t routing' RFCs. And obviously, Destination Option can be used with Multicast Address as IPv= 6 DA.=20 To quote RFC8200: The Option Type identifiers are internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. Thanks Jingrong -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Saturday, August 18, 2018 3:29 AM To: 6man Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-dest-o= ps-00.txt Hello, I wrote up a short draft to try to clarify the requirements of processing D= estination Options that are before a Routing header. This work was motivate= d by some of the discussions around SRv6. It also would one of the argument= s that TLVs in SRv6 are needed because Destination Options can't be ignored= at SRv6 destinations. The draft also clarifies what it means for a Destina= tion Option to be changeable en route. Thanks, Tom ---------- Forwarded message ---------- From: Date: Fri, Aug 17, 2018 at 12:18 PM Subject: New Version Notification for draft-herbert-ipv6-update-dest-ops-00= .txt To: Tom Herbert A new version of I-D, draft-herbert-ipv6-update-dest-ops-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repos= itory. Name: draft-herbert-ipv6-update-dest-ops Revision: 00 Title: Updates to Destination Options Processing Document date: 2018-08-17 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-dest-ops-00.= txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-update-dest-ops/ Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-dest-ops Abstract: This document updates the requirements for processing Destination Options in IPv6 in two ways. First, the requirement that all intermediate destinations in a Routing header must process options in a Destination header appearing before the Routing header is relaxed. Secondly, the processing of a Destination Option marked as changeable is clarified. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Sat Sep 8 05:44:27 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9AF128CFD for ; Sat, 8 Sep 2018 05:44:26 -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 i9kDI3SpFuC7 for ; Sat, 8 Sep 2018 05:44: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 358F2128CF2 for ; Sat, 8 Sep 2018 05:44:22 -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 w88BiGK7005961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2018 12:44: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 Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Brian E Carpenter Cc: ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Nick Hilliard Message-ID: <9ce71e9b-b391-86b4-1ed0-9a1d87cbd658@foobar.org> Date: Sat, 8 Sep 2018 13:44:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: 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.29 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 Sep 2018 12:44:26 -0000 Brian E Carpenter wrote on 08/09/2018 00:29: >> There's been a substantial number of serious technical >> concerns posted in this WG about this draft, both in terms of the >> problem statement and the proposed solution. Most of these remain fully >> unaddressed in any reasonable way in terms of either discussion on the >> mailing list or updates to the document. > > I think we've made it clear (on the list and in the draft) that we > are proposing something in addition to switch-based solutions, that > (as I just wrote to Bert) can only be achieved by sending a signal > to the hosts. That said, I really don't know which technical concerns > haven't been addressed. Can you be explicit, because we considered > all previous comments when producing the current draft? I've already done this, repeatedly and at some length, and you have either agreed with, ignored or inadequately addressed the points that were brought up. If you compare versions -00 and -02 of the draft, the changes are minimal and for the most part don't substantially address the technical comments that have been made either by me or anyone else, going right back to before WG adoption when the draft was still draft-hinden. >> I can see why the ipv6only flag might seem attractive from an >> ideological point of view, but from the point of view of production >> engineering, the problem statement does not withstand scrutiny. > > o Such traffic may drain battery power on wireless hosts that have > no interest in link-local IPv4 traffic. [RFC7772] indicates how > this risk might be quantified. > > o Similarly, hosts may waste battery power on futile attempts to > access IPv4 services. > > Those are the problem statements concerning hosts. What's wrong > with them? For starters, these two particular points are in fact the same point fleshed out to make it looks it's two points. One concerns traffic received by battery-powered wifi hosts; the other concerns traffic sent by battery-powered wifi hosts. This point should be coalesced this into a single point because it's the same underlying issue. As I've repeatedly said, this particular point has some limited legitimacy, but it is strongly bounded by the fact that it is of most relevance on poorly designed large networks and in any case there are far better ways of dealing with it than draft-ietf-6man-ipv6only-flag could ever hope to achieve. Secondly, I wasn't just talking about problem statements concerning hosts. I was talking about all the points because they're all weak. If you number them in order, 1 to 5: 1. is a general L2 design issue, i.e not relevant to this draft. The last time this was relevant was the 1990s, when we learned that gigantic l2 domains was a terminally broken approach to IP networking. This point needs to be deleted. 2. is a red herring and needs to be removed. In my email of Aug 16, I had originally fleshed out why switches don't store ipv4 hardware state in general, but deleted the text before sending because I had thought it should have been obvious enough. But in the interests of completeness, I will reply later on that part of the thread because you are largely incorrect on a point of fact. 3. / 4. are the same point dressed up to look like two different points and are of limited scope in terms of overall relevance. I.e. the relevant is only to battery powered wifi devices and is of no particular relevance to any other type of host on any other network medium. 5. this point needs to be removed entirely. If link security is an issue, it is something that needs to be policed rather than depending on advisory flags which may not even be implemented by the hosts on the network. Leaving this point in the document displays a disconcerting misunderstanding of the fundamentals of network security. > (I agree that the other problems listed can be mitigated > by switches. We could reorganise the text to make this clearer.) >> Even if >> it did, the issues identified in the draft could be handled more >> comprehensively and more simply in several other ways. > > How else could we tell hosts to ignore IPv4 completely? You need to start out by not putting the cart before the horse, i.e. sort out your problem statement. Right now, it boils down to: 1. we allege that a flag of this form could be useful for power management on battery-powered wifi-enabled devices on unmanaged wifi networks Nick From nobody Sat Sep 8 11:25:41 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62044130E46 for ; Sat, 8 Sep 2018 11:25:26 -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 Jeg47Y8p3Ydz for ; Sat, 8 Sep 2018 11:25: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 5CF1C130E4C for ; Sat, 8 Sep 2018 11:25: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 w88HPGdX046309 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2018 18:25:17 +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 Subject: Re: Fwd: New Version Notification for draft-ietf-6man-ipv6only-flag-02.txt To: Brian E Carpenter Cc: ipv6@ietf.org References: <153428037054.27172.4026363156538220783.idtracker@ietfa.amsl.com> <1085472B-7D0C-454F-9017-C3CDE7B52123@gmail.com> <0e26b40d-c457-f329-8947-a9e50bce6fa2@foobar.org> <09d90235-99e4-c663-c7be-68fd0d9b6e03@gmail.com> From: Nick Hilliard Message-ID: Date: Sat, 8 Sep 2018 19:25:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: <09d90235-99e4-c663-c7be-68fd0d9b6e03@gmail.com> 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.29 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 Sep 2018 18:25:39 -0000 [returning to this point due to concerns raised during WGLC] Brian E Carpenter wrote on 16/08/2018 23:42: > On 2018-08-17 10:05, Nick Hilliard wrote: >>> o In particular, this may overload switches in multi-segment >>> wireless networks because it will create IPv4 state for every dual >>> stack host. >> >> I'm not clear what you mean here. Switches don't carry ipv4 state, and >> creating ipv4 state in dual stack hosts is of negligible overhead (e.g. >> sockets, etc). > > 1) Switches may sometimes do things like ARP snooping and caching. > 2) Any overhead is significant in a battery-limited device. 2) is continued repetition of the battery power consumption issue for wifi networks, which is already dealt with separately in your draft. This is not relevant to switch forwarding planes. Regarding your assertion about switches becoming overloaded due to carrying ipv4 traffic, layer 2 switches do not carry ipv4 state in any meaningful sense. It is technically misleading, bordering on flat-out incorrect, to suggest otherwise. And even if it were correct in some sense, it wouldn't be relevant because on a network link with ipv4 services disabled, you wouldn't be doing any ipv4 snooping anyway, just ethertype filtering. It is true that some switches perform certain types of frame snooping associated with ipv4, including DHCP snooping and dynamic arp inspection. This is handled based on explicit configuration by the switch operator, and I have never seen either option enabled by default. The mechanisms varies from chipset to chipset, but generally involve a stateless process on the forwarding plane whereby packets of interest are punted up to the control plane via a qos policer so that the control plane CPU is not trashed. The control plane will then do some processing, e.g. comparing against a static arp binding table in the case of dynamic arp inspection, or packet dissection in the case of DHCP. "State", to the extent that it exists, refers solely to tiny memory structures held on the control plane of the switch. In the case of DHCP snooping, these structures are informational; in the case of ARP snooping, they are generally pre-configured on the control plane, i.e. necessarily limited by the amount of configuration entered on the switch. I.e. the configuration mechanism will prevent you from entering too many entries into that state table. You will run out of configuration token space long before you run into RAM limits on the control plane. Based on how the switch is configured, the control plane will then make a decision whether or not to forward the frame back down to the forwarding plane for transmission to the egress port. There is no state maintained in the place where it matters, namely on the forwarding plane, i.e. where hardware resource limits are a very real issue and can present problems which can be difficult to handle. The only area where this can cause issues is where you have excessive frame punting, causing high switch CPU usage on the control plane. This is not going to be a problem in a situation where the operator wants to disable ipv4, as that operator will almost certainly not have enabled ARP inspection or DHCP snooping because, well, that would be dumb. Even if the operator hasn't done this - which should be treated as a network misconfiguration - all reasonable quality managed switches have options for rate limiting punted packets, and these rate limiters are active by default. Even then, the ARP inspection table should have been configured to be of zero size for that network segment, as ipv4 should be disabled, no? And DHCP snooping creates no state to start with. You need to remove this point completely from the draft. Nick From nobody Sun Sep 9 05:30:44 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA0130DC6 for ; Sun, 9 Sep 2018 05:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qne9JzabjCDg for ; Sun, 9 Sep 2018 05:30:38 -0700 (PDT) Received: from caict.ac.cn (unknown [111.204.176.144]) by ietfa.amsl.com (Postfix) with ESMTP id 056A41277D2 for ; Sun, 9 Sep 2018 05:30:36 -0700 (PDT) Received: from userTHINK (unknown [10.2.97.11]) by app2 (Coremail) with SMTP id FxADCgDXLixLEpVbv+gQAA--.2450S2; Sun, 09 Sep 2018 20:30:03 +0800 (CST) From: "Liu,Shu@CATR" To: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> In-Reply-To: Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Date: Sun, 9 Sep 2018 20:30:03 +0800 Message-ID: <000601d44838$d5a696a0$80f3c3e0$@ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHURT+5fmxjNPJnAkOJ7cXg3yn1RqTkUw2AgAAOlwCAAOf7AIAAMHUAgAJru5A= Content-Language: zh-cn X-CM-TRANSID: FxADCgDXLixLEpVbv+gQAA--.2450S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tw4xWFW7Zr4fWw1fuF45KFg_yoW8ZFWrpF y3GF47K3y8JF15Ar1ktr18Cr4Yy3yjqryUXrn5tr1rXFyqkr1qqr12ya48uFyUtr97Wr1Y yrWjg34UXryrJrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyqb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x0EwIxGrwCF x2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14 v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY 67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2 IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AK xVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUcVWlDUUUU X-CM-SenderInfo: polx2x3x6ftx1fwotugofq/ Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 12:30:42 -0000 Hi all I don't like the idea ipv6-only network, when you think about the upnp = and auto-ip, the ipv4 still works in a LAN environment without dhcpv4 = server. andrew -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Tim Chown Sent: Saturday, September 8, 2018 7:27 AM To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 On 7 Sep 2018, at 21:33, Brian E Carpenter = wrote: >=20 > On 2018-09-07 18:43, Ole Troan wrote: >>=20 >>=20 >> On 7 Sep 2018, at 07:51, sthaug@nethelp.no wrote: >>=20 >>>> Title : IPv6 Router Advertisement IPv6-Only Flag >>>> Authors : R. Hinden, B. Carpenter >>>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>>> Pages : 11 >>>> Date : 2018-08-14 >>>>=20 >>>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>>>=20 >>>> as a Proposed Standard. Substantive comments and statements of=20 >>>> support for publishing this document should be directed to the = mailing list. >>>> Editorial suggestions can be sent to the author. This last call=20 >>>> will end on 19 September 2018. >>>=20 >>> With my ISP hat on: We have no plans to ask our equipment vendors to = >>> support this, or to configure it if it was available. We see this as = >>> a completely unnecessary change. >>>=20 >>> Not supported. >>=20 >> Right, there probably isn=E2=80=99t much of a use case for an ISP. If = considering the PE - CE link, RFC7083 is probably the only thing akin to = this. Apart from public WIFI.=20 >=20 > Correct. It's a solution for certain scenarios, and it's a market=20 > decision which scenarios justify the cost. Have you spoken to vendors or ISPs / enterprise who would either = implement or use this flag? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Sun Sep 9 10:44:19 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB516130DCA for ; Sun, 9 Sep 2018 10:44:17 -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 achnvyFWCV_e for ; Sun, 9 Sep 2018 10:44:15 -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 CBDE91200D7 for ; Sun, 9 Sep 2018 10:44:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3656420090; Sun, 9 Sep 2018 14:03:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 54A02344A; Sun, 9 Sep 2018 13:44:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 508753446; Sun, 9 Sep 2018 13:44:14 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: David Schinazi , ipv6@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 In-Reply-To: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 17:44:18 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Hi Brian, >> >> The updates to the draft do not address my comments. > They are intended to explain how this proposal fits in with the > alternative (layer 2 solutions). The draft doesn't suggest that it's an > exclusive solution; it's entirely complementary to layer 2 solutions, > and it *adds* an explicit signal to dual stack nodes telling them that > they SHOULD NOT send IPv4 packets. Of course, it's an engineering > choice whether that is a win, but like all IETF standards, this would > be for the market to decide. A home (or coffee shop gateway) that saw the IPv6-only flag on it's upstream link might well take that as a clue that it ought to implement the layer-2 solutions on *its* ethernet/wifi. Would I want to enable this functionality by default on a device that was intended for FutureShop? No. Would I want it this functionality enabled on devices intended for coffee shops that I support, whose ISPs are transitioning to IPv6 and IPv6-only uplinks? Yes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluVW+4ACgkQgItw+93Q 3WXdPAf/TXqPJW8W2VGEfc70FDrcQSHNqugJgY4/i05B93wiC5eMFDbtiC42eOyR 4NqNZfiaIpwKmUdriwc2juZOMlrFKLpo1Ih3exVR/4n3IBDmPYgOM8a+Jx69Fj14 0yhLcePuftwwDcFnWaI7S8k3y7+BOnP8r6QbOpa46guqiHBM7IwNL9OWTXEfI0PT uwJoFpbNhgXA1BCLp4xE6CD9wye+OgAnDQWFgu93yVWeB/9FT+B192hiDLB9p3x3 CvnouULSGvNbkKS8t5F+bb+TW65A7eAwLJnC9jpyM8P5eTeosy8FKVYgYoHarlbD saGfMmp/euegrvyMdw9l6uKiyV7AWw== =ypUr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 9 12:02:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504F2130DE4 for ; Sun, 9 Sep 2018 12:02: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] 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 CTgPDSYp_BhN for ; Sun, 9 Sep 2018 12:01:59 -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 64628130DCD for ; Sun, 9 Sep 2018 12:01:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 61FA91BC37 for ; Sun, 9 Sep 2018 19:01:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Simon Hobson In-Reply-To: <000601d44838$d5a696a0$80f3c3e0$@ac.cn> Date: Sun, 9 Sep 2018 20:01:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 19:02:01 -0000 Liu,Shu@CATR wrote: > I don't like the idea ipv6-only network, when you think about the upnp = and auto-ip, the ipv4 still works in a LAN environment without dhcpv4 = server. And (rhetorical question) do the equivalents not work in IPv6 ? The thing is, if you have completely transitioned to IPv6, then the same = things will work - auto IP via SLAAC and/or use of link local = address(es), device/service discovery via mDNS, and so on. So "turning = off" IPv4 by setting this flag wouldn't be noticed by users - the = printer would still "just work", the NAS would "just be there", and so = on but using IPv6 instead of IPv4. From nobody Sun Sep 9 12:22:25 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73440130DDE for ; Sun, 9 Sep 2018 12:22:22 -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 oNX5AOp5Bco1 for ; Sun, 9 Sep 2018 12:22: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 D7BD9126F72 for ; Sun, 9 Sep 2018 12:22: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 w89JMJn3008846; Sun, 9 Sep 2018 12:22:19 -0700 Received: from XCH15-01-12.nw.nos.boeing.com (xch15-01-12.nw.nos.boeing.com [137.136.239.188]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w89JM8V7008715 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 9 Sep 2018 12:22:08 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-12.nw.nos.boeing.com (137.136.239.188) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 9 Sep 2018 12:22:08 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Sun, 9 Sep 2018 12:22:07 -0700 From: "Manfredi (US), Albert E" To: Michael Richardson , Brian E Carpenter CC: "ipv6@ietf.org" Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHUSGS55Ieh5nHO1E6PHkpFno+usqToTpfA Date: Sun, 9 Sep 2018 19:22:07 +0000 Message-ID: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <29735.1536515054@localhost> In-Reply-To: <29735.1536515054@localhost> 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] x-tm-snts-smtp: ADDF1053D629C10B5EC76A28E1100A40A3FCEC1ABBEF1A5A7DF4A5EE33F838232000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 19:22:23 -0000 -----Original Message----- From: ipv6 On Behalf Of Michael Richardson Brian E Carpenter wrote: > They are intended to explain how this proposal fits in with the > alternative (layer 2 solutions). The draft doesn't suggest that it's = an > exclusive solution; it's entirely complementary to layer 2 solutions, > and it *adds* an explicit signal to dual stack nodes telling them tha= t > they SHOULD NOT send IPv4 packets. Of course, it's an engineering > choice whether that is a win, but like all IETF standards, this would > be for the market to decide. > A home (or coffee shop gateway) that saw the IPv6-only flag on it's > upstream link might well take that as a clue that it ought to implement > the layer-2 solutions on *its* ethernet/wifi. I suppose so, although Brian's point is that the flag is primarily intended= for hosts in the local subnet, e.g. to not waste energy trying to acquire = an IPv4 address. Although here's another thought, concerning a layer 2-only solution, which = might achieve much the same effect. Given that this flag's primary user app= ears to be hosts, hosts need to be updated too. So, forgetting about a new = layer 3 flag, why not program hosts to only very infrequently attempt anyth= ing at IPv4, when ARP or DHCPv4 fail (as a result of all 1s broadcast and I= Pv4 Ethertype failing to work with the local routers)? As long as hosts nee= d to be changed anyway, this seems as easy as any change to read and react = to a new flag at layer 3? And too, we can fine tune how this layer 2 solution works. The layer 2 bloc= king of IPv4 (and ARP) can occur only on the actual router interface, let's= say in that home or coffee shop net, or also on WiFi and Ethernet ports in= side that home or coffee shop. So in principle, in cases where the gateway = itself won't handle IPv4, you could still run IPv4 apps inside that venue. Bert From nobody Sun Sep 9 13:49:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA53130DFB for ; Sun, 9 Sep 2018 13:49: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 C9my-Rr1bwvF for ; Sun, 9 Sep 2018 13:49:23 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26B1130DF9 for ; Sun, 9 Sep 2018 13:49:23 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id x17-v6so9413393pfh.5 for ; Sun, 09 Sep 2018 13:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Hb+5iR1LpOV5BOLnkinfyT6jNBCJhPr3lHurVm+SX2s=; b=FWr41NybIDnFk36tt+PCZdJkhHqjuDTG07mllpKsJeP5Fnida+vjtFa6X5kOmt37sw INsAFhEvCvVZopcP+tsYMgEttcFhKTc9zPDSZ6wKJGoH/fnAwGSEbQ6O7Fv+0pDtQJxk lJN+mk9JFWExvL1g9pfHeIWbc2pQoCkyzpKHMUU0BsWKR1Ppa1VUPnHS4CpuBA4qpA2d SXt7/yxxJrZ1vQqe5mZ+nmY8ExYr9vd0zOJto/g5G2YCjBYb7GPG2tIyTZ2RCS3HQM67 3eVn5o0m2vqKUxyxp6dwTyjs36cUQat+YPt4bbw0l6Df4EODtxnM5W5dJFcaIbE+b75z mL8g== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Hb+5iR1LpOV5BOLnkinfyT6jNBCJhPr3lHurVm+SX2s=; b=TRZLXRhRhgBcdVn0ie0WDvaGdRJMSjmN1DbuUPNbWlUCpf3hT/8IArOt0oDkknjILn 5SUyT+mq5AO8ij0aj3xmWp9FoRGM0iwOa2mEZE8bozlNBQVGlQvUHWybiV7s9bybvy4m aso9lYtUwbFQQrsm50eVmVfiYkrMol4/tMjBT4vABWV1it40m3Hzaqo+/IgwFChP183q TfQd8IJ46GCp8D26awFsquZFvgOHhQWdLJ4QG3q7PuK1hbt+zvGpVGuN1HWxir8oy6X2 nEYdwrH51hkI4JlhhV84Mp8++3uoPeYydBBy5/eSXwWl6f2HjMPwBL6EJ5jAmzEtX/B7 3ASQ== X-Gm-Message-State: APzg51AknBjrim/ermAyEdwjJUPYNIft3Tb4AxzyWNDkJNWg1P1gpJF/ XqZLjdXHl2LnltMGU/70CrvR/WC3 X-Google-Smtp-Source: ANB0Vdbd6YcLJzF8kn2hvYVcDAIQ20n+a0suatXow8CRm3xw0VSdPktxg+Y3mtKomt5VJymD4NHJuw== X-Received: by 2002:a63:f002:: with SMTP id k2-v6mr19052848pgh.8.1536526162818; Sun, 09 Sep 2018 13:49:22 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id w5-v6sm16995351pfn.44.2018.09.09.13.49.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Sep 2018 13:49:21 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: "Manfredi (US), Albert E" , Michael Richardson Cc: "ipv6@ietf.org" References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <29735.1536515054@localhost> From: Brian E Carpenter Message-ID: <814d8220-531e-613e-e5f6-10aa863885f1@gmail.com> Date: Mon, 10 Sep 2018 08:49:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 20:49:27 -0000 On 2018-09-10 07:22, Manfredi (US), Albert E wrote: > -----Original Message----- > From: ipv6 On Behalf Of Michael Richardson > > Brian E Carpenter wrote: > > They are intended to explain how this proposal fits in with the > > alternative (layer 2 solutions). The draft doesn't suggest that it's an > > exclusive solution; it's entirely complementary to layer 2 solutions, > > and it *adds* an explicit signal to dual stack nodes telling them that > > they SHOULD NOT send IPv4 packets. Of course, it's an engineering > > choice whether that is a win, but like all IETF standards, this would > > be for the market to decide. > >> A home (or coffee shop gateway) that saw the IPv6-only flag on it's >> upstream link might well take that as a clue that it ought to implement >> the layer-2 solutions on *its* ethernet/wifi. > > I suppose so, although Brian's point is that the flag is primarily intended for hosts in the local subnet, e.g. to not waste energy trying to acquire an IPv4 address. > > Although here's another thought, concerning a layer 2-only solution, which might achieve much the same effect. Given that this flag's primary user appears to be hosts, hosts need to be updated too. So, forgetting about a new layer 3 flag, why not program hosts to only very infrequently attempt anything at IPv4, when ARP or DHCPv4 fail (as a result of all 1s broadcast and IPv4 Ethertype failing to work with the local routers)? Yes, that's a good idea - basically a change to the backoff timers. My thought was that the v6only flag could trigger such behaviour. Whether we could persuade all IPv4 stack developers to make such an update without the flag to act as a signal is another question. > As long as hosts need to be changed anyway, this seems as easy as any change to read and react to a new flag at layer 3? Well, it introduces state anyway. Instead of state saying "I have seen the IPv6-only flag from every router" it would be state saying "I have seen no ARP or DHCP response, so my backoff timer is now T". > And too, we can fine tune how this layer 2 solution works. The layer 2 blocking of IPv4 (and ARP) can occur only on the actual router interface, let's say in that home or coffee shop net, or also on WiFi and Ethernet ports inside that home or coffee shop. So in principle, in cases where the gateway itself won't handle IPv4, you could still run IPv4 apps inside that venue. Using IPv4 link-local addressing, yes, as briefly mentioned in the draft. But it seems to me that filtering on the Ethertype would block even that. Brian From nobody Sun Sep 9 14:23:44 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBDC130DFD for ; Sun, 9 Sep 2018 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 4a0FHFI-eelp for ; Sun, 9 Sep 2018 14:23:39 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04DA130DF9 for ; Sun, 9 Sep 2018 14:23:39 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id v198-v6so18829991oif.9 for ; Sun, 09 Sep 2018 14:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XMUmaAN74Chw5foECitFLyVzFAcOqsq6ZLAOLB4+gNg=; b=bO5QIxmj/mmOaJdPT/1B22y3HJaYG/zO9H8Q97UC0CFGzDf/7bbVhuWWhdauvCHgUm GkfPRihgimlKOB3SuRCLVkT7xrJexUeflfgaciGaDdG8xCEaFUxP7xDX4CxBtavJCK09 TNje/7SbPEeZ73vexubcr41U+zXZ1CGhgVpsJvU0ggF8VRkd7tchlNdl3XVDN92iNRuL gv1YZKSlb/+oBQE2YGyMAq80V60Boog1kQq3vQXw3EDImdeDpy6pKLC4YslAeLLgDoIE 5NlTs1UHzh9+Ko1bj0SCtZ1edZWIcqUT4BP7RWFd6094/5LD3pJj0jN7cQpauV7lOtx+ 6k5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XMUmaAN74Chw5foECitFLyVzFAcOqsq6ZLAOLB4+gNg=; b=Fob9CXcVZwiDJa2KS3I6ZhCJp4HEnyl+WRzGfK8DRAJ16UMRk4PEAjyDRSLQe+39kb ubOdKeOb9bYMZbaV3KuJCje1tJ6Ymqr4RUjFs3jVqVdFu5IIUigaPxcCF0IKJv5wkHSW M4FhyX6Z1xyj7Ohqqfoiek4k9MQUdyLti82Ib3zQQr9N4hHLtdUUWFuAeaZ/jbpESQjU yY6jcAybg/mA2o4k6IIrr1X1wlX8KN7QMhji6eoLdDMIoiphmHSDU1w+SWO0k/LTSMnu NNPNWA6+ecmTUd3IsSnYrIYrTDPwudqlyuvVG3eJnCRenRn+S8Z8EUvoR42Wu5Va2UjT NncA== X-Gm-Message-State: APzg51CXdDYELdj4zFp+0opLSDPwQDpLlPM6ItN9ZOOwwvYQmPRPn/Ag 3Y/8vtmIC5ZV+JVon1kLDSB4YPkCPfUFtWiwqF4= X-Google-Smtp-Source: ANB0VdZitEch7nYFfmbf/HjzlCfD+BTX0/+AATsH9j8S/VatzZvTOyDCu43ECcF8wNf8U6mQFf1LA6nMTOLS9H5wx2A= X-Received: by 2002:aca:e748:: with SMTP id e69-v6mr18939576oih.263.1536528218855; Sun, 09 Sep 2018 14:23:38 -0700 (PDT) MIME-Version: 1.0 References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <29735.1536515054@localhost> <814d8220-531e-613e-e5f6-10aa863885f1@gmail.com> In-Reply-To: <814d8220-531e-613e-e5f6-10aa863885f1@gmail.com> From: Mark Smith Date: Mon, 10 Sep 2018 07:23:12 +1000 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Brian E Carpenter Cc: "Manfredi, Albert E" , Michael Richardson , 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.29 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 Sep 2018 21:23:41 -0000 On Mon, 10 Sep 2018 at 06:50, Brian E Carpenter wrote: > > On 2018-09-10 07:22, Manfredi (US), Albert E wrote: > > -----Original Message----- > > From: ipv6 On Behalf Of Michael Richardson > > > > Brian E Carpenter wrote: > > > They are intended to explain how this proposal fits in with the > > > alternative (layer 2 solutions). The draft doesn't suggest that i= t's an > > > exclusive solution; it's entirely complementary to layer 2 soluti= ons, > > > and it *adds* an explicit signal to dual stack nodes telling them= that > > > they SHOULD NOT send IPv4 packets. Of course, it's an engineering > > > choice whether that is a win, but like all IETF standards, this w= ould > > > be for the market to decide. > > > >> A home (or coffee shop gateway) that saw the IPv6-only flag on it's > >> upstream link might well take that as a clue that it ought to implemen= t > >> the layer-2 solutions on *its* ethernet/wifi. > > > > I suppose so, although Brian's point is that the flag is primarily inte= nded for hosts in the local subnet, e.g. to not waste energy trying to acqu= ire an IPv4 address. > > > > Although here's another thought, concerning a layer 2-only solution, wh= ich might achieve much the same effect. Given that this flag's primary user= appears to be hosts, hosts need to be updated too. So, forgetting about a = new layer 3 flag, why not program hosts to only very infrequently attempt a= nything at IPv4, when ARP or DHCPv4 fail (as a result of all 1s broadcast a= nd IPv4 Ethertype failing to work with the local routers)? > > Yes, that's a good idea - basically a change to the backoff timers. My th= ought was > that the v6only flag could trigger such behaviour. So I think this is where there is still some ambiguity with the name. As a signal to hosts, the name "IPv6 only" says to me that it is a statement that the link only supports IPv6 - IPv4 is intended not to work by policy, so don't bother trying to do use it. In other words, switch off any attempts to acquire IPv4 addresses, and if any applications try to open any IPv4 sockets, the host OS generates an error immediately because there is no IPv4 address available to use, with this always occurring on an "IPv6 Only" link. If a host may still be able to use IPv4 on the link for the IPv4 Link Local address case, then "IPv6 only" isn't the truth. It seems there are really two situations here that are trying to be represented by a single flag: - IPv4 off-link won't work, so only IPv4 Link Local will work, if it is necessary. Only IPv6 is supported for both on-link and off-link destinations. - IPv4 on-link and off-link won't work by policy, so don't bother even trying to bring up IPv4, even IPv4 Link-Local. This may be further enforced by layer 2 filters that drop 0x800 and 0x806. The name "IPv6 Only" suits the latter, however I don't think it suits the former. I think that argues for either a less definite and more accurate name than "IPv6 Only", or perhaps two flags for these two situations - "Only IPv4 Link-Local Supported" and "IPv6 Only Link". Regards, Mark. >Whether we could persuade all > IPv4 stack developers to make such an update without the flag to act as a= signal > is another question. > > > As long as hosts need to be changed anyway, this seems as easy as any c= hange to read and react to a new flag at layer 3? > > Well, it introduces state anyway. Instead of state saying "I have seen th= e IPv6-only > flag from every router" it would be state saying "I have seen no ARP or D= HCP response, > so my backoff timer is now T". > > > And too, we can fine tune how this layer 2 solution works. The layer 2 = blocking of IPv4 (and ARP) can occur only on the actual router interface, l= et's say in that home or coffee shop net, or also on WiFi and Ethernet port= s inside that home or coffee shop. So in principle, in cases where the gate= way itself won't handle IPv4, you could still run IPv4 apps inside that ven= ue. > > Using IPv4 link-local addressing, yes, as briefly mentioned in the draft.= But it > seems to me that filtering on the Ethertype would block even that. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Sep 10 06:00:50 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145D1130E96 for ; Mon, 10 Sep 2018 06:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuN2ySwYHk56 for ; Mon, 10 Sep 2018 06:00:41 -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 0374F130E94 for ; Mon, 10 Sep 2018 06:00:41 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8ACtCIN034494; Mon, 10 Sep 2018 09:00:40 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2mdkha0yyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 09:00:40 -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 w8AD0aKX019007; Mon, 10 Sep 2018 09:00:38 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8AD0U6e018464; Mon, 10 Sep 2018 09:00:30 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 1739940F6CE4; Mon, 10 Sep 2018 13:00:30 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30485.vci.att.com (Service) with ESMTPS id EDC6F40F6CE3; Mon, 10 Sep 2018 13:00:29 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.179]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Mon, 10 Sep 2018 09:00:29 -0400 From: "STARK, BARBARA H" To: "'Simon Hobson'" , IPv6 List Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURT+zzjWobNx2k0inD30YrzcK7qTklhuAgAAOlwCAAOf8AIAAMHaAgAJtFICAAG14gIAA5uUA Date: Mon, 10 Sep 2018 13:00:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> In-Reply-To: <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.240.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=439 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809100134 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 13:00:47 -0000 > > I don't like the idea ipv6-only network, when you think about the upnp = and > auto-ip, the ipv4 still works in a LAN environment without dhcpv4 server. >=20 > And (rhetorical question) do the equivalents not work in IPv6 ? > The thing is, if you have completely transitioned to IPv6, then the same > things will work - auto IP via SLAAC and/or use of link local address(es)= , > device/service discovery via mDNS, and so on. So "turning off" IPv4 by > setting this flag wouldn't be noticed by users - the printer would still = "just > work", the NAS would "just be there", and so on but using IPv6 instead of > IPv4. Apparently, this isn't a rhetorical question. The answer is "no". There are= many IPv4-only devices that are using IPv4 "Auto IP". The vast majority of= these will never support IPv6 and would never support this flag. If router= s started blocking IPv4 at L2, these devices will stop working. That provid= es no benefit to the devices that stop working, and the devices that respec= t the flag and stop doing IPv4 won't care. If the goal is to help hosts-tha= t-respect-the-flag save power, then disabling IPv4 at L2 is completely unne= cessary, and potentially harmful. I'm with Andrew (Liu,Shu@CATR) on this. I don't object to the flag as a potential aid to battery-challenged devices= . I do object to proposals that IPv4 be disabled at L2. Barbara From nobody Mon Sep 10 07:02:05 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590A8130E06 for ; Mon, 10 Sep 2018 07:02:04 -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 IsXpv0iSEd8d for ; Mon, 10 Sep 2018 07:02:02 -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 488DB127333 for ; Mon, 10 Sep 2018 07:02:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EC0320090; Mon, 10 Sep 2018 10:20:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B4CE118DC; Mon, 10 Sep 2018 10:01:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B2506180C; Mon, 10 Sep 2018 10:01:59 -0400 (EDT) From: Michael Richardson To: "STARK\, BARBARA H" cc: "'Simon Hobson'" , IPv6 List Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 14:02:04 -0000 --=-=-= Content-Type: text/plain STARK, BARBARA H wrote: > Apparently, this isn't a rhetorical question. The answer is "no". There > are many IPv4-only devices that are using IPv4 "Auto IP". The vast > majority of these will never support IPv6 and would never support this > flag. If routers started blocking IPv4 at L2, these devices will stop > working. If the operator of the network wants these devices to continue operating, then they don't set the flag, and they don't block IPv4 at L2. (Maybe there is some scenarios where one sets the flag, but doesn't block IPv4, or maybe even the opposite. Both are intentional acts) > That provides no benefit to the devices that stop working, and > the devices that respect the flag and stop doing IPv4 won't care. If > the goal is to help hosts-that-respect-the-flag save power, then > disabling IPv4 at L2 is completely unnecessary, and potentially > harmful. > I'm with Andrew (Liu,Shu@CATR) on this. > I don't object to the flag as a potential aid to battery-challenged > devices. I do object to proposals that IPv4 be disabled at L2. It's not like we are forcing operators to either: 1) disable IPv4 at L2 2) set the ipv6-only flag For those that want to set the flag, the flag can exist. So, can we stop thinking that this is being forced on all networks, all the time? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluWeVcACgkQgItw+93Q 3WXJHAf+PGIg2cwIieA6o6kb2T8FmQO6PjfiPzaU6lMyzWLeUwEBoOxkIMTN4mUj gzckAzx4wvNL9ZM0aMIu8arLEOCIZ6dwRFwqnj3o+FprbN+afpkoPCHw81qEagsU QMcqYMnIlYPraEb0S7dMCblDwXk6WeMz0Y9VRKw9CiB8dKeXHVTmnYSSxLOK/hll c2aRfrDpKAti5QWxevsRxMB01CpLjNjS5zMvO/NssuTT+uKH5BeZZlIw1tyc1yyE SBiApsZajgQjHuV1GoKdeKzDlsJkroof8ds2W5NCPSB6KBTj4KVhdO0EKVpmiKWM srl1lzBwWArKLakoj8ydWzmpMWm9ag== =Ir19 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 10 07:40:29 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC98130ECF for ; Mon, 10 Sep 2018 07:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu_wImCNEWoE for ; Mon, 10 Sep 2018 07:40:26 -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 49E2A130E9F for ; Mon, 10 Sep 2018 07:40:26 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8AEZkFU022483; Mon, 10 Sep 2018 10:40:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2mdsve9pmu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 10:40:25 -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 w8AEeOZX021754; Mon, 10 Sep 2018 10:40:24 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8AEeIpY021532; Mon, 10 Sep 2018 10:40:21 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id E127A400579E; Mon, 10 Sep 2018 14:40:18 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id CCD46400575E; Mon, 10 Sep 2018 14:40:18 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.179]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Mon, 10 Sep 2018 10:40:18 -0400 From: "STARK, BARBARA H" To: "'Michael Richardson'" CC: "'Simon Hobson'" , IPv6 List Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURT+zzjWobNx2k0inD30YrzcK7qTklhuAgAAOlwCAAOf8AIAAMHaAgAJtFICAAG14gIAA5uUAgABXqID//74gkA== Date: Mon, 10 Sep 2018 14:40:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE9C5DE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> In-Reply-To: <24692.1536588119@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.240.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=2 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=2 clxscore=1015 lowpriorityscore=0 mlxscore=2 impostorscore=0 mlxlogscore=160 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809100150 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 14:40:28 -0000 > From: Michael Richardson >=20 > STARK, BARBARA H wrote: > > Apparently, this isn't a rhetorical question. The answer is "no". T= here > > are many IPv4-only devices that are using IPv4 "Auto IP". The vast > > majority of these will never support IPv6 and would never support t= his > > flag. If routers started blocking IPv4 at L2, these devices will st= op > > working. >=20 > If the operator of the network wants these devices to continue operating, > then they don't set the flag, and they don't block IPv4 at L2. >=20 > (Maybe there is some scenarios where one sets the flag, but doesn't block > IPv4, or maybe even the opposite. Both are intentional acts) I agree that there are 2 intentional acts being discussed -- I disagree as = to what the 2 acts are (or rather, should be). I believe the 2 acts are (1)= a flag that tells hosts they don't need to do any IPv4 and shouldn't expec= t to find any DHCPv4 server; and (2) preventing all LL IPv4 from working. If the goal of the flag is to benefit hosts who want to save power by not d= oing DHCPv4 (or any IPv4), then L2 blocking is orthogonal to this goal. Suc= h hosts are perfectly capable of not using IPv4 (including "Auto IP" LL IPv= 4). Disabling LL IPv4 has absolutely nothing to do with helping battery-con= strained hosts.=20 To suggest that managed networks are only permitted to benefit from this fl= ag if they also break legacy devices' use of "Auto IP" LL IPv4 makes the fl= ag harmful and undesirable. Since we're talking about managed routers, there is no reason why configuri= ng this flag and blocking IPv4 ethertype need to be combined. They can (and= should be) be completely distinct configuration settings.=20 =20 > > That provides no benefit to the devices that stop working, and > > the devices that respect the flag and stop doing IPv4 won't care. I= f > > the goal is to help hosts-that-respect-the-flag save power, then > > disabling IPv4 at L2 is completely unnecessary, and potentially > > harmful. >=20 > > I'm with Andrew (Liu,Shu@CATR) on this. >=20 > > I don't object to the flag as a potential aid to battery-challenged > > devices. I do object to proposals that IPv4 be disabled at L2. >=20 > It's not like we are forcing operators to either: > 1) disable IPv4 at L2 > 2) set the ipv6-only flag >=20 > For those that want to set the flag, the flag can exist. >=20 > So, can we stop thinking that this is being forced on all networks, all t= he time? I'm not suggesting it's being forced on all networks, all the time. I'm obj= ecting to suggestions that we either need 2 flags (if you're going to have = 2 things to set, just make the 2 things the "no need for IPv4" flag and "bl= ock IPv4 ethertype"), or that we need to automatically block IPv4 if the si= ngle proposed flag is set. The linkage of flag and IPv4 blocking makes the = flag much more likely to be harmful and adds no value. Barbara From nobody Mon Sep 10 13:06:48 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6800C130EEB for ; Mon, 10 Sep 2018 13:06: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 vmiFo90LSfNw for ; Mon, 10 Sep 2018 13:06:44 -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 90A06126F72 for ; Mon, 10 Sep 2018 13:06:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9FF291BC37 for ; Mon, 10 Sep 2018 20:06:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Simon Hobson In-Reply-To: <24692.1536588119@localhost> Date: Mon, 10 Sep 2018 21:06:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 20:06:46 -0000 STARK, BARBARA H wrote: > Apparently, this isn't a rhetorical question. The answer is "no". = There > are many IPv4-only devices that are using IPv4 "Auto IP". The vast > majority of these will never support IPv6 and would never support this > flag. If routers started blocking IPv4 at L2, these devices will stop > working. Then the network isn't transitioned to IPv6 only. It's rather implicit = in saying a network is IPv6 only that you have no devices left that need = IPv4. Michael Richardson wrote: > If the operator of the network wants these devices to continue = operating, > then they don't set the flag, and they don't block IPv4 at L2. Indeed. From nobody Mon Sep 10 13:37:07 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15A4130F94 for ; Mon, 10 Sep 2018 13:37:05 -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 4aMx2wQQOoW7 for ; Mon, 10 Sep 2018 13:37:04 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30A2130F9D for ; Mon, 10 Sep 2018 13:37:03 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id b12-v6so10254061plr.8 for ; Mon, 10 Sep 2018 13:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=uOZX9raicKfnzs6WqsJvWs/Rj+YpZ903yNRdQeG3y08=; b=PGjJmUFPhB4uI8Ub7c1Me8QuhDLL+BC31N6QichEdQDlwO72Kcrktr90HaPL+YQjZ6 vwr78H6FqvwVbK7aruipDqYTl+hjJSgv1cPylG8mlSQYYoyoAN06Kn1d1vt+eNLAlRm1 Voi8GBLXpxlZITNpcWbWcGEOsnKTecxAl1pfb3Pm8OMIT1DtUYs2viPRSmIj2b9+n/vC hmZ3xrYBBMWlUpzuwKWSycrcv0F2JZQhENHlFTdDLicqluT+Js18++Av7tv4nfn4JAT9 tTGdhmfyIewz5ffTlWr9xQc8RD7/2Lkxg1QOyO8osoDFLh6zcuIi8UTbkRk37295F1sT EpOg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uOZX9raicKfnzs6WqsJvWs/Rj+YpZ903yNRdQeG3y08=; b=txr4oRnxxJlstj10IdD/s32JF+2oiZkS56IGBn6JK3K50995SZoXg//zYuWIHxuwju h5ZW5PsnJS5m1aiW9SnCs53vxPgzbNFs5mZ+BVTcnnGM/Cv4efJBOgEP4vdVMJzSvOcr Tehb0/4qfFvjpmZDp9JWyCZYMm9BfyHPG+vnKqigbWuZOxC+PvKJzudbyOkArQHSvQKN NS0E/qEiM+ljEJW2Udp200Tdph7xfH/PlIGNeI3pd3rU7nKWrxcxdT7VJnTJOHbAIHOS vgWCJYkS9SZ11AY+p6rr5yaIvETFjtIMCyZ+NClXipP8HdBu5bWSA17+/qtpuWkS7RRb QKaQ== X-Gm-Message-State: APzg51CTMl8E3RdAiACLhj7Cs/a1yDuc4tWHU2ORdrsatHpOGyea+TAQ kv86R/7z34TEZ8wSQ1FSkpvx7tco X-Google-Smtp-Source: ANB0VdboHYhRlGWc4/Zv8kyNVJafTfhyVcNSfuVPaMZR5eFf1wGG3z+d4vfSeJQnglVQ37depgjOoA== X-Received: by 2002:a17:902:7c96:: with SMTP id y22-v6mr23964061pll.332.1536611823010; Mon, 10 Sep 2018 13:37:03 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id d22-v6sm39507098pfm.48.2018.09.10.13.37.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 13:37:02 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: ipv6@ietf.org References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> <2D09D61DDFA73D4C884805CC7865E6114DE9C5DE@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Message-ID: Date: Tue, 11 Sep 2018 08:36:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE9C5DE@GAALPA1MSGUSRBF.ITServices.sbc.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.29 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 Sep 2018 20:37:06 -0000 Excuse front-posting but, of course, what a network admin chooses to do about L2 blocking of IPv4 is *irrelevant* to the normative part of this draft. It's clear from some of the comments that some operators might choose to block the IPv4 Ethertypes at L2. It's also clear (to me) that by even mentioning this in the draft, we've ended up confusing the issue (the opposite of what we intended). So I think we need to do some rewriting. Regards Brian On 2018-09-11 02:40, STARK, BARBARA H wrote: >> From: Michael Richardson >> >> STARK, BARBARA H wrote: >> > Apparently, this isn't a rhetorical question. The answer is "no". There >> > are many IPv4-only devices that are using IPv4 "Auto IP". The vast >> > majority of these will never support IPv6 and would never support this >> > flag. If routers started blocking IPv4 at L2, these devices will stop >> > working. >> >> If the operator of the network wants these devices to continue operating, >> then they don't set the flag, and they don't block IPv4 at L2. >> >> (Maybe there is some scenarios where one sets the flag, but doesn't block >> IPv4, or maybe even the opposite. Both are intentional acts) > > I agree that there are 2 intentional acts being discussed -- I disagree as to what the 2 acts are (or rather, should be). I believe the 2 acts are (1) a flag that tells hosts they don't need to do any IPv4 and shouldn't expect to find any DHCPv4 server; and (2) preventing all LL IPv4 from working. > > If the goal of the flag is to benefit hosts who want to save power by not doing DHCPv4 (or any IPv4), then L2 blocking is orthogonal to this goal. Such hosts are perfectly capable of not using IPv4 (including "Auto IP" LL IPv4). Disabling LL IPv4 has absolutely nothing to do with helping battery-constrained hosts. > > To suggest that managed networks are only permitted to benefit from this flag if they also break legacy devices' use of "Auto IP" LL IPv4 makes the flag harmful and undesirable. > > Since we're talking about managed routers, there is no reason why configuring this flag and blocking IPv4 ethertype need to be combined. They can (and should be) be completely distinct configuration settings. > >> > That provides no benefit to the devices that stop working, and >> > the devices that respect the flag and stop doing IPv4 won't care. If >> > the goal is to help hosts-that-respect-the-flag save power, then >> > disabling IPv4 at L2 is completely unnecessary, and potentially >> > harmful. >> >> > I'm with Andrew (Liu,Shu@CATR) on this. >> >> > I don't object to the flag as a potential aid to battery-challenged >> > devices. I do object to proposals that IPv4 be disabled at L2. >> >> It's not like we are forcing operators to either: >> 1) disable IPv4 at L2 >> 2) set the ipv6-only flag >> >> For those that want to set the flag, the flag can exist. >> >> So, can we stop thinking that this is being forced on all networks, all the time? > > I'm not suggesting it's being forced on all networks, all the time. I'm objecting to suggestions that we either need 2 flags (if you're going to have 2 things to set, just make the 2 things the "no need for IPv4" flag and "block IPv4 ethertype"), or that we need to automatically block IPv4 if the single proposed flag is set. The linkage of flag and IPv4 blocking makes the flag much more likely to be harmful and adds no value. > > Barbara > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Sep 10 13:44:55 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB75130FF9 for ; Mon, 10 Sep 2018 13:44: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 BWXnT1iaCTDU for ; Mon, 10 Sep 2018 13:44:43 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A1B130FF0 for ; Mon, 10 Sep 2018 13:44:43 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id p5-v6so2803231plk.3 for ; Mon, 10 Sep 2018 13:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AD54u9GjrZx2PY6ShQHN6jVv4nlLBcmnrHzIG6B1dDY=; b=csmJZa3b8bll0mNKZDc4Bgr9u3WXfrtPHlTrvquFAYABftwCI/wyj1Z1RJFknOIW5J 6as9heKg4xE0wFq63FAgCECtbJlWoTq1a/KH3uF1WzI6zv+7DwN3BBGwdIKXVkfU4EeK yiSyOcjPK6gXBhjEbuPZGOM/7FoOAb0FW4KO9Sne60i1nx3smkS+xGizjS4u0Tianco7 cMlECIE8fArgqzhTuOYvDL6lZoZ4QpNmPjKFDAi14j9PneobwJyYAz8Oq9oLsmh82/z9 WRa1hbR1J4vfkxaxv/e43OgHTOA6MtX17rxG9YGds8eHG2RDEG7UZU1gCiEArlDhLdwh oJrQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AD54u9GjrZx2PY6ShQHN6jVv4nlLBcmnrHzIG6B1dDY=; b=p6TK1FmIZzUVuWmATEeDNmfr3rs70qF20uKcqSuXWpwbnvVFVHp6mny7Sgg/4Sh58u 6stZQoQkeF4lU4CYkIZn4kIgjguoXx6wqs8/fi6uz3BSFPADPRhDGqfW/+saeLCCuLEI 78+jGN7ZI0A8771liGHO6Kr+ayOgAD14SI1InR29a3dtNbs30hWM58sK/0xBTbDUflXp zqx1vlqo7Hzv6bmBU5kMyB5frh89Oi27w+CeMOJ73cUvtOZnSySiqkwIsvKh677A22Aj /Q/QQxSqI9ITq3LPsJ+sZYVVcxt5PoSpfsxG82eqX5mkMrSC8rKo+RdLE3FlyyjvFrC+ QxgQ== X-Gm-Message-State: APzg51CrJsdzx+pSNOA1qLBQLq5/g+KIYL9qOo7IrJhuxHoALLOLqeHB ktO0kza8vMffL0MERLiNNbcOtiCz X-Google-Smtp-Source: ANB0VdY045aOOf3xXfxiiUxkpLOqhS61H6XmdiYcVc/yQwfHM6plFVMEeTuDs0lpQS0ccC3tHDTF2Q== X-Received: by 2002:a17:902:3fa5:: with SMTP id a34-v6mr23883972pld.244.1536612282957; Mon, 10 Sep 2018 13:44:42 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id b73-v6sm30230445pfj.93.2018.09.10.13.44.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 13:44:42 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Simon Hobson , IPv6 List References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> From: Brian E Carpenter Message-ID: Date: Tue, 11 Sep 2018 08:44:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 20:44:55 -0000 On 2018-09-11 08:06, Simon Hobson wrote: > STARK, BARBARA H wrote: > >> Apparently, this isn't a rhetorical question. The answer is "no". There >> are many IPv4-only devices that are using IPv4 "Auto IP". The vast >> majority of these will never support IPv6 and would never support this >> flag. If routers started blocking IPv4 at L2, these devices will stop >> working. > > Then the network isn't transitioned to IPv6 only. It's rather implicit in saying a network is IPv6 only that you have no devices left that need IPv4. But the operator may or may not know that. In a large network (in particular with BYOD) it may even be unknowable. This gets back to Michael Richardson's point. The operator can know for sure that the network provides neither DHCP nor IPv4 routing. That's all the flag says definitively in the current definition. Whether link-local IPv4 works is a separate issue. > > > Michael Richardson wrote: > >> If the operator of the network wants these devices to continue operating, >> then they don't set the flag, and they don't block IPv4 at L2. > > Indeed. See above... Brian From nobody Mon Sep 10 14:42:11 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A00130EF7 for ; Mon, 10 Sep 2018 14:42:09 -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 KmiTUNNCCLgp for ; Mon, 10 Sep 2018 14:42:08 -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 4CEC5130DE1 for ; Mon, 10 Sep 2018 14:42:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 242911BC37 for ; Mon, 10 Sep 2018 21:42:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Simon Hobson In-Reply-To: Date: Mon, 10 Sep 2018 22:42:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 21:42:10 -0000 Brian E Carpenter wrote: >> Then the network isn't transitioned to IPv6 only. It's rather = implicit in saying a network is IPv6 only that you have no devices left = that need IPv4. >=20 > But the operator may or may not know that. In a large network (in = particular > with BYOD) it may even be unknowable. >=20 > This gets back to Michael Richardson's point. The operator can know = for > sure that the network provides neither DHCP nor IPv4 routing. That's = all the > flag says definitively in the current definition. Whether link-local = IPv4 > works is a separate issue. That does not change the argument. If the network owner/operator/admin = has decided that the network is now IPv6 only then they presumably will = have decided one or more of the following (which are really the same = thing) : 1) They have decided that there are no devices left on the network that = need IPv4 **AND** that they are concerned about still working 2) They've made a business decision to not support IPv4 and if some = Internet-of-Tat junk doesn't work then "someone" (it's BYOD owner for = example) will need to upgrade or replace it if they want it to work. At some point, when IPv4 use is sufficiently declining, various networks = will be making such decisions - and there'll be a decision to be made as = to where the line is drawn between the costs of continuing to support = the legacy protocol, and the costs of dropping it. So yes, it is valid to say that a network can be IPv6 only but have = devices that don't do IPv6. Those devices will then be broken - and if = they are needed then something will need to be done about it (such as = buying one that's not stuck in the 20th century). If you need them to = work and can't/won't upgrade them, then you keep IPv4 working and the = network is not IPv6 only - so the admin doesn't set the flag. TL;DR - if you need some IPv4 devices to work then you have not = transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag. From nobody Mon Sep 10 15:19:44 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D38130FB8 for ; Mon, 10 Sep 2018 15:19:42 -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 oFfrT8T3bD3U for ; Mon, 10 Sep 2018 15:19:40 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9910130FBA for ; Mon, 10 Sep 2018 15:19:40 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id j26-v6so11160195pfi.10 for ; Mon, 10 Sep 2018 15:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=vilj4MmCwm/GFCSPbJaaSJPZJYYMLMHZHSpFtWvF204=; b=jWQHAQa7wtq+iw3mBmz/tYlswQGWPEdoib3LiptARST22HCThlu2Q5ilKrYj6elvbE Pxkqb5uLrsjXG9mlRTZ6EHc9rU05F9NUyNIWmG+4AQhieffimXVhhZEKwATMtIke6osb AmEFDn2F56wNOUpFGQ7GuxqVK6/xwlKjD0FPqTEFMZO5YX7hdZgOHCJdvNTDduq+IsQQ CXh/pXXNIr1VjHCZQHubY39bTOKt21r9qO1ymStQ3yR0MJEEtMhCCjXpl9y5ENXyVvV6 ycE3DXMInk+hK4KSoa2QZfF6nuAXwwILE4OwZZve2+c2Dbw0ts9sAeeoTec1AAQ4LK8P YlsA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vilj4MmCwm/GFCSPbJaaSJPZJYYMLMHZHSpFtWvF204=; b=W1eOrOW6mdcCvhxvWfrXM6tGbnzR1m8nLnRS0nSU7JGg8n/sE2ZefFLVeR+Eymg7A5 noIvpr9gwKBSQ/i8sFTXeodb04LmPVzh47xPL3+uMtqYLEkV8naPe7GnqPSrgFL7vRxi DVy1B2mB2EdGPOGgOt6jJZ6fDYYBBTWPnW5AIfuXblfvDj7BOu4JhnXqaKabawXnsja0 vofAVDj9OpdKq3qdiiw8Huw9s6NVibHcI/sKA4+lfYBRxqwsCOEsPgotLo5ylGkzsJbZ F2KlhLkWWmUdeDILjs3Pv9zjzZbnDKAtfxhfvEA1v/aEfSHads5XnlOL1rBZ0WwUHYid 2Emw== X-Gm-Message-State: APzg51C+70A0nrK9hw6EZyAVHLbrYfSi5ieZIrV8aEoVrrAhJPSXluGq mqZiDjKNv19I67OiLxS6ZRBBR+G6 X-Google-Smtp-Source: ANB0Vdag/xFm+KFKQKrul4cNZkfgZU1TQwI3Fi9+wUXm8OXjTqNURA4QSDMGGtQPeGF5P7ve7r5ciQ== X-Received: by 2002:a62:4fd9:: with SMTP id f86-v6mr26293591pfj.110.1536617979786; Mon, 10 Sep 2018 15:19:39 -0700 (PDT) Received: from [130.216.38.157] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.157]) by smtp.gmail.com with ESMTPSA id p1-v6sm21271098pfn.53.2018.09.10.15.19.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 15:19:38 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Simon Hobson , IPv6 List References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> From: Brian E Carpenter Message-ID: Date: Tue, 11 Sep 2018 10:19:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 22:19:43 -0000 Simon, > TL;DR - if you need some IPv4 devices to work then you have not transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag. I think that misses a subtlety. The "operator" (who may be no expert) might not be aware of situations like the following: Some of the devices (installed long ago and forgotten) are IPv4-only smoke alarms. They can use link-local IPv4 to communicate with a more modern dual stack master alarm, which communicates with the outside world via IPv6. So in that situation there is a crucial difference between IPv4 "not routed" and "IPv4 blocked by the switches." In the latter case, the legacy smoke alarms won't work. The flag as currently defined is "IPv4 not routed". That is less drastic than "IPv4 blocked". It may even be helpful information for that dual stack master alarm. Regards Brian On 2018-09-11 09:42, Simon Hobson wrote: > Brian E Carpenter wrote: > >>> Then the network isn't transitioned to IPv6 only. It's rather implicit in saying a network is IPv6 only that you have no devices left that need IPv4. >> >> But the operator may or may not know that. In a large network (in particular >> with BYOD) it may even be unknowable. >> >> This gets back to Michael Richardson's point. The operator can know for >> sure that the network provides neither DHCP nor IPv4 routing. That's all the >> flag says definitively in the current definition. Whether link-local IPv4 >> works is a separate issue. > > That does not change the argument. If the network owner/operator/admin has decided that the network is now IPv6 only then they presumably will have decided one or more of the following (which are really the same thing) : > 1) They have decided that there are no devices left on the network that need IPv4 **AND** that they are concerned about still working > 2) They've made a business decision to not support IPv4 and if some Internet-of-Tat junk doesn't work then "someone" (it's BYOD owner for example) will need to upgrade or replace it if they want it to work. > > At some point, when IPv4 use is sufficiently declining, various networks will be making such decisions - and there'll be a decision to be made as to where the line is drawn between the costs of continuing to support the legacy protocol, and the costs of dropping it. > > So yes, it is valid to say that a network can be IPv6 only but have devices that don't do IPv6. Those devices will then be broken - and if they are needed then something will need to be done about it (such as buying one that's not stuck in the 20th century). If you need them to work and can't/won't upgrade them, then you keep IPv4 working and the network is not IPv6 only - so the admin doesn't set the flag. > > TL;DR - if you need some IPv4 devices to work then you have not transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Sep 10 15:21:43 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77917130FD4; Mon, 10 Sep 2018 15:21:41 -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 3pgmUCtALjaK; Mon, 10 Sep 2018 15:21:40 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2959130FE4; Mon, 10 Sep 2018 15:21:39 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id l63-v6so11167955pga.7; Mon, 10 Sep 2018 15:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aQPla2+5aDK6YEnfsIVuugGquW4T3Eu2WCiammGWB/M=; b=QlWZJJGOrMFp8Ln2u0pHxbZQWDs+iGNz4+OEb6FF1L98GJF0N0k30qEDWo1E7Bgk+P owivzF2ZGxyaCuG41o5L4v7FiWypDmKRdoFGKC6dgzzcddD3wJ86PyXlyGz+sCwnhrjn RuKZdcpCk87Aw3RXuqNHbN1+XRZ9hgCvpAusFvaf6m4zZirawQbM8AB3Au8ow9sKYWdv ZbISf4v/voM9zOJnxc3pTWWbh40fQUdeCADR4lUOGvYi3veI3HiCUbp36xnJ16lRJ2ht 8U9WHX62PAQBNjuQFzAPOczwPAkFCC5ZgPRss7iDkHqaHEiUdmnW7A9Ixj0nNSwOUz+h 8Eyg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aQPla2+5aDK6YEnfsIVuugGquW4T3Eu2WCiammGWB/M=; b=blKTvm3C3TuSOr35SCvv/+R/AfMuip79bQv5TB/29m5qTQthzVvy7zTj9yf+wZoeU7 npk6pN+Xk3/PKIYOscNCcix5olC86uroxRQtXNoBE/h4z3mL6MWSlY1RO/hIx3kxi0pd pvO/54k1yPXcL80kfasZCbZ77hZSZHVB/U71jMgHDzJIg15Tn+zBlWCy5PGMbzdMj2TW peUQbeW3K+ANHYbst5+/j8I4N6mrFOvcpVRSB7L9V2yS/wjpwyM4zHY8KoOy1AghI5FE MtnL2HzYEDYeqF/izK1Vgc/gkUbjGVs+njfu+TnFPB72sMA1/3/auCr0S1BEBffLIX5I Vq+g== X-Gm-Message-State: APzg51AOjb04plgARTjaLh0TMEfuMsHtju2VPygOctaBMkLi3Q+k12XU F6fACQvFfHGUgiyo4x7gmsSyM2mC X-Google-Smtp-Source: ANB0VdbHYWYOfbUwELzLAdTVgdGsMXSZaxG0D2hsaL7I+eVTOkHboLp3jEVREu9fS1vvb3+v+xAueg== X-Received: by 2002:a63:1e63:: with SMTP id p35-v6mr25162652pgm.376.1536618099111; Mon, 10 Sep 2018 15:21:39 -0700 (PDT) Received: from [130.216.38.157] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.157]) by smtp.gmail.com with ESMTPSA id p26-v6sm21493330pgn.64.2018.09.10.15.21.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 15:21:38 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Ole Troan , 6man WG Cc: 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> From: Brian E Carpenter Message-ID: <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> Date: Tue, 11 Sep 2018 10:21:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.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.29 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 Sep 2018 22:21:42 -0000 On 2018-09-06 05:40, Ole Troan wrote: > This message starts a two week 6MAN Working Group Last Call on advancin= g: >=20 > Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: IPv6 Router Advertise= ment IPv6-Only Flag > Authors =C2=A0 =C2=A0 =C2=A0: R. Hinden, B. Carpenter > Filename =C2=A0 =C2=A0 : draft-ietf-6man-ipv6only-flag-02.txt > Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0: 11 > Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-08-14 >=20 > =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-6man-ipv6only-= flag-02 So, those 2 weeks are well past. The authors will think about next steps,= given the complicated discussion. Brian >=20 > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 19 September 2018. >=20 > An issue tracker will be setup to track issues raised on this document.= >=20 > Thanks, > Ole >=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 Mon Sep 10 15:26:34 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBEA130FBA for ; Mon, 10 Sep 2018 15:26:33 -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, 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 mpE6A4esz34u for ; Mon, 10 Sep 2018 15:26:31 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCB4130FD4 for ; Mon, 10 Sep 2018 15:26:30 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 8-v6so43471076oip.0 for ; Mon, 10 Sep 2018 15:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YCv8+ETIRNlDkxYPNgpbIURObULFCuuCSG7ebnYRy+M=; b=bgJyaZMawccfbTFLzK55xezVhnWsMlpwg5nXuiLF2V+20jgS347bDYx+yr8LbKaHog fZxw1eOheoxeRMprtPFWGYEa6IRxOaiJNIQfRKA1PZ7Ff9CsRbn0QtVth8fD+CgbPeoK MtpdZ9iJeXSdEUuLRBzjD+R4Bmfxbnx2LP2uEcXMy8srd5ebwUnIaAiyyty4kwIiLu4h orFMx9S0027rRX8ed+aVXPrzyUBtf1ppdyhW8sBM6CGHTb8r4OC8pATh6P0k5BSujaFZ SS9cSMIff/Fs5FbHvgImIg1Y/JGdpPMqv2YencshZetLXMsNXKKh83CCtzQmc9Rj33Gj qxzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YCv8+ETIRNlDkxYPNgpbIURObULFCuuCSG7ebnYRy+M=; b=Y79e0TweNGPI4h346nGCxQXePAYWd8N1fXgxwMRA0iso2xb/R4rsHQCdCsOJZL+wFY i7JS2BaRX/rD+xfUlXXUEJr+n2REfOZroRxKYTAFONHtHUWwc5ZMJX+n6QJMVYhAH5a/ sO5OfaTzTtu+rhWvMmN+1Pa1hGAUupw7mzTn/MfDS8VOoBtNitXMGz5RCmmv8c9E2e/z BHLey9wOCOl26Tsc/YSGP6VNQjuNoayCLFqU7NimzQKP+vaIjIKwl07SV45is29JtJAI qAtv/DXC4IGs0XO9gPmvCXa+/UNbIXyo8nn7nMvSSndjf9A8zuqK/BnM6X0Ttyn/FJM6 HNag== X-Gm-Message-State: APzg51CCwRzPPXp9Jn/cqoJ1RE0h1xkGyCPC9NADon7b7Qu1nNAmXMYh x1LJ7I0vYYN3W7tMBmNXIFty+744clRBz0571U5B8w== X-Google-Smtp-Source: ANB0VdY1ZKDxDpPxkYCntcqD9uN0igMithtCEDoIAXmO1awNEsaBByiUF/elzrPqMkOQwpUUtxXUBQjPCh0yWaK6Irw= X-Received: by 2002:aca:2cd3:: with SMTP id s202-v6mr22200353ois.253.1536618390155; Mon, 10 Sep 2018 15:26:30 -0700 (PDT) MIME-Version: 1.0 References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> In-Reply-To: From: Mark Smith Date: Tue, 11 Sep 2018 08:26:17 +1000 Message-ID: Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Simon Hobson Cc: 6man WG Content-Type: multipart/alternative; boundary="0000000000004cf5fa05758bd9ab" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:26:33 -0000 --0000000000004cf5fa05758bd9ab Content-Type: text/plain; charset="UTF-8" On Tue., 11 Sep. 2018, 07:42 Simon Hobson, wrote: > Brian E Carpenter wrote: > > >> Then the network isn't transitioned to IPv6 only. It's rather implicit > in saying a network is IPv6 only that you have no devices left that need > IPv4. > > > > But the operator may or may not know that. In a large network (in > particular > > with BYOD) it may even be unknowable. > > > > This gets back to Michael Richardson's point. The operator can know for > > sure that the network provides neither DHCP nor IPv4 routing. That's all > the > > flag says definitively in the current definition. Whether link-local IPv4 > > works is a separate issue. > > That does not change the argument. If the network owner/operator/admin has > decided that the network is now IPv6 only then they presumably will have > decided one or more of the following (which are really the same thing) : > 1) They have decided that there are no devices left on the network that > need IPv4 **AND** that they are concerned about still working > 2) They've made a business decision to not support IPv4 and if some > Internet-of-Tat junk doesn't work then "someone" (it's BYOD owner for > example) will need to upgrade or replace it if they want it to work. > > At some point, when IPv4 use is sufficiently declining, various networks > will be making such decisions - and there'll be a decision to be made as to > where the line is drawn between the costs of continuing to support the > legacy protocol, and the costs of dropping it. > > So yes, it is valid to say that a network can be IPv6 only but have > devices that don't do IPv6. Those devices will then be broken - and if they > are needed then something will need to be done about it (such as buying one > that's not stuck in the 20th century). If you need them to work and > can't/won't upgrade them, then you keep IPv4 working and the network is not > IPv6 only - so the admin doesn't set the flag. > > TL;DR - if you need some IPv4 devices to work then you have not > transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag. > Who is arguing that? I'm not, and I'm pretty sure Brian and others aren't. If you still want off-link IPv4 to work, you'll have a default IPv4 router and most likely a DHCPv4 server. Why would any operator purposely set an "IPv6 Only" flag in that scenario, unless it is a step as part of removing IPv4 support from the link? IPv4 is a legacy protocol, and on these links is purposely being treated as a second class protocol by the link operator. If a link doesn't provide full IPv4 support, mainly meaning no default router, so no off-link IPv4, isn't the nice and best thing to do for the hosts and their end-users to tell them so? This is in effect an "ICMPv4 destination unreachable" message for all off-link IPv4 destinations, except that it avoids all the IPv4 protocol initialisation and infrastructure (hosts acquiring IPv4 addresses, a DHCPv4 server, default router with no IPv4 routes) that would be needed to send those ICMPv4 messages for all off-link destinations. Regards, Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000004cf5fa05758bd9ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Tue., 11 Sep. 2018, 07:42 Simon Hobson, <linux@thehobsons.co.uk> wrote:
Brian E Carpenter <brian.e.carpenter@gmail.com= > wrote:

>> Then the network isn't transitioned to IPv6 only. It's rat= her implicit in saying a network is IPv6 only that you have no devices left= that need IPv4.
>
> But the operator may or may not know that. In a large network (in part= icular
> with BYOD) it may even be unknowable.
>
> This gets back to Michael Richardson's point. The operator can kno= w for
> sure that the network provides neither DHCP nor IPv4 routing. That'= ;s all the
> flag says definitively in the current definition. Whether link-local I= Pv4
> works is a separate issue.

That does not change the argument. If the network owner/operator/admin has = decided that the network is now IPv6 only then they presumably will have de= cided one or more of the following (which are really the same thing) :
1) They have decided that there are no devices left on the network that nee= d IPv4 **AND** that they are concerned about still working
2) They've made a business decision to not support IPv4 and if some Int= ernet-of-Tat junk doesn't work then "someone" (it's BYOD = owner for example) will need to upgrade or replace it if they want it to wo= rk.

At some point, when IPv4 use is sufficiently declining, various networks wi= ll be making such decisions - and there'll be a decision to be made as = to where the line is drawn between the costs of continuing to support the l= egacy protocol, and the costs of dropping it.

So yes, it is valid to say that a network can be IPv6 only but have devices= that don't do IPv6. Those devices will then be broken - and if they ar= e needed then something will need to be done about it (such as buying one t= hat's not stuck in the 20th century). If you need them to work and can&= #39;t/won't upgrade them, then you keep IPv4 working and the network is= not IPv6 only - so the admin doesn't set the flag.

TL;DR - if you need some IPv4 devices to work then you have not transitione= d to IPv6 only. Don't set the "no IPv4 spoken here" flag.
=


=
Who is arguing that? I'm not, and I'm prett= y sure Brian and others aren't.

If you still want off-link IPv4 to work, you'll have a defa= ult IPv4 router and most likely a DHCPv4 server. Why would any operator pur= posely set an "IPv6 Only" flag in that scenario, unless it is a s= tep as part of removing IPv4 support from the link?
=
IPv4 is a legacy protocol, and on these links i= s purposely being treated as a second class protocol by the link operator.<= /div>

If a link doesn't pr= ovide full IPv4 support, mainly meaning no default router, so no off-link I= Pv4, isn't the nice and best thing to do for the hosts and their end-us= ers to tell them so?

Thi= s is in effect an "ICMPv4 destination unreachable" message for al= l off-link IPv4 destinations, except that it avoids all the IPv4 protocol i= nitialisation and infrastructure (hosts acquiring IPv4 addresses, a DHCPv4 = server, default router with no IPv4 routes) that would be needed to send th= ose ICMPv4 messages for all off-link destinations.
<= br>
Regards,
Mark.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
--------------------------------------------------------------------
--0000000000004cf5fa05758bd9ab-- From nobody Mon Sep 10 18:28:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC57131008 for ; Mon, 10 Sep 2018 18:28: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, 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 UG2Ef-6lTpmV for ; Mon, 10 Sep 2018 18:28:03 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7224130E11 for ; Mon, 10 Sep 2018 18:28:03 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id k21-v6so11344512pff.11 for ; Mon, 10 Sep 2018 18:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JEIn1/XP51Nf5QfbWwPVsRM60HFYbactrCvBfLllbig=; b=nNOiH9mCPAaiKE0GQK361WxpYq7cfdjkpYH6+5c9trxwFvbLh5/oh4xhZGXQXyjn77 vWXwkDW50pp9273jA3xzs7zhvMLutBaHci8pqhbu674/BTEsV6hfD2CVLE+Qyquhb8yB dJRz/CWHX55Mo/lCZ6N5XhOjLdsUDgtQfw5Vs9E6UAFUKShiH8XtpPNjvFhqvOpv0hum otKNjPJZ+T4ZjqS9IdzjG9YlWAG+OxkDpnEfTe/xttch/sIZjjT4KPMgsvh+3ZFa90Vs qNCkZ2nYGsal5/gpTCIzOL9euoMQim6YaC9RcbSB8gHs66cPhCr3GUS+RqoygUBJxxF3 WIUg== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JEIn1/XP51Nf5QfbWwPVsRM60HFYbactrCvBfLllbig=; b=dFg8PDiv3ph6dMdiT5wv2ao0kSiJ2hv1904QuZt97zr+bxEVP21aakE2PiIhCTDn+i 9rXTiCf2eOSe3g/gjEMDqAhYTx87SgM3IyI2PIl95z/ieQnXb0W14k4srUQPwtB0ob1w XUHtt0YMW7jS8LDn39uLVVrcCt26R9W2Mt5CQoVvHxH+KpFReFq/Ebq9K3oS5mUWgaO7 b9A62haHtvptWrh7lMsAFzM5gwzdspfjRY37YhlG7TNkpDLgL63WZqdwAWksrQsOXgZ2 45uMZ42go0Nd7VpP5uo8NVDcSqzAg86fRcf6bvTIZahiMmWg3Jn+Kyo8uz9kv+SpL+rk mrew== X-Gm-Message-State: APzg51CPNBty/8mtyKsr/FKtoiytauaBYEKb9ogDLIhTX7Go6hrEb1P1 HJfJ+W4BcApgbO42y0RX0wEqAGyC X-Google-Smtp-Source: ANB0VdZ59l9lRqP/eSOV7d7P6TrDN35P9gt9pe201Wx82KJEONOeIml/NPYCZe4ob9hbNd0TacP55A== X-Received: by 2002:a62:e412:: with SMTP id r18-v6mr26731575pfh.25.1536629282839; Mon, 10 Sep 2018 18:28:02 -0700 (PDT) Received: from [130.216.38.157] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.157]) by smtp.gmail.com with ESMTPSA id l6-v6sm23557647pfl.169.2018.09.10.18.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 18:28:01 -0700 (PDT) Subject: Re: Comments on draft-herbert-ipv6-update-dest-ops To: Tom Herbert , Ole Troan Cc: "C. M. Heard" , 6man WG References: <837265C7-AF4A-4E78-A7B4-5D4AE5C38C8A@employees.org> <970CDF5C-1E76-4241-9BCA-B053F637DE40@employees.org> From: Brian E Carpenter Message-ID: Date: Tue, 11 Sep 2018 13:27:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 01:28:06 -0000 A bit late to the party, but I have a few words to add: On 2018-08-22 03:09, Tom Herbert wrote: > On Tue, Aug 21, 2018 at 3:55 AM, Ole Troan wrote= : >> Hi Tom, >> >>>>>>> Consider the folling scenario: >>>>>>> >>>>>>> Someone is developing a new Destination Option that might be of >>>>>>> interest for use with tunnels and might even become one of those >>>>>>> options "that makes sense to support" . Maybe it's an option for = thenaforementioned insitu-OAM, or maybe a general packet CRC, etc. The >>>>>>> developer dutifully uses experimental option type 0x1e for the ty= pe >>>>>>> value of their option to test it. In particular, the action taken= if >>>>>>> the option is unknown to a receiver is to skip over it. They made= that >>>>>>> choice because that allows incremental deployment of the support = for >>>>>>> the option in any combination supporting sending side or receiver= s. In >>>>>>> other words, they don't want a flag day for the option that requi= res >>>>>>> all nodes to support the new option. >>>>>>> >>>>>>> Now they go to test backwards comapatbility of the option by send= ing >>>>>>> it to a node that hasn't been updated to receive it. If the recei= ving >>>>>>> node is a Linux system, then the option is ignored and the tunnel= ed >>>>>>> packet is processed as before-- expected behavior per the spec. >>>>>>> However, if it's sent to a VPP node then the packet is dropped-- = not >>>>>>> expected. Even if this doesn't lead to incorrectness, it does bre= aks >>>>>>> interoperability and violates "be liberal in what you receive". T= his >>>>>>> net effect is that this makes development, test, and pilot deploy= ment >>>>>>> of new options really hard. Just implementing the TLV loop, even = if >>>>>>> the implementation doesn't process any of them, would resolve thi= s. >>>>>> >>>>>> Absolutely. The set of _optional_ destination options would benefi= t from this approach. >>>>>> Of which we have none. I=E2=80=99d much rather just implement new = options as they come available (if they ever will) >>>>> >>>>> Ole, >>>>> >>>>> I'm not sure what "comes available" mean here. Does that mean VPP >>>>> would only support TLVs parsing once one becomes standardized and t= he >>>>> VPP maintainers think is worth supporting? As shown in the scenario= >>>>> above, with that approach its difficult to develop optional TLVs if= >>>>> implementations don't properly skip over them. >>>> >>>> No, don=E2=80=99t get me wrong. >>>> As in any open source project you are welcome to provide a patch, an= d I=E2=80=99m pretty sure it would get in. >>>> >>> I would, but for me VPP code is very hard to decipher. For someone wh= o >>> knows the code this should be relatively easy. The ip6_parse_tlv (in >>> net-next/net/ipv6/exthdrs.c) function does this in Linux in < 100 LOC= =2E >>> It's straightforward, supporting padding, unknown options, and limits= =2E >>> >>>> That said since we=E2=80=99re talking about tunnels, and in those ca= ses you generally know whom you are talking to, I=E2=80=99m not sure I bu= y the argument that would make deploying new destination options harder. = It=E2=80=99s not like a tunnel head end accepts traffic from random sourc= es around the Internet (well, we=E2=80=99ve tried that with stuff like RF= C1933, 6to4 and so on, but that didn=E2=80=99t quite pan out). >>> >>> I'm not sure this is just about tunnels. It looks like VPP can also >>> support TCP connections (there's a reference on web to HTTP server fo= r >>> VPP) as well as UDP sockets, and VPP also can do classification, NAT,= >>> and other firewall functions. Do you know if VPP properly handle >>> Destination Options in these cases? >>> >>> I'm afraid this might be an example of an implementation deployed on >>> middleboxes in the Internet (like firewalls) that arbitrarily drop >>> packets because they have a DestOpts extension header (RFC7872). >>> That's exactly a principle reason why Destination Options are unusabl= e >>> on the Internet, and hence why there's been so much effort to avoid >>> using them and no one bother's trying to create "useful" options. Thi= s >>> is an example of death of a good protocol feature by undermining it >>> with a thousand arbitrary decisions on what parts of the spec to >>> implement or not. >>> >>> This goes goes back to a major rationale for this draft. If an >>> implementation really doesn't want to implement the TLV loop for >>> processing options then so be it, but then at least they should skip >>> over the options instead of just dropping the packet so as not to kil= l >>> the feature for everyone else. >> >> You have at least 4 arguments going at once here. >> >> 1) How to deal with destination options on intermediate devices termin= ating and forwarding traffic (tunnels, source routing) The words "destination option" and "marked to be changeable" in the same sentence make my head hurt. So I think that indeed 8200 needs clarifying on this, much as the draft says: if the option *precedes* the routing hea= der it's intended to be processed by the intermediate forwarder. (As a side question, should that forwarder be entitled to remove the option complete= ly, as well as to modify it?) But apart from that, "changeable" is a nonsense= for a *destination* option and should be forbidden. >> 2) Dealing with destination options when terminating traffic as a host= That seems clear cut. >> 3) Dealing with destination options when acting as a layer violating m= iddlebox. >=20 > Note that that RFC8200 doesn't distiguish any of the cases. Per the > spec there is no difference between a tunnel endpoint and a end host > in how they are supposed to process Destination Options. Neither is > there is any difference between how a hardware and software > implemenation of protocol is supposed to work. Middleboxes that aren't > destinations of a packet aren't supposed to be looking at Destination > Options header at all. +1 >=20 >> 4) Why after 20 years aren=E2=80=99t there any =E2=80=9Cuseful=E2=80=9D= destination options created? >=20 > One could also argue that IPv6 itself has gotten enough traction until > recently to warrant interest in the creating them. +1. >=20 > All these fall under the same root problem, namely how do we undo the > effects of non-compliant implementations for core protocol features > (i.e. Destination Options in this case). It seems like there's three > alternatives: abandon trying to use the feature and try to do > something else to get the functionality, fix implementations to be > compliant, change protocols to adapt to reality of implementation that > best preserves the feature. There's a 4th alternative hiding in draft-carpenter-limited-domains-03. Namely, only use them where they actually work. Brian > VPP is an example of an implementation that should simply be fixed to > be compliant (I have taken that up with the VPP developers). This > draft updates processing of Destination Options before the Routing > header relax the requirements similar to how this was does for > Hop-by-Hop options. It makes the assumption that some intermediate > devices in a routing list won't processing the Destination Options per > the current specification. That assumption seems to be true for VPP, > and it seems like that some other implementations will also not be > processing them ostensibly because of performance hit and processing > cost. >=20 > Tom >=20 >> Best regards, >> Ole >> >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Sep 10 21:51:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C836C130E54; Mon, 10 Sep 2018 21:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z8VY4eInYg_g; Mon, 10 Sep 2018 21:51:07 -0700 (PDT) Received: from bugle.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 1D9AD130E1C; Mon, 10 Sep 2018 21:51:07 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 78C27FECBB29; Tue, 11 Sep 2018 04:51:06 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> Date: Tue, 11 Sep 2018 06:50:50 +0200 Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 04:51:09 -0000 Brian, > On 11 Sep 2018, at 00:21, Brian E Carpenter w= rote: >=20 >> On 2018-09-06 05:40, Ole Troan wrote: >> This message starts a two week 6MAN Working Group Last Call on advancing:= >>=20 >> Title : IPv6 Router Advertisement IPv6-Only Flag >> Authors : R. Hinden, B. Carpenter >> Filename : draft-ietf-6man-ipv6only-flag-02.txt >> Pages : 11 >> Date : 2018-08-14 >>=20 >> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >=20 > So, those 2 weeks are well past. The authors will think about next steps, > given the complicated discussion. It might have felt like two weeks, but the last call doesn=E2=80=99t end bef= ore September 19th.=20 Ole >> as a Proposed Standard. Substantive comments and statements of support >> for publishing this document should be directed to the mailing list. >> Editorial suggestions can be sent to the author. This last call will >> end on 19 September 2018. >>=20 >> An issue tracker will be setup to track issues raised on this document. >>=20 >> Thanks, >> Ole >>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 From nobody Mon Sep 10 22:19:43 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8DD130E34; Mon, 10 Sep 2018 22:19:40 -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 CvV3U8wIkyUU; Mon, 10 Sep 2018 22:19:39 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29943130DD9; Mon, 10 Sep 2018 22:19:39 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id j8-v6so10773095pll.12; Mon, 10 Sep 2018 22:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fL3qxaLhDlJUGmmFI4bvzopRuSnkvhXRsEqgML0l2c0=; b=HOjdJqN65UIn2cypfCCyjdum1WGi2W6FZ1FFd766mzpMznKnlmNQG4c4p9tZ+ON4N9 mQ4w3ZlkoPcBa5i3lOB/UlEJA7Jei4LwZao+aXRJwG3Neg0+nb1kvTfsaSlBUk0I0M01 vcROQENc6YY7WswvelPLjHSlFAgzRtH87hneAat7bmPUKWhAaXEiemaY4UXZFve0GIT8 sPU/6H52bg7Hr6phwB6RUxVzoiqh72olb9ImPfaigK/peMIvGH4hPbpBagNoIUS6tfts 15Ri2jbZVIgel3tkX1ueA0JHHh4l4v63W9xqPcGE0HEfGAjD1v5fbKX/7DG4gCZsWXK3 sSeA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fL3qxaLhDlJUGmmFI4bvzopRuSnkvhXRsEqgML0l2c0=; b=HM1JFEveVhotqcLViFpl79mqzM5KkMq0L5+IoFcNEKHg26nPUafTZezdNK32NIW8mw B1rUCuXcCq/gS8ORUfmrI0g8Ly80dkKjNvCdVNFvwsdAUucdEOz6nSYtmblc4WXXCVpG kQPCJ86DzUbIqGzsk0p6Ny5ZPHxQ/voDuYPL4Ynsk+rc4iCyiTwiAzS33VbFwuh8C5Am 6Wl6/l7na6vqSDySXtP+kfnXZGuydLIjWk4GXTL8ocPjB8fW9E+7dvb1JNM7d0igbL33 AHR/svaLwOjS9lGuqe9hu1Px0/WMRiJhXYSu+enmDmnRjuqu67L3GhhZMZ/xf+eVLMxQ 1xAw== X-Gm-Message-State: APzg51Ar1Fg2WI5mXC2gXhIBCVnvOQX0Mb8wgI3jNT7c4twtcWQyGVwZ yc+TliQLRqfuv9xzgEpZUuG1q/dK X-Google-Smtp-Source: ANB0VdbY/JmHmbjH5SsPYXQ4Qh20FG4hC1OylFjJ4cM655ANmoLx4htrfFlwg59/W76+Ba77J2MWjA== X-Received: by 2002:a17:902:b595:: with SMTP id a21-v6mr25311275pls.23.1536643178399; Mon, 10 Sep 2018 22:19:38 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 71-v6sm22927942pfx.182.2018.09.10.22.19.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 22:19:37 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Ole Troan Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> From: Brian E Carpenter Message-ID: <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> Date: Tue, 11 Sep 2018 17:19:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 05:19:41 -0000 On 2018-09-11 16:50, Ole Troan wrote: > Brian, >=20 >> On 11 Sep 2018, at 00:21, Brian E Carpenter wrote: >> >>> On 2018-09-06 05:40, Ole Troan wrote: >>> This message starts a two week 6MAN Working Group Last Call on advanc= ing: >>> >>> Title : IPv6 Router Advertisement IPv6-Only Flag >>> Authors : R. Hinden, B. Carpenter >>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>> Pages : 11 >>> Date : 2018-08-14 >>> >>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >> >> So, those 2 weeks are well past. The authors will think about next ste= ps, >> given the complicated discussion. >=20 > It might have felt like two weeks, but the last call doesn=E2=80=99t en= d before September 19th.=20 Silly me, sorry, I misread the date (new computer, still fiddling with fo= nt sizes etc.). Doesn't change my conclusion that we have to work on the = draft... Brian >=20 > Ole >=20 >=20 >>> as a Proposed Standard. Substantive comments and statements of suppor= t >>> for publishing this document should be directed to the mailing list. >>> Editorial suggestions can be sent to the author. This last call will >>> end on 19 September 2018. >>> >>> An issue tracker will be setup to track issues raised on this documen= t. >>> >>> Thanks, >>> Ole >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >=20 >=20 From nobody Mon Sep 10 23:27:31 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A9B130E35; Mon, 10 Sep 2018 23:27:29 -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 vwnWDVxU2W9Z; Mon, 10 Sep 2018 23:27:28 -0700 (PDT) Received: from bugle.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 20DAA130E3A; Mon, 10 Sep 2018 23:27:28 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id C0D4AFECBB28; Tue, 11 Sep 2018 06:27:27 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> Date: Tue, 11 Sep 2018 08:27:25 +0200 Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 06:27:30 -0000 >> On 11 Sep 2018, at 07:19, Brian E Carpenter = wrote: >>=20 >> On 2018-09-11 16:50, Ole Troan wrote: >> Brian, >>=20 >>>>> On 11 Sep 2018, at 00:21, Brian E Carpenter wrote: >>>>=20 >>>> On 2018-09-06 05:40, Ole Troan wrote: >>>> This message starts a two week 6MAN Working Group Last Call on advancin= g: >>>>=20 >>>> Title : IPv6 Router Advertisement IPv6-Only Flag >>>> Authors : R. Hinden, B. Carpenter >>>> Filename : draft-ietf-6man-ipv6only-flag-02.txt >>>> Pages : 11 >>>> Date : 2018-08-14 >>>>=20 >>>> https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 >>>=20 >>> So, those 2 weeks are well past. The authors will think about next steps= , >>> given the complicated discussion. >>=20 >> It might have felt like two weeks, but the last call doesn=E2=80=99t end b= efore September 19th. >=20 > Silly me, sorry, I misread the date (new computer, still fiddling with fon= t sizes etc.). Doesn't change my conclusion that we have to work on the draf= t... Right. Trying to categorize the comments: 1) Not deploy. This doesn=E2=80=99t fit with our model of network operation= s.=20 2) No need. It=E2=80=99s sufficient to block IPv4 traffic in the network and= no need to signal hosts.=20 3) Implications of flag. Does the flag mean an IPv6 only link, ie no IPv4 pa= ckets on it or does it only mean that routers don=E2=80=99t forward IPv4.=20= Please add if there are some I have missed. In my view 1+2 are relevant in judging if we should do this work at all, and= if there=E2=80=99s consensus to proceed. While 3 is more relevant to what we traditionally discuss during a last call= . Is the document clear, solution described interoperable etc.=20 Cheers=20 Ole >>=20 >>=20 >>>> as a Proposed Standard. Substantive comments and statements of support >>>> for publishing this document should be directed to the mailing list. >>>> Editorial suggestions can be sent to the author. This last call will >>>> end on 19 September 2018. >>>>=20 >>>> An issue tracker will be setup to track issues raised on this document.= >>>>=20 >>>> Thanks, >>>> Ole >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >=20 From nobody Tue Sep 11 03:11:38 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC7B130DE0 for ; Tue, 11 Sep 2018 03:11:36 -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, 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 (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 zNBtwezcxb3v for ; Tue, 11 Sep 2018 03:11:34 -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 C8E4412D7EA for ; Tue, 11 Sep 2018 03:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1536660691; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sPfjy6IES1SfKCFrqzyUTJLrgy7B6ciD2M3/NSH/WS8=; b=STQ4Ow5cgfv3JaJCYfsw4/ISngtrtOLdpYVXGnOMgLa7zSK+py490rv0whXKHzeez6kTJC5ahFlu7S+x6N9tjMF2uafOs6JoKgHHMYzw6VuPgGeS4khAQ8Iho7tr7JI2gmOem9QXv78dxjjAYaoYqZtvOCWJ6dqOOcEJS+f0XCQ= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0115.outbound.protection.outlook.com [213.199.154.115]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-52-ortgMop7MU64FuUSGe-DuA-1; Tue, 11 Sep 2018 11:11:30 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.82.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 10:11:28 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 10:11:28 +0000 From: Tim Chown To: Brian E Carpenter CC: Simon Hobson , IPv6 List Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHURT+5fmxjNPJnAkOJ7cXg3yn1RqTkUw2AgAAOlwCAAOf7AIAAMHUAgAR/TJ6AAApPgIAAEAiAgAAKf4CAAMbkgA== Date: Tue, 11 Sep 2018 10:11:28 +0000 Message-ID: <0F0A2667-62B0-4E91-B67F-87D6325D69FB@jisc.ac.uk> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> 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.3445.9.1) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB3876; 20:sawgzzeQyxQQfeIOHECJ6TCiC4sBdOyPwk3dega9bydUKqH5/Ss5FR7z8WrnLlHi4zKZCdyt2bJXIBBrCokJ5IdU0Nmd3iOnxB2WkTtcSDfSRufxT7ri0kRYrANvM/34mIpgDVeQ/Ypo9Uk7hvmpuc4AXspf+3I7kvyqTlj0CdU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ec038c7b-c750-46f4-7919-08d617cef0c1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB3876; x-ms-traffictypediagnostic: AM0PR07MB3876: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(788757137089)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231344)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991033); SRVR:AM0PR07MB3876; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB3876; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39850400004)(396003)(376002)(346002)(199004)(189003)(51444003)(105586002)(2906002)(14444005)(106356001)(53936002)(5250100002)(6306002)(81156014)(102836004)(6512007)(83716003)(256004)(786003)(316002)(54906003)(2616005)(6436002)(476003)(966005)(6346003)(11346002)(486006)(8936002)(26005)(66066001)(82746002)(81166006)(6506007)(53546011)(86362001)(50226002)(446003)(25786009)(186003)(6246003)(6116002)(2900100001)(97736004)(68736007)(4326008)(229853002)(57306001)(7736002)(305945005)(6486002)(33656002)(8676002)(3846002)(14454004)(76176011)(74482002)(5660300001)(39060400002)(36756003)(6916009)(478600001)(99286004)(93886005)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3876; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-microsoft-antispam-message-info: js3ldvz+BbpQV4C9DUMahXRVbFiheo4hJP0OLLQEqcHQZdfg0AJlTVUEMMLA9mgIWBfIKK1j9IMJA90ERbDPDv7j7MmU11msF7RL3AJDRsstsBdwrxD+5HiiVk9TUi8qGxqOihLOTDVijuN2p10YHA0r9tzOylhM8JcSYaFfLaq3Xm7U6B+5vLVhJrQDw/U/5H2jYGNZ0pbnuAoMTQh+8D0usWX1r8KxGrRlbSuwjtrmUX/ljb9BJcDJjrIHUCHWGZa+dyc85XPXWgzLwPq/WgFZ+Agzpee6YZeB6/pJ2lLdXlX1Asqi+0bj+7UtLJg6XBmW+G6YEeRVSbEDW7asSFF/y2oQMrENocGfebYjxWA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ec038c7b-c750-46f4-7919-08d617cef0c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 10:11:28.7785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3876 X-MC-Unique: ortgMop7MU64FuUSGe-DuA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 10:11:37 -0000 > On 10 Sep 2018, at 23:19, Brian E Carpenter = wrote: >=20 > Simon, >=20 >> TL;DR - if you need some IPv4 devices to work then you have not transiti= oned to IPv6 only. Don't set the "no IPv4 spoken here" flag. >=20 > I think that misses a subtlety. The "operator" (who may be no expert) mig= ht > not be aware of situations like the following: >=20 > Some of the devices (installed long ago and forgotten) are IPv4-only smok= e > alarms. They can use link-local IPv4 to communicate with a more modern > dual stack master alarm, which communicates with the outside world via > IPv6. >=20 > So in that situation there is a crucial difference between IPv4 "not > routed" and "IPv4 blocked by the switches." In the latter case, the > legacy smoke alarms won't work. >=20 > The flag as currently defined is "IPv4 not routed". That is less drastic > than "IPv4 blocked". It may even be helpful information for that dual > stack master alarm. Well, "IPv4 not routed by the device sending this RA". I would not expect L2 blocking as a default action of this flag being set, = but it all depends on the context of the network where it's being used. Ev= en if only IPv6 is routed externally to the LAN, I would still expect IPv4 = LL and SD to work, even when the IPv4 SD messages are likely to be duplicat= es of the same IPv6 SD messages, given a dual-stack device will typically i= ssue the same SD messages over both protocols. Tim > Regards > Brian >=20 > On 2018-09-11 09:42, Simon Hobson wrote: >> Brian E Carpenter wrote: >>=20 >>>> Then the network isn't transitioned to IPv6 only. It's rather implicit= in saying a network is IPv6 only that you have no devices left that need I= Pv4. >>>=20 >>> But the operator may or may not know that. In a large network (in parti= cular >>> with BYOD) it may even be unknowable. >>>=20 >>> This gets back to Michael Richardson's point. The operator can know for >>> sure that the network provides neither DHCP nor IPv4 routing. That's al= l the >>> flag says definitively in the current definition. Whether link-local IP= v4 >>> works is a separate issue. >>=20 >> That does not change the argument. If the network owner/operator/admin h= as decided that the network is now IPv6 only then they presumably will have= decided one or more of the following (which are really the same thing) : >> 1) They have decided that there are no devices left on the network that = need IPv4 **AND** that they are concerned about still working >> 2) They've made a business decision to not support IPv4 and if some Inte= rnet-of-Tat junk doesn't work then "someone" (it's BYOD owner for example) = will need to upgrade or replace it if they want it to work. >>=20 >> At some point, when IPv4 use is sufficiently declining, various networks= will be making such decisions - and there'll be a decision to be made as t= o where the line is drawn between the costs of continuing to support the le= gacy protocol, and the costs of dropping it. >>=20 >> So yes, it is valid to say that a network can be IPv6 only but have devi= ces that don't do IPv6. Those devices will then be broken - and if they are= needed then something will need to be done about it (such as buying one th= at's not stuck in the 20th century). If you need them to work and can't/won= 't upgrade them, then you keep IPv4 working and the network is not IPv6 onl= y - so the admin doesn't set the flag. >>=20 >> TL;DR - if you need some IPv4 devices to work then you have not transiti= oned to IPv6 only. Don't set the "no IPv4 spoken here" flag. >>=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 > -------------------------------------------------------------------- >=20 From nobody Tue Sep 11 03:23:42 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E9130934 for ; Tue, 11 Sep 2018 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 L1wz_DEPh7m9 for ; Tue, 11 Sep 2018 03:23:37 -0700 (PDT) Received: from bugle.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 E329B130DE0 for ; Tue, 11 Sep 2018 03:23:36 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id E8CA3FECBB28; Tue, 11 Sep 2018 10:23:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <0F0A2667-62B0-4E91-B67F-87D6325D69FB@jisc.ac.uk> Date: Tue, 11 Sep 2018 12:23:32 +0200 Cc: Brian E Carpenter , IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <2BF340C6-B64B-4E30-A0B5-8D5052EA68F9@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <20180907.075109.15713895.sthaug@nethelp.no> <38566B11-E38B-4C16-896C-8ED084B17949@employees.org> <485604f0-21a7-bf85-e500-bde3c47eaf2f@gmail.com> <000601d44838$d5a696a0$80f3c3e0$@ac.cn> <46111D68-4CF3-4B93-9B2F-F751A3B35838@thehobsons.co.uk> <2D09D61DDFA73D4C884805CC7865E6114DE9C3B6@GAALPA1MSGUSRBF.ITServices.sbc.com> <24692.1536588119@localhost> <0F0A2667-62B0-4E91-B67F-87D6325D69FB@jisc.ac.uk> To: Tim Chown Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 10:23:41 -0000 On 11 Sep 2018, at 12:11, Tim Chown wrote: >> On 10 Sep 2018, at 23:19, Brian E Carpenter = wrote: >>=20 >> Simon, >>=20 >>> TL;DR - if you need some IPv4 devices to work then you have not transiti= oned to IPv6 only. Don't set the "no IPv4 spoken here" flag. >>=20 >> I think that misses a subtlety. The "operator" (who may be no expert) mig= ht >> not be aware of situations like the following: >>=20 >> Some of the devices (installed long ago and forgotten) are IPv4-only smok= e >> alarms. They can use link-local IPv4 to communicate with a more modern >> dual stack master alarm, which communicates with the outside world via >> IPv6. >>=20 >> So in that situation there is a crucial difference between IPv4 "not >> routed" and "IPv4 blocked by the switches." In the latter case, the >> legacy smoke alarms won't work. >>=20 >> The flag as currently defined is "IPv4 not routed". That is less drastic >> than "IPv4 blocked". It may even be helpful information for that dual >> stack master alarm. >=20 > Well, "IPv4 not routed by the device sending this RA". >=20 > I would not expect L2 blocking as a default action of this flag being set,= but it all depends on the context of the network where it's being used. Ev= en if only IPv6 is routed externally to the LAN, I would still expect IPv4 L= L and SD to work, even when the IPv4 SD messages are likely to be duplicates= of the same IPv6 SD messages, given a dual-stack device will typically issu= e the same SD messages over both protocols. In my view this flag should not be about what the network does. It should be configuration information to the host. =E2=80=9CPlease disable I= Pv4 on the interface connected to this link. =E2=80=9C Ole >=20 >> Regards >> Brian >>=20 >>> On 2018-09-11 09:42, Simon Hobson wrote: >>> Brian E Carpenter wrote: >>>=20 >>>>> Then the network isn't transitioned to IPv6 only. It's rather implicit= in saying a network is IPv6 only that you have no devices left that need IP= v4. >>>>=20 >>>> But the operator may or may not know that. In a large network (in parti= cular >>>> with BYOD) it may even be unknowable. >>>>=20 >>>> This gets back to Michael Richardson's point. The operator can know for= >>>> sure that the network provides neither DHCP nor IPv4 routing. That's al= l the >>>> flag says definitively in the current definition. Whether link-local IP= v4 >>>> works is a separate issue. >>>=20 >>> That does not change the argument. If the network owner/operator/admin h= as decided that the network is now IPv6 only then they presumably will have d= ecided one or more of the following (which are really the same thing) : >>> 1) They have decided that there are no devices left on the network that n= eed IPv4 **AND** that they are concerned about still working >>> 2) They've made a business decision to not support IPv4 and if some Inte= rnet-of-Tat junk doesn't work then "someone" (it's BYOD owner for example) w= ill need to upgrade or replace it if they want it to work. >>>=20 >>> At some point, when IPv4 use is sufficiently declining, various networks= will be making such decisions - and there'll be a decision to be made as to= where the line is drawn between the costs of continuing to support the lega= cy protocol, and the costs of dropping it. >>>=20 >>> So yes, it is valid to say that a network can be IPv6 only but have devi= ces that don't do IPv6. Those devices will then be broken - and if they are n= eeded then something will need to be done about it (such as buying one that'= s not stuck in the 20th century). If you need them to work and can't/won't u= pgrade them, then you keep IPv4 working and the network is not IPv6 only - s= o the admin doesn't set the flag. >>>=20 >>> TL;DR - if you need some IPv4 devices to work then you have not transiti= oned to IPv6 only. Don't set the "no IPv4 spoken here" flag. >>>=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 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Sep 11 07:33:49 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF5130DD1 for ; Tue, 11 Sep 2018 07:33:48 -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 ml-4C4IlV6Xh for ; Tue, 11 Sep 2018 07:33:46 -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 2AFFD12F1A2 for ; Tue, 11 Sep 2018 07:33:45 -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 w8BDXZ2E034860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2018 14:33:36 +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 Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Ole Troan Cc: 6man WG References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> From: Nick Hilliard Message-ID: <9dd21670-de7d-90f9-d71f-402d5653da93@foobar.org> Date: Tue, 11 Sep 2018 15:33:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 14:33:48 -0000 Ole Troan wrote on 11/09/2018 07:27: > Please add if there are some I have missed. it hasn't been discussed in the context of the WGLC for this draft, but the security implications of this flag give me the heebie-jeebies. Do we need to discuss this? Nick From nobody Tue Sep 11 08:00:47 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D46130E63 for ; Tue, 11 Sep 2018 08:00:45 -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 7D12M6YHo8v8 for ; Tue, 11 Sep 2018 08:00:43 -0700 (PDT) Received: from bugle.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 20605130E7F for ; Tue, 11 Sep 2018 08:00:43 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id A9202FECBC70; Tue, 11 Sep 2018 15:00:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <9dd21670-de7d-90f9-d71f-402d5653da93@foobar.org> Date: Tue, 11 Sep 2018 17:00:26 +0200 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> <9dd21670-de7d-90f9-d71f-402d5653da93@foobar.org> To: Nick Hilliard Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 15:00:46 -0000 Nick, > On 11 Sep 2018, at 16:33, Nick Hilliard wrote: >=20 > Ole Troan wrote on 11/09/2018 07:27: >> Please add if there are some I have missed. >=20 > it hasn't been discussed in the context of the WGLC for this draft, but th= e security implications of this flag give me the heebie-jeebies. Do we need= to discuss this? Yes, most definitely.=20 We cannot publish something with heebie-jeebies security. :-) Cheers=20 Ole= From nobody Tue Sep 11 08:28:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8780A130EA2 for ; Tue, 11 Sep 2018 08:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bntBMZjImpW3 for ; Tue, 11 Sep 2018 08:28:53 -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 F1407130E93 for ; Tue, 11 Sep 2018 08:28:52 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w8BFClV8028826; Tue, 11 Sep 2018 11:28:42 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2meg538k3a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Sep 2018 11:28: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 w8BFSdDk025302; Tue, 11 Sep 2018 11:28:40 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w8BFSVHb025065; Tue, 11 Sep 2018 11:28:31 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 9E720400579E; Tue, 11 Sep 2018 15:28:31 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id 8DF5A412F80B; Tue, 11 Sep 2018 15:28:31 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.25]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 11:28:31 -0400 From: "STARK, BARBARA H" To: "'Ole Troan'" , Nick Hilliard CC: 6man WG Subject: ipv6only-flag-02 security Thread-Topic: ipv6only-flag-02 security Thread-Index: AdRJ4jpfslLYhFtzQ6qTnrhecW+klg== Date: Tue, 11 Sep 2018 15:28:30 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.255.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-11_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=344 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110154 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 15:28:55 -0000 > ... the security implications of this flag give me the heebie-jeebies I think the current draft has already done some mitigation of potential DoS= attack on hosts by saying that if at least 1 RA has the bit *not* set, the= host SHOULD NOT assume IPv6 only. Another possible mitigation that occurre= d to me is the host could try DHCPv4 for a minute before shutting down IPv4= operations (if no DHCPv4 response). If there is a DHCPv4 response, then th= e router is lying. If there is no DHCPv4 response within a minute, then eit= her the router is correct and not malicious, or there is a malicious router= that has so much control over the network that it can prevent all other ro= uter Ras from arriving at the host and it can prevent DHCPv4 messages from = succeeding. If the latter, then this flag is the least of the network's wor= ries. If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 oper= ations. The RA flag is incorrectly configured. Barbara From nobody Tue Sep 11 08:39:33 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B0130EA9 for ; Tue, 11 Sep 2018 08:39:31 -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, 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 (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 nIyS7UgYBRdJ for ; Tue, 11 Sep 2018 08:39:29 -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 910AA130EA1 for ; Tue, 11 Sep 2018 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1536680367; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/3JAajPLzck1uWU42wlscubtnKynfwRUadAXi9jVEik=; b=DwU5W5WcnbZggnESCZ8GEgFGjdIG2xhMUG/EQOl0V/jXAroE/uXXPw1zYfIDzc939nZ5/jRkYa4x6yFj0JMx9PFe9ooQs/2jV2lT9F/8Pw2/+WT9c3v3m/kkRROsVJvek5wF0korm5wrz8Izcb89W2K62UT9MbYb1h28fAJ4HLo= Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp0148.outbound.protection.outlook.com [23.103.133.148]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-30-mXgpuDqpN-yoR4XglScVJA-2; Tue, 11 Sep 2018 16:39:26 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB4498.eurprd07.prod.outlook.com (52.135.151.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.14; Tue, 11 Sep 2018 15:39:23 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 15:39:23 +0000 From: Tim Chown To: "STARK, BARBARA H" CC: Ole Troan , Nick Hilliard , 6man WG Subject: Re: ipv6only-flag-02 security Thread-Topic: ipv6only-flag-02 security Thread-Index: AdRJ4jpfslLYhFtzQ6qTnrhecW+klgAA2KSA Date: Tue, 11 Sep 2018 15:39:23 +0000 Message-ID: <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@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.3445.9.1) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4498; 20:BepkjEOF+06dM3C1GmvdReVciO3qQzPyJvV+GCanXmWu+3ToOoGEskYPAerFRncXSJun0NspGmfS39M018MWnoLyFBEm4vDebwJ6Q0felKkjwRZZHAWQO1HRwYSUP/f6qJCXoY/rN0p9zZFmZ7FX1GbRWLHKt1QbYImi9Vtm2C4= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 04fe5a65-4740-4623-7b5b-08d617fcbfe3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4498; x-ms-traffictypediagnostic: AM0PR07MB4498: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231344)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991033); SRVR:AM0PR07MB4498; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4498; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39850400004)(396003)(366004)(136003)(199004)(189003)(6346003)(26005)(33656002)(53936002)(6506007)(5660300001)(186003)(102836004)(6512007)(53546011)(6116002)(3846002)(54906003)(316002)(2906002)(786003)(256004)(6486002)(14444005)(82746002)(6916009)(229853002)(57306001)(83716003)(15650500001)(76176011)(106356001)(6436002)(74482002)(105586002)(6246003)(86362001)(97736004)(66066001)(99286004)(8936002)(486006)(8676002)(72206003)(5250100002)(2900100001)(81166006)(81156014)(4326008)(478600001)(446003)(476003)(25786009)(68736007)(14454004)(7736002)(2616005)(36756003)(305945005)(50226002)(11346002)(32563001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4498; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-microsoft-antispam-message-info: h+62Bqkwq57QHGT37LU9d4s6ak8jjwtCYL8nBNNBjKGEAzNbWMvp7CogAwpEHfGpHagCi8gGlkIQb1cG0DNfe5hR3rvONDRrHe5q+0URwzkI44FwdI2ybEnZfgrUH2jte77wwrdg+ifiu6wh1R96boxN5awqdhMXIkv5ztzBgTozkRX0BiK9YvV8RW/BfFSBXZe1X3S6/4pliXmJwnarr4qOe2naBkK04sE+xztdSxgLAgrOL5m8/WAJ32SOIvznBKluXcV9flwNBeWo93eymEKsZNdUIBx10CiIGJ8x1B0Xnfadtrnldq4RF6lElUQC0DYiAPlgAdAX+Myw21+ELRRsVo7ZYgeAjjbNUJJULn8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <15ABEFEF47BBD947832E2D0C13B2036F@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 04fe5a65-4740-4623-7b5b-08d617fcbfe3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 15:39:23.7177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4498 X-MC-Unique: mXgpuDqpN-yoR4XglScVJA-2 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 15:39:32 -0000 > On 11 Sep 2018, at 16:28, STARK, BARBARA H wrote: >=20 >> ... the security implications of this flag give me the heebie-jeebies >=20 > I think the current draft has already done some mitigation of potential D= oS attack on hosts by saying that if at least 1 RA has the bit *not* set, t= he host SHOULD NOT assume IPv6 only. Another possible mitigation that occur= red to me is the host could try DHCPv4 for a minute before shutting down IP= v4 operations (if no DHCPv4 response). If there is a DHCPv4 response, then = the router is lying. If there is no DHCPv4 response within a minute, then e= ither the router is correct and not malicious, or there is a malicious rout= er that has so much control over the network that it can prevent all other = router Ras from arriving at the host and it can prevent DHCPv4 messages fro= m succeeding. If the latter, then this flag is the least of the network's w= orries. >=20 > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 op= erations. The RA flag is incorrectly configured. Or there is a rogue DHCPv4 server? I'll see your heebie and raise you a je= ebie ;) Tim From nobody Tue Sep 11 08:40:47 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09030130EA9 for ; Tue, 11 Sep 2018 08:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 h5A8kx7Y6QvS for ; Tue, 11 Sep 2018 08:40:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 6CFB6130EAA for ; Tue, 11 Sep 2018 08:40:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G4AQAH4Zdb/wUHmMZbHAEBAQQBAQoBA?= =?us-ascii?q?YJ6VIFkMot7ji+RC4UvgXoLLIRAAoQOITQYAQIBAQEBAQECAgJpKIU6AQICARI?= =?us-ascii?q?oRA0BCA0VFEImAQQBGhqEeQgBm2GLHRoCiWiKZxeBQj6BEkaCTIQ9JRwCgzCCJ?= =?us-ascii?q?gKcEQkCkBuBMoc7A4YFlBiBQjmBVXAVgyiQUoIFjCoBgR0BAQ?= X-IPAS-Result: =?us-ascii?q?A2G4AQAH4Zdb/wUHmMZbHAEBAQQBAQoBAYJ6VIFkMot7ji+?= =?us-ascii?q?RC4UvgXoLLIRAAoQOITQYAQIBAQEBAQECAgJpKIU6AQICARIoRA0BCA0VFEImA?= =?us-ascii?q?QQBGhqEeQgBm2GLHRoCiWiKZxeBQj6BEkaCTIQ9JRwCgzCCJgKcEQkCkBuBMoc?= =?us-ascii?q?7A4YFlBiBQjmBVXAVgyiQUoIFjCoBgR0BAQ?= X-IronPort-AV: E=Sophos;i="5.53,360,1531800000"; d="scan'208";a="296989486" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Sep 2018 11:40:40 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 11:40:41 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 11 Sep 2018 11:40:39 -0400 From: "Mudric, Dusan (Dusan)" To: "ipv6@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AdRJ5coS/KxZVicxQmGgBVgiONVbqg== Date: Tue, 11 Sep 2018 15:40:39 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB5783D@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] 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.29 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 Sep 2018 15:40:45 -0000 > o Such traffic may drain battery power on wireless hosts that have > no interest in link-local IPv4 traffic. [RFC7772] indicates how > this risk might be quantified. >=20 > o Similarly, hosts may waste battery power on futile attempts to > access IPv4 services. > Is it mentioned already that a dual network can disable IPv4 using this fla= g and that way a network operator can test the migration to IPv6-Only mode?= If something goes wrong in IPv6-Only mode, the network can be turned back = into a dual mode, while IPv6-Only problems are worked on. Dusan From nobody Tue Sep 11 09:47:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57B8130E5A for ; Tue, 11 Sep 2018 09:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.188 X-Spam-Level: *** X-Spam-Status: No, score=3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 MqFaVPA0bqJz for ; Tue, 11 Sep 2018 09:47:52 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00120.outbound.protection.outlook.com [40.107.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9B2128B14 for ; Tue, 11 Sep 2018 09:47:52 -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:X-MS-Exchange-SenderADCheck; bh=6tgrFMZhbMNCHn76Y9i5kZK5uLIb3w4qVCHkrOkyKy0=; b=YIeGObpCl9X8BVn0dh4MbUzTmEqXM7eZmSUNUfBLsy/6Lk13GXeSWxC4cU+mUKlKrttoCE4+diSpcsDI8byukqB+Pt2o+7RWSeBD7BcbhKeVPDxaFW8436czAsxi4DQ+lb4UKmCGejZKtut04+K8It3oPnmNf3EKK4tjlICrprk= Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB3471.eurprd07.prod.outlook.com (10.175.244.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 16:47:49 +0000 Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::715f:f4a2:caef:d939]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::715f:f4a2:caef:d939%2]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 16:47:49 +0000 From: tom petch To: "STARK, BARBARA H" , 'Ole Troan' , Nick Hilliard CC: 6man WG Subject: Re: ipv6only-flag-02 security Thread-Topic: ipv6only-flag-02 security Thread-Index: AQHUSe8spvDnNgHjfUGLFAg4Y1ED5w== Date: Tue, 11 Sep 2018 16:47:49 +0000 Message-ID: <00e601d449ef$2597be20$4001a8c0@gateway.2wire.net> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0064.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::28) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.131.229.47] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3471; 6:4oYxBReLImV7ZM9WnrbNrZTh6fcOOk9csMZf6b1q2RuRbDV3yHFzmNfFnSLa4vPTJvJtTGEXDVhz6Pj++y8PXXuty9wgAFb08p00CBcYSsP8UfrmVtCfXFdOs2t1DXwxBA7yKO7hdcFaxm0PiG2g1cDofUFW8rV+IZz5dRmmr7Ge/Q28MIT3IQ/Ere3g5PxkF5w4LYCZ3b5p+h4ecxfST7HNRC+YuxcivBUC+DLbzpPpYvjduehIU/2EQMfh9jorgG3/U1WLbrR9O+z0VeITp2WMptG92/wD/+2vnOBhJnBI/k8iwbgAcFrMPuMwMbgawIkueyjAEeHFyn1obfqLJbNy4wwkh1pDTrmp3/ASyPJoeyBgMvkoKC5F13yGe+qkkOMz4af98UMABkDmb9C/jIuakuBNipBFGCWvgPxHh7aBg8yXQ7WCZfCOZilnNCpOGjZs65G/ObVMWGjk9hmqqQ==; 5:hoyUmrrDg2m7lCR53XdnrgxgTSitEfAbaOS7nPaF1tkvMLePI7Yui+GmowLDbVtTdWMlhMRhzPNumu0FAU4Qye8y01mQ+4d3QeNSUuu55PSbF5aQPygNIucAdh59Tz7hoJyzevrmxxJuJPYfBAfUbKdDRby19DU9xgHgiuPND5Q=; 7:ThAfTD8B+P6j+D1ZIwQINGDRKb9uxWafqePs/E1j3Jidkl/ZZNJgrx6FBirQM2Uock2wuyRSvvXRLxqOa4yULCEKalHgywSmb2VWs/orvssokq7CZ2edVSJqx9Y7Kv+nFQtob+r39ZPQZlwVAN1V1oku5P8kRTeWG+x1VEkqAGEBUPfFjIozC5foaYyBEfiY+krldtMAG56tAkNEXlMuTINUn2oimIkGe2vffZUtH2/ZnBAM3CEKpa9dPMcipvCX x-ms-office365-filtering-correlation-id: 859d8e00-01a1-4e22-dc7e-08d618064ed5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB3471; x-ms-traffictypediagnostic: VI1PR07MB3471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(97927398514766); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:VI1PR07MB3471; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3471; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39860400002)(396003)(366004)(51444003)(13464003)(189003)(199004)(33896004)(25786009)(3846002)(15650500001)(2900100001)(110136005)(446003)(66066001)(316002)(6116002)(68736007)(386003)(84392002)(76176011)(2906002)(8676002)(478600001)(6506007)(102836004)(4326008)(6246003)(99286004)(52116002)(186003)(105586002)(14454004)(256004)(106356001)(486006)(86362001)(7736002)(97736004)(966005)(476003)(6486002)(44736005)(9686003)(6306002)(86152003)(229853002)(1556002)(6512007)(5660300001)(53936002)(5250100002)(305945005)(6436002)(8936002)(81156014)(81166006)(14444005)(26005)(14496001)(32563001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3471; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 31iyFI0SVkD5Jxf6xOuorb++ulLjGgY8BvtqXIIyAiC1fIyFFpWiSUN4gxAcekPhbj72l4GPMz1YHPSJ2QbClhf4GvSXiv6XM1dv7FA5WK59uq5I9hgDQ6FIusjms/KPWxxYVMnLUg3T5niJzsA43Z87Mt7jDg1BF6xmz0biAnCsUu0BAbDM27z95+lHizWibrmpDqRyOWghX2/AMZcKaQcBjkTTbWTstM3eilZqXjr3Fy8FvQolCLFTAIkIkIw0OzP9/9o4rhgDJYytMfWTPwK0EyWrBfzV9tvOFTCQMqIC6Mkmg4PtXKrbvgrGNlKWo+LRhMczdKQM95yEL0LxjOrSa7NFOVdxgjr/83WxglE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 859d8e00-01a1-4e22-dc7e-08d618064ed5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 16:47:49.5936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3471 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 16:47:55 -0000 ---- Original Message ----- From: "STARK, BARBARA H" To: "'Ole Troan'" ; "Nick Hilliard" Cc: "6man WG" Sent: Tuesday, September 11, 2018 4:28 PM Subject: ipv6only-flag-02 security > > ... the security implications of this flag give me the heebie-jeebies > > I think the current draft has already done some mitigation of potential DoS attack on hosts by saying that if at least 1 RA has the bit *not* set, the host SHOULD NOT assume IPv6 only. Another possible mitigation that occurred to me is the host could try DHCPv4 for a minute before shutting down IPv4 operations (if no DHCPv4 response). If there is a DHCPv4 response, then the router is lying. If there is no DHCPv4 response within a minute, then either the router is correct and not malicious, or there is a malicious router that has so much control over the network that it can prevent all other router Ras from arriving at the host and it can prevent DHCPv4 messages from succeeding. If the latter, then this flag is the least of the network's worries. > > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 operations. The RA flag is incorrectly configured. Or a bad actor has access to the link and has injected a malicious DHCPv4 response in order to deceive those who would rather not bother with IPv4.. I think that the current Security Considerations spell out the possibility of bad actors quite well and do not understand what other threats the instigators of this thread have in mind. Tom Petch > Barbara > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Sep 11 11:04:15 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A60128BAC for ; Tue, 11 Sep 2018 11:04: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, 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 IvYbPx3v_RCV for ; Tue, 11 Sep 2018 11:04:12 -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 3AF11130EDA for ; Tue, 11 Sep 2018 11:04:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3102820090 for ; Tue, 11 Sep 2018 14:23:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6603182; Tue, 11 Sep 2018 14:04:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 622D77C for ; Tue, 11 Sep 2018 14:04:11 -0400 (EDT) From: Michael Richardson To: "ipv6\@ietf.org" Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB5783D@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E459CB5783D@AZ-US1EXMB03.global.avaya.com> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 18:04:14 -0000 --=-=-= Content-Type: text/plain {BTW, on the subject-line topic: I have read ipv6only-flag-02. I find the Security Considerations do not give me any heebies or jeebies. The last paragraph could be split off into a Privacy Considerations though} === onto the subject of this thread: Mudric, Dusan (Dusan) wrote: >> o Such traffic may drain battery power on wireless hosts that have no >> interest in link-local IPv4 traffic. [RFC7772] indicates how this >> risk might be quantified. >> >> o Similarly, hosts may waste battery power on futile attempts to >> access IPv4 services. > Is it mentioned already that a dual network can disable IPv4 using this > flag and that way a network operator can test the migration to > IPv6-Only mode? If something goes wrong in IPv6-Only mode, the network > can be turned back into a dual mode, while IPv6-Only problems are > worked on. In particular, it's probably easier and less risky to set/unset the ipv6-only flag than it is install/remove IPv4 L2 filters! Since only newer devices will even implement the flag, it's pretty certain that they will have other modern patches. The IPv4 ARP table now gives the operator a list of devices that didn't respect the flag and/or might be IPv4-only. And thus an enterprise operator (like a university) can see if that network is ready for IPv6-only operation quite easily. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluYA5sACgkQgItw+93Q 3WVDagf8CPzUYPG2ym2N9+4+735X+JnlQDO0PaHG+jMhKn2ZSKJdXCLNwbUQantM qRmmOauoqlTZDcq6BXlMkUyHyM2EHAu2Mc5CYzRo9d6/ezZfcE8y8ffpHA6n3Bv9 HDvW3wDqHWjgoYcf/iJhK+n7ZIPAl912m9QYniTBS8YvGnFyirG4hrJevA4LSIQP jYyDpdKydbvYfR9Fff1dzssHijXJplqTXcRlAWZ2KPe1oqiHTBY1JW/Ytj3LsNe6 8uWg+6t3nxNnu3fImE5zPLY27LRPM5QW657iWRiC4jH8xsxrEanPgwAF1AVziDgM dEQipKe6CD7XbqERiIEjC/R8e7uz5g== =eEVc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 11 11:08:24 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40B3130F8B; Tue, 11 Sep 2018 11:08:18 -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 geqV4Lq4bqmr; Tue, 11 Sep 2018 11:08:16 -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 11C811310F3; Tue, 11 Sep 2018 11:08:16 -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 w8BI8Fh4038198; Tue, 11 Sep 2018 11:08:15 -0700 Received: from XCH15-01-09.nw.nos.boeing.com (xch15-01-09.nw.nos.boeing.com [137.136.239.185]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w8BI86kj037754 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 11 Sep 2018 11:08:06 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-09.nw.nos.boeing.com (137.136.239.185) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Sep 2018 11:08:05 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Tue, 11 Sep 2018 11:08:05 -0700 From: "Manfredi (US), Albert E" To: Ole Troan CC: 6man WG , 6man Chairs <6man-chairs@ietf.org> Subject: RE: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Topic: WGLC: draft-ietf-6man-ipv6only-flag-02 Thread-Index: AQHUSVShYYAcCkkXCkuQik7ziFc4naTq+LUAgAAIBoCAABL2gIAAS/Ng Date: Tue, 11 Sep 2018 18:08:05 +0000 Message-ID: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> In-Reply-To: <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> 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] x-tm-snts-smtp: 675268DF1B80DB13A2F12320D16EFA32275A5E5EB7C7393DB6A75024B87ED2AC2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 18:08:23 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgPGlwdjYtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIE9sZSBUcm9hbg0KDQo+IFJpZ2h0LiBUcnlpbmcgdG8gY2F0ZWdv cml6ZSB0aGUgY29tbWVudHM6DQo+DQo+IDEpIE5vdCBkZXBsb3kuICBUaGlzIGRvZXNu4oCZdCBm aXQgd2l0aCBvdXIgbW9kZWwgb2YgbmV0d29yayBvcGVyYXRpb25zLiANCj4NCj4gMikgTm8gbmVl ZC4gSXTigJlzIHN1ZmZpY2llbnQgdG8gYmxvY2sgSVB2NCB0cmFmZmljIGluIHRoZSBuZXR3b3Jr IGFuZCBubyBuZWVkIHRvIHNpZ25hbCBob3N0cy4gDQo+DQo+IDMpIEltcGxpY2F0aW9ucyBvZiBm bGFnLiBEb2VzIHRoZSBmbGFnIG1lYW4gYW4gSVB2NiBvbmx5IGxpbmssIGllIG5vIElQdjQgcGFj a2V0cyBvbiBpdCBvciBkb2VzIGl0IG9ubHkgbWVhbiB0aGF0IHJvdXRlcnMgZG9u4oCZdCBmb3J3 YXJkIElQdjQuDQoNCkkgbWlnaHQgbW9kaWZ5IDIgc2xpZ2h0bHksIHRvIHNheSwgIkl0J3Mgc3Vm ZmljaWVudCB0byBibG9jayBJUHY0IHRyYWZmaWMgYXQgbGF5ZXIgMiwgYW5kIGhhdmUgdGhhdCBi bG9ja2luZyBhY3QgYXMgYW4gaW1wbGljaXQgc2lnbmFsIHRvIGhvc3RzLCB0aGF0IHRoZSByb3V0 ZXIgaXMgbm90IGZvcndhcmRpbmcgSVB2NCBwYWNrZXRzLiIgKFRpbWVycyBpbiBob3N0cyB3b3Vs ZCBoYXZlIHRvIGJlIG1vZGlmaWVkIHRvIG1ha2UgdXNlIG9mIHRoaXMuIE9uIHRoZSBvdGhlciBo YW5kLCBhIG5ldyBmbGFnIHdvdWxkIGFsc28gaW52b2x2ZSBjaGFuZ2VzIHRvIGhvc3RzLikNCg0K T25lIGNvdWxkIGNvbmNlaXZhYmx5IG5vdCBibG9jayBhbGwgdGhlIGludGVybmFsIHRyYWZmaWMg YXQgbGF5ZXIgMiwgYnV0IG9ubHkgd2hhdCBpcyBzZW50IHRvIHRoZSByb3V0ZXIgaXRzZWxmLiBT byBpbiBhIGhvbWUgbmV0LCBwb3RlbnRpYWxseSwgdGhlIGxheWVyIDIgc3dpdGNoIHBhcnQgb2Yg dGhlIG1vZGVtL3JvdXRlciBjb3VsZCBhbGxvdyAweDgwMCBhbmQgMHg4MDYgdGhyb3VnaCB0byB0 aGUgb3RoZXIgaW50ZXJuYWwgcG9ydHMsIGJ1dCBibG9jayB0aG9zZSB0byB0aGUgcm91dGVyLCBw cmV2ZW50aW5nIERIQ1AgZnJvbSB3b3JraW5nIGFuZCBwcmV2ZW50aW5nIHRoZSBkZWZhdWx0IHJv dXRlciBNQUMgYWRkcmVzcyB0byBiZSBmb3VuZCwgZm9yIElQdjQgcm91dGluZy4NCg0KQmVydA0K DQo= From nobody Tue Sep 11 11:14:38 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E8D130EDA for ; Tue, 11 Sep 2018 11:14:37 -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 Lgu9-NLG4xFT for ; Tue, 11 Sep 2018 11:14:34 -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 CEDA31292F1 for ; Tue, 11 Sep 2018 11:14:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E143120090; Tue, 11 Sep 2018 14:33:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1ED1E82; Tue, 11 Sep 2018 14:14:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1BBD57C; Tue, 11 Sep 2018 14:14:34 -0400 (EDT) From: Michael Richardson To: "STARK\, BARBARA H" cc: "'Ole Troan'" , Nick Hilliard , 6man WG Subject: Re: ipv6only-flag-02 security In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 18:14:37 -0000 --=-=-= Content-Type: text/plain STARK, BARBARA H wrote: >> ... the security implications of this flag give me the heebie-jeebies > I think the current draft has already done some mitigation of potential > DoS attack on hosts by saying that if at least 1 RA has the bit *not* > set, the host SHOULD NOT assume IPv6 only. > Another possible mitigation > that occurred to me is the host could try DHCPv4 for a minute before > shutting down IPv4 operations (if no DHCPv4 response). If there is a > DHCPv4 response, then the router is lying. Or, an attacker is running a rogue DHCPv4 server, and is planning to examine all the traffic that passes through. Since the IPv6-only network probably has NAT64 somewhere, the rogue can easily arrange to do stateless translation and make the connection look good. (remember, this can be configured by mistake on a number of desktop OSs by mistake, rather than malicious intent and it's rather common in many networks) Is it likely that an attacker would be aware of the NAT64, and yet not aware that they can spoof the RA ipv6-only=0? That seems to dumb to me, but then script kiddies often make such mistakes. > If there is no DHCPv4 > response within a minute, then either the router is correct and not > malicious, or there is a malicious router that has so much control over > the network that it can prevent all other router Ras from arriving at > the host and it can prevent DHCPv4 messages from succeeding. If the > latter, then this flag is the least of the network's worries. Agreed. > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 > operations. The RA flag is incorrectly configured. Barbara I don't agree. If all the RAs have ipv6-only set, and there is still DHCPv4, I'd conclude that the IPv4 is fake. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluYBgkACgkQgItw+93Q 3WW5Kgf8DdNyqzeHtXty1oa84ZiTO4EEjzDYz/zCSWJzFKd5VFuxA2lVNkrS57sj I5WxnXyUsp3L00IY1iazzN5uKNHp0DffykkYK1zm5MYKdzPB94ksWuaKlj6gqHt1 eJbvUARHZULSAzTujEwAGHTEKFRoN4uKTxe6bKy0saVYL3QPl1PtvrFF5D3zKaPZ K6pj+JlPJ9aRHSjQuG5ieddvOnETKYu7sRyBoijNtRSEcIq4uQxxojj3KPvdi685 wAlWgF4JjGEhUjBq63qGaQR3ANLPgdZL+u/+uc2p6nhUTeQN7O00EgDf9w+/V++q xRY0JFLQcnSSCK6BG735D/E0oCk48A== =2KNl -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 11 11:31:02 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7031310A8 for ; Tue, 11 Sep 2018 11:30:54 -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 twMbkbpc7uwY for ; Tue, 11 Sep 2018 11:30:52 -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 BAA55130F2D for ; Tue, 11 Sep 2018 11:30:52 -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 w8BIUp4K012811; Tue, 11 Sep 2018 11:30:52 -0700 Received: from XCH15-01-12.nw.nos.boeing.com (xch15-01-12.nw.nos.boeing.com [137.136.239.188]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w8BIUhLq012371 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 11 Sep 2018 11:30:43 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-12.nw.nos.boeing.com (137.136.239.188) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Sep 2018 11:30:43 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Tue, 11 Sep 2018 11:30:43 -0700 From: "Manfredi (US), Albert E" To: Michael Richardson , "STARK, BARBARA H" CC: 6man WG Subject: RE: ipv6only-flag-02 security Thread-Topic: ipv6only-flag-02 security Thread-Index: AdRJ4jpfslLYhFtzQ6qTnrhecW+klgAU7y4AAA5IPaA= Date: Tue, 11 Sep 2018 18:30:42 +0000 Message-ID: <1b3a5f9f1a554708af0d36147fbce9c2@XCH15-01-07.nw.nos.boeing.com> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> In-Reply-To: <19297.1536689674@localhost> 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] x-tm-snts-smtp: E6DDC88453D31DCA493527228E05B13066CB839F65DC80B689AFB80C62286C892000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 18:31:01 -0000 -----Original Message----- From: ipv6 On Behalf Of Michael Richardson STARK, BARBARA H wrote: >> Another possible mitigation >> that occurred to me is the host could try DHCPv4 for a minute before >> shutting down IPv4 operations (if no DHCPv4 response). If there is a >> DHCPv4 response, then the router is lying. > > Or, an attacker is running a rogue DHCPv4 server, and is planning to > examine all the traffic that passes through. Going back to the filter at layer 2 option, blocking all internal ARP and I= Pv4 in the internal switch solves that problem. As to rogue DHCPv4 servers = or even rogue routers, I think you cannot ultimately get away from having t= o do security the right way, if things are that bad. Which means, encryptio= n and authentication. Anyone can add such rogue devices in a network, no ma= tter flag or no flag, or layer 2 blocking or no. Bert From nobody Tue Sep 11 12:23:11 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF70130F12 for ; Tue, 11 Sep 2018 12:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 LUevm73uq0dZ for ; Tue, 11 Sep 2018 12:23:07 -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 CFDD3130F0F for ; Tue, 11 Sep 2018 12:23:06 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id t39-v6so29468112qtc.8 for ; Tue, 11 Sep 2018 12:23:06 -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=4DQjvjTPr8KT6h5DqP50zpMtJs076CKX1/wVryouOOU=; b=bcdrGIN9JduWwwGTSSXgqU18JDyvHBY0OuaO+rIHaY6p2ieanRbzIQYVIMZp1SI7SX gWIUGHT5uvrnqtTyVBN4ZG3JkDUwn+l3XBR24AWlB93+NkBr4BouQF87QE1GDTNbGskl iVemqSYLONMgVeWmgab+VMW2DLXOcNYwQ9wt7tRGOO3mgcEx+obuHyfQ74d+3O1X8L8S 2xWbt995JP5FzP4pzq/O643CWYVtlz0Qt717eXLnxqSHV3z9om1HZFEvOs5rBm3xWyt2 lqr6T8sFQSVbuuT9ErflsK2TM4I4mGIoyTIv5IAjZaFzvDg4SEPYP/sMjE1HF8yj1b9t zU5Q== 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=4DQjvjTPr8KT6h5DqP50zpMtJs076CKX1/wVryouOOU=; b=uC8MGypugtRZQxcFWGC2z6euGcrgd1JmbKh9fKSXrK62llSKEcgbR/NXspAAxD2rPr dDVxDQL0H6nmSfUxmxbG1Of7MAF4GuPHi5bC/oJlXm2tj7qCgQorFcLqSqLfsqmfiVOq GoVzmC8fJJbSiCGajlxBc44pCNmbMmvmPLOQd1/OOoIjNo0ACDG59TpASXnl2Av83KwJ omuZGpVuge1GviyfKrgUuOLTrJMzACB6IQmQq80nXFxUJljh4yrey3G4GsMQsn1ohAOa 3TrJC6vLcQpgbo7t3K5giF74Q8IvJJ4c3O5VwmQu/71dG9uzeEbMwlOWNdLqr5q1yjpF auZA== X-Gm-Message-State: APzg51AvjjfosWbPhG58w4d6JmYWqLfDc+l4BXildR2iFJ+gJi3Gpsnx JrmEnM6rCnpDSvtrOnrNj90Z/NQ3i5RNCv7woULTfQ== X-Google-Smtp-Source: ANB0VdYE5cNzJqauPqDhOl5aX/kK+8/Dh3wS3K9Umiwg8pttHtfpIeNK4wst77k5NynybQHBw6kDEbFrQb0D5Pyiex8= X-Received: by 2002:a0c:bd0e:: with SMTP id m14-v6mr19683715qvg.168.1536693785751; Tue, 11 Sep 2018 12:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 12:23:04 -0700 (PDT) In-Reply-To: References: <837265C7-AF4A-4E78-A7B4-5D4AE5C38C8A@employees.org> <970CDF5C-1E76-4241-9BCA-B053F637DE40@employees.org> From: Tom Herbert Date: Tue, 11 Sep 2018 12:23:04 -0700 Message-ID: Subject: Re: Comments on draft-herbert-ipv6-update-dest-ops To: Brian E Carpenter Cc: Ole Troan , "C. M. Heard" , 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.29 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 Sep 2018 19:23:10 -0000 On Mon, Sep 10, 2018 at 6:27 PM, Brian E Carpenter wrote: > A bit late to the party, but I have a few words to add: > On 2018-08-22 03:09, Tom Herbert wrote: >> On Tue, Aug 21, 2018 at 3:55 AM, Ole Troan wrote: >>> Hi Tom, >>> >>>>>>>> Consider the folling scenario: >>>>>>>> >>>>>>>> Someone is developing a new Destination Option that might be of >>>>>>>> interest for use with tunnels and might even become one of those >>>>>>>> options "that makes sense to support" . Maybe it's an option for t= henaforementioned insitu-OAM, or maybe a general packet CRC, etc. The >>>>>>>> developer dutifully uses experimental option type 0x1e for the typ= e >>>>>>>> value of their option to test it. In particular, the action taken = if >>>>>>>> the option is unknown to a receiver is to skip over it. They made = that >>>>>>>> choice because that allows incremental deployment of the support f= or >>>>>>>> the option in any combination supporting sending side or receivers= . In >>>>>>>> other words, they don't want a flag day for the option that requir= es >>>>>>>> all nodes to support the new option. >>>>>>>> >>>>>>>> Now they go to test backwards comapatbility of the option by sendi= ng >>>>>>>> it to a node that hasn't been updated to receive it. If the receiv= ing >>>>>>>> node is a Linux system, then the option is ignored and the tunnele= d >>>>>>>> packet is processed as before-- expected behavior per the spec. >>>>>>>> However, if it's sent to a VPP node then the packet is dropped-- n= ot >>>>>>>> expected. Even if this doesn't lead to incorrectness, it does brea= ks >>>>>>>> interoperability and violates "be liberal in what you receive". Th= is >>>>>>>> net effect is that this makes development, test, and pilot deploym= ent >>>>>>>> of new options really hard. Just implementing the TLV loop, even i= f >>>>>>>> the implementation doesn't process any of them, would resolve this= . >>>>>>> >>>>>>> Absolutely. The set of _optional_ destination options would benefit= from this approach. >>>>>>> Of which we have none. I=E2=80=99d much rather just implement new o= ptions as they come available (if they ever will) >>>>>> >>>>>> Ole, >>>>>> >>>>>> I'm not sure what "comes available" mean here. Does that mean VPP >>>>>> would only support TLVs parsing once one becomes standardized and th= e >>>>>> VPP maintainers think is worth supporting? As shown in the scenario >>>>>> above, with that approach its difficult to develop optional TLVs if >>>>>> implementations don't properly skip over them. >>>>> >>>>> No, don=E2=80=99t get me wrong. >>>>> As in any open source project you are welcome to provide a patch, and= I=E2=80=99m pretty sure it would get in. >>>>> >>>> I would, but for me VPP code is very hard to decipher. For someone who >>>> knows the code this should be relatively easy. The ip6_parse_tlv (in >>>> net-next/net/ipv6/exthdrs.c) function does this in Linux in < 100 LOC. >>>> It's straightforward, supporting padding, unknown options, and limits. >>>> >>>>> That said since we=E2=80=99re talking about tunnels, and in those cas= es you generally know whom you are talking to, I=E2=80=99m not sure I buy t= he argument that would make deploying new destination options harder. It=E2= =80=99s not like a tunnel head end accepts traffic from random sources arou= nd the Internet (well, we=E2=80=99ve tried that with stuff like RFC1933, 6t= o4 and so on, but that didn=E2=80=99t quite pan out). >>>> >>>> I'm not sure this is just about tunnels. It looks like VPP can also >>>> support TCP connections (there's a reference on web to HTTP server for >>>> VPP) as well as UDP sockets, and VPP also can do classification, NAT, >>>> and other firewall functions. Do you know if VPP properly handle >>>> Destination Options in these cases? >>>> >>>> I'm afraid this might be an example of an implementation deployed on >>>> middleboxes in the Internet (like firewalls) that arbitrarily drop >>>> packets because they have a DestOpts extension header (RFC7872). >>>> That's exactly a principle reason why Destination Options are unusable >>>> on the Internet, and hence why there's been so much effort to avoid >>>> using them and no one bother's trying to create "useful" options. This >>>> is an example of death of a good protocol feature by undermining it >>>> with a thousand arbitrary decisions on what parts of the spec to >>>> implement or not. >>>> >>>> This goes goes back to a major rationale for this draft. If an >>>> implementation really doesn't want to implement the TLV loop for >>>> processing options then so be it, but then at least they should skip >>>> over the options instead of just dropping the packet so as not to kill >>>> the feature for everyone else. >>> >>> You have at least 4 arguments going at once here. >>> >>> 1) How to deal with destination options on intermediate devices termina= ting and forwarding traffic (tunnels, source routing) > > The words "destination option" and "marked to be changeable" in the same > sentence make my head hurt. Hi Brian, Yeah, I liken trying to resolve this to interpreting the meaning single obscure phrase in a consititution a hundred years after the fact! > So I think that indeed 8200 needs clarifying > on this, much as the draft says: if the option *precedes* the routing hea= der > it's intended to be processed by the intermediate forwarder. Is section 3 of the draft not clear on this? > (As a side > question, should that forwarder be entitled to remove the option complete= ly, > as well as to modify it?) My interpretation of RFC8200 is that if an option (HBH or Dest Opt) is marked changeable, then only the option data may change. Length and type cannot change, Options cannot be added nor deleted, and neither can extension headers be added nor removed, nor their lengths change. I think these requirements must be strict to achieve proper accountability in IP. For instance, if an intermeidate node makes some change to a packet field outside of what the sender has declared changeable, and if the change causes an error in a dowstream node, an ICMP error might be sent with a pointer to change data. The problem is that the ICMP error is sent to the source address not the party that made the change. The source might be able to deduce that the packet was changed and that caused the error, but would have no idea who actually made the change or how to prevent them from continuing to do that in subsequent packets. Does this need clarification in the draft? > But apart from that, "changeable" is a nonsense > for a *destination* option and should be forbidden. > I'm not sure what forbidden would mean at least beyond what second paragraph describes. If someone marks a destination option a changeable in dest opts that is after a routing header or no routing header, then that is ignored (except for the auth header interaction). It's still legal to set the bit in that case. Does this paragraph need further clarification? Tom >>> 2) Dealing with destination options when terminating traffic as a host > > That seems clear cut. > >>> 3) Dealing with destination options when acting as a layer violating mi= ddlebox. >> >> Note that that RFC8200 doesn't distiguish any of the cases. Per the >> spec there is no difference between a tunnel endpoint and a end host >> in how they are supposed to process Destination Options. Neither is >> there is any difference between how a hardware and software >> implemenation of protocol is supposed to work. Middleboxes that aren't >> destinations of a packet aren't supposed to be looking at Destination >> Options header at all. > > +1 > >> >>> 4) Why after 20 years aren=E2=80=99t there any =E2=80=9Cuseful=E2=80=9D= destination options created? >> >> One could also argue that IPv6 itself has gotten enough traction until >> recently to warrant interest in the creating them. > > +1. > >> >> All these fall under the same root problem, namely how do we undo the >> effects of non-compliant implementations for core protocol features >> (i.e. Destination Options in this case). It seems like there's three >> alternatives: abandon trying to use the feature and try to do >> something else to get the functionality, fix implementations to be >> compliant, change protocols to adapt to reality of implementation that >> best preserves the feature. > > There's a 4th alternative hiding in draft-carpenter-limited-domains-03. > Namely, only use them where they actually work. > > Brian > >> VPP is an example of an implementation that should simply be fixed to >> be compliant (I have taken that up with the VPP developers). This >> draft updates processing of Destination Options before the Routing >> header relax the requirements similar to how this was does for >> Hop-by-Hop options. It makes the assumption that some intermediate >> devices in a routing list won't processing the Destination Options per >> the current specification. That assumption seems to be true for VPP, >> and it seems like that some other implementations will also not be >> processing them ostensibly because of performance hit and processing >> cost. >> >> Tom >> >>> Best regards, >>> Ole >>> >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From nobody Tue Sep 11 13:07:35 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13090130F1F for ; Tue, 11 Sep 2018 13:07:32 -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, 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 qc-0FPouH4AI for ; Tue, 11 Sep 2018 13:07:30 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF97130EB5 for ; Tue, 11 Sep 2018 13:07:30 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id t68-v6so49654332oie.12 for ; Tue, 11 Sep 2018 13:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zrPrUEHyBIp80Y9rVZfoGdiPPd1007JSI1CtrYynupQ=; b=IvSiQxYQppX2unUjDOtzEEf/pfpsi8B30/j/k/zbH6UAUC73OD/m/mnV28QU+CxE6M n+i1fgi0LNKk34KF6nt9OSv/cdPIjAo5IcOw1gQo0apspDjUSzj30O9lbbKHxUPL5fDX gYcRv1CkGV7/ByHQMed2V49idvrKCug41yRcwZMzodwV7vVwvRmPzs04r147GJgZPe9a N2iOI6wFkrn0sOx/kDDJ6Eq/peBHS0Yo6Z6zLXSWBpRLSWOu1ney6PXkNcLr0slKiyKB HsYrefLjG+WNt2vMBgGKN51smkXwDuoFiegOY5rNJDjfWck4bj8L2YnkDBEwDN9UxJ8f bHEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zrPrUEHyBIp80Y9rVZfoGdiPPd1007JSI1CtrYynupQ=; b=p7JYceopkOcIZvx3f36oAQcxZTzR7vwa3FslaSOaTpVmGlfI837rzPuJRt9j50ymBq 6j0x+zXJDKKWr/uRHF2TvkQQlP/Qp19PHetjLvebyiJJ9/nhveKTa7qZp/L82GlP767w Bd6MJTP/sj207So6qkvB1A9PQNQrVlOWY+cpNs1t7F4NtxIQkL/4jRW6T/m/6S+ZKLzZ ziU1rsKzDuhjxX7wGmixU0qV8PMWdawobO3MBF0114SDwmgwpfwwAAAvHYYAMErOWw/k zYhfxxDv89e9LN706/yuw8+Ps1935lsYysowEV4IOVmMd5uOHLx1f0peaGvWtIs8hXi5 uyFQ== X-Gm-Message-State: APzg51CALkIekuhUdPci3UnKXeL7zt4NMQioEhncgFKG4p1dMw3gEMHs gy0DDxgMCyAYEgb6HOEQ/bVT1JF8rRY4UZUaGj8= X-Google-Smtp-Source: ANB0VdaTWR3hRYp/c6fDHcfenH85pNwl5kRICEwMtjqunHSTIQ8T8q+b6dM8QGA+JRzslLSl2Sc5nuNjR8PJygtJjC8= X-Received: by 2002:aca:cf97:: with SMTP id f145-v6mr29415677oig.131.1536696449883; Tue, 11 Sep 2018 13:07:29 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> In-Reply-To: <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> From: Mark Smith Date: Wed, 12 Sep 2018 06:07:03 +1000 Message-ID: Subject: Re: ipv6only-flag-02 security To: Tim Chown Cc: "STARK, BARBARA H" , 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.29 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 Sep 2018 20:07:32 -0000 On Wed, 12 Sep 2018 at 01:39, Tim Chown wrote: > > > On 11 Sep 2018, at 16:28, STARK, BARBARA H wrote: > > > >> ... the security implications of this flag give me the heebie-jeebies > > > > I think the current draft has already done some mitigation of potential= DoS attack on hosts by saying that if at least 1 RA has the bit *not* set,= the host SHOULD NOT assume IPv6 only. Another possible mitigation that occ= urred to me is the host could try DHCPv4 for a minute before shutting down = IPv4 operations (if no DHCPv4 response). If there is a DHCPv4 response, the= n the router is lying. If there is no DHCPv4 response within a minute, then= either the router is correct and not malicious, or there is a malicious ro= uter that has so much control over the network that it can prevent all othe= r router Ras from arriving at the host and it can prevent DHCPv4 messages f= rom succeeding. If the latter, then this flag is the least of the network's= worries. > > > > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 = operations. The RA flag is incorrectly configured. > > Or there is a rogue DHCPv4 server? I'll see your heebie and raise you a = jeebie ;) > As observed, this is really just another example of a rogue packet that can disrupt other hosts' operation. People are already tolerating and accepting this type of risk already when they attach multiple untrusted hosts to a mutual trust multi-access link layer. Point-to-point physical or logical link and IPv6 prefix per individual host, isolating them entirely from all other hosts, is the only way to fully mitigate all these issues. There could be some specific mitigations for this risk, however it it is not a new risk. Regards, Mark. > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Sep 11 13:55:25 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72F130DF1 for ; Tue, 11 Sep 2018 13:55:23 -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 XeFR7H56z_ZW for ; Tue, 11 Sep 2018 13:55:21 -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 903C2130DE4 for ; Tue, 11 Sep 2018 13:55:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DC58220496 for ; Tue, 11 Sep 2018 17:14:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AC02E82; Tue, 11 Sep 2018 16:55:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A8FE67C for ; Tue, 11 Sep 2018 16:55:20 -0400 (EDT) From: Michael Richardson To: ipv6@ietf.org Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 In-Reply-To: References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 20:55:23 -0000 --=-=-= Content-Type: text/plain >>>>> ipv6 < On Behalf Of Ole Troan> writes: Manfredi (US), Albert E wrote: > I might modify 2 slightly, to say, "It's sufficient to block IPv4 > traffic at layer 2, and have that blocking act as an implicit signal to > hosts, that the router is not forwarding IPv4 packets." (Timers in > hosts would have to be modified to make use of this. On the other hand, > a new flag would also involve changes to hosts.) That actually won't work automatically in many hosts today. Many hosts/UIs have a set of flags that today says: [x] IPv4 required for this connection to be valid. [ ] IPv6 required for this connection to be valid. This works just fine with Dual-Stack, or IPv4 only. If you block IPv4 "implicitely", then with this makes the connection mysteriously fail. The ipv6-only flag makes it clear that this combination isn't going to work, and the OS can either suggest something different, or could even be told to automatically swap this for new connections. The flag is useful, even if all it does is put up a dialogue box the first one it is used that: "This network is 128-bit. Yeah!" -- ] 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----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluYK7gACgkQgItw+93Q 3WVyxwf/cS/16KR1rF/vVYhHA2Z6DzA41lePHFngm0CZmBjJOlg4rY9zZnM5UEBG Ju9tSOpIpZG0ar3FhxTeiErIrUqljMJEg4ZVfd9w6BjuBXow66f/7ddzS2TtbuCP UfRfPPTXv1cI0aI6dqUQc7wiFT0thXsLp3j0BlIaIZ90nG/Uism+9DN+20kclB8T IOjiBBL9WKKKYbpfoSyJhH7u2W6mXuXM59flEP1pjVu5JvOarm6/e6oe205p0Y05 RF4JlI2JfsiH68J/aKfMQrqilV3kMhfBJZ+8J8joV/ljSXZimIW7lFlVPf10B228 6CwuqUyW3x2eaGREAGLYWh388hhuKQ== =7kNQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 11 14:05:24 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C814130DE4 for ; Tue, 11 Sep 2018 14:05:23 -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 fyaTOsKWfvuN for ; Tue, 11 Sep 2018 14:05:21 -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 8F98F130ED2 for ; Tue, 11 Sep 2018 14:05:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 524F820496 for ; Tue, 11 Sep 2018 17:24:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2115082; Tue, 11 Sep 2018 17:05:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1E76D7C for ; Tue, 11 Sep 2018 17:05:20 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: ipv6only-flag-02 security In-Reply-To: <1b3a5f9f1a554708af0d36147fbce9c2@XCH15-01-07.nw.nos.boeing.com> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <1b3a5f9f1a554708af0d36147fbce9c2@XCH15-01-07.nw.nos.boeing.com> X-Mailer: MH-E 8.6; nmh 1.7+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.29 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 Sep 2018 21:05:23 -0000 --=-=-= Content-Type: text/plain >>>>> ipv6 < On Behalf Of Michael Richardson> writes: Manfredi (US), Albert E wrote: >>> Another possible mitigation that occurred to me is the host could try >>> DHCPv4 for a minute before shutting down IPv4 operations (if no >>> DHCPv4 response). If there is a DHCPv4 response, then the router is >>> lying. >> >> Or, an attacker is running a rogue DHCPv4 server, and is planning to >> examine all the traffic that passes through. > Going back to the filter at layer 2 option, blocking all internal ARP > and IPv4 in the internal switch solves that problem. Yes, it does, provided you can control block every single layer-2 device. If not, you get islands where IPv4 LL continues to work, and people might not even know that IPv4 was turned off, or that their printer is obsolete. The feature to block specific ethertypes is rare among comodity APs that you find in coffee shops, or homes. Plain old unmanaged ethernet switches are found in quite a number of unexpected places, and they aren't going to block things, because they can't. (I'm thinking university campuses, labs in enterprises, and pretty much any government department I know of where IT is totally outsourced, and people resort to under-the-desk ethernet switches because getting a new drop takes 1-2 years) And, pretty much every single laptop and desktop PC running Windows, Linux or MacOS has an unmanaged ethernet switch in it thanks to the fact that we pretty much all have the ability to run virtual machines. And those bridges exist even though the "front" internet is wireless... > As to rogue DHCPv4 > servers or even rogue routers, I think you cannot ultimately get away > from having to do security the right way, if things are that bad. Which > means, encryption and authentication. Anyone can add such rogue devices > in a network, no matter flag or no flag, or layer 2 blocking or no. As I said, it doesn't have to be malicious. Three clicks in the wrong place and many laptops start bridging between wired and wireless. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluYLg8ACgkQgItw+93Q 3WUlPAf+KCudhfO3jCRhcV2phY9OAxFbK9KakiF017kuBWjg7JkaFfvyQJlBEOsS MTsh1H9d3WK1zjg3bqdWMBtTpUHweMDHmaQlNfl6V61+t56Gd4TRJlJzlmKcmWFb MUVWHShM3VfrhcEuYteE0e2m43wb42dDNbfuBkZgnasESkAAcYIAzbriYO66+I01 wLaT9NYmIJHINvkKYa8Wjj/Xs3WEBRDocsR0knA41eJRq/XwMHb7jK8sv/LSK7Uy Ml1PEyFEc9ilbEIvDmv3bLLTUmsHh3oGjy7iO5kuXlJSzsqTKYBY1MjQjaN47ELw h9fV4ndEE87VpVIofZdWqPojyRIALw== =y1qP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 11 14:56:28 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDB131024 for ; Tue, 11 Sep 2018 14:56:16 -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 p9AFiHAVvGPM for ; Tue, 11 Sep 2018 14:56: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 A50E2130F75 for ; Tue, 11 Sep 2018 14:56:14 -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 w8BLuC2m034097; Tue, 11 Sep 2018 14:56:13 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (xch15-01-07.nw.nos.boeing.com [137.136.239.154]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w8BLu8LL033700 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 11 Sep 2018 14:56:08 -0700 Received: from XCH15-01-07.nw.nos.boeing.com (137.136.239.154) by XCH15-01-07.nw.nos.boeing.com (137.136.239.154) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Sep 2018 14:56:07 -0700 Received: from XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) by XCH15-01-07.nw.nos.boeing.com ([137.136.239.154]) with mapi id 15.00.1367.000; Tue, 11 Sep 2018 14:56:07 -0700 From: "Manfredi (US), Albert E" To: Michael Richardson , 6man WG Subject: RE: ipv6only-flag-02 security Thread-Topic: ipv6only-flag-02 security Thread-Index: AdRJ4jpfslLYhFtzQ6qTnrhecW+klgAU7y4AAA5IPaD//710AIAAa3Xg Date: Tue, 11 Sep 2018 21:56:07 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <1b3a5f9f1a554708af0d36147fbce9c2@XCH15-01-07.nw.nos.boeing.com> <26515.1536699920@localhost> In-Reply-To: <26515.1536699920@localhost> 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] x-tm-snts-smtp: 504CDF51E4FD4242AA7643BC800A10C9A296E6083F204B2FFC82C1D391E0D56B2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 21:56:22 -0000 -----Original Message----- From: ipv6 On Behalf Of Michael Richardson > As I said, it doesn't have to be malicious. > Three clicks in the wrong place and many laptops start bridging between w= ired > and wireless. I think we're going off in too many directions at the same time. The purpose of this flag was for things like wireless devices saving energy= , by not attempting to acquire IPv4 addresses. Or really any device, saving= time by avoiding looking for IPv4 service. Filtering at layer 2, and then = adjusting timers in these devices, could also achieve this type of purpose. In addition to enterprise nets, home modem/router/WiFi access points are, o= r can be, managed by your ISP. So this type of layer 2 filtering could be d= one, by the guy who is saying "no IPv4 in your net." Today these devices in= corporate unmanaged switches? Maybe some of them do. New ones could be desi= gned differently. Sure, the user can always add his own Ethernet switch, to run his own old p= rinter or what have you, but that switch would probably not be a DHCP serve= r or the router to the WAN. So for these battery operated hosts that you're= worried about, let's say they are not the ones who are trying to use the a= ncient printer, nothing would change, necessarily. They would still know th= at IPv4 is not routed. And finally, if someone innocently connects a DHCPv4 server and perhaps an = IPv4 router, not maliciously, what harm is done? Not much! At most, devices= in that local net will be wasting energy and time, waiting on IPv4 service= s. In short, for the purposes mentioned, I think the IPv6-only flag, or layer = 2 filtering, could pretty much do the same automatic job. Bert From nobody Tue Sep 11 15:07:44 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794B4130F40 for ; Tue, 11 Sep 2018 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (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 x1Qi2rLD0jE7 for ; Tue, 11 Sep 2018 15:07: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 C6D75130F3C for ; Tue, 11 Sep 2018 15:07:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 7A4856A0 for ; Tue, 11 Sep 2018 22:07:38 +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 Lp4tIgp2jNeu for ; Tue, 11 Sep 2018 17:07:38 -0500 (CDT) Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.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 42D0D126 for ; Tue, 11 Sep 2018 17:07:38 -0500 (CDT) Received: by mail-ua1-f72.google.com with SMTP id l14-v6so13112433uaf.21 for ; Tue, 11 Sep 2018 15:07:38 -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=W3tS1KOQSkBlLzani5RKtr8aXY1soG6T1e0Ku/TmsXw=; b=AdK4uDeXvQJAqq7UwuqpGzchpmqIwp+fFZaMLHios33OyQ9yim6C5VTU4zl+pvph+0 pUHJ94tTpM2xSLASZoNVeIpgPWA7kzG1N/y8gUuXYGYUVk4d9anrfC8/McFeahZIKSD8 M3VPnN2VKuvbVWdGk3C3dSbjO1K27iWSkwJJjyp2OUhgN4UrE/nqtN+FeVvSBB10vWEt xH9Zb9TroYUzJ7AqCNnj1tVDn0staBYWvEOEA63pfj3kLZ2IK3FFf4cYKi1mcQa0DBSW DC0DbCJMZ8zTsh6k+C56sRxQtL0x7kB4/Hoavh6WH4f7eKQh8gPhFuxnAbtbhhmBVy6C RFiQ== 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=W3tS1KOQSkBlLzani5RKtr8aXY1soG6T1e0Ku/TmsXw=; b=pwVOooylhpz5nX12vhyhVrtf0gMYeegC9ZMbvhvSu1slYo1DWCnYMiSj3xwEILYWR4 FAYDxT7YEMxNd2KKNcaRnnsMCivPyvP+t/iWkx1claMbPYIksfB0VwsQ9I4HC1Byv68g 0AlMAYGJW6PhnwVSLtMoarQOsg9OwCrW1jWDC/5LfRngcnmh0CY7fOFHFP/j8sXFYd4U hlHinzHNSx2oFOUFTHpnIcICbt/9mqF4+DpgE8gMQ3+AOJ+mjr/oxPpSHR6znF8wxRBk L0608aXWH71r/IFFY759HMJdrVrlMpVDwQwyIjQv3F34RSkxcUyYNYNDE1UjLDX8bAMW Rntw== X-Gm-Message-State: APzg51B/y2cKNAtHWifKtnmbC3gqoL6X5hAVoU43yj0tUYpX2Dng2RLS IoLOqDhRj+OK2c5E/7G9vYnqc2xw5cDy05wk1TOyunNp3pY7lb1PDpbZkbhdgNcKXWzwfhcIY8h /Tl6PC4/VpZdzOoo4kHOlo0L6 X-Received: by 2002:ab0:7414:: with SMTP id r20-v6mr2810266uap.167.1536703657125; Tue, 11 Sep 2018 15:07:37 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaUmk/PwP0b/7uDZVt+Pv0vLHZRypwryOO42EtPQh2nGC5txCLRYPcf1hfHzyoq7nXBz2N7E0gnnpI2ZkxDc2w= X-Received: by 2002:ab0:7414:: with SMTP id r20-v6mr2810250uap.167.1536703656768; Tue, 11 Sep 2018 15:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:6042:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 15:07:36 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> From: David Farmer Date: Tue, 11 Sep 2018 17:07:36 -0500 Message-ID: Subject: Re: ipv6only-flag-02 security To: Mark Smith Cc: Tim Chown , 6man WG Content-Type: multipart/alternative; boundary="00000000000096537305759fb348" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:07:42 -0000 --00000000000096537305759fb348 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 11, 2018 at 3:07 PM, Mark Smith wrote: > On Wed, 12 Sep 2018 at 01:39, Tim Chown wrote: > > > > > On 11 Sep 2018, at 16:28, STARK, BARBARA H wrote: > > > > > >> ... the security implications of this flag give me the heebie-jeebies > > > > > > I think the current draft has already done some mitigation of > potential DoS attack on hosts by saying that if at least 1 RA has the bit > *not* set, the host SHOULD NOT assume IPv6 only. Another possible > mitigation that occurred to me is the host could try DHCPv4 for a minute > before shutting down IPv4 operations (if no DHCPv4 response). If there is a > DHCPv4 response, then the router is lying. If there is no DHCPv4 response > within a minute, then either the router is correct and not malicious, or > there is a malicious router that has so much control over the network that > it can prevent all other router Ras from arriving at the host and it can > prevent DHCPv4 messages from succeeding. If the latter, then this flag is > the least of the network's worries. > > > > > > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 > operations. The RA flag is incorrectly configured. > > > > Or there is a rogue DHCPv4 server? I'll see your heebie and raise you a > jeebie ;) > > > > As observed, this is really just another example of a rogue packet > that can disrupt other hosts' operation. People are already tolerating > and accepting this type of risk already when they attach multiple > untrusted hosts to a mutual trust multi-access link layer. > > Point-to-point physical or logical link and IPv6 prefix per individual > host, isolating them entirely from all other hosts, is the only way to > fully mitigate all these issues. > > There could be some specific mitigations for this risk, however it it > is not a new risk. > > Regards, > Mark. > One of the reasons I like this strategy, adding a flag to the RA, is we already mostly understand the risks involved and have developed tools to mitigate many of those risks. If we build a new mechanism to signal this as has been suggested, we may have to develop those mitigation tools from scratch. 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 =============================================== --00000000000096537305759fb348 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 11, 2018 at 3:07 PM, Mark Smith <markzzzsmith@gmail.com= > wrote:
On Wed, 12 Sep 201= 8 at 01:39, Tim Chown <Tim.Chown= @jisc.ac.uk> wrote:
>
> > On 11 Sep 2018, at 16:28, STARK, BARBARA H <bs7652@att.com> wrote:
> >
> >> ... the security implications of this flag give me the heebie= -jeebies
> >
> > I think the current draft has already done some mitigation of pot= ential DoS attack on hosts by saying that if at least 1 RA has the bit *not= * set, the host SHOULD NOT assume IPv6 only. Another possible mitigation th= at occurred to me is the host could try DHCPv4 for a minute before shutting= down IPv4 operations (if no DHCPv4 response). If there is a DHCPv4 respons= e, then the router is lying. If there is no DHCPv4 response within a minute= , then either the router is correct and not malicious, or there is a malici= ous router that has so much control over the network that it can prevent al= l other router Ras from arriving at the host and it can prevent DHCPv4 mess= ages from succeeding. If the latter, then this flag is the least of the net= work's worries.
> >
> > If there is a DHCPv4 response, then the host SHOULD NOT shut down= IPv4 operations. The RA flag is incorrectly configured.
>
> Or there is a rogue DHCPv4 server?=C2=A0 I'll see your heebie and = raise you a jeebie ;)
>

As observed, this is really just another example of a rogue packet
that can disrupt other hosts' operation. People are already tolerating<= br> and accepting this type of risk already when they attach multiple
untrusted hosts to a mutual trust multi-access link layer.

Point-to-point physical or logical link and IPv6 prefix per individual
host, isolating them entirely from all other hosts, is the only way to
fully mitigate all these issues.

There could be some specific mitigations for this risk, however it it
is not a new risk.

Regards,
Mark.

One of the reasons I like this st= rategy, adding a flag to the RA, is we already mostly understand the risks = involved and have developed tools=C2=A0to mitigate ma= ny of those risks. If we build a new mechanism to signal this as has been s= uggested, we may have to develop those mitigation tools from scratch.
<= br>
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
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
--00000000000096537305759fb348-- From nobody Tue Sep 11 15:42:09 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24F9130F55 for ; Tue, 11 Sep 2018 15:42:07 -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 kI-XKfSj2SQt for ; Tue, 11 Sep 2018 15:42:06 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F91130EF7 for ; Tue, 11 Sep 2018 15:42:05 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id a20-v6so235072edd.4 for ; Tue, 11 Sep 2018 15:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HEY1HTBMbHmkZ8z/yEq8kPdnZkIV64tVMqrNAosPePg=; b=H6fn2AVMaQLUDicb2XuXyFjbcLWgNc4Kdx6w+Eh5+fMcNRXsDG5IQZDDRALguQxwl5 QuMovc1LetARs/dlqtQsKew2Q0JDI4Q8S3N1GArPecuc58mVmPKSZu7PMQkkPAFMQWCF TDd2GEu5zp6OVmGsIMKLvnhjpOWHOJ4a6HfhK7dRleFSzwzT42qZaeQeAC3HzXzeJQ6Z aq+Lct+tY4xM/lWbzRG2++XXjihsYRJ/YD1xRbj4llsxYVGifRuqMkwJgF1SYiKNStKW n6mfprslcmxkuyZcE1PP3oE43hXmjZmaU9Vaot1s1tO5X+R59sWJ+c7OnFSaue0ifCkV M0zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HEY1HTBMbHmkZ8z/yEq8kPdnZkIV64tVMqrNAosPePg=; b=TX9yu6S+rdkH2KI+peB8ickhATkD83dTb+BaqvgsPn+LLdEmjBljs+VZ05VhhtfYxu FnA420oLTV8jgJCw6+g/+p4HWG/Ju8x6uiJnCAItPPUyDclRfIRAJLbEf8r1abz8L+0j objTWpGSyBTV1Q79lWIdM4SViUJLbRwubT+74y/2xAvYmhdDciect1tIR9TlUStzsFEl m8sVNPfd28MZjxCPoU7CAY16ohAZAn8hzFpsRgHw46iRqmLm+X5nIpfcW1FcuVzf97+O LfN7UGECeiTIwhMvKF65allkpTerPNLHE6OPeZC15n6Tw2Z7b+lWbO7U/2SJfJMIGtBt Dm3Q== X-Gm-Message-State: APzg51AWCuF2wsS86275Z1m8h4OW+GNKDVRbHB9qvXjvl05SudU7Buz1 n5ZtGQ9So6BNdB+HIfIoYMh1NsXSZI3+p/UnO3c= X-Google-Smtp-Source: ANB0VdY8TQ63ZvJ/qUjG2F6SUghGsEW/QEON/IinHocCS/huCvHD+WhYcMWE4d+BWbZtlhMvBy8RyKO2Ic86nqYjujs= X-Received: by 2002:a50:c8c3:: with SMTP id k3-v6mr30333047edh.193.1536705724303; Tue, 11 Sep 2018 15:42:04 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> In-Reply-To: From: Rob Evans Date: Tue, 11 Sep 2018 23:41:52 +0100 Message-ID: Subject: Re: ipv6only-flag-02 security To: farmer@umn.edu Cc: markzzzsmith@gmail.com, 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.29 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 Sep 2018 22:42:08 -0000 > One of the reasons I like this strategy, adding a flag to the RA, is we a= lready mostly understand the risks involved and have developed tools to mit= igate many of those risks. If we build a new mechanism to signal this as ha= s been suggested, we may have to develop those mitigation tools from scratc= h. I agree. We do appear to be obsessed with corner cases with this draft. Cheers, Rob From nobody Tue Sep 11 19:46:57 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AFF130DF0 for ; Tue, 11 Sep 2018 19:46: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 6y5lhBjKAa5h for ; Tue, 11 Sep 2018 19:46:53 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79406130DC1 for ; Tue, 11 Sep 2018 19:46:53 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id p5-v6so224777plk.3 for ; Tue, 11 Sep 2018 19:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WOPmS3uJZJVrSc8j2Vyj+vSdpR6aelS1gUzgZr3mXTQ=; b=KDUcjA8VZjuu70NS2zlQEYonLzmi5M6BnTzePsA1cy9K3Q68T62egaDlxt57QuPl77 nP2joM5eBI/r8iDRw2UZCMhojcV2/aWYxqHe2b9p1Bc1ZEvvj9jJpfjAN4j/jlcQ5wkk 8iVvNDq6uoFALtaT3y17+mQYvVmJFqr1qZnWqu9VUbCngjtNA7P4QFpW9CEa7UGgMshe JSXeL/TtYfLje3QlgKAeTIWAvYJGc0xou9uvSK2FU/czmg4CIwM09VsSXaltN+3nIHTv Apk/ZdZoIglz6e6pq0xTih6msEyiULBkumFuDHxmE7MP0Q/O6iYO2OBPSCW7Gn+GX7rm UeVw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WOPmS3uJZJVrSc8j2Vyj+vSdpR6aelS1gUzgZr3mXTQ=; b=WnfBfq8yzHL+v+qBhsHGSUiTyqsM8qrunuGSu0gCzX5paCxZXzZlgOkS21lBB/3d9X YX377bAAGuSKMFLqJXZQXd7xXilFYC4sXWjo/4Cnxq5O4Q0r/XnP6UdiEbbLRqo0KJmy 3+AXM9hl3ksAM0KVM9kxO6kSz5z18ayaeWsO1cXDEb6ME0ctemP1EmFcHaPUXQ3N45JZ nzoh2EJQa1QXfQZLlZRaiXkIHM3M5kQVagSIhYImQT/kDmSRR2Mwb9c6+i1RfRZ2+TXf u+Tg0cfVYkr5/8Gsg+hfSIjCwpmxjTiY2Tw29L17/SwVMx529VrYgJz7grFbUGtQbzrg 2Rlg== X-Gm-Message-State: APzg51DSRMcpTGgPIptAX6VBMW7Nn4cYPicCcuCKbEZpWTGFaKSn+LpA pIyWNLeHEx8e0xtTIXdt+vFvLWMx X-Google-Smtp-Source: ANB0VdYrPywv9vJRaLC9vYDiabjBKp8+HaPcVvAfgTYXPJNGfPaQXlox+5kcfcjgfcN2qQcybtR8ZQ== X-Received: by 2002:a17:902:402:: with SMTP id 2-v6mr29989732ple.277.1536720412698; Tue, 11 Sep 2018 19:46:52 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id z2-v6sm22328312pgv.12.2018.09.11.19.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 19:46:51 -0700 (PDT) Subject: Re: Comments on draft-herbert-ipv6-update-dest-ops To: Tom Herbert Cc: Ole Troan , "C. M. Heard" , 6man WG References: <837265C7-AF4A-4E78-A7B4-5D4AE5C38C8A@employees.org> <970CDF5C-1E76-4241-9BCA-B053F637DE40@employees.org> From: Brian E Carpenter Message-ID: <34b285e1-1c49-2d84-5bd7-b76ae9c5308b@gmail.com> Date: Wed, 12 Sep 2018 14:46:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 02:46:56 -0000 Hi Tom, On 2018-09-12 07:23, Tom Herbert wrote: >>>> You have at least 4 arguments going at once here. >>>> >>>> 1) How to deal with destination options on intermediate devices term= inating and forwarding traffic (tunnels, source routing) >> >> The words "destination option" and "marked to be changeable" in the sa= me >> sentence make my head hurt. >=20 > Hi Brian, >=20 > Yeah, I liken trying to resolve this to interpreting the meaning > single obscure phrase in a consititution a hundred years after the > fact! A well regulated header format, being necessary to the security of a free= Internet, the right of the people to keep and transmit destination optio= ns, shall not be infringed.=20 =20 >> So I think that indeed 8200 needs clarifying >> on this, much as the draft says: if the option *precedes* the routing = header >> it's intended to be processed by the intermediate forwarder. >=20 > Is section 3 of the draft not clear on this? Yes, I intended to indicate agreement. >> (As a side >> question, should that forwarder be entitled to remove the option compl= etely, >> as well as to modify it?) >=20 > My interpretation of RFC8200 is that if an option (HBH or Dest Opt) is > marked changeable, then only the option data may change. Length and > type cannot change, Options cannot be added nor deleted, and neither > can extension headers be added nor removed, nor their lengths change. > I think these requirements must be strict to achieve proper > accountability in IP. For instance, if an intermeidate node makes some > change to a packet field outside of what the sender has declared > changeable, and if the change causes an error in a dowstream node, an > ICMP error might be sent with a pointer to change data. The problem is > that the ICMP error is sent to the source address not the party that > made the change. The source might be able to deduce that the packet > was changed and that caused the error, but would have no idea who > actually made the change or how to prevent them from continuing to do > that in subsequent packets. Does this need clarification in the draft? I think it would do no harm to make it 100% clear. It's never been clear to me whether a change in the option data is allowed to change the *lengt= h* of the option data; changing the length breaks IPsec (see RFC 4302 sectio= n 3.3.3.1.2.2) and might confuse PMTUD. >> But apart from that, "changeable" is a nonsense >> for a *destination* option and should be forbidden. >> >=20 > I'm not sure what forbidden would mean at least beyond what second > paragraph describes. If someone marks a destination option a > changeable in dest opts that is after a routing header or no routing > header, then that is ignored (except for the auth header interaction). > It's still legal to set the bit in that case. Does this paragraph need > further clarification? No, it seems clear enough to me. Brian >=20 > Tom >=20 >>>> 2) Dealing with destination options when terminating traffic as a ho= st >> >> That seems clear cut. >> >>>> 3) Dealing with destination options when acting as a layer violating= middlebox. >>> >>> Note that that RFC8200 doesn't distiguish any of the cases. Per the >>> spec there is no difference between a tunnel endpoint and a end host >>> in how they are supposed to process Destination Options. Neither is >>> there is any difference between how a hardware and software >>> implemenation of protocol is supposed to work. Middleboxes that aren'= t >>> destinations of a packet aren't supposed to be looking at Destination= >>> Options header at all. >> >> +1 >> >>> >>>> 4) Why after 20 years aren=E2=80=99t there any =E2=80=9Cuseful=E2=80= =9D destination options created? >>> >>> One could also argue that IPv6 itself has gotten enough traction unti= l >>> recently to warrant interest in the creating them. >> >> +1. >> >>> >>> All these fall under the same root problem, namely how do we undo the= >>> effects of non-compliant implementations for core protocol features >>> (i.e. Destination Options in this case). It seems like there's three >>> alternatives: abandon trying to use the feature and try to do >>> something else to get the functionality, fix implementations to be >>> compliant, change protocols to adapt to reality of implementation tha= t >>> best preserves the feature. >> >> There's a 4th alternative hiding in draft-carpenter-limited-domains-03= =2E >> Namely, only use them where they actually work. >> >> Brian >> >>> VPP is an example of an implementation that should simply be fixed to= >>> be compliant (I have taken that up with the VPP developers). This >>> draft updates processing of Destination Options before the Routing >>> header relax the requirements similar to how this was does for >>> Hop-by-Hop options. It makes the assumption that some intermediate >>> devices in a routing list won't processing the Destination Options pe= r >>> the current specification. That assumption seems to be true for VPP, >>> and it seems like that some other implementations will also not be >>> processing them ostensibly because of performance hit and processing >>> cost. >>> >>> Tom >>> >>>> Best regards, >>>> Ole >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >=20 From nobody Tue Sep 11 19:52:39 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6C9130DF0 for ; Tue, 11 Sep 2018 19:52: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 x-uc50ZrUGZe for ; Tue, 11 Sep 2018 19:52:35 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA48B130DC1 for ; Tue, 11 Sep 2018 19:52:34 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id b11-v6so244308pfo.3 for ; Tue, 11 Sep 2018 19:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BIt+q6qbUoTZNg6jljb8WcEpnFCxS4e3RqS3+0mRI5s=; b=Vu1oIhlcg1ACk5bMGhDyYDfxxDxBZ+DV0XWw1lcc/z6+0U3gu0pT0lNPeD9nXvbBNE jj3sRP3QzG79+G18mJseAmEoxHOWvbHNYa7C6TInDJb8e0aY19ZxLDTSdP/74tA728wC hESVCOl45/V+l6rZ+EL7HPp9MB7ub8yQJu7uekaxrhQNsma3NDQCO0ZuuqSv/gHZ2RDp 4GRtKNvDTW23rr0hnWVt4UI75Sl7C+RkCjJsChm2k/G7CX8XMSS8kOAMDZX/yt8BLlLC igphxXVEJB6fF5gaaiR7FGjqsrL4aIVuZN1q/ccAge3PsTRa4AD+BWsUoAY1rVwjVcJt ziPw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BIt+q6qbUoTZNg6jljb8WcEpnFCxS4e3RqS3+0mRI5s=; b=PQWXMspMCLowgKBM93StaxCs5uyj5afpDNz8rcXQZ7E5do8Bi8cuBXpl3e8d2IvEKw hbI9gutGRKBSnatzpiUUljBpgWFONWj4d0GqYIsyHnA2ZbU7X0QZlEODpkbJTRNgUKsL YNA+pnpe+xh+NpXTdbx9k9jykmsRI8B+/PxZ4YF7btr3jxU4vZ7WYHBO5YC5zjObH7nB MhL/OAwQOjIue+NZP26j503Ao9yLaaODoydrTfRKarhKK9oDMq5/bMl5A02qfbGzmRXC bc1CL9ASHrKrqPKL6TafewUB62R+GUmZrFkfu3NPPjqghtcYS6Gd+K79GM4adLPuP2UC LNtg== X-Gm-Message-State: APzg51AGnrdoYF/w7mYKzfBfzPBB+01W89VJWPVxeRdDuYwLsHi1uA1C IXPV2K/gLspSDKJ1CZmw9DigLMvg X-Google-Smtp-Source: ANB0VdbmLaMu/kDGrcR/c1kqS9ryncysVWmq3bi5HWapdPWxRc5SI2/zepQz/SOmDvjPcrcFurhIKg== X-Received: by 2002:a63:5f01:: with SMTP id t1-v6mr31867637pgb.149.1536720754106; Tue, 11 Sep 2018 19:52:34 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id y3-v6sm43094222pfi.24.2018.09.11.19.52.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 19:52:33 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: "Mudric, Dusan (Dusan)" , "ipv6@ietf.org" References: <9142206A0C5BF24CB22755C8EC422E459CB5783D@AZ-US1EXMB03.global.avaya.com> From: Brian E Carpenter Message-ID: Date: Wed, 12 Sep 2018 14:52:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB5783D@AZ-US1EXMB03.global.avaya.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.29 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 Sep 2018 02:52:37 -0000 On 2018-09-12 03:40, Mudric, Dusan (Dusan) wrote: >> o Such traffic may drain battery power on wireless hosts that have >> no interest in link-local IPv4 traffic. [RFC7772] indicates how >> this risk might be quantified. >> >> o Similarly, hosts may waste battery power on futile attempts to >> access IPv4 services. >> > > Is it mentioned already that a dual network can disable IPv4 using this flag and that way a network operator can test the migration to IPv6-Only mode? If something goes wrong in IPv6-Only mode, the network can be turned back into a dual mode, while IPv6-Only problems are worked on. At least two people have mentioned using the flag for this purpose, so it needs to be on the list of issues. (I'm not yet convinced it will work as hoped for this, so it needs some thought.) Brian From nobody Tue Sep 11 20:02:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B54130DC1; Tue, 11 Sep 2018 20:02:09 -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 verqcZk2DRLw; Tue, 11 Sep 2018 20:02:06 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED0E130DC7; Tue, 11 Sep 2018 20:02:06 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id g23-v6so231548plq.9; Tue, 11 Sep 2018 20:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9CURyzaORnlqpwKLuHI7TK9t4aN7H6KCg/aJHNGWl7A=; b=PWwvxEe00S4KwlVd5VgMAUTl8PfniUnS00RdSxIjTuF9w1HXHsM+4g1ksyQJKySHFo TrQLd48WiRWtMAabRbKyWTVv2ryRXwqKCz1noBNHFcuL20c1sS8TJXGkvXzt+vu8imc5 D79jUxLcKMHUbBI+FkgXYGU2YMeOA4mjYwXGtU5sZngBb6Avyrn13n7CY2yuj7g/00d3 T8LF4iy4kJlpBfaD35kIptpky4GftDGzj7fAPDjdf9F38tKpXCp9TEfwSQo7nDY5jw+y GmyUj7ITFXyIzM3g/QUS8w9u9GDq9Nkn2RlMd2agNY8OcQi+lVjK8X2Qypw1U96ZZ/qP mY7A== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9CURyzaORnlqpwKLuHI7TK9t4aN7H6KCg/aJHNGWl7A=; b=XXN4cJkYlM3FBYu0ZcqtFa2DlYiiPPBUe47l6+TNTOMBjGp0a+X3qQSmZh5pM2Jf2I 7ybwK1GBmPQGrOdiZBt6jngitTVd4UFzWYUMX4fWEplL1h8CX9lz/S3nwGTfHB+0Pqbm 0A3td5mRVIkEx8ApMfh1OXzwmMV2P5CwBAKOozJ6yLgaLgDX6PUdYg/EsGUrg8uMfKeR k50KeQ3l6nuEoaSiU+AmOjLGsICBceJY310kjs0SuyE9EIbzy2YF+3n19zbzE0ge9sPz a3F6UQKJWAz0RdPhtp1pJuNuHJVaCtyJJGGNSonGgBZdTTT5YsIzTUpWOY2ty1pMZpTr rrOQ== X-Gm-Message-State: APzg51DlNMvcqjorJzVaMI5PBXYO2UZPfaVvvJ9oyfF0jpnl8KqDMRf2 e+u8ZU8/+bLyO2k/sosqH4xleNwA X-Google-Smtp-Source: ANB0VdYC/wSYNAGtYU1DKTv3SxZmwQyITqYJHXs5iTOMJcjuiqQvVo4WEIpswsOHgHdSx/YRTZdeIA== X-Received: by 2002:a17:902:e5:: with SMTP id a92-v6mr30302679pla.273.1536721325735; Tue, 11 Sep 2018 20:02:05 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id d22-v6sm45921132pfm.48.2018.09.11.20.02.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 20:02:04 -0700 (PDT) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 To: Ole Troan Cc: 6man WG , 6man Chairs <6man-chairs@ietf.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> <60dac1f7-2bff-9b52-c434-2ab8b7678ec4@gmail.com> <14e1604b-4c17-26e5-0ad4-789a7affd3e7@gmail.com> <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.org> From: Brian E Carpenter Message-ID: <3adf6f4e-aa17-ad4d-2b97-0fb812967f63@gmail.com> Date: Wed, 12 Sep 2018 15:02:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <541E8D36-E273-4990-9AFB-0BB9BF7510BD@employees.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.29 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 Sep 2018 03:02:10 -0000 On 2018-09-11 18:27, Ole Troan wrote: =2E.. > Right. Trying to categorize the comments: >=20 > 1) Not deploy. This doesn=E2=80=99t fit with our model of network oper= ations.=20 >=20 > 2) No need. It=E2=80=99s sufficient to block IPv4 traffic in the networ= k and no need to signal hosts.=20 >=20 > 3) Implications of flag. Does the flag mean an IPv6 only link, ie no IP= v4 packets on it or does it only mean that routers don=E2=80=99t forward = IPv4.=20 >=20 > Please add if there are some I have missed. I've got 4) Not useful enough to justify burning an RA flag bit. 5) Is the flag useful to test the migration to IPv6-Only mode? 6) Security heebie-jeebies >=20 > In my view 1+2 are relevant in judging if we should do this work at all= , and if there=E2=80=99s consensus to proceed. Well, 1) is fine for anybody to say, but it seems other people find the f= lag useful, that's fine too, so I think it's a wash. The draft itself argues against 2) by saying that layer 2 blocking doesn'= t work in all cases and only partly mitigates the battery and spectrum arguments. YMMV. Honestly I believed we had covered those arguments during the WG adoption= call. The people who disagreed then also disagree now. Brian > While 3 is more relevant to what we traditionally discuss during a last= call. Is the document clear, solution described interoperable etc.=20 >=20 > Cheers=20 > Ole >=20 >>> >>> >>>>> as a Proposed Standard. Substantive comments and statements of supp= ort >>>>> for publishing this document should be directed to the mailing list= =2E >>>>> Editorial suggestions can be sent to the author. This last call wil= l >>>>> end on 19 September 2018. >>>>> >>>>> An issue tracker will be setup to track issues raised on this docum= ent. >>>>> >>>>> Thanks, >>>>> Ole >>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------= - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= >>>>> -------------------------------------------------------------------= - >> >=20 > . >=20 From nobody Tue Sep 11 20:09:31 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1645130DF0 for ; Tue, 11 Sep 2018 20:09:29 -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 d74sDN2qeeCf for ; Tue, 11 Sep 2018 20:09:28 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C07130EC7 for ; Tue, 11 Sep 2018 20:09:26 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id f66-v6so239404plb.10 for ; Tue, 11 Sep 2018 20:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G96RfWQs+CCJyTitGBI3inDbG4Q1/YGfO6kKLBzWR80=; b=P2xNFgralP+MQUIYmjCyQI5eGaDDwcVzuQ8D32ecJtQVz/1zL3oQaeH5OauZSQYnnH lnpizFqR7t23h0Qv4TcZUltTJPw67wMCwwYbTx2U1Ws3o21qkWSg3v7J0jc7JKN9p+Tg IYcH/fc4O8KzgoxFxIea+U8o0QdqQ8hxgRzy70aOqlQJVeYvWM3G69BO6Y7T8zJi+P9K Jd3Zaz83JTeEqhJ9CvrYFuT4csJsf0++L1fefHadIg+zxuq0YJ/5GcPbh4v4Gky21HjP m789bEwID3VWCsuaXQmf/PfbAzz28H/2JLYdQ1pgu6+DQNWdH7pG/XB8/1qQpPcjg/D0 3UkQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G96RfWQs+CCJyTitGBI3inDbG4Q1/YGfO6kKLBzWR80=; b=Ia4uNIIwc4fiTrwHzMQk011SLRmDotiNiHasf2uQDBCntC701Mwq26IrVHNuLqysnH Q/pjxsttGJf9nH9zfPkbQGeHBgQjFay1uw1grTFXJgfn32thdQbVXd9QeBa9apFCuydr ZbtsMHjyyY1ic0KULhjECq6Pkn6PbiVOhibMY8/QChDAVqNSgInMb5Nv5QkrMCRYcTUd gb+AX8IEQSzTkzRCuoOehNIeAOtEEkpyP15RK5F5EpdKSZ2KHpwC+OkuUBYMr9WCkgfX HMcwC1gD9KpnE3HOf2L+QlZ80EnL9gLjEPj8CQ8s021ysBbXqq9oBngpUxop4klXNsYF Oyyw== X-Gm-Message-State: APzg51C2d3XF0fXkMaqDoXSLh2uwQ2ST1I+FuAhm1PU8CLGNGsl/gm8U boNlPlHK1rlItnRrDtb8hwoEaiQh X-Google-Smtp-Source: ANB0VdascN41/hWqRx5e64o5sK5DcLrGpUeVSLW3x0QBN2e9kudwHcocoKaDntOXGVnQmyRgIXUzBw== X-Received: by 2002:a17:902:f096:: with SMTP id go22mr30964589plb.183.1536721765919; Tue, 11 Sep 2018 20:09:25 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id a15-v6sm34548915pfe.32.2018.09.11.20.09.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 20:09:25 -0700 (PDT) Subject: Re: ipv6only-flag-02 security To: Michael Richardson , "STARK, BARBARA H" Cc: 6man WG References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> From: Brian E Carpenter Message-ID: Date: Wed, 12 Sep 2018 15:09:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <19297.1536689674@localhost> 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.29 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 Sep 2018 03:09:30 -0000 On 2018-09-12 06:14, Michael Richardson wrote: > > STARK, BARBARA H wrote: > >> ... the security implications of this flag give me the heebie-jeebies > > > I think the current draft has already done some mitigation of potential > > DoS attack on hosts by saying that if at least 1 RA has the bit *not* > > set, the host SHOULD NOT assume IPv6 only. > > > Another possible mitigation > > that occurred to me is the host could try DHCPv4 for a minute before > > shutting down IPv4 operations (if no DHCPv4 response). If there is a > > DHCPv4 response, then the router is lying. > > Or, an attacker is running a rogue DHCPv4 server, and is planning to > examine all the traffic that passes through. > > Since the IPv6-only network probably has NAT64 somewhere, the rogue can > easily arrange to do stateless translation and make the connection look > good. (remember, this can be configured by mistake on a number of desktop OSs by > mistake, rather than malicious intent and it's rather common in many > networks) > > Is it likely that an attacker would be aware of the NAT64, and yet not aware > that they can spoof the RA ipv6-only=0? That seems to dumb to me, but then > script kiddies often make such mistakes. > > > If there is no DHCPv4 > > response within a minute, then either the router is correct and not > > malicious, or there is a malicious router that has so much control over > > the network that it can prevent all other router Ras from arriving at > > the host and it can prevent DHCPv4 messages from succeeding. If the > > latter, then this flag is the least of the network's worries. > > Agreed. > > > If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 > > operations. The RA flag is incorrectly configured. Barbara > > I don't agree. If all the RAs have ipv6-only set, and there is still DHCPv4, > I'd conclude that the IPv4 is fake. It's either fake, or it's a mistake. Either way, it's a heuristic choice for the host stack to make: trust the unexpected DHCP server, or don't. If a bad actor has enough access to the link to bring up a DHCP server, she's got enough access to do many other evil things, so does it really matter? On 2018-09-12 10:41, Rob Evans wrote: >> One of the reasons I like this strategy, adding a flag to the RA, is we already mostly understand the risks involved and have developed tools to mitigate many of those risks. If we build a new mechanism to signal this as has been suggested, we may have to develop those mitigation tools from scratch. > > I agree. We do appear to be obsessed with corner cases with this draft. Thank you. Brian From nobody Wed Sep 12 02:08:33 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9188A130DBE for ; Wed, 12 Sep 2018 02:08:32 -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 MrQomwyOkUrW for ; Wed, 12 Sep 2018 02:08:30 -0700 (PDT) Received: from bugle.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 E48FD126DBF for ; Wed, 12 Sep 2018 02:08:30 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 7A796FECBBEB; Wed, 12 Sep 2018 09:08:30 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4185758CC95; Wed, 12 Sep 2018 11:08:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: ipv6only-flag-02 security From: Ole Troan In-Reply-To: <19297.1536689674@localhost> Date: Wed, 12 Sep 2018 11:08:27 +0200 Cc: Barbara H Stark , Nick Hilliard , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 09:08:32 -0000 > On 11 Sep 2018, at 20:14, Michael Richardson = wrote: >=20 >=20 > STARK, BARBARA H wrote: >>> ... the security implications of this flag give me the = heebie-jeebies >=20 >> I think the current draft has already done some mitigation of = potential >> DoS attack on hosts by saying that if at least 1 RA has the bit *not* >> set, the host SHOULD NOT assume IPv6 only. >=20 >> Another possible mitigation >> that occurred to me is the host could try DHCPv4 for a minute before >> shutting down IPv4 operations (if no DHCPv4 response). If there is a >> DHCPv4 response, then the router is lying. >=20 > Or, an attacker is running a rogue DHCPv4 server, and is planning to > examine all the traffic that passes through. >=20 > Since the IPv6-only network probably has NAT64 somewhere, the rogue = can > easily arrange to do stateless translation and make the connection = look > good. (remember, this can be configured by mistake on a number of = desktop OSs by > mistake, rather than malicious intent and it's rather common in many > networks) >=20 > Is it likely that an attacker would be aware of the NAT64, and yet not = aware > that they can spoof the RA ipv6-only=3D0? That seems to dumb to me, = but then > script kiddies often make such mistakes. >=20 >> If there is no DHCPv4 >> response within a minute, then either the router is correct and not >> malicious, or there is a malicious router that has so much control = over >> the network that it can prevent all other router Ras from arriving at >> the host and it can prevent DHCPv4 messages from succeeding. If the >> latter, then this flag is the least of the network's worries. >=20 > Agreed. >=20 >> If there is a DHCPv4 response, then the host SHOULD NOT shut down = IPv4 >> operations. The RA flag is incorrectly configured. Barbara >=20 > I don't agree. If all the RAs have ipv6-only set, and there is still = DHCPv4, > I'd conclude that the IPv4 is fake. Agree. =46rom my perspective the whole point of this flag is to signal = configuration information to hosts. A compliant host receiving this flag, should disable all IPv4 processing = on the relevant interface. =E2=80=9CLet the host figure it out itself is where we are today=E2=80=9D.= And they can=E2=80=99t do a very good job at it, e.g. they do very = poorly for noisy protocols like MDNS. Cheers, Ole From nobody Wed Sep 12 02:31:22 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B860130DCB for ; Wed, 12 Sep 2018 02:31:20 -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 DHeAetoO2iAN for ; Wed, 12 Sep 2018 02:31:18 -0700 (PDT) Received: from moth.iki.fi (moth.iki.fi [212.16.111.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A23A1274D0 for ; Wed, 12 Sep 2018 02:31:18 -0700 (PDT) Received: from [130.188.13.218] (218.13.vtt.fi [130.188.13.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id 61C5D2A00C2 for ; Wed, 12 Sep 2018 12:28:55 +0300 (EEST) Subject: Re: ipv6only-flag-02 security To: ipv6@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> From: Markku Savela Message-ID: Date: Wed, 12 Sep 2018 12:31:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 09:31:20 -0000 On 12/09/18 12:08, Ole Troan wrote: >>> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 >>> operations. The RA flag is incorrectly configured. Barbara >> I don't agree. If all the RAs have ipv6-only set, and there is still DHCPv4, >> I'd conclude that the IPv4 is fake. > Agree. From my perspective the whole point of this flag is to signal configuration information to hosts. > A compliant host receiving this flag, should disable all IPv4 processing on the relevant interface. And if I have a home/site network - connected to ISP offering IPv6 only, - and internally using additional IPv4 addresses via local DHCP server (or via another ISP connection offering IPv4) to support locally IPv4 only legacy devices (printers, etc.). As home/small site user (*), I may not have ANY control on RA's sent by the first ISP. If they were to set this ipv6-only flag and, if this would disable my IPv4 addressing, I would be a bit pissed off... (*) though, if ISP provided "home router" is configurable, and the ipv6-only flag in RA would be controllable by home user. Then maybe acceptable... From nobody Wed Sep 12 02:35:25 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19C1274D0 for ; Wed, 12 Sep 2018 02:35:24 -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, 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 El3MMTyv7Ryo for ; Wed, 12 Sep 2018 02:35:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 055C1126DBF for ; Wed, 12 Sep 2018 02:35:22 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B0D473AB044; Wed, 12 Sep 2018 09:35:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 63D9F160054; Wed, 12 Sep 2018 09:35:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4197F160084; Wed, 12 Sep 2018 09:35:20 +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 QF80OQrdYtgh; Wed, 12 Sep 2018 09:35:20 +0000 (UTC) Received: from [10.9.102.52] (unknown [120.17.157.180]) by zmx1.isc.org (Postfix) with ESMTPSA id DFE7B160054; Wed, 12 Sep 2018 09:35:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: ipv6only-flag-02 security From: Mark Andrews X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Wed, 12 Sep 2018 19:35:12 +1000 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54B5053B-CDBF-464F-A263-058F44D5E760@isc.org> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> To: Markku Savela Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 09:35:24 -0000 Then you ring the ISP and give them hell for being idiots. --=20 Mark Andrews > On 12 Sep 2018, at 19:31, Markku Savela wrote: >=20 > On 12/09/18 12:08, Ole Troan wrote: >>>> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 >>>> operations. The RA flag is incorrectly configured. Barbara >>> I don't agree. If all the RAs have ipv6-only set, and there is still DH= CPv4, >>> I'd conclude that the IPv4 is fake. >> Agree. =46rom my perspective the whole point of this flag is to signal co= nfiguration information to hosts. >> A compliant host receiving this flag, should disable all IPv4 processing o= n the relevant interface. >=20 > And if I have a home/site network >=20 > - connected to ISP offering IPv6 only, >=20 > - and internally using additional IPv4 addresses via local DHCP server (or= via another ISP connection offering IPv4) to support locally IPv4 only lega= cy devices (printers, etc.). >=20 > As home/small site user (*), I may not have ANY control on RA's sent by th= e first ISP. If they were to set this ipv6-only flag and, if this would disa= ble my IPv4 addressing, I would be a bit pissed off... >=20 > (*) though, if ISP provided "home router" is configurable, and the ipv6-on= ly flag in RA would be controllable by home user. Then maybe acceptable... >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Sep 12 07:19:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC71F130E08 for ; Wed, 12 Sep 2018 07:19:07 -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, 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 JhURM3YInrL2 for ; Wed, 12 Sep 2018 07:19:06 -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 293D21277C8 for ; Wed, 12 Sep 2018 07:19:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id D7A3A5ED for ; Wed, 12 Sep 2018 14:19:04 +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 6zMkrduhh0FG for ; Wed, 12 Sep 2018 09:19:04 -0500 (CDT) Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (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 934747B7 for ; Wed, 12 Sep 2018 09:19:04 -0500 (CDT) Received: by mail-ua1-f72.google.com with SMTP id g19-v6so841292uan.14 for ; Wed, 12 Sep 2018 07:19:04 -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=Zzi/FUtsztwFG0t3Lks2OSBfvuB7GUwqZnqTAeSJDmk=; b=Yd7jS5QtAROD2sCqKqqSxKstftzApJhoIj60v5jCCkEN1QWGAQWDbztkx+gTdwpeOX ++XIzXCUnueYyM9DyI3WL+oU7yO28S5HsilGYCyPgiM/YiHt/f3RFDVe6piGS1oJaBss YTBH9AGrMl3OSrw6Bm7qBEkd0HxJaLid0djorowrgZxOmRpr1SClkq03DbiblSB4ALYa 1dEw/4CNFhmVGE0Uw5aQN93kOk7aVygdmkRSDThZx8vwy+7akOxtwzxYtQ0Gs+IWDeRV lzDoAURF/8FbKTFpUPzST6weivoSHy+2f9P0Z6Rr660siBQYKonXr3JY5f+EG2PNiXsP 04dQ== 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=Zzi/FUtsztwFG0t3Lks2OSBfvuB7GUwqZnqTAeSJDmk=; b=nzuI1IN8331B167w2tugl/RB+DayySTJ995vNF5uqH2Fv/Ug3lMb8+xA3WpBgxFZSd cJedeNCEgwLKX4aVoSMWGD+N+SQMl7no0AaQ0RQ/qfmSnptxC5PIrcE42jtCcgNmk7a5 xxaZMVQt9Lg/0MTszrxthZeivUvqpIoUu8XtoBQ2oc9CE122p+pR9wefXCytxS3O8kUP WFeamU4GlslKTGZrHqxiRZ/nD4eE/mlTweVGlhgVsyGxt/B9DrqnQt9jW5EjKQWL5/tK 5k4YvxAMbEJTgaLz3WRpRgzQK+if4vE+N3CcAngc4Fw1vDBzkMTKI45ZlycEo91QPIOk 5ssw== X-Gm-Message-State: APzg51DpZGe1cD2a+WQmDQedwLwVMYJMvCFxGqafN7c8WPtzB5WnnYqY o6LrGH5OkdohdozvuDf2SlbxGRPzCSDEwHwUlmaR9WNAvpHuHn4IZYu3Z1XVffJkyvKMc7k7gKM e5JThrGMa5F2R6R7a6l22wtFU X-Received: by 2002:ab0:7414:: with SMTP id r20-v6mr962033uap.167.1536761942958; Wed, 12 Sep 2018 07:19:02 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaiNXOupDoSjcXfaJGuLaVsDRcN51/t8mrX07XdMTdiSPg1jVyQQSxUNV5H7qJmTdZhCAMh1Pganz7QhrrL+JY= X-Received: by 2002:ab0:7414:: with SMTP id r20-v6mr962003uap.167.1536761942286; Wed, 12 Sep 2018 07:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:6042:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 07:19:01 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> From: David Farmer Date: Wed, 12 Sep 2018 09:19:01 -0500 Message-ID: Subject: Re: ipv6only-flag-02 security To: Markku Savela Cc: 6man WG Content-Type: multipart/alternative; boundary="000000000000acaff30575ad45b2" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 14:19:08 -0000 --000000000000acaff30575ad45b2 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 12, 2018 at 4:31 AM, Markku Savela wrote: > On 12/09/18 12:08, Ole Troan wrote: > >> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 >>>> operations. The RA flag is incorrectly configured. Barbara >>>> >>> I don't agree. If all the RAs have ipv6-only set, and there is still >>> DHCPv4, >>> I'd conclude that the IPv4 is fake. >>> >> Agree. From my perspective the whole point of this flag is to signal >> configuration information to hosts. >> A compliant host receiving this flag, should disable all IPv4 processing >> on the relevant interface. >> > > And if I have a home/site network > > - connected to ISP offering IPv6 only, > > - and internally using additional IPv4 addresses via local DHCP server (or > via another ISP connection offering IPv4) to support locally IPv4 only > legacy devices (printers, etc.). > > As home/small site user (*), I may not have ANY control on RA's sent by > the first ISP. If they were to set this ipv6-only flag and, if this would > disable my IPv4 addressing, I would be a bit pissed off... > > (*) though, if ISP provided "home router" is configurable, and the > ipv6-only flag in RA would be controllable by home user. Then maybe > acceptable... > The default for this flag is cleared for a reason, only someone with knowledge of the devices attached to the LAN should set this flag. My ISP has no idea what devices are attached to my home network, therefore it is wholly inappropriate for an ISP to set this flag for the LAN in my house. It could be reasonable for them to set the flag on a public WiFi network, if it is clear it is an IPv6-only WiFi network, such as if it has "IPv6" in the SSID or this is made clear in some other way. Furthermore, the flag is not intended to signal anything about the WAN or upstream service provided to an ISP's customers, it is about the local LAN. A local LAN can have IPv4 routing with an IPv6-only uplink, using 464xlate, DS-Lite, etc.... Maybe someday in the future, it will be reasonable to change the default for this flag to be set. That is when it is reasonable to expect that LANs don't have IPv4, that is not the normal expectation today and it will be sometime before that changes. Something like the following should be added to the draft; It is only appropriate for someone, an administrator, to set this flag if they have a reasonable knowledge that the devices attached to a network don't need IPv4 routing services or are not intended to have these services. 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 =============================================== --000000000000acaff30575ad45b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Sep 12, 2018 at 4:31 AM, Markku Savela = <msa@moth.iki.fi> wrote:
On= 12/09/18 12:08, Ole Troan wrote:
If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4
operations. The RA flag is incorrectly configured.=C2=A0 Barbara
I don't agree.=C2=A0 If all the RAs have ipv6-only set, and there is st= ill DHCPv4,
I'd conclude that the IPv4 is fake.
Agree. From my perspective the whole point of this flag is to signal config= uration information to hosts.
A compliant host receiving this flag, should disable all IPv4 processing on= the relevant interface.

And if I have a home/site network

- connected to ISP offering IPv6 only,

- and internally using additional IPv4 addresses via local DHCP server (or = via another ISP connection offering IPv4) to support locally IPv4 only lega= cy devices (printers, etc.).

As home/small site user (*), I may not have ANY control on RA's sent by= the first ISP. If they were to set this ipv6-only flag and, if this would = disable my IPv4 addressing, I would be a bit pissed off...

(*) though, if ISP provided "home router" is configurable, and th= e ipv6-only flag in RA would be controllable by home user. Then maybe accep= table...

The default for this flag is cleared for a = reason, only someone with knowledge of the devices attached to the LAN shou= ld set this flag. My ISP has no idea what devices are attached to my home n= etwork, therefore it is wholly inappropriate for an ISP to set this flag fo= r the LAN in my house.=C2=A0 It could be reasonable for them to set the fla= g=C2=A0on a public WiFi network, if it is clear it is an IPv6-only WiFi net= work, such=C2=A0as if it has "IPv6" in the SSID or this is made c= lear in some other way. Furthermore, the flag is not intended to signal any= thing about the WAN or upstream service provided to an ISP's customers,= it is about the local LAN. A local LAN can have IPv4 routing with an IPv6-= only uplink, using 464xlate, DS-Lite, etc....=C2=A0

Maybe someda= y in the future, it will be reasonable=C2=A0to change the default for this = flag to be set. That is when it is reasonable to expect that LANs don't= have IPv4, that is not the normal expectation today and it will be sometim= e before that changes.

Something like the following should be a= dded to the draft;

It is only appropriate for someone, an administrator, to set this f= lag if they have a reasonable knowledge that the devices attached to a netw= ork don't need IPv4 routing services or are not intended to have these = services.

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 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
--000000000000acaff30575ad45b2-- From nobody Wed Sep 12 12:20:09 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4749130EAA for ; Wed, 12 Sep 2018 12:20:06 -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 sG8VnEzxDZcP for ; Wed, 12 Sep 2018 12:20:05 -0700 (PDT) Received: from bugle.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 24801130E00 for ; Wed, 12 Sep 2018 12:20:05 -0700 (PDT) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 6B9B0FECBC5F; Wed, 12 Sep 2018 19:20:04 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 4BDCF595416; Wed, 12 Sep 2018 21:20:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02 From: Ole Troan In-Reply-To: Date: Wed, 12 Sep 2018 21:20:02 +0200 Cc: Brian E Carpenter , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <9756763D-AFB4-40A9-8BD5-368947723E67@employees.org> References: <59AE59C7-6704-4069-A62C-E11248AE0B32@employees.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 19:20:08 -0000 Hi Nick, > It's not ok to brush technical critique off with answers along the = lines of "you may have a point ... but the market will decide". The = IETF has a duty to assess drafts on the basis of whether they solve = clearly-defined problems in technically appropriate ways, and any draft = going through a WG should be able to withstand reasonable commentary and = criticism. There's been a substantial number of serious technical = concerns posted in this WG about this draft, both in terms of the = problem statement and the proposed solution. Most of these remain fully = unaddressed in any reasonable way in terms of either discussion on the = mailing list or updates to the document. Would you mind enumerate the technical issues with draft so we can put = those in the tracker? Please spell them out, because I have reviewed the thread without quite = understanding what the technical issues are. Best regards, Ole= From nobody Wed Sep 12 15:11:37 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACEE130DFA for ; Wed, 12 Sep 2018 15:11: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 sjmtzES8JC63 for ; Wed, 12 Sep 2018 15:11:34 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C657D126F72 for ; Wed, 12 Sep 2018 15:11:34 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id h79-v6so1669222pfk.8 for ; Wed, 12 Sep 2018 15:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6NJQQc+M66bGzxmhGXty4kEZh9TfhDnamP4TQAh12Hw=; b=vMIEGgGCv7VJ1QTHDTWmmZq0EX/Kz4RfLzJ1rtjl90tkzF88b58XkZVLACOoiCZ7Rn lAfTKG41TQ439EwkmhXPnLx+P4Gq42C7UoFkHeNzsZo/TP+zHWFP081BkZiTeeSh9MFY PB3LlbZQ4twAdjcibskpQzTVeDA8/lQZFjt1jWBH2cbdGUe+gZxS50hJRAijLiIITTjk /HjRImKMTAKiVSs0wcUZ6kxRJsrUFY2OkYmDQXQsI00BikQUsnGqNodJ/sibbMWE5c0M VgRyvmCIihkPoEQIDVQQRaOmfoWpYtkj0Urz/fjZTiyh+dC67vnGW2/GlN6kcOtqDpwq NXlw== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6NJQQc+M66bGzxmhGXty4kEZh9TfhDnamP4TQAh12Hw=; b=r83VCy2dL9pVKvVOWzYele9gan+sbFr/dUuPmiIyTlKO0bPKU6XoyY9MSMx8sVBx2O ds6BdHHQhAWdrYDxti23cup/VuNRpnARcL1/OEu2fgrXe/iKeiqB/iwpese4+Jsnt+4A b2UsOJ0EuU8qVfAVDjRL5oRFmzJrIA5LFGuAFag908WxJIjRR7k/mu+4FXy4r2aMeXsY O9x2JYYOwksyt+Oub5+BMDXzAkFWvBNj+VQQ35UPAHfxuHy/gAiFqmWWJ+G7/UTcHxtY hzAwHx5bABOkwUP/o7Ly0QYh1HQ9VRqEZwRHl/POWNJHvCTvL7wtGrWhFyo3LGWBhGb3 dhtA== X-Gm-Message-State: APzg51Cqy3MTGbw71dxjURP9ncdgX/bSej4/Jj92TkXGSeyXaWhLAVBI W/X3KiV3QuBQNt2FQB4dRK+WH3sH X-Google-Smtp-Source: ANB0VdZOvqr6JUr5h03kbQH7HFZzyWwJ9jBPcKjlVoB795rKqZ9E5sLlhWnm49e85+PyWeKeQVHTAg== X-Received: by 2002:a63:4606:: with SMTP id t6-v6mr4271325pga.271.1536790294001; Wed, 12 Sep 2018 15:11:34 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 3-v6sm3966937pfq.10.2018.09.12.15.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 15:11:33 -0700 (PDT) Subject: Re: ipv6only-flag-02 security To: Markku Savela , ipv6@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> From: Brian E Carpenter Message-ID: <73165153-8396-6bc5-b6d6-c4130913cd14@gmail.com> Date: Thu, 13 Sep 2018 10:11:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 22:11:37 -0000 On 2018-09-12 21:31, Markku Savela wrote: > On 12/09/18 12:08, Ole Troan wrote: >>>> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 >>>> operations. The RA flag is incorrectly configured. Barbara >>> I don't agree. If all the RAs have ipv6-only set, and there is still DHCPv4, >>> I'd conclude that the IPv4 is fake. >> Agree. From my perspective the whole point of this flag is to signal configuration information to hosts. >> A compliant host receiving this flag, should disable all IPv4 processing on the relevant interface. > > And if I have a home/site network > > - connected to ISP offering IPv6 only, > > - and internally using additional IPv4 addresses via local DHCP server > (or via another ISP connection offering IPv4) to support locally IPv4 > only legacy devices (printers, etc.). > > As home/small site user (*), I may not have ANY control on RA's sent by > the first ISP. If they were to set this ipv6-only flag and, if this > would disable my IPv4 addressing, I would be a bit pissed off... > > (*) though, if ISP provided "home router" is configurable, and the > ipv6-only flag in RA would be controllable by home user. Then maybe > acceptable... Well yes. The scope is managed networks. We can make that clearer in the Applicability section. Brian From nobody Wed Sep 12 15:13:27 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB62130ECA for ; Wed, 12 Sep 2018 15:13:25 -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 WK3UKr4eKbyx for ; Wed, 12 Sep 2018 15:13:24 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732E2126F72 for ; Wed, 12 Sep 2018 15:13:24 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id r1-v6so1725544pgp.11 for ; Wed, 12 Sep 2018 15:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cc4lip5hLVO5EPUH2ztWzItWxYJO9wRkFWzZS46hqXI=; b=sbLAR51V3ahtqyfnjfK4zxrB5eWWhtslk8gLXXTVxKDbH0nX2M3sAJhs8ksY8KeZYj bFm7Qdio3lioJv1I+prxBp4/nggfZ2iYsFauazIL+mJyeKda2SnS7QT6QqukIO1Pu4jz S5WnwArl0q8kZ3WXqsFZKCCjpmBxggFMyHuOBNGmANVAqhdeo/b0l9Piy1u4Xxa1h7+j 9JVvYHI5UKGwkm1QgLxfPM86cbwbXAXHmx7l+Aea7u7JSyGhi3NRCTYWKVxreMUBd5Vh xkiaAqilNR3AfvTeSa3iXuUWTy37UCdyFRSn4thDSBONTf40oCIGmG2DvqglkaU0p/LV yZwA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cc4lip5hLVO5EPUH2ztWzItWxYJO9wRkFWzZS46hqXI=; b=rMS13urv1EGLNxD70w00yz/5SwNMS6a2WjKK+BOuyonHTZ1UXj4yALUZGSAhzdAxBd EumPg+hblFEKJ3j76QScUJWwdycGYWtp05vy4810yiBMwMLf60jwqRHoqHha9dogAbfr 1N6CqGh4mD2fTA35Hf1/QzeXk1fyFDkML6E3zMfHwfi9Kmq6ltzlk6kGiOajaLcM1cuC jcs93iWzidSmjvdafp3Zs2LZBH3NxW4m/XdFpZ6maUhyQLlIYtFenVYVcpM2HzEJ/aaQ BXKmNpA+A7vJ5J5xd7RRX3dw61ZRCPHo1fANrI/XJQAORY+TK17tAYEweOZBgnFECSea EQZQ== X-Gm-Message-State: APzg51Cv1MP/ESqPYSVqazshI88p1UDeZckDfTBnpP/lP6T+kQKcy56Y O+v9gQBBDW1yLUpwic42mby/xsBB X-Google-Smtp-Source: ANB0VdZbbTBDOhn6UWFYhSCR0uttbNc2EPAuZG3vjCW6FwJQ1zNQaFPzvOhr85uwS4yoDMJTDaatpA== X-Received: by 2002:a63:881:: with SMTP id 123-v6mr4337286pgi.244.1536790403647; Wed, 12 Sep 2018 15:13:23 -0700 (PDT) Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id n83-v6sm5466913pfk.19.2018.09.12.15.13.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 15:13:22 -0700 (PDT) Subject: Re: ipv6only-flag-02 security To: David Farmer , Markku Savela Cc: 6man WG References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> From: Brian E Carpenter Message-ID: <5f7ca4f5-5303-6a26-216f-db7c14ad09f2@gmail.com> Date: Thu, 13 Sep 2018 10:13:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 22:13:26 -0000 On 2018-09-13 02:19, David Farmer wrote: > On Wed, Sep 12, 2018 at 4:31 AM, Markku Savela wrote: > >> On 12/09/18 12:08, Ole Troan wrote: >> >>> If there is a DHCPv4 response, then the host SHOULD NOT shut down IPv4 >>>>> operations. The RA flag is incorrectly configured. Barbara >>>>> >>>> I don't agree. If all the RAs have ipv6-only set, and there is still >>>> DHCPv4, >>>> I'd conclude that the IPv4 is fake. >>>> >>> Agree. From my perspective the whole point of this flag is to signal >>> configuration information to hosts. >>> A compliant host receiving this flag, should disable all IPv4 processing >>> on the relevant interface. >>> >> >> And if I have a home/site network >> >> - connected to ISP offering IPv6 only, >> >> - and internally using additional IPv4 addresses via local DHCP server (or >> via another ISP connection offering IPv4) to support locally IPv4 only >> legacy devices (printers, etc.). >> >> As home/small site user (*), I may not have ANY control on RA's sent by >> the first ISP. If they were to set this ipv6-only flag and, if this would >> disable my IPv4 addressing, I would be a bit pissed off... >> >> (*) though, if ISP provided "home router" is configurable, and the >> ipv6-only flag in RA would be controllable by home user. Then maybe >> acceptable... >> > > The default for this flag is cleared for a reason, only someone with > knowledge of the devices attached to the LAN should set this flag. My ISP > has no idea what devices are attached to my home network, therefore it is > wholly inappropriate for an ISP to set this flag for the LAN in my house. > It could be reasonable for them to set the flag on a public WiFi network, > if it is clear it is an IPv6-only WiFi network, such as if it has "IPv6" in > the SSID or this is made clear in some other way. Furthermore, the flag is > not intended to signal anything about the WAN or upstream service provided > to an ISP's customers, it is about the local LAN. A local LAN can have IPv4 > routing with an IPv6-only uplink, using 464xlate, DS-Lite, etc.... > > Maybe someday in the future, it will be reasonable to change the default > for this flag to be set. That is when it is reasonable to expect that LANs > don't have IPv4, that is not the normal expectation today and it will be > sometime before that changes. > > Something like the following should be added to the draft; > > It is only appropriate for someone, an administrator, to set this flag if > they have a reasonable knowledge that the devices attached to a network > don't need IPv4 routing services or are not intended to have these services. Plus: The flag must be cleared by default. Brian From nobody Thu Sep 13 14:29:49 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5048A130E7D; Thu, 13 Sep 2018 14:29:47 -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 KndBHaL9dEKB; Thu, 13 Sep 2018 14:29:45 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071F7130E7C; Thu, 13 Sep 2018 14:29:45 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id r69-v6so10908921oie.3; Thu, 13 Sep 2018 14:29:44 -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=a5/UsJRTe1olkuhZ+G2CZWt/k84ynhvcNTOKokuVWLY=; b=Pflfejm+Sgm5hdbAgWafTtou0ZetpB+qurHBtcJn1QZOo2dG7DngJDwJqK+Gnv85MO Lq/1aKQHZMb7vUQKVbV0LjXiHkGuVZP+YYZ/AZyfcxkaE+zjJDuQmcGF3BobyX3FEznG bWy08NctVkVPvby2NdydqqNiggVxm7GJHn42A6SvKTwteEOUwTPrUExpgwNiUpcUo0Sa TihFVfxmI4h6FwWWr9cLO3csjmjAT2XYN1nzVRsnrwxYMIyAS3lpzz/Be51aVtsBlsCQ u7Cy8zuhQDt9PFY5Ncjw3ZOlw5JJvPBR0fAMBdEJgnQtF4K87nGqusDDl6MBo5OhU8WA vnlg== 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=a5/UsJRTe1olkuhZ+G2CZWt/k84ynhvcNTOKokuVWLY=; b=dSmUPQXrn9yOqUMMaPgVGa8oriG4gySUCu/OQ36a2N4iWkkxoSHOEMah6ia9YHEWpC DeaPCIqjUX96/aDbJ2q6Anb6l/XDIYBZY67dNQ5drmrFTgSAn8UQgOE+hYlZ3fsbESY+ ZHWI13m8J/DXn7ItQVTcQ7WYVBh5bAfmFqmq3i63eAwlvocFxRp1vQcN5mI2/252MZ05 FMAHO3fNX90DGl5CuLb9MRI9gZmPmneL2Ty3hKd0DzhL9qKF7BY7+p0ZbLthk8eVwXDu TMFmXtxEmiVhTAL/qqTFYaivfusQOwYTixrMGS7zRy2qYvJ4dR8pNTOUIil5WP97Tipv hW/A== X-Gm-Message-State: APzg51CBAppyHZ7yS+XE13HTfZUnWVsUdCx92VpU21aeRgZ9WO9ywymG qhNUl3STQ2LMMM4bT0XIwNF/W8Cc X-Google-Smtp-Source: ANB0VdaiNTtUxws8mjceO3aMqvVFtw4DRZX9cruaOdruFdJ0fI6zWtwKZ4o36OQwGCAWr3WsJid+fg== X-Received: by 2002:aca:f105:: with SMTP id p5-v6mr8065060oih.342.1536874184269; Thu, 13 Sep 2018 14:29:44 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1073? ([2600:8802:5600:1546::1073]) by smtp.gmail.com with ESMTPSA id q12-v6sm942364otd.41.2018.09.13.14.29.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 14:29:43 -0700 (PDT) From: Fred Baker Message-Id: <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9ACC1D7F-9565-4A26-89BF-7150FB92DCE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: ipv6only-flag-02 security Date: Thu, 13 Sep 2018 14:29:41 -0700 In-Reply-To: Cc: 6man WG , V6 Ops List To: Markku Savela References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 21:29:47 -0000 --Apple-Mail=_9ACC1D7F-9565-4A26-89BF-7150FB92DCE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking strictly for myself, all one of me. However, I'm copying v6ops = in case someone operational will dispute my viewpoint or support it. I would expect that if an ISP is offering only IPv6 to the CPE, the CPE = might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 = within the LAN. The ISP will never know whether there is actual IPv4 in = the home/SOHO/Enterprise, other than that the PLAT it presumably = implements will see traffic. If it's doing CGN, MAP-E, or MAP-T, it is = implementing the overlay, will be aware of it, and will be paying for = it; the 464XLAT model means that it doesn't have to think about it (or = pay for it) beyond the PLAT and its prefix. I'm hearing rumblings from = various operators to the effect that IPv4 is becoming operationally = expensive - one that has been in the news recently was Aussie Broadband, = but they are in no sense the only source of such rumblings. =46rom my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is = the best case currently on the table. If 6man agrees, I would suggest = using draft-pref64folks-6man-ra-pref64 at PS to deprecate (make = historic/NOT RECOMMENDED) RFCs 6147 and 7050. In that, there would be = value in a plugfest, perhaps at IETF 103 or 104 during the Hackathon, to = let various implementors demonstrate draft-ietf-v6ops-transition-ipv4aas = using 464XLAT+draft-pref64folks-6man-ra-pref64 and state their roll-out = plans. I find myself thinking about = https://www.youtube.com/watch?v=3D_y36fG2Oba0. Yes, I think a day = something like that is coming. First they ignore you; then they laugh at = you, ... > On Sep 12, 2018, at 2:31 AM, Markku Savela wrote: >=20 > On 12/09/18 12:08, Ole Troan wrote: >>>> If there is a DHCPv4 response, then the host SHOULD NOT shut down = IPv4 >>>> operations. The RA flag is incorrectly configured. Barbara >>> I don't agree. If all the RAs have ipv6-only set, and there is = still DHCPv4, >>> I'd conclude that the IPv4 is fake. >> Agree. =46rom my perspective the whole point of this flag is to = signal configuration information to hosts. >> A compliant host receiving this flag, should disable all IPv4 = processing on the relevant interface. >=20 > And if I have a home/site network >=20 > - connected to ISP offering IPv6 only, >=20 > - and internally using additional IPv4 addresses via local DHCP server = (or via another ISP connection offering IPv4) to support locally IPv4 = only legacy devices (printers, etc.). >=20 > As home/small site user (*), I may not have ANY control on RA's sent = by the first ISP. If they were to set this ipv6-only flag and, if this = would disable my IPv4 addressing, I would be a bit pissed off... >=20 > (*) though, if ISP provided "home router" is configurable, and the = ipv6-only flag in RA would be controllable by home user. Then maybe = acceptable... >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_9ACC1D7F-9565-4A26-89BF-7150FB92DCE1 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlua1sUACgkQEhdRnd2G P+BDhQ/+LtYy9DQUuzZwJ5+mLemwABJwAQIYeYNBL0P85tA+UwKc4RQJ55kftohb WXUvY8GhgvUS4YiFyAfE8cR6+MpHxdgdywLHdp0afFETFWuPlYgvHuoVVkWVHpyY wqROEvLeLhqD7lvo7xmHvZ/XHx3+sBTN5iRUOvanTjIUsc52FdKsuQPt+/bCJOFX /zTU1mlC7aIfzZFB+de8D4IKR/oTBGOgtxusWvC8U0K+XjJJtv+beWH5CnTa7CRx 4tFuT/wNipfpDNrxBIlu/EB+R6BMi7VFGyazhbBeLTTkozlyLVzkP3zGXXD6Wx2q kRY0Jr9asFGkldq4UhbU5VrPvtAVT/XbakUnSgaMfHb60k4TH4iC6DTanka6y1Co eyX5bHMFErZg9nR2GymnFr4x6oWcmkjgxCZvWrXtNXgbc0rceQjeewNikanL3SUW sR7O2dwpOW6NuVv5qNKe7FqHzUDdPAKFZaMrX8qakdhuSczyFmB06OfW6MoYjqFm TYwUOzR/XnfI7OrD8B8gkwBWhZA4kEdbLTDNb5SaabnIjMDyqZ5C0JyxFb/sTbC2 pNJQ3ZHXEdO2ZIIivF7GHDUfLNNmRKGwIXxbP8v4G4ZaYHgyZyZGItR6hmFvf6uP X8obmcoyCTEPB0sXir+2eI4FRYVJjRbZ+ETdxRKdTUBeuw63jMk= =3GH7 -----END PGP SIGNATURE----- --Apple-Mail=_9ACC1D7F-9565-4A26-89BF-7150FB92DCE1-- From nobody Thu Sep 13 16:53:26 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6D12008A; Thu, 13 Sep 2018 16:53:18 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PR9KQ0B_VNI; Thu, 13 Sep 2018 16:53:15 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBDF129C6B; Thu, 13 Sep 2018 16:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1536882793; x=1537487593; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=wgYrHKXFF2w4/6Wp6ehbbc8R4+ZmO/0yuZBJ6D9JJiI=; b=wgv6h0G5RtkOR vv7bqbvaNUAHW1Kg4IBuTzMTevYEFRr2BiiCbMIdIOUgKBWDfmiPWZhx4WJHj8Qs j9OvDpudYv9Mh/dolAaIpNrx+rSCUtxQufTNsZ93aHpHzEKU3HjW+hM9MRaEnu74 GrYHCEvU2hZgYTs6KfRwByo2/nXDhs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 14 Sep 2018 01:53:13 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 14 Sep 2018 01:53:12 +0200 Received: from [172.16.188.4] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005878760.msg; Fri, 14 Sep 2018 01:53:11 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [172.16.188.4] X-MDArrival-Date: Fri, 14 Sep 2018 01:53:11 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1794e86a39=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Fri, 14 Sep 2018 10:52:53 +1100 Subject: Re: [v6ops] ipv6only-flag-02 security From: JORDI PALET MARTINEZ To: Fred Baker , Markku Savela CC: V6 Ops List , 6man WG Message-ID: Thread-Topic: [v6ops] ipv6only-flag-02 security References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> In-Reply-To: <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:53:18 -0000 I fully agree with this point of view. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: viernes, 14 de septiembre de 2018, 8:31 Para: Markku Savela CC: V6 Ops List , 6man WG Asunto: Re: [v6ops] ipv6only-flag-02 security Speaking strictly for myself, all one of me. However, I'm copying v6ops= in case someone operational will dispute my viewpoint or support it. =20 I would expect that if an ISP is offering only IPv6 to the CPE, the CPE= might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 withi= n the LAN. The ISP will never know whether there is actual IPv4 in the home= /SOHO/Enterprise, other than that the PLAT it presumably implements will se= e traffic. If it's doing CGN, MAP-E, or MAP-T, it is implementing the overl= ay, will be aware of it, and will be paying for it; the 464XLAT model means= that it doesn't have to think about it (or pay for it) beyond the PLAT and= its prefix. I'm hearing rumblings from various operators to the effect tha= t IPv4 is becoming operationally expensive - one that has been in the news = recently was Aussie Broadband, but they are in no sense the only source of = such rumblings. =20 From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is t= he best case currently on the table. If 6man agrees, I would suggest using = draft-pref64folks-6man-ra-pref64 at PS to deprecate (make historic/NOT RECO= MMENDED) RFCs 6147 and 7050. In that, there would be value in a plugfest, p= erhaps at IETF 103 or 104 during the Hackathon, to let various implementors= demonstrate draft-ietf-v6ops-transition-ipv4aas using 464XLAT+draft-pref64= folks-6man-ra-pref64 and state their roll-out plans. =20 I find myself thinking about https://www.youtube.com/watch?v=3D_y36fG2O= ba0. Yes, I think a day something like that is coming. First they ignore yo= u; then they laugh at you, ... =20 > On Sep 12, 2018, at 2:31 AM, Markku Savela wrote: >=20 > On 12/09/18 12:08, Ole Troan wrote: >>>> If there is a DHCPv4 response, then the host SHOULD NOT shut down = IPv4 >>>> operations. The RA flag is incorrectly configured. Barbara >>> I don't agree. If all the RAs have ipv6-only set, and there is sti= ll DHCPv4, >>> I'd conclude that the IPv4 is fake. >> Agree. From my perspective the whole point of this flag is to signal= configuration information to hosts. >> A compliant host receiving this flag, should disable all IPv4 proces= sing on the relevant interface. >=20 > And if I have a home/site network >=20 > - connected to ISP offering IPv6 only, >=20 > - and internally using additional IPv4 addresses via local DHCP serve= r (or via another ISP connection offering IPv4) to support locally IPv4 onl= y legacy devices (printers, etc.). >=20 > As home/small site user (*), I may not have ANY control on RA's sent = by the first ISP. If they were to set this ipv6-only flag and, if this woul= d disable my IPv4 addressing, I would be a bit pissed off... >=20 > (*) though, if ISP provided "home router" is configurable, and the ip= v6-only flag in RA would be controllable by home user. Then maybe acceptabl= e... >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =20 -----------------------------------------------------------------------= --------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Sep 14 04:10:56 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0FD130E12; Fri, 14 Sep 2018 04:10:44 -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 codbVimoGHA8; Fri, 14 Sep 2018 04:10:42 -0700 (PDT) Received: from bugle.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 BDFB0126DBF; Fri, 14 Sep 2018 04:10:42 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 292CCFECBB47; Fri, 14 Sep 2018 11:10:41 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D86CF5ABCB5; Fri, 14 Sep 2018 13:10:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 security) From: Ole Troan In-Reply-To: <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> Date: Fri, 14 Sep 2018 13:10:38 +0200 Cc: Markku Savela , V6 Ops List , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 11:10:45 -0000 Fred, Did you post this on the wrong thread? I am not sure how this relates to = the ip6only-flag draft. Changed subject. > Speaking strictly for myself, all one of me. However, I'm copying = v6ops in case someone operational will dispute my viewpoint or support = it. >=20 > I would expect that if an ISP is offering only IPv6 to the CPE, the = CPE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 = within the LAN. The ISP will never know whether there is actual IPv4 in = the home/SOHO/Enterprise, other than that the PLAT it presumably = implements will see traffic. If it's doing CGN, MAP-E, or MAP-T, it is = implementing the overlay, will be aware of it, and will be paying for = it; the 464XLAT model means that it doesn't have to think about it (or = pay for it) beyond the PLAT and its prefix. I'm hearing rumblings from = various operators to the effect that IPv4 is becoming operationally = expensive - one that has been in the news recently was Aussie Broadband, = but they are in no sense the only source of such rumblings. Speaking as one of the editors of the MAP series documents, that=E2=80=99s= a misrepresentation. PLAT =3D stateful NAT64 has similar costs and scaling properties as a = CGN. That is, significantly worse than stateless solutions. > =46rom my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 = is the best case currently on the table. If 6man agrees, I would suggest = using draft-pref64folks-6man-ra-pref64 at PS to deprecate (make = historic/NOT RECOMMENDED) RFCs 6147 and 7050. In that, there would be = value in a plugfest, perhaps at IETF 103 or 104 during the Hackathon, to = let various implementors demonstrate draft-ietf-v6ops-transition-ipv4aas = using 464XLAT+draft-pref64folks-6man-ra-pref64 and state their roll-out = plans. I don=E2=80=99t know if 6man has a particular view on provisioining of a = NAT64 prefixes. Nor do I know if we should. If you mentioned the ipv6only-flag draft in the context 464XLAT. 464XLAT = offers a native dual-stack service, and that=E2=80=99s not what the = ipv6only-flag draft is about. That=E2=80=99s about true IPv6 only links, where there is no IPv4 = packets on the link. Ole= From nobody Fri Sep 14 04:42:13 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBA2130E35; Fri, 14 Sep 2018 04:42:04 -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 fe0ZbGkKhhY2; Fri, 14 Sep 2018 04:42:02 -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 2CD36126DBF; Fri, 14 Sep 2018 04:42:02 -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 w8EBfv65031215; Fri, 14 Sep 2018 13:41:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BC32F2059E3; Fri, 14 Sep 2018 13:41:57 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7A33203195; Fri, 14 Sep 2018 13:41:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EBfu6E019520; Fri, 14 Sep 2018 13:41:57 +0200 Subject: Re: [v6ops] NAT64 prefix configuration To: Ole Troan , Fred Baker Cc: V6 Ops List , 6man WG , Markku Savela References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> From: Alexandre Petrescu Message-ID: <4fcbfcea-2419-fa3a-4e27-33dd4c62e435@gmail.com> Date: Fri, 14 Sep 2018 13:41:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 11:42:05 -0000 Le 14/09/2018 à 13:10, Ole Troan a écrit : > Fred, > > Did you post this on the wrong thread? I am not sure how this relates to the ip6only-flag draft. > Changed subject. > >> Speaking strictly for myself, all one of me. However, I'm copying v6ops in case someone operational will dispute my viewpoint or support it. >> >> I would expect that if an ISP is offering only IPv6 to the CPE, the CPE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 within the LAN. The ISP will never know whether there is actual IPv4 in the home/SOHO/Enterprise, other than that the PLAT it presumably implements will see traffic. If it's doing CGN, MAP-E, or MAP-T, it is implementing the overlay, will be aware of it, and will be paying for it; the 464XLAT model means that it doesn't have to think about it (or pay for it) beyond the PLAT and its prefix. I'm hearing rumblings from various operators to the effect that IPv4 is becoming operationally expensive - one that has been in the news recently was Aussie Broadband, but they are in no sense the only source of such rumblings. > > Speaking as one of the editors of the MAP series documents, that’s a misrepresentation. > PLAT = stateful NAT64 has similar costs and scaling properties as a CGN. That is, significantly worse than stateless solutions. > >> From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is the best case currently on the table. If 6man agrees, I would suggest using draft-pref64folks-6man-ra-pref64 at PS to deprecate (make historic/NOT RECOMMENDED) RFCs 6147 and 7050. In that, there would be value in a plugfest, perhaps at IETF 103 or 104 during the Hackathon, to let various implementors demonstrate draft-ietf-v6ops-transition-ipv4aas using 464XLAT+draft-pref64folks-6man-ra-pref64 and state their roll-out plans. > > I don’t know if 6man has a particular view on provisioining of a NAT64 prefixes. Nor do I know if we should. > > If you mentioned the ipv6only-flag draft in the context 464XLAT. 464XLAT offers a native dual-stack service, and that’s not what the ipv6only-flag draft is about. > That’s about true IPv6 only links, where there is no IPv4 packets on the link. On 4G links of smartphones using CLAT and PDP type IPv6 (no IPv4 PDP type) there are no IPv4 packets. I understand CLAT has to do with 464xlat. So I suppose there is relevance of ipv6-only flag and 464xlat. I may be wrong though. Alex > > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 14 06:00:52 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D904130ED8; Fri, 14 Sep 2018 06:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 5sxYuBhWbB5j; Fri, 14 Sep 2018 06:00:36 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B428F130E3D; Fri, 14 Sep 2018 06:00:36 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id y134-v6so2573839ywg.1; Fri, 14 Sep 2018 06:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yyQVAh1Se6jXvP1AA4Z1wsdYHLHX6ZfY2xbRp44Olak=; b=QeOsvqblw5kJBsUvglgydphJ1BsyNCK/Wls08U2nPODFghJe0/MOpewVZkVYSiFePP 6qO4+inS1wYIxVGNcJpMPbGPNVFSCxIDxCbW1Oib4iwQ0GmfWn/atflMxctaqK+v7CNI gqAxCCLjyVgeBN6qLanMCjl8fcxlPTln26mLnX2YG8gFxp+vv40wDaixABvSegQi/mYZ FM7whuToUJF4HQl31HHd7d7sOVI8Adz6xTGfEugxwqOYLN/h5mUORlZYSmhPIAt1Sc7m jp1FCB1xq0QKIkNXx1k0Lx+ufNy4bnqI0h/ToFxg6S9adWF1eeY29Uvc1U1spjwm6iXa AAmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yyQVAh1Se6jXvP1AA4Z1wsdYHLHX6ZfY2xbRp44Olak=; b=MJ/2bPXrt9AW2qTjlZJLwtdR+lGn/6DNHZ2EJdHHNkOtnZPWJcQ6RtVJFc0m/hDczs ktd2SDrWxdCm6iXATCctufD9aPDQNuoqVouv2joX1Yl5SS4xQD7LRFxbqzkVsNN7wwrK h9NEX/yEm6LrlLd+tg7aIwLYn7GFB7WbCiDwtVhR6kU2iuRsBh+SVR4VmI/nG5TaHDpP 0qzPwe1I8px3L/Ph2Dl5GSDSZqUe7V7MsxmiMgLef175ysLH3HsDQau4/UiN9nxN2xyW ijNiraUbJLJTnJY3nsLGi18JzPDG8UrZk32IIGm3hU8Mz4nhXNte1Gkc2snncDy2dTVl uAjg== X-Gm-Message-State: APzg51CyxQx/gQX9vEz6S/lnrOynavwgtZDiHyy4CdFdL3yfCg0K7wbQ hrD0CkPoUIS1eJPxZNqOVhDh73mCfQpac5E3oi0f7A== X-Google-Smtp-Source: ANB0VdZTJ/RX34Yu1Y0ErArkjRJX8hze9L4zcc0dCcIqCCljCTSosNwyh6w1HHxX+QpI9xlZEjZGMcpNQrA1gycFQzI= X-Received: by 2002:a0d:c505:: with SMTP id h5-v6mr5416511ywd.477.1536930035817; Fri, 14 Sep 2018 06:00:35 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> In-Reply-To: From: Ca By Date: Fri, 14 Sep 2018 06:00:24 -0700 Message-ID: Subject: =?UTF-8?Q?Market_Rate_Cost_of_IPv4_life_support=E2=80=94_was_Re=3A_=5Bv6?= =?UTF-8?Q?ops=5D_NAT64_prefix_configuration?= To: Ole Troan Cc: 6man WG , Fred Baker , Markku Savela , V6 Ops List Content-Type: multipart/alternative; boundary="000000000000d45fca0575d468bf" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 13:00:45 -0000 --000000000000d45fca0575d468bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2018 at 4:11 AM Ole Troan > Speaking as one of the editors of the MAP series documents, that=E2=80=99= s a > misrepresentation. > PLAT =3D stateful NAT64 has similar costs and scaling properties as a CGN= . > That is, significantly worse than stateless solutions. > Citation? I don=E2=80=99t believe it is true, but would like to see your m= arket rate analysis (not the stateless religion axiom). In my own case, coming from nat44, we simply turned on nat64 on the same box, added ipv6 to the user, and load has gone down on that combined nat44/64 box due to most traffic going ipv6 e2e. In this way, nat64 has lowerd my load / bill with no new capex. That is my specific case. That said, i have only seen MAP BR be spec=E2=80=99d to deployed on million= dollar cards in million dollar routers. Also, map comes with a less efficient static v4 allocation model and complex dhcpv6 deployment. Both MAP and NAT64 come as freeware, but that is less interesting than a commercial solution a general telco could deploy, unless you have a freeware deployment case study. > > --000000000000d45fca0575d468bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri,= Sep 14, 2018 at 4:11 AM Ole Troan <mblings.

Speaking as one of the editors of the MAP series documents, that=E2=80=99s = a misrepresentation.
PLAT =3D stateful NAT64 has similar costs and scaling properties as a CGN. = That is, significantly worse than stateless solutions.

Citation?=C2=A0 = I don=E2=80=99t believe it is true, but would like to see your market rate = analysis (not the stateless religion axiom).=C2=A0
<= br>
In my own case, coming from nat44, we simply tur= ned on nat64 on the same box, added ipv6 to the user, and load has gone dow= n on that combined nat44/64 box due to most traffic going ipv6 e2e. =C2=A0 = In this way, nat64 has lowerd my load / bill with no new capex. That is my = specific case.=C2=A0

Tha= t said, i have only seen MAP BR be spec=E2=80=99d to deployed on million do= llar cards in million dollar routers.=C2=A0 Also, map comes with a less eff= icient static v4 allocation model and complex dhcpv6 deployment.=C2=A0 Both= MAP and NAT64 come as freeware, but that is less interesting than a commer= cial solution a general telco could deploy, unless you have a freeware depl= oyment case study.=C2=A0



--000000000000d45fca0575d468bf-- From nobody Fri Sep 14 06:57:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1516130E3A for ; Fri, 14 Sep 2018 06:57:08 -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, HTML_MESSAGE=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 9q8GxAcHFEEY for ; Fri, 14 Sep 2018 06:57:06 -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 7C755130E01 for ; Fri, 14 Sep 2018 06:57:06 -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 w8EDv4un010175 for ; Fri, 14 Sep 2018 15:57:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CA3A1205AF0 for ; Fri, 14 Sep 2018 15:57:04 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BEBF02058F7 for ; Fri, 14 Sep 2018 15:57:04 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EDv4rH003534 for ; Fri, 14 Sep 2018 15:57:04 +0200 To: IPv6 From: Alexandre Petrescu Subject: SLAAC RFC4862 - appropriate length of fe80:: prefix Message-ID: <6d9657d0-803c-fcb2-ddb9-13f707bdfd47@gmail.com> Date: Fri, 14 Sep 2018 15:57:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------08C8A0DB6A1907270D14C445" Content-Language: fr Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 13:57:09 -0000 This is a multi-part message in MIME format. --------------08C8A0DB6A1907270D14C445 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In RFC4862 'SLAAC' there is text about an 'appropriate length' of the link-local prefix, and further pointing to RFC4291. What is the 'appropriate length'? Because otherwise it is hard to implement step 2, because it tells the bits after the ll prefix are set to 0. > A link-local address is formed by combining the well-known link-local > prefix FE80::0 [RFC4291 ] (of appropriate length) with an interface > identifier as follows: > > 1. The left-most 'prefix length' bits of the address are those of > the link-local prefix. > > 2. The bits in the address to the right of the link-local prefix are > set to all zeroes. Which are those bits? > > 3. If the length of the interface identifier is N bits, the right- > most N bits of the address are replaced by the interface > identifier. Alex --------------08C8A0DB6A1907270D14C445 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

In RFC4862 'SLAAC' there is text about an 'appropriate length' of the link-local prefix, and further pointing to RFC4291.

What is the 'appropriate length'?

Because otherwise it is hard to implement step 2, because it tells the bits after the ll prefix are set to 0.


  A link-local address is formed by combining the well-known link-local
   prefix FE80::0 [RFC4291] (of appropriate length) with an interface
   identifier as follows:

   1.  The left-most 'prefix length' bits of the address are those of
       the link-local prefix.

   2.  The bits in the address to the right of the link-local prefix are
       set to all zeroes.

Which are those bits?



   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

Alex


--------------08C8A0DB6A1907270D14C445-- From nobody Fri Sep 14 07:01:58 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B035E130E34 for ; Fri, 14 Sep 2018 07:01:56 -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, HTML_MESSAGE=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 8vVHGPsDfUQA for ; Fri, 14 Sep 2018 07:01:55 -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 2FEB812785F for ; Fri, 14 Sep 2018 07:01:55 -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 w8EE1rtA046426 for ; Fri, 14 Sep 2018 16:01:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 740432015F6 for ; Fri, 14 Sep 2018 16:01:53 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 68E8D201063 for ; Fri, 14 Sep 2018 16:01:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w8EE1rjr007008 for ; Fri, 14 Sep 2018 16:01:53 +0200 To: IPv6 From: Alexandre Petrescu Subject: RFC8064 'stable IIDs' - for LLs Message-ID: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> Date: Fri, 14 Sep 2018 16:01:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010793C64D8B17DD810E6ADC" Content-Language: fr Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 14:01:57 -0000 This is a multi-part message in MIME format. --------------010793C64D8B17DD810E6ADC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, In RFC8064 'stable IIDs' are recommended to be used for SLAAC. But does this include the part of SLAAC that generates link-local addresses? I am asking because the part of SLAAC that generates link-local addresses is not clear on the prefix length. As such, I am tempted to believe RFC8064 does not apply to link-local addresses and other methods to achieve the same could be better, e.g. dynamically changing a MAC address. Alex --------------010793C64D8B17DD810E6ADC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

In RFC8064 'stable IIDs' are recommended to be used for SLAAC.

But does this include the part of SLAAC that generates link-local addresses?

I am asking because the part of SLAAC that generates link-local addresses is not clear on the prefix length.

As such, I am tempted to believe RFC8064 does not apply to link-local addresses and other methods to achieve the same could be better, e.g. dynamically changing a MAC address.

Alex

--------------010793C64D8B17DD810E6ADC-- From nobody Fri Sep 14 07:17:00 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF7D1277BB; Fri, 14 Sep 2018 07:16:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQEHuiWyDKbi; Fri, 14 Sep 2018 07:16:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69ED12785F; Fri, 14 Sep 2018 07:16:55 -0700 (PDT) Received: from [192.168.2.228] ([80.159.240.8]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MQ2Wx-1fvbxx1TRT-005FQ8; Fri, 14 Sep 2018 16:16:50 +0200 From: ianfarrer@gmx.com Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_873CAC1F-2D28-4BBA-BB7A-54608E3FB027" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: =?utf-8?Q?Re=3A_Market_Rate_Cost_of_IPv4_life_support=E2=80=94_wa?= =?utf-8?Q?s_Re=3A_=5Bv6ops=5D_NAT64_prefix_configuration?= Date: Fri, 14 Sep 2018 16:16:48 +0200 In-Reply-To: Cc: Ole Troan , V6 Ops List , 6man WG To: Ca By References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:hewbFQGPBqOce//xmHQleDLbNUUP0lmAiPTzGs9ZRpwZ0FHHP8U 6ERD00+PVInFCWtd52aXgtQQqYMDPQOYDuGpZaSt1OrtM1S3QbrCYSRE+S/2BJQZESxy9Qp uN+xV/yVvBjrA+BoZPfwwilSA0fTXjPrgcP1SJDPl0O9cOzNiqEcZlXZF4Os2DHCDEEKf0u dR96Kod5+D4uAdzt2483A== X-UI-Out-Filterresults: notjunk:1;V01:K0:p3EHsIXqS68=:Zo22tcy2vme7Ii7M4L0kal kzyFih+w3DY9/cu/t2qhRueuQXNWybAcBvp0C7VxoB24/UnJouS5HKpcAt/ROLlTtgcIsro1+ WOBtD1Dd9KzwqWASo/8tZyen7Q0ZB/3iipr5AKOJr+imCYD2AzLt8sLOelK7rWhxalrg0TyVx /azgipkJj9su1mud3Fwa2KzqwkutwAwA/Mh9OGog6fYW+rm3OpZbGdc1HZnn/YRCrg5Phx2nI veVy7y8aLbxXLEAjhlUchu1KYBUqu2oGdU5Cg0AlCRy44/JF8/Cybr0joDfy6SgR/ycXfs0LN svdq7TxJc/OE1q9PmDD1iH0OcqCYqcoD00NxJpqqY7JVk3wWpNWrIf1Wdn8gnPmznF6kuSbSC k7bbWrfQEDSCbh2QMv2sXPDFlbZ6o5gNzUXsWppCEMqWRIR73CO47awB8Aderspz8UzhiSzxr a5VnVImSQx9CS4Xq/1RyDkHMqqGjLijtiEEtpxtife3W2wSS03KyM7yTnqPXJ0mhvz1alnNkO kYAwjk3aGPb49BsJk0MdmhpkKIHR8RHGh5Yvt/9wMTVx8F3jrqR0CU8LzJ10zmAwPjMTEqoPX OURdSbY2O8ZqvUbmgHk0mpBte0Yc4cAwRt5k8UUWfiCwvctYoVOeIB4XoHahsQJ3t9h1h6nc/ WI/SVW5wfm5PqI1Q64PJfo2Z4/FHORa8c19HC7Oytpe1rMpi4MYyPi9ABNPD8UJrE/xy4OR1O pwEg+7ZyQM8Ote4nVxKYDiUlkS9oK801P9dXqaVS+uO08RjWeuyQBerTvS1YeFFuwXc2Crq8S gPyy0vo6EGcdx4iRIKBazjyNfInPm/mk4RaRNprGRNxtfEwzxw= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 14:16:58 -0000 --Apple-Mail=_873CAC1F-2D28-4BBA-BB7A-54608E3FB027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 H Cameron, >=20 > Speaking as one of the editors of the MAP series documents, that=E2=80=99= s a misrepresentation. > PLAT =3D stateful NAT64 has similar costs and scaling properties as a = CGN. That is, significantly worse than stateless solutions. >=20 > Citation? I don=E2=80=99t believe it is true, but would like to see = your market rate analysis (not the stateless religion axiom).=20 We (DT) currently have customer deployments of both FOSS and commercial = implementations of lw4o6 AFTRs in production. Compared to a stateful = NAT44/64 based solution (where none was currently deployed), the = business case was pretty simple to make. Cheers, Ian --Apple-Mail=_873CAC1F-2D28-4BBA-BB7A-54608E3FB027 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 H = Cameron,


Speaking as one of the editors of the MAP series documents, that=E2=80=99s= a misrepresentation.
PLAT =3D stateful NAT64 has similar costs and scaling properties as a = CGN. That is, significantly worse than stateless solutions.
=

Citation?  I don=E2=80=99t believe it is = true, but would like to see your market rate analysis (not the stateless = religion axiom). 

We (DT) currently have customer deployments of = both FOSS and commercial implementations of lw4o6 AFTRs in production. = Compared to a stateful NAT44/64 based solution (where none was currently = deployed), the business case was pretty simple to make.

Cheers,
Ian


= --Apple-Mail=_873CAC1F-2D28-4BBA-BB7A-54608E3FB027-- From nobody Fri Sep 14 08:15:04 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28539130E3A for ; Fri, 14 Sep 2018 08:15:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFHfd7994Nbb for ; Fri, 14 Sep 2018 08:14:59 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A1A5D130F2C for ; Fri, 14 Sep 2018 08:14:59 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1g0po8-0001nI-Q5 for ipv6@ietf.org; Fri, 14 Sep 2018 17:14:57 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1g0po5-00013h-G8 for ipv6@ietf.org; Fri, 14 Sep 2018 11:14:54 -0400 Received: (qmail 12411 invoked from network); 14 Sep 2018 15:14:50 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.28]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Sep 2018 15:14:50 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-EB09CB69-14E7-4C10-A9BB-C630EF731193 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15G77) In-Reply-To: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> Date: Fri, 14 Sep 2018 08:14:48 -0700 Cc: IPv6 Content-Transfer-Encoding: 7bit Message-Id: <59C12D2E-7AA1-4876-9BE0-1E925846B418@huitema.net> References: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> To: Alexandre Petrescu Subject: Re: RFC8064 'stable IIDs' - for LLs X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ibhc+sx9NfOdRD26+h7pk9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0+c5LB5+AaOnyUGHzplYThs1ujulqUFmMITHM77eiViUqVzP1UflIEv9E7NXZkpec7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMRfGK/Ioq0dRA5A4PDP/VsLPwUimsNGvJJilSn4u6QSZK79ow2+LfYh ZbtSfVm8g2As95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GALxCCXdUXmVhCtBec/fcEYvj esdofIZr77ejLGfC2JB7GPG0gBeFe8dTkoKHsNX/zU8cW9l7L/bUyy3TdA61l2ekajBWnAs1+ZT0 1veM1Hk9bht5tEV/FXnWhTl8G6jhA9Iivy+nwsaRXVdompsKqyI7+HMsm+XOE+peQg8UdgPS647l NwN4qOsSZg+fYhVZG8EuigKZXkUgcJXSWcT6ymmvPRlp44C0jVYGRiPSt4ToCZPO2GKNZaMtjfyA obtcMvAFMvX7q8M4x6bP/gjzw0OjTdGcfvx5IojyUdakbY3OIKvEx19waJj/yR/yCVBWvmU/ts+C IC6rClmkQnuoxlv2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 15:15:03 -0000 --Apple-Mail-EB09CB69-14E7-4C10-A9BB-C630EF731193 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The stable IID algorithm is fine but if you want privacy you have to ensure t= hat the IID gets randomized whenever you randomize the MAC. -- Christian Huitema=20 > On Sep 14, 2018, at 7:01 AM, Alexandre Petrescu wrote: >=20 > Hi, >=20 > In RFC8064 'stable IIDs' are recommended to be used for SLAAC. >=20 > But does this include the part of SLAAC that generates link-local addresse= s? >=20 > I am asking because the part of SLAAC that generates link-local addresses i= s not clear on the prefix length. >=20 > As such, I am tempted to believe RFC8064 does not apply to link-local addr= esses and other methods to achieve the same could be better, e.g. dynamicall= y changing a MAC address. >=20 > Alex >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-EB09CB69-14E7-4C10-A9BB-C630EF731193 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit The stable IID algorithm is fine but if you want privacy you have to ensure that the IID gets randomized whenever you randomize the MAC.

-- Christian Huitema 

On Sep 14, 2018, at 7:01 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Hi,

In RFC8064 'stable IIDs' are recommended to be used for SLAAC.

But does this include the part of SLAAC that generates link-local addresses?

I am asking because the part of SLAAC that generates link-local addresses is not clear on the prefix length.

As such, I am tempted to believe RFC8064 does not apply to link-local addresses and other methods to achieve the same could be better, e.g. dynamically changing a MAC address.

Alex

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--Apple-Mail-EB09CB69-14E7-4C10-A9BB-C630EF731193-- From nobody Fri Sep 14 09:42:26 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1E8130E44 for ; Fri, 14 Sep 2018 09:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.146, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIFJwkySB2Wl for ; Fri, 14 Sep 2018 09:42:09 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD35130E1F for ; Fri, 14 Sep 2018 09:42:08 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id d7-v6so3002377lfa.5 for ; Fri, 14 Sep 2018 09:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DiHFmeu2SgGjKW4gCe7eZOfO2U5MGoI/A4rapjAhJVM=; b=Wx40eieezJJiRJQxpXDYr3SXI0+06loN14T5AAle2+yFPZtXZmchs5yZmFGaqeJL4b uJ7Qpmj/9OgndQB4fbtRbCl8z2/EVttCeypoz4to89CB7XBv+W1ULvXttojjFbWTA8BB Y4aBWs4loZKlkz6xaX6VNc2vxEr85BWssbWZLSUW4Z4DwIx3Wf/z933Uy8LQykVSuTb+ fUbje3wjlbIiXSQ+oZtOGfIyKsEaWQiU6xWc1q6AHhrmhUFLb3etWAsbaN4+5/ZLkaBz 79+rSSoKB74507ngLjjyaKVJ9Nm6ZBQSmRKhkbA9qiSLmwVnvqLZ6wTRNN6wXbKXldrN nj8g== X-Gm-Message-State: APzg51COAOSpdfOAFs4gXcy72dcf+dWj59zcMrQzkQynmn2esXZgK7cu 9O7axdqAR5mtlg07KfD8EBqw/YvhX0xDVu2Shsc= X-Google-Smtp-Source: ANB0VdamI6Bd4j51sdqJxI8SE6Culqm2fXd8pITmGs004T/oWU6Hun1WsOq9Dugr4vMyD5zQjVza3A1Adjuq9q947v0= X-Received: by 2002:a19:db15:: with SMTP id s21-v6mr2587125lfg.114.1536943326816; Fri, 14 Sep 2018 09:42:06 -0700 (PDT) MIME-Version: 1.0 References: <6d9657d0-803c-fcb2-ddb9-13f707bdfd47@gmail.com> In-Reply-To: <6d9657d0-803c-fcb2-ddb9-13f707bdfd47@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 14 Sep 2018 09:41:55 -0700 Message-ID: Subject: Re: SLAAC RFC4862 - appropriate length of fe80:: prefix To: Alexandre Petrescu Cc: IPv6 IPv6 List Content-Type: multipart/alternative; boundary="00000000000008eeeb0575d781b4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 16:42:25 -0000 --00000000000008eeeb0575d781b4 Content-Type: text/plain; charset="UTF-8" At Fri, 14 Sep 2018 15:57:04 +0200, Alexandre Petrescu wrote: > In RFC4862 'SLAAC' there is text about an 'appropriate length' of the > link-local prefix, and further pointing to RFC4291. > > What is the 'appropriate length'? > > Because otherwise it is hard to implement step 2, because it tells the > bits after the ll prefix are set to 0. > > > A link-local address is formed by combining the well-known link-local > > prefix FE80::0 [RFC4291 ] (of appropriate length) with an interface > > identifier as follows: > > > > 1. The left-most 'prefix length' bits of the address are those of > > the link-local prefix. > > > > 2. The bits in the address to the right of the link-local prefix are > > set to all zeroes. > > Which are those bits? The short answer would be: - "the link-local prefix" is fe80::/10 - "the bits" in bullet #2 are the rightmost 118 bits Somewhat longer answer, or explanation: I guess a background motivation of the question is that RFC4291 doesn't explicitly define the term "link-local prefix". While I personally believe the specifications are sufficiently clear for the vast majority of implementors, it would have been even more super perfect if the description of RFC4862 referred to Section 2.4 of RFC4291 and stated "the link-local prefix is the binary prefix shown in Section 2.4 of RFC4291 that identifies link-local unicast addresses". In practice, if it were not fe80::/10, the only other possibility from RFC4291 would be fe80::/64 according to this diagram: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Again, personally, I wouldn't consider the intermediate 54 bits to be a part of the "link-local prefix", but since RFC4291 doesn't explicitly define this term, I can't deny the possibility that someone with extraordinary imagination could think that the 54 bits are part of "the prefix". Even with this interpretation, however, that doesn't matter much in practice (at least today), since as of RFC4862 the length of the interface ID is supposed to be defined in link-type documents, and (AFAIK) all existing such documents say it's 64 bits. So, either way, an implementation can auto-configure a link-local address, and the result is the same. -- JINMEI, Tatuya --00000000000008eeeb0575d781b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Fri, 14 Sep 2018 15:57:04 +0200,
Al= exandre Petrescu <alexan= dre.petrescu@gmail.com> wrote:

> In RFC4862 'SLAAC'= ; there is text about an 'appropriate length' of the
> link-= local prefix, and further pointing to RFC4291.
>
> What is the= 'appropriate length'?
>
> Because otherwise it is har= d to implement step 2, because it tells the
> bits after the ll pref= ix are set to 0.
>
> >=C2=A0=C2=A0=C2=A0 A link-local addre= ss is formed by combining the well-known link-local
> >=C2=A0=C2= =A0=C2=A0=C2=A0 prefix FE80::0 [RFC4291 <https://tools.ietf.org/html/rfc4291>] (of appropria= te length) with an interface
> >=C2=A0=C2=A0=C2=A0=C2=A0 identifie= r as follows:
> >
> >=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0 Th= e left-most 'prefix length' bits of the address are those of
>= ; >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the link-local prefi= x.
> >
> >=C2=A0=C2=A0=C2=A0=C2=A0 2.=C2=A0 The bits in t= he address to the right of the link-local prefix are
> >=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set to all zeroes.
>
>= Which are those bits?

The short answer would be:
- "the lin= k-local prefix" is fe80::/10
- "the bits" in bullet #2 ar= e the rightmost 118 bits

Somewhat longer answer, or explanation:
=
I guess a background motivation of the question is that RFC4291
does= n't explicitly define the term "link-local prefix".=C2=A0 Whi= le I
personally believe the specifications are sufficiently clear for th= e
vast majority of implementors, it would have been even more super
p= erfect if the description of RFC4862 referred to Section 2.4 of
RFC4291 = and stated "the link-local prefix is the binary prefix shown
in Sec= tion 2.4 of RFC4291 that identifies link-local unicast
addresses".<= br>
In practice, if it were not fe80::/10, the only other possibility fr= om
RFC4291 would be fe80::/64 according to this diagram:

=C2=A0= =C2=A0 |=C2=A0=C2=A0 10=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 |=C2=A0 b= its=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 54 = bits=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64 bits=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 +----------+-----------------= --------+----------------------------+
=C2=A0=C2=A0 |1111111010|=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 interface ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0 +----------+-------------------------+------------= ----------------+

Again, personally, I wouldn't consider the int= ermediate 54 bits to be
a part of the "link-local prefix", but= since RFC4291 doesn't
explicitly define this term, I can't deny= the possibility that someone
with extraordinary imagination could think= that the 54 bits are part
of "the prefix".

Even with t= his interpretation, however, that doesn't matter much in
practice (a= t least today), since as of RFC4862 the length of the
interface ID is su= pposed to be defined in link-type documents, and
(AFAIK) all existing su= ch documents say it's 64 bits.

So, either way, an implementation= can auto-configure a link-local
address, and the result is the same.
--
JINMEI, Tatuya
--00000000000008eeeb0575d781b4-- From nobody Fri Sep 14 10:23:21 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC05130F25 for ; Fri, 14 Sep 2018 10:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 z5SxLzNGhBXw for ; Fri, 14 Sep 2018 10:23:08 -0700 (PDT) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::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 8155C130EDC for ; Fri, 14 Sep 2018 10:23:08 -0700 (PDT) Received: by mail-qt0-x243.google.com with SMTP id n6-v6so9430872qtl.4 for ; Fri, 14 Sep 2018 10:23:08 -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=Ywi4mylri7S3OqRYa/U9OC5OhTm+KCbmOiOiU7n17Io=; b=z8lmLVCR/ZE/6zCv/ZFvj3dfZEIzZEcDLfr/bgbgwjuuRRRnAmzIHYRGwQlNwTzxCB tm/WLWwWchBs7UnvvspIIYmWJXp3EbTEOXf9rwU2EcEQLATe4T1bEg8smJWU1iSQa7eR QppG5VX7Lcl5ZTKmF5XVzsfxgPFsz8du8VD0FPLTvpP4EYYHk+ukkISvrU0SKlJykcOV WJeDuqGzScNCPeTo+KRbPsP3qyO4fRqICSF44NsFDWmtHy2M9Nglupm1ZwXU0bXycdCZ q7kVc+NMOzmA3i1tfaNsqJnPVb/QtqI5UjnvThUx1nxwgFUHcxGE79Q+9+rRS1O7pUug E8pQ== 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=Ywi4mylri7S3OqRYa/U9OC5OhTm+KCbmOiOiU7n17Io=; b=YMepleWvSpihU5JwP9mccHW2ZGWZd5Pg3UAZP2shypXfPBcLlgg9TRpDS3wJi0SO+M wLU9Ho6eqjO3Wb+NkwbmtGXhDu+3bVQjL6QOHUl3qwiP/9j1ZoKxSWxFCsPBZ9NRMc5m Nn6I3Jc5Mi/zL+gp+C8rjgtRXzdVJX/gpsCF9jHjkWdywxUNHk35KhHjtEn8NF3YIh5i GjL9OENZvCWDYhUufSX63+FgK7i/nSnClVi3ibPFKo43rR0kL5HS8Ol0uosM16/NOn7i wU8k1olUuLcQ6RMLC7mWoGwgN0DvveQdSr+AN4Ie6nZdYCVM146nqu5XCPVqUg2b6UGv Oc+A== X-Gm-Message-State: APzg51CLHlmLhg0ZNizsW0o3aR4bCu/SjSzWyleOZ1rLkjFLFttifCDD TbHIteXX7MKDwHpfpabaxFQS79ML81MR9wdHNftyDg== X-Google-Smtp-Source: ANB0VdYl1570+KJ2WXHiCF8sKm2HYk9zf1eqBzR9m5lcXoc8uASDmf+z0q2YVDwulpLi+bjjDEitt3T+yMV68b5HrgY= X-Received: by 2002:ac8:6790:: with SMTP id b16-v6mr9505935qtp.66.1536945787355; Fri, 14 Sep 2018 10:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 10:23:06 -0700 (PDT) In-Reply-To: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> From: Tom Herbert Date: Fri, 14 Sep 2018 10:23:06 -0700 Message-ID: Subject: Re: Modifiable Destination Options To: Xiejingrong Cc: Fred Baker , IPv6 IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 17:23:21 -0000 On Fri, Sep 7, 2018 at 11:54 PM, Xiejingrong wrote= : > Hi all, > > I think the Destination Options is different from HBH, though they share = "The same Option Type numbering space", and have the same "Modifiable or no= t" bit. > > The draft means to use such a "Modifi= able Destination Options" with a Multicast Address in the IPv6 DA. > > My understanding about the "change en route to the packet's final destina= tion" is that, > > (1) For a Multicast Address in IPv6 DA, the "final destination" is the IP= v6 node(s) who don't forward the packet anymore. And thus the "Modifiable D= estination Options" is required. > > (2) If is also suitable for cases when Unicast Address in IPv6 DA and Des= tination Options is ahead of Routing header. > Hi Xiejinggrong, I don't think it should matter whether the final destination is multicast or unicast. The final destination is at the node that is addressed in the destination address. In the case of multicast, it's simply the end nodes that receive the packets as addressed by the multicast address. It is unclear to me if a Destination Option is appropriate for BIER. It seems like the target of the information is intermediate routers in the path that are not explicitly addressed by the destination address (i.e. there's no routing header present that writes destination addresses en route). Should this be a Hop-by-Hop option instead? Tom > To quote two paragraphs of RFC8200: > note 1: for options to be processed by the first destination that > appears in the IPv6 Destination Address field plus > subsequent destinations listed in the Routing header. > > The third-highest-order bit of the Option Type specifies whether or > not the Option Data of that option can change en route to the > packet's final destination. > > Thanks > Jingrong > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Saturday, June 30, 2018 5:38 AM > To: Tom Herbert > Cc: IPv6 IPv6 List ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > Subject: Re: Modifiable Destination Options > > > >> On Jun 29, 2018, at 9:54 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> >> At Thu, 28 Jun 2018 15:09:05 -0700, >> Tom Herbert wrote: >> >>> I don't see that that setting this bit for a Destination Option is >>> prohibited. So what is the effect of setting a Destination Option >>> type to be modifiable en route? > > I thought the point of a destination option was that it was only evaluate= d by the system identified by the destination address? If it's being modifi= ed in flight, that sounds like it belongs in the HBH header. > >>> Is setting a Destination Option to be changeable en route valid? I >>> suppose the text that extension headers except for HBH can't be >>> processed in transit implies that a DO can never be modified en route >>> and trumps the DO changeable bit, but are there case where it could >>> be legitimately be changed, maybe the end host is allowed to modify >>> the option before delivery to the application? >> >> When used with a routing header? >> >> -- >> JINMEI, Tatuya >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Fri Sep 14 12:44:58 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8D130E6B; Fri, 14 Sep 2018 12:44: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 o4ht49ixMFlM; Fri, 14 Sep 2018 12:44:54 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764F0130E3A; Fri, 14 Sep 2018 12:44:54 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id b15-v6so13836302oib.10; Fri, 14 Sep 2018 12:44:54 -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=kwczqSRZun2u2WnwQPayOTwj1WPUk+pg3zEsy64V8tw=; b=ec1JfZ95DOPEbkbWh5L79cWJLLf3hT9o/F8lzNkJet/Fc6IN5z0Q4z7QaflhWUDQ7X uu+G+WkDL02aWS/dH+DAkna5N6jxqtTkt9CjUVSN+JD76/+X5oF1JSPht5MWEISKkfcJ sO2El+bgkUr30TBvlzkhlKaSY5ev6N9exCZPFdMrPn4DcEoi+zd4c3p+jyco1rZJJq03 m2jvEwm15mzDeJaiQ5S22yhQAq6Fz9c1Meq6W1u79w+N/2P//T1L3uhM3KNaDlDH6eQ3 V5HH8Ec/nlLTg0yXiy8rDwTS1lzH2dpfH59n112IHaKyx98EWvkFPLDVNNv0Z1Hc0N0H FR+g== 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=kwczqSRZun2u2WnwQPayOTwj1WPUk+pg3zEsy64V8tw=; b=qdYK1mnGMjSIRHx9i+/k2Jj3nRBDcvIhvgkhyztH9V6Af7eamfm5EZqcD40lQ9rfHr AcL3WDlpuRwFM6+caeFdVcChhElaYR3Mdin6AVD8qrHkL73Vivji0I2N6jsKURNcmfa4 FJpLtgzG2ao1KMpxBMlsGwsGSXLSbXh5vh2Bq7vMJ+9IIUV1dF4XJ0AGE9jLrGQPflou Skb0E1cczAmVXLxofylmHsCoV5jxZ0fMoFSy1sTTNyb5x8D3AulXoSOqe4lPt0A5WPdG q4k/rvMT8tOUU1k5NkhGQbhxO++iJwm8OJA+DQNt2e5zZK3DnIM4kj5oz7r3EdrxoVB/ EdBQ== X-Gm-Message-State: APzg51D4XnuH52J9Fw/daMGdsA5NVYeNO/eT3WXSfP4sjl0HYxJ+8aTQ cwfFD/OkJPkHiJvwRDwQpcY= X-Google-Smtp-Source: ANB0VdZ7T3SO3A13AGnLbmCUPK5QUpQ7kYxl/da1un4dbJCwHkGZo0mpBVhTe5AY5UlwNctAsOu6rg== X-Received: by 2002:a54:4017:: with SMTP id x23-v6mr10013659oie.25.1536954293690; Fri, 14 Sep 2018 12:44:53 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1073? ([2600:8802:5600:1546::1073]) by smtp.gmail.com with ESMTPSA id 207-v6sm7360720oie.14.2018.09.14.12.44.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 12:44:52 -0700 (PDT) From: Fred Baker Message-Id: <55866B92-DF5B-4E17-89A8-8B0B409AC23D@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_303BD5F0-E9BA-455B-9860-3FF4A1756A45"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 security) Date: Fri, 14 Sep 2018 12:44:41 -0700 In-Reply-To: Cc: Markku Savela , V6 Ops List , 6man WG To: Ole Troan References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 19:44:57 -0000 --Apple-Mail=_303BD5F0-E9BA-455B-9860-3FF4A1756A45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 14, 2018, at 4:10 AM, Ole Troan wrote: >=20 > Fred, >=20 > Did you post this on the wrong thread? I am not sure how this relates = to the ip6only-flag draft. Well, it was in the context of a comment raised on that thread. But yes, = after I sent it, I realized I should have changed the subject. > Changed subject. >=20 >> Speaking strictly for myself, all one of me. However, I'm copying = v6ops in case someone operational will dispute my viewpoint or support = it. >>=20 >> I would expect that if an ISP is offering only IPv6 to the CPE, the = CPE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 = within the LAN. The ISP will never know whether there is actual IPv4 in = the home/SOHO/Enterprise, other than that the PLAT it presumably = implements will see traffic. If it's doing CGN, MAP-E, or MAP-T, it is = implementing the overlay, will be aware of it, and will be paying for = it; the 464XLAT model means that it doesn't have to think about it (or = pay for it) beyond the PLAT and its prefix. I'm hearing rumblings from = various operators to the effect that IPv4 is becoming operationally = expensive - one that has been in the news recently was Aussie Broadband, = but they are in no sense the only source of such rumblings. >=20 > Speaking as one of the editors of the MAP series documents, that=E2=80=99= s a misrepresentation. > PLAT =3D stateful NAT64 has similar costs and scaling properties as a = CGN. That is, significantly worse than stateless solutions. Agreed. But a stateless solution has the operator purchasing IPv4 = address space and using it end to end for the IPv4 component. If the = objective is to no longer need to purchase or manage IPv4 address space = (Aussie Broadband's presentation at AUSNOG a couple of weeks ago being = but one example of such a viewpoint), a solution that requires them to = purchase and manage IPv4 in the ISP network fails the requirement. >> =46rom my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 = is the best case currently on the table. If 6man agrees, I would suggest = using draft-pref64folks-6man-ra-pref64 at PS to deprecate (make = historic/NOT RECOMMENDED) RFCs 6147 and 7050. In that, there would be = value in a plugfest, perhaps at IETF 103 or 104 during the Hackathon, to = let various implementors demonstrate draft-ietf-v6ops-transition-ipv4aas = using 464XLAT+draft-pref64folks-6man-ra-pref64 and state their roll-out = plans. --Apple-Mail=_303BD5F0-E9BA-455B-9860-3FF4A1756A45 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlucD6wACgkQEhdRnd2G P+A1hw/+L2yHvmg1089sCUw2V55t+/8tqm3pcZ8y91FitCEEaMrIgRdtFGVigcMh m0pz2BMZe0+fKqjTx6DfPoauqEgoCWQ19TB2ng5nngZb5Sce3jr3k82gVH7aNo3Y n6CURTPMxElH+2fxLR4O2qviHQSHe0aM0Hzjfftq85jCk6r29Ws2oMQ+VfjdWJoU w05bvq55Mz8M2HargrtLlT2vjw5auIkVMIdwfxS7cgXWlTYMBl4Ri7xvi+AqH6mV L11i2rZb+MIe8RI74JD87XkqkyU4W0VA6rPb9rDkB3VoGB+Fa88QJLg1K58qYL9k MLDAoFQMfeb/9ANAnD2MqC6VAgT71/K2f0t0DhI0OOd89OHhpH5PmvTrKMS6YpP/ 2N8DZFslQlBz5ZK1bH6f4dLbec+C2IKSe1vtlaPG0mZoBf1wuMBYGUB3bLaKZLB6 +2GFigN7MoLDuysuFgt7ntfC2Y10WA7ONNe6oKR8HIKvogHXD+Yw/Uri6lJaCkPS i7vQJpdbaw6cg+SyvE0u+EJR2YGYFGG6l1/8fDX9tqGmsN6ShBZBvIdY47E4NdpN gaT8nKq9vUR6PiznoTHdi5pcAsU3WC1qJsqGoUGD2rxsNzBNKbjkrmhhqAkG9CVA +fDh0ghslssqXxZqBmsyrw/StNj6zJwvcABWrDRlVD3m7K6PBqo= =4KlS -----END PGP SIGNATURE----- --Apple-Mail=_303BD5F0-E9BA-455B-9860-3FF4A1756A45-- From nobody Fri Sep 14 13:30:25 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC51128D0C for ; Fri, 14 Sep 2018 13:30: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 TpFI1fH36A-h for ; Fri, 14 Sep 2018 13:30:20 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D811128CF3 for ; Fri, 14 Sep 2018 13:30:20 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id f6-v6so4700596plo.1 for ; Fri, 14 Sep 2018 13:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0Vvr2xzUU04tnUdt+Y53VTAmVjoSCx6YCFnzkDa2YmQ=; b=XsnKXs2NYkegFBTuOfYhb9f14QS7Ln/gmia6XjYUkmW9CfrQwd8aRTHqLuQv2X04PX 4JMXTtoSTB2JjZSRRpvv2bDy/4VRx/NAXXNu+iTHSEriHaCiKegSqBOvkKC50w8PemP5 KzDplT2fKKPQ7/D/PVegNJsYL8aYWTcpVJrfNGT1ILC8dXp3qauWM5uh2xy4pK6ja7cY s4jw7vvYYIUZPFRwUFkbfBJvk1SOAovrtL3wUOQlcOuzNEdT1cwWc4X21uztA89q19om qN++aa3NQxAZKO93Ri3Ex9w5HLsPoP4dVdLeuS9FzZ3ATab3N440olaCbmku6Rz2Tgyc 9iYQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0Vvr2xzUU04tnUdt+Y53VTAmVjoSCx6YCFnzkDa2YmQ=; b=cwUoTdTA0jvrRjLfzTBWhBhWVGgGLYYJ/eRqWJQ077cTWv87HzLyHmPuvfjJrRQpCR 5101Deu2JDZHA0sMW+Kd4kejGtvwyrEUvJCn1PzHE7mfBrIDsg1C+Pofwuo7SVgnsaof vAnvEuiYmZ9cTHFi3RB9uou2xvvRW8HOBsNOIxLcX8R34l0WsxsbDGF0039kZ46kNayP XM2JLMKEySRsreiIAXdLG7ZwkoAbA5L/U+h/qTdP1Hdxq2wtoXhCrlBHMxxYaKF5ADH+ YoBQvHGbrG6GZQHR8P1fhfE5HZi7W3g7G7WvH/n7TaSyxdB2ezw1T4dGLUjb5LveZYnD kgxw== X-Gm-Message-State: APzg51D1zB3vZ+5CnUXLAUzFYZKW5Tkh4L+5OvghsRFWwnAlVkTNbgyA 0IwbvzNXJB8WaA7AomjJSxD1HqOr X-Google-Smtp-Source: ANB0Vdb9Ix+dDtWkZRxEcEqMTrnENcCOEf0JG+HJnBhP8qRmBlWFIs/DxfV+LWbTCcRGl3FbZdGAEg== X-Received: by 2002:a17:902:e088:: with SMTP id cb8-v6mr13772653plb.189.1536957019051; Fri, 14 Sep 2018 13:30:19 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id s27-v6sm13498799pfk.133.2018.09.14.13.30.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 13:30:18 -0700 (PDT) Subject: Re: SLAAC RFC4862 - appropriate length of fe80:: prefix To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Alexandre Petrescu Cc: IPv6 IPv6 List References: <6d9657d0-803c-fcb2-ddb9-13f707bdfd47@gmail.com> From: Brian E Carpenter Message-ID: <0c8dc6f6-43f7-e066-f497-66e9642bab0d@gmail.com> Date: Sat, 15 Sep 2018 08:30:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.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.29 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 Sep 2018 20:30:23 -0000 Incidentally, this matches the terminology of draft-carpenter-6man-lap-01= =2E The Shortest Acceptable Identifier Length (SAIL) is 64 because of SLAAC, and the Longest Acceptable Prefix (LAP) is 10. This is made very clear by the diagram in RFC4291 section 2.5.6. The inequality LAP + SAIL <=3D 128 is satisfied, and the bits in the middle are zero by definition. Regards Brian On 2018-09-15 04:41, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 14 Sep 2018 15:57:04 +0200, > Alexandre Petrescu wrote: >=20 >> In RFC4862 'SLAAC' there is text about an 'appropriate length' of the >> link-local prefix, and further pointing to RFC4291. >> >> What is the 'appropriate length'? >> >> Because otherwise it is hard to implement step 2, because it tells the= >> bits after the ll prefix are set to 0. >> >>> A link-local address is formed by combining the well-known link-lo= cal >>> prefix FE80::0 [RFC4291 ] (o= f > appropriate length) with an interface >>> identifier as follows: >>> >>> 1. The left-most 'prefix length' bits of the address are those o= f >>> the link-local prefix. >>> >>> 2. The bits in the address to the right of the link-local prefix= > are >>> set to all zeroes. >> >> Which are those bits? >=20 > The short answer would be: > - "the link-local prefix" is fe80::/10 > - "the bits" in bullet #2 are the rightmost 118 bits >=20 > Somewhat longer answer, or explanation: >=20 > I guess a background motivation of the question is that RFC4291 > doesn't explicitly define the term "link-local prefix". While I > personally believe the specifications are sufficiently clear for the > vast majority of implementors, it would have been even more super > perfect if the description of RFC4862 referred to Section 2.4 of > RFC4291 and stated "the link-local prefix is the binary prefix shown > in Section 2.4 of RFC4291 that identifies link-local unicast > addresses". >=20 > In practice, if it were not fe80::/10, the only other possibility from > RFC4291 would be fe80::/64 according to this diagram: >=20 > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ >=20 > Again, personally, I wouldn't consider the intermediate 54 bits to be > a part of the "link-local prefix", but since RFC4291 doesn't > explicitly define this term, I can't deny the possibility that someone > with extraordinary imagination could think that the 54 bits are part > of "the prefix". >=20 > Even with this interpretation, however, that doesn't matter much in > practice (at least today), since as of RFC4862 the length of the > interface ID is supposed to be defined in link-type documents, and > (AFAIK) all existing such documents say it's 64 bits. >=20 > So, either way, an implementation can auto-configure a link-local > address, and the result is the same. >=20 > -- > JINMEI, Tatuya >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Fri Sep 14 13:36:30 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA65F12426A for ; Fri, 14 Sep 2018 13:36: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 sszblMI-w-Gy for ; Fri, 14 Sep 2018 13:36:25 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED55130E1F for ; Fri, 14 Sep 2018 13:36:24 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id k19-v6so4823447pfi.1 for ; Fri, 14 Sep 2018 13:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+BBnWTKcDmW5yjfyaWKlrHbzj0auIYZXgQDAL4/0fdY=; b=UWctP/B9DXKwDasTfF5ZUdSFStYNltpeQFtoF9P9Cz1eFCsXVOoNga6FaSdwhxY9XF 9oLH93Idl/i7A41nRJcpSmmdyzu7JXXBEKvRu+JmWQUEzxQsytUwIXiVkc5na4TB9GoY jGK7ccmcXxjmIwy5FYunCf6sgJUxykTmGw2jJY0/KP0/ZQZNhPIasDpuBwqNtldf7JgW C3y0ksA0DR9maw4v246GFLRtgcguOz6miDXCpf5aI5mmNq7iSh7KPc5Jl+S5e0wcSBHR 7+xFmN/Oao/Ve4w4jLGahjxxHB6gMikEGYEEP8e25uoPtJFM2gvyD5dqys/jr3jFsXaO M2AA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+BBnWTKcDmW5yjfyaWKlrHbzj0auIYZXgQDAL4/0fdY=; b=sLVwZCpvZMN2trDZrytOi/l/sLzlFCx31Q6SBXrASYyijVZhNodBSdSc5sd+VP7+uE eWbn1v73Lm20yYbQI0FD30uyjQ4xWqUBMIGiJlwsRTzPgVwPjAYYIVPgUR8+YQDbx0Qe Nm/TxL1lDENnXJawU0lY/ElvJonGUShzTfJJQy7VwbssZWhnW/lus5sSwgYo7/++Qk3K /7aquMW8L/3qJRu+OFMlZPfMcdr5ciwGZ+xZ0TRS/eZSraFUSdYeaVAjUgjlUeHfsWwi Bs50hMI6136KQTaU/JBEpvbU5+8620+B2woepnCLeXcM8Gqd7zNMSOp1hf6uOVCiIAHx b/7w== X-Gm-Message-State: APzg51DxSPWJFJPZnNnyOCKikVKN6KZHvC7/dFYHIJC73lwwFq/YIe5L DDgdF69rY/1rUeIkN98ziLdDHgjq X-Google-Smtp-Source: ANB0VdZFYBs7RbZNnGzKkNCEE8yMVLjEDUt9JQbz9oRgx1jY4OIEwFwBDpXIfe30SB3NJ6x+RORUQw== X-Received: by 2002:a62:8ad1:: with SMTP id o78-v6mr14146420pfk.17.1536957383551; Fri, 14 Sep 2018 13:36:23 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id h85-v6sm12339793pfk.71.2018.09.14.13.36.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 13:36:22 -0700 (PDT) Subject: Re: RFC8064 'stable IIDs' - for LLs To: ipv6@ietf.org References: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> From: Brian E Carpenter Message-ID: <027c5c98-927e-3c2e-df0e-e950b1623d7d@gmail.com> Date: Sat, 15 Sep 2018 08:36:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <31865d67-72bc-1841-e0f2-ef9b15218036@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.29 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 Sep 2018 20:36:28 -0000 On 2018-09-15 02:01, Alexandre Petrescu wrote: > Hi, > > In RFC8064 'stable IIDs' are recommended to be used for SLAAC. > > But does this include the part of SLAAC that generates link-local addresses? > > I am asking because the part of SLAAC that generates link-local > addresses is not clear on the prefix length. As noted on the other thread, RFC4291 is 100% clear on the identifier length, which is what matters for your question. I haven't bothered to check on Linux, but the Windows implementors clearly decided to use the same IID for LL and stable GUAs. Brian > > As such, I am tempted to believe RFC8064 does not apply to link-local > addresses and other methods to achieve the same could be better, e.g. > dynamically changing a MAC address. > > Alex > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Sep 14 14:18:03 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C59128C65; Fri, 14 Sep 2018 14:17: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Brlg0DUbEKuV; Fri, 14 Sep 2018 14:17:53 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30257126CB6; Fri, 14 Sep 2018 14:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1536959870; x=1537564670; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Ao/9NH0pR4kvy8wW8tl+JHgRumr/VCxR7pv21cdLVI8=; b=Dg0iOw1Ha65S6 MmI6ph60WzEqmOf3e3gaVJx0GB7FY1LUjnkm/o/0++rZrJywyPuQIERP3npO60A4 jP/U2+tkvryDaTryyh20sgkLCq9jxgkTZ1W8lVroe3Xd5ZnhIgPWD343/kzTxs1Z qGozmd0tksw5HkDqDChzDnQpOoKth0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 14 Sep 2018 23:17:50 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 14 Sep 2018 23:17:50 +0200 Received: from [172.16.188.4] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005879498.msg; Fri, 14 Sep 2018 23:17:49 +0200 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [172.16.188.4] X-MDArrival-Date: Fri, 14 Sep 2018 23:17:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1795d2080d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Sat, 15 Sep 2018 08:17:32 +1100 Subject: Re: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 security) From: JORDI PALET MARTINEZ To: Ole Troan , Fred Baker CC: V6 Ops List , 6man WG Message-ID: <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> Thread-Topic: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 security) References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 21:17:55 -0000 Hi Ole, I don't think you can compare CGN with NAT64. NAT64 is doing a much better and dynamic (on demand) usage of the port of t= he IPv4 address pool. So, it scales much more than CGN. As a consequence, a= n ISP need much less IPv4 addresses for the same number of customers with N= AT64 than CGN, and you don't have many of the problems that CGN poses becau= se the restrictions in the number of ports. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ipv6 en nombre de Ole Troan Fecha: viernes, 14 de septiembre de 2018, 22:13 Para: Fred Baker CC: V6 Ops List , 6man WG Asunto: NAT64 prefix configuration (was: Re: [v6ops] ipv6only-flag-02 secur= ity) Fred, =20 Did you post this on the wrong thread? I am not sure how this relates t= o the ip6only-flag draft. Changed subject. =20 > Speaking strictly for myself, all one of me. However, I'm copying v6o= ps in case someone operational will dispute my viewpoint or support it. >=20 > I would expect that if an ISP is offering only IPv6 to the CPE, the C= PE might well implement both an IPv6 router and a 464XLAT CLAT for IPv4 wit= hin the LAN. The ISP will never know whether there is actual IPv4 in the ho= me/SOHO/Enterprise, other than that the PLAT it presumably implements will = see traffic. If it's doing CGN, MAP-E, or MAP-T, it is implementing the ove= rlay, will be aware of it, and will be paying for it; the 464XLAT model mea= ns that it doesn't have to think about it (or pay for it) beyond the PLAT a= nd its prefix. I'm hearing rumblings from various operators to the effect t= hat IPv4 is becoming operationally expensive - one that has been in the new= s recently was Aussie Broadband, but they are in no sense the only source o= f such rumblings. =20 Speaking as one of the editors of the MAP series documents, that=E2=80= =99s a misrepresentation. PLAT =3D stateful NAT64 has similar costs and scaling properties as a C= GN. That is, significantly worse than stateless solutions. =20 > From my perspective, 464XLAT plus draft-pref64folks-6man-ra-pref64 is= the best case currently on the table. If 6man agrees, I would suggest usin= g draft-pref64folks-6man-ra-pref64 at PS to deprecate (make historic/NOT RE= COMMENDED) RFCs 6147 and 7050. In that, there would be value in a plugfest,= perhaps at IETF 103 or 104 during the Hackathon, to let various implemento= rs demonstrate draft-ietf-v6ops-transition-ipv4aas using 464XLAT+draft-pref= 64folks-6man-ra-pref64 and state their roll-out plans. =20 I don=E2=80=99t know if 6man has a particular view on provisioining of = a NAT64 prefixes. Nor do I know if we should. =20 If you mentioned the ipv6only-flag draft in the context 464XLAT. 464XLA= T offers a native dual-stack service, and that=E2=80=99s not what the ipv6o= nly-flag draft is about. That=E2=80=99s about true IPv6 only links, where there is no IPv4 packe= ts on the link. =20 Ole -------------------------------------------------------------------- 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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Sep 14 14:48:41 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF4B130E6B for ; Fri, 14 Sep 2018 14:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 mjUH-ViGipUP for ; Fri, 14 Sep 2018 14:48:38 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1024130E6C for ; Fri, 14 Sep 2018 14:48:37 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l202-v6so14117105oig.7 for ; Fri, 14 Sep 2018 14:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLRDDkajktMSYNxNWxQX1+0o3194yPIj39IFfHOOqNs=; b=ed1BsL4icdhpBwJtSOCqXIOXwXw92dEasvJFTTsBs8W+0BgDOqLEKl6fvePfWrIO/M suA/2BeohpV0T0PLRK8+tIvBI4vlDj5ACg1olCXEq9KkLb6iem2dEoyVwHEOcMqaRUhC SRcoeQqUpagzZt3qCnQYDcWkRmHAxzcEaVtLw7AMBE7VROVEjHbVXnpF8xEb1Rpy7zML 5wZD/Qut01WiHv3JTcFIYgvWt6jM8FLwaKLS+8GFDs3Z0wSIC1gJ3DEkfmXhATzrAAfg Y45b+1DLUQanDED+MsckBvcEWf0gGTBoQIMXDEI4MCAifCjOoX0WdpdoqkK4yd6+au2A NQdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLRDDkajktMSYNxNWxQX1+0o3194yPIj39IFfHOOqNs=; b=jYy4tfYEa72ExlOJ0lEcfCwQbMbrnLnZfSJ76gJqUeA/W4kroIl9wAS+qO+okOKkwV icWEZI6NShGNvySPKiLBgDGEDFxxaTjwzj5cygG2sDaMXPdRL0kkGjHaulgbH25DRaoy kXFWR86qAuX+8yIlIcEomHNQE0xwr1UbjlU75TVOcvFhomGRIPQ2TijRpfGLPNyTjSi2 raciluTtrtDn6He9Db5myKrWqmxDh3MxX9Q5dEAMgFONLGAEywUdNyhPaV6SoaJ4n1db u2Ox3s9WhCg9v7pt6bKUkA50YSkXT2BSDhh+xV/fh6ofVoRru3wxogGuLKvA8xEGC/nS a6RA== X-Gm-Message-State: APzg51AMemJGQv+pTk9tZT4uF6V5yS6bEX/yLj0MSLKc3qMZt1phDbNg utxQCOvwJ1AVedRZivk4DLZmA4FmRoFQ9SpTDXw= X-Google-Smtp-Source: ANB0VdYWknlhFITbLBrfAoXkgfNmmkySMnkqDhhMdo+30bP6Yhu4QR+Q99OxD3UU9RLGlq8lVuqx6fmkV4gmyS7tw4c= X-Received: by 2002:aca:b541:: with SMTP id e62-v6mr11408096oif.136.1536961717055; Fri, 14 Sep 2018 14:48:37 -0700 (PDT) MIME-Version: 1.0 References: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> In-Reply-To: <31865d67-72bc-1841-e0f2-ef9b15218036@gmail.com> From: Mark Smith Date: Sat, 15 Sep 2018 07:48:10 +1000 Message-ID: Subject: Re: RFC8064 'stable IIDs' - for LLs To: Alexandre Petrescu Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 21:48:40 -0000 On Sat, 15 Sep 2018 at 00:02, Alexandre Petrescu wrote: > > Hi, > > In RFC8064 'stable IIDs' are recommended to be used for SLAAC. > > But does this include the part of SLAAC that generates link-local addresses? Yes, RFC7217, which it specifies to use, specifically says "The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses)." and here it is called out in the algorithm parameters: "Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message, or the link-local IPv6 unicast prefix [RFC4291]." Regards, Mark. > > I am asking because the part of SLAAC that generates link-local addresses is not clear on the prefix length. > > As such, I am tempted to believe RFC8064 does not apply to link-local addresses and other methods to achieve the same could be better, e.g. dynamically changing a MAC address. > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Sep 14 15:07:40 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ACE130E8D; Fri, 14 Sep 2018 15:07:38 -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, 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 ObKBSomSeQJ0; Fri, 14 Sep 2018 15:07:36 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 B91FE130E43; Fri, 14 Sep 2018 15:07:36 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4CE5E3AB004; Fri, 14 Sep 2018 22:07:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 35F9A160046; Fri, 14 Sep 2018 22:07:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EDF3316005C; Fri, 14 Sep 2018 22:07:35 +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 dDoxAGLWTu6L; Fri, 14 Sep 2018 22:07:35 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AB308160046; Fri, 14 Sep 2018 22:07:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) From: Mark Andrews In-Reply-To: <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> Date: Sat, 15 Sep 2018 08:07:32 +1000 Cc: Ole Troan , Fred Baker , V6 Ops List , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <69A473AC-E52E-48E3-B31C-15C7E17C607F@isc.org> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:07:39 -0000 > On 15 Sep 2018, at 7:17 am, JORDI PALET MARTINEZ = wrote: >=20 > Hi Ole, >=20 > I don't think you can compare CGN with NAT64. >=20 > NAT64 is doing a much better and dynamic (on demand) usage of the port = of the IPv4 address pool. So, it scales much more than CGN. As a = consequence, an ISP need much less IPv4 addresses for the same number of = customers with NAT64 than CGN, and you don't have many of the problems = that CGN poses because the restrictions in the number of ports. >=20 > Regards, > Jordi There is nothing architecturally different between CGN and NAT64 w.r.t. = IPv4 port allocation. NAT64 may have less traffic going though it as we = know there is a IPv6 service. For CGN we don=E2=80=99t know if there is = a IPv6 service to offload traffic or not. IPv6 + NAT64 vs IPv6 + CGN vs CGN Both destination address selection rules and DNS64 (if in use) push = traffic towards IPv6 if there is a choice in transports. Even if you don=E2=80=99t have = native IPv6 you can still move traffic off the CGN using 6rd where the = BR is stateless. IPv6 + NAT64 vs IPv6 + CGN vs CGN vs CGN + 6rd Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 14 16:03:19 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A971292F1; Fri, 14 Sep 2018 16:03: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 YUf-i3rb9t0v; Fri, 14 Sep 2018 16:03:08 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C84F12872C; Fri, 14 Sep 2018 16:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1536966185; x=1537570985; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=/8sDHy544QLsftZd0IoHwUeyLta50hLgTqEcvThgp+w=; b=IIECUI2EdTMw8 KcpZHpKeb1QRRRMlUfNNAFOn1uOOUuy+32ZXPGj/yonI1Yt6JAfetS+fgvwvtcl0 t+U//6anOm+ixW8B3FAQZbi8O9WkbGUSR8D6LkYEsu5xQvWsWfEMHPoVS7bOZPhB Bh5iDQgQqbxGB3szLxQBKAnVqqfOhk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 15 Sep 2018 01:03:05 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 15 Sep 2018 01:03:05 +0200 Received: from [172.16.188.4] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005879564.msg; Sat, 15 Sep 2018 01:03:04 +0200 X-MDRemoteIP: 202.22.157.240 X-MDHelo: [172.16.188.4] X-MDArrival-Date: Sat, 15 Sep 2018 01:03:04 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1795d2080d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.2.180910 Date: Sat, 15 Sep 2018 09:13:33 +1100 Subject: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) From: JORDI PALET MARTINEZ To: Mark Andrews , JORDI PALET MARTINEZ CC: 6man WG , V6 Ops List Message-ID: <86710663-6F7A-4A6E-8F46-C62D46DD0DDB@consulintel.es> Thread-Topic: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> <69A473AC-E52E-48E3-B31C-15C7E17C607F@isc.org> In-Reply-To: <69A473AC-E52E-48E3-B31C-15C7E17C607F@isc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:03:11 -0000 Hi Mark, It may depend on the specific CGN implementation protocol, but in CGN you p= re-allocate a given number of ports per user. Is not relevant if that user actually uses all those ports or needs more. T= hey aren't available for other users and each user has a specific limit on = the number of ports. In NAT64, the ports get allocated on the fly as needed for each user. So I = think it is clear that it is much more efficient. Regars, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mark Andrews Fecha: s=C3=A1bado, 15 de septiembre de 2018, 9:09 Para: JORDI PALET MARTINEZ CC: 6man WG , V6 Ops List Asunto: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 s= ecurity) =20 =20 > On 15 Sep 2018, at 7:17 am, JORDI PALET MARTINEZ wrote: >=20 > Hi Ole, >=20 > I don't think you can compare CGN with NAT64. >=20 > NAT64 is doing a much better and dynamic (on demand) usage of the por= t of the IPv4 address pool. So, it scales much more than CGN. As a conseque= nce, an ISP need much less IPv4 addresses for the same number of customers = with NAT64 than CGN, and you don't have many of the problems that CGN poses= because the restrictions in the number of ports. >=20 > Regards, > Jordi =20 There is nothing architecturally different between CGN and NAT64 w.r.t.= IPv4 port allocation. NAT64 may have less traffic going though it as we k= now there is a IPv6 service. For CGN we don=E2=80=99t know if there is a I= Pv6 service to offload traffic or not. =20 IPv6 + NAT64 vs IPv6 + CGN vs CGN =20 Both destination address selection rules and DNS64 (if in use) push tra= ffic towards IPv6 if there is a choice in transports. Even if you don=E2=80=99t have nat= ive IPv6 you can still move traffic off the CGN using 6rd where the BR is s= tateless. =20 IPv6 + NAT64 vs IPv6 + CGN vs CGN vs CGN + 6rd =20 Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =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 exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Sep 14 16:21:37 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2863130EDF; Fri, 14 Sep 2018 16:21:23 -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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh6lARNiOSOz; Fri, 14 Sep 2018 16:21:21 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E80130E97; Fri, 14 Sep 2018 16:21:21 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 270C13AB001; Fri, 14 Sep 2018 23:21:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D305616005C; Fri, 14 Sep 2018 23:21:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0675160066; Fri, 14 Sep 2018 23:21:19 +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 MQkMdTvqeqSS; Fri, 14 Sep 2018 23:21:19 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id BE20E16005C; Fri, 14 Sep 2018 23:21:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) From: Mark Andrews In-Reply-To: <86710663-6F7A-4A6E-8F46-C62D46DD0DDB@consulintel.es> Date: Sat, 15 Sep 2018 09:21:16 +1000 Cc: JORDI PALET MARTINEZ , 6man WG , V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> <69A473AC-E52E-48E3-B31C-15C7E17C607F@isc.org> <86710663-6F7A-4A6E-8F46-C62D46DD0DDB@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:21:35 -0000 > On 15 Sep 2018, at 8:13 am, JORDI PALET MARTINEZ = wrote: >=20 > Hi Mark, >=20 > It may depend on the specific CGN implementation protocol, but in CGN = you pre-allocate a given number of ports per user. It=E2=80=99s definitely implementation specific. You can do the same = thing with a NAT64 box (IPv6 prefix to IPv4 ). = It=E2=80=99s all about logging trade offs. There is nothing in the two = technologies requiring it or prohibiting it. In many cases those = logging trade offs are driven by legislative requirements to be able to = trace back to specific customers for traffic that is years old. > Is not relevant if that user actually uses all those ports or needs = more. They aren't available for other users and each user has a specific = limit on the number of ports. >=20 > In NAT64, the ports get allocated on the fly as needed for each user. = So I think it is clear that it is much more efficient. >=20 > Regars, > Jordi --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 14 16:49:08 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65F1128D68 for ; Fri, 14 Sep 2018 16:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 YZrgp1cxUTo9 for ; Fri, 14 Sep 2018 16:49:03 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FF112426A for ; Fri, 14 Sep 2018 16:49:03 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id b19-v6so6111186qkc.6 for ; Fri, 14 Sep 2018 16:49:03 -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; bh=VgrNAwqJS6nPFGjxB3k6Dtmdl8eNjl71V44cKIqXqOw=; b=stR1KYn9x5TcYYQxejiepY+6CxOupxhctfaSnxe39TTIhVUK+46OCub8a5tB0k7RXY Zi/3ClBjrtht3smVak0n9EbO511WICMawxXs9TZmhkWFGl/lhXyPH+Vh09MBpgjIpHWv Eu1nbEXdkPmlFPSIN39Us/Yn6zt89CJMFkAR7/bR3WNeS0wzBinjG/NwoP+pIpSN+Pzg o8D82f58jISoxEVybib9VxbW29AJ74/kq8E5XDLyTLk0cYe2SxOSn5kQKMZbai6FTTaT e+wUbXCH0zDBrApSuoXG8spjoZP0aiX5xax8UTI2wyzk0qGSIB+95Az/B6zKYae10vZH KnYw== 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=VgrNAwqJS6nPFGjxB3k6Dtmdl8eNjl71V44cKIqXqOw=; b=jfZOLuJ6nwou18PMSO2QgBpSiePDYkLVQX9PHGY9b0Sp53eoGi+TJdndOQxeStbEgO Pw3uJwWJOF/swxQEdFiuuUO6kziBZO81iL7ADcdIjaSehuutwsVQ5Q9671/VEzQ/0IP7 fwCVKmn+6TW3OI+tPDDIhV/x95cmi+oY6bwpC1q0wpei1K+Tx0LM0O0U1uZ6pVl543+4 Gs6QHtkpWQbhgoSefwy1kiEYhEwwBmRk2v3SGUj/P9wSiBPbJj6Wf7lVLYr/btSO6j/V 5c9w/wit5m/QlA4Fd0XSZ4jJybXTovSe8TcSwbta1pgwVcH6K0TWIfxb/74aNyeir7RH WNIw== X-Gm-Message-State: APzg51DB7NOCEd9uvC3Z0XrnvGTY6R5l6jPRmzQfLFF92exu8MSpAxi8 ppjR8sz03FsvStKDE6bQ4/2x8TidAJLVauB8IDe6MPZl X-Google-Smtp-Source: ANB0Vdb0M2LxbqJqKhuQ0dCJ2q1r0RqLHIXOQLgr4FiIwypqPNyIynaeazQMQ6vOB5uElFC6e0keXKOYteaALvMCS0s= X-Received: by 2002:a37:5a06:: with SMTP id o6-v6mr10453932qkb.44.1536968942516; Fri, 14 Sep 2018 16:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 16:49:02 -0700 (PDT) In-Reply-To: References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Fri, 14 Sep 2018 16:49:02 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-opts-00.txt To: 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 23:49:06 -0000 Hello, I submitted a new version of draft to update option requirements. Since this now includes updates to requirements that cover both DestOpts and HBH options, I renamed the draft. Other changes include feedback from the list. I also added a section on detecting that Destination Options precede a Routing header which is needed if they are to be processed differently. Tom ---------- Forwarded message ---------- From: Date: Fri, Sep 14, 2018 at 4:43 PM Subject: New Version Notification for draft-herbert-ipv6-update-opts-00.txt To: Tom Herbert A new version of I-D, draft-herbert-ipv6-update-opts-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-ipv6-update-opts Revision: 00 Title: Updates to Requirements for IPv6 Options Document date: 2018-09-14 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-update-opts/ Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-opts-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts Abstract: This document updates requirements for IPv6 Destination and Hop-by- Hop Options. The requirements that option type and option length cannot change en route, as well as the requirements that options cannot be added or removed, are made explicit. The meaning and requirements of a Destination Option marked as changeable are clarified. Finally, the requirement that all destinations listed in a Routing header must process options in a Destination Options header preceding the Routing header is relaxed. 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 Fri Sep 14 18:08:18 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAB8126F72 for ; Fri, 14 Sep 2018 18:08: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, 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 eSoT_M__0ghl for ; Fri, 14 Sep 2018 18:08:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 36A9312008A for ; Fri, 14 Sep 2018 18:08:15 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BA37FE5A8EE6F for ; Sat, 15 Sep 2018 02:08:11 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 02:08:13 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Sat, 15 Sep 2018 09:08:01 +0800 From: Xiejingrong To: Tom Herbert , 6man Subject: RE: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Topic: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Index: AQHUTIWjzTO1UMf1YU+FkULBRRqNoaTwhbeg Date: Sat, 15 Sep 2018 01:08:02 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 01:08:17 -0000 Hi Tom, I have read the fresh draft just now. I agree with you some of the good catch, "Intermediate destination nodes ma= y be closer in taxonomy to switches and routers than end hosts". But I did not agree with this point, "Allowing nodes to ignore options reta= ins the primary value and usability of Destination Options preceding a Rout= ing header." Quite the contrary, I do think the "Destination Options preceding a Routing= header" should not happen absolutely." Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr can'= t be removed, but the RH can be popped by an router. How will that happen ? Thanks, Jingrong -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Saturday, September 15, 2018 7:49 AM To: 6man Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-opts-0= 0.txt Hello, I submitted a new version of draft to update option requirements. Since this now includes updates to requirements that cover both DestOpts an= d HBH options, I renamed the draft. Other changes include feedback from the= list. I also added a section on detecting that Destination Options precede= a Routing header which is needed if they are to be processed differently. Tom ---------- Forwarded message ---------- From: Date: Fri, Sep 14, 2018 at 4:43 PM Subject: New Version Notification for draft-herbert-ipv6-update-opts-00.txt To: Tom Herbert A new version of I-D, draft-herbert-ipv6-update-opts-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repos= itory. Name: draft-herbert-ipv6-update-opts Revision: 00 Title: Updates to Requirements for IPv6 Options Document date: 2018-09-14 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-update-= opts/ Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-opts-= 00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts Abstract: This document updates requirements for IPv6 Destination and Hop-by- Hop Options. The requirements that option type and option length cannot change en route, as well as the requirements that options cannot be added or removed, are made explicit. The meaning and requirements of a Destination Option marked as changeable are clarified. Finally, the requirement that all destinations listed in a Routing header must process options in a Destination Options header preceding the Routing header is relaxed. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Sep 14 18:12:28 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11263130E28 for ; Fri, 14 Sep 2018 18:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 Uxmx2S4FY7Ve for ; Fri, 14 Sep 2018 18:12:21 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA110130E78 for ; Fri, 14 Sep 2018 18:12:20 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id 130-v6so6178236qkd.10 for ; Fri, 14 Sep 2018 18:12:20 -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=oaOfBGVxZxlP26+RrkMTV6qJg1RUXliPLdA/TXCk21o=; b=Z7CWLRA6JEBhscDPs/42rAQVEpv007Xz1xOIxBA8X04aVd/bfrphO8oa6FACPKKfHs R89ZcbBypr6o6nMnMhX7ZioTIsCVVw7pZQgcKPhNubKBxnmjGT1kYlUWXCylXWszHExu kSil0If0dvoSuq9yGFJWT/RVN36jLsC7mtuqCY9Mrb+z/+4RiXAfUj7ZKUqbz9MiCGXw 7igyoWRvBcKF76cJaTSk28XhzzdBKbRSkcCuouVNc0HVvBWAcOqb4seYSzOJcvdeMFsh 9Oa3Tf3M0xS0/HZg5RzC6CrZa0ZV5yhSllzYir6oQ8K+Ylk/AGqJL3fobqG43+3eCT0W nztw== 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=oaOfBGVxZxlP26+RrkMTV6qJg1RUXliPLdA/TXCk21o=; b=RZMNw0Mvz7rXZgyAZqWGZtO0jHqBQtKTLQw1g12hgyaG8iAmu5x75wytrL9Eh0z07T yvbuFEXxRLvNd3zCQ7CeSdujItmbr6lSbgIkcKVJuDrW9BxwhYysczhTIB3vbwe7Bss9 Ny+5xR5BVezcbXg6Dtm5W2ZM3NN4muoE5QRywWaIttHJQjEV5fBsk+UqvHcC4CpTlJHx /PqatWcRkZIV9sWLEPMuJZ1iquFOl0WwO+lN6SFaoF0kN+CBOjup4xivPERoPsMhImG8 Om6FTTbS/Tozw2mIbNn7lBWh4/veXFnkuFIyMvdcKCx2XtDzrItu9HJl+2Lj8WgIX3R+ ZXbA== X-Gm-Message-State: APzg51At+0xJOUhGjwekEWNFu6JnxN8bBY9tKUCxd2frfdnDYAYnc4Xo RFzflx+6PIgVi843g0srcrxvNlUfecxBwmt2XWMXusaXvOs= X-Google-Smtp-Source: ANB0VdYR8FfrRuVYjfjux+VPiFlvz1+6ObObKvpfN7+ZzSGMQqQBIOCaye+OXxU+lfnM4f+yWjCux9F3VxyV8w2Cc74= X-Received: by 2002:a37:168e:: with SMTP id 14-v6mr10438242qkw.168.1536973939816; Fri, 14 Sep 2018 18:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 18:12:19 -0700 (PDT) In-Reply-To: <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> From: Tom Herbert Date: Fri, 14 Sep 2018 18:12:19 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt To: Xiejingrong Cc: 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.29 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 Sep 2018 01:12:23 -0000 On Fri, Sep 14, 2018 at 6:08 PM, Xiejingrong wrote= : > Hi Tom, > > I have read the fresh draft just now. > I agree with you some of the good catch, "Intermediate destination nodes = may be closer in taxonomy to switches and routers than end hosts". > But I did not agree with this point, "Allowing nodes to ignore options re= tains the primary value and usability of Destination Options preceding a Ro= uting header." > Quite the contrary, I do think the "Destination Options preceding a Routi= ng header" should not happen absolutely." > Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr ca= n't be removed, but the RH can be popped by an router. How will that happen= ? Xiejingrong, The routing header can't be removed either. Per RFC8200: "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." Tom > > Thanks, > Jingrong > > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Saturday, September 15, 2018 7:49 AM > To: 6man > Subject: Fwd: New Version Notification for draft-herbert-ipv6-update-opts= -00.txt > > Hello, > > I submitted a new version of draft to update option requirements. > Since this now includes updates to requirements that cover both DestOpts = and HBH options, I renamed the draft. Other changes include feedback from t= he list. I also added a section on detecting that Destination Options prece= de a Routing header which is needed if they are to be processed differently= . > > Tom > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Sep 14, 2018 at 4:43 PM > Subject: New Version Notification for draft-herbert-ipv6-update-opts-00.t= xt > To: Tom Herbert > > > > A new version of I-D, draft-herbert-ipv6-update-opts-00.txt > has been successfully submitted by Tom Herbert and posted to the IETF rep= ository. > > Name: draft-herbert-ipv6-update-opts > Revision: 00 > Title: Updates to Requirements for IPv6 Options > Document date: 2018-09-14 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.tx= t > Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-updat= e-opts/ > Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-opt= s-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts > > > Abstract: > This document updates requirements for IPv6 Destination and Hop-by- > Hop Options. The requirements that option type and option length > cannot change en route, as well as the requirements that options > cannot be added or removed, are made explicit. The meaning and > requirements of a Destination Option marked as changeable are > clarified. Finally, the requirement that all destinations listed in a > Routing header must process options in a Destination Options header > preceding the Routing header is relaxed. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Sep 14 18:52:36 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E256B130E6D for ; Fri, 14 Sep 2018 18:52:34 -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 wl2tuAym6NF9 for ; Fri, 14 Sep 2018 18:52:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E0A18130DF1 for ; Fri, 14 Sep 2018 18:52:32 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DAF95B4DD4025 for ; Sat, 15 Sep 2018 02:52:29 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 02:52:30 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Sat, 15 Sep 2018 09:52:21 +0800 From: Xiejingrong To: Tom Herbert CC: 6man Subject: RE: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Topic: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Index: AQHUTIWjzTO1UMf1YU+FkULBRRqNoaTwhbeg//99bYCAAIwdgA== Date: Sat, 15 Sep 2018 01:52:20 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AEA865@nkgeml514-mbs.china.huawei.com> References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] 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.29 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 Sep 2018 01:52:35 -0000 SGkgVG9tLA0KDQpTdXBwb3NlIGEgbmV0d29yayB3aXRoIHRoZXNlIHJvdXRlciBub2RlczogQ0Ux LS1QRTEtLVAxLVAyLVAzLVBFMi0tQ0UyLg0KUEUxIGltcG9zZSBhbiBvdXRlciBJUHY2IEhlYWRl ciBvbiB0aGUgY3VzdG9tZXIgSVAgcGFja2V0LCB3aXRoIGEgRGVzdE9wdEhkciBwcmVjZWRpbmcg YSBSb3V0aW5nSGRyLCB3aXRoIHRoZSBmaW5hbCBEZXN0IFBFMiwgYW5kIHRoZSBpbnRlcm1lZGlh dGUgZGVzdCBQMi4NClAyIHdpbGwgaGF2ZSB0byBrZWVwIHRoZSBEZXN0T3B0SGRyIGJlY2F1c2Ug dGhlIERlc3RPcHRIZHIgaXMgcHJlY2VkaW5nIGEgUm91dGluZ0hkci4NClBFMiB3aWxsIGFsc28g a2VlcCB0aGUgRGVzdE9wdEhkciBmaXJzdCBiZWNhdXNlIHRoZSBEZXN0T3B0SGRyIGlzIHByZWNl ZGluZyBhIFJvdXRoaW5nSGRyLCBhbmQgUEUyIGNhbid0IGp1ZGdlIGlmIGl0IGlzIHRoZSBmaW5h bCBkZXN0IHVudGlsIGl0IGNoZWNrIHRoZSBmb2xsb3dpbmcgUkggaW4gYSBkZXRhaWxlZCB3YXks IGFuZCBJIHN1cHBvc2UgaXQgd2lsbCBub3QgZG8uDQpUaGVuIFBFMiBnb3RvIHRoZSBSSCwgYW5k IHBvcCB0aGUgUkggYWNjb3JkaW5nIHRvIHRoZSBoYW5kbGluZyBvZiBSSCBpdHNlbGYuDQpXaGF0 IGlzIHRoZSB0aW1lIHRvIHJlbW92ZSB0aGUgRGVzdE9wdEhkciB0aGF0IFBFMSBpbXBvc2VkID8g DQpPbmUgbWF5IHRoaW5rIHRoYXQsIGFmdGVyIHdoZW4gUkggaXMgcmVtb3ZlZCB0aGVuIHRoZSBE ZXN0T3B0SGRyIHNob3VsZCBhbHNvIHJlbW92ZWQsIGJ1dCB0aGF0IHdpbGwgYnJpbmcgdGhlIGhh bmRsaW5nIG9mIERlc3RPcHRIZHIgdG8gdGhlIGhhbmRsaW5nIG9mIFJILg0KDQpKaW5ncm9uZw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0 b21AaGVyYmVydGxhbmQuY29tXSANClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTgg OToxMiBBTQ0KVG86IFhpZWppbmdyb25nIDx4aWVqaW5ncm9uZ0BodWF3ZWkuY29tPg0KQ2M6IDZt YW4gPGlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1oZXJiZXJ0LWlwdjYtdXBkYXRlLW9wdHMtMDAudHh0DQoNCk9uIEZyaSwgU2Vw IDE0LCAyMDE4IGF0IDY6MDggUE0sIFhpZWppbmdyb25nIDx4aWVqaW5ncm9uZ0BodWF3ZWkuY29t PiB3cm90ZToNCj4gSGkgVG9tLA0KPg0KPiBJIGhhdmUgcmVhZCB0aGUgZnJlc2ggZHJhZnQganVz dCBub3cuDQo+IEkgYWdyZWUgd2l0aCB5b3Ugc29tZSBvZiB0aGUgZ29vZCBjYXRjaCwgIkludGVy bWVkaWF0ZSBkZXN0aW5hdGlvbiBub2RlcyBtYXkgYmUgY2xvc2VyIGluIHRheG9ub215IHRvIHN3 aXRjaGVzIGFuZCByb3V0ZXJzIHRoYW4gZW5kIGhvc3RzIi4NCj4gQnV0IEkgZGlkIG5vdCBhZ3Jl ZSB3aXRoIHRoaXMgcG9pbnQsICJBbGxvd2luZyBub2RlcyB0byBpZ25vcmUgb3B0aW9ucyByZXRh aW5zIHRoZSBwcmltYXJ5IHZhbHVlIGFuZCB1c2FiaWxpdHkgb2YgRGVzdGluYXRpb24gT3B0aW9u cyBwcmVjZWRpbmcgYSBSb3V0aW5nIGhlYWRlci4iDQo+IFF1aXRlIHRoZSBjb250cmFyeSwgSSBk byB0aGluayB0aGUgIkRlc3RpbmF0aW9uIE9wdGlvbnMgcHJlY2VkaW5nIGEgUm91dGluZyBoZWFk ZXIiIHNob3VsZCBub3QgaGFwcGVuIGFic29sdXRlbHkuIg0KPiBCZWNhdXNlLCBvbmNlIHlvdSBw dXQgYSBEZXN0T3B0SGRyIHByZWNlZGluZyBhIFJILCB0aGVuIHRoZSBEZXN0T3B0SGRyIGNhbid0 IGJlIHJlbW92ZWQsIGJ1dCB0aGUgUkggY2FuIGJlIHBvcHBlZCBieSBhbiByb3V0ZXIuIEhvdyB3 aWxsIHRoYXQgaGFwcGVuID8NCg0KWGllamluZ3JvbmcsDQoNClRoZSByb3V0aW5nIGhlYWRlciBj YW4ndCBiZSByZW1vdmVkIGVpdGhlci4gUGVyIFJGQzgyMDA6DQoNCiJFeHRlbnNpb24gaGVhZGVy cyAoZXhjZXB0IGZvciB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlcikgYXJlIG5vdCBwcm9j ZXNzZWQsIGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3Mg ZGVsaXZlcnkgcGF0aCwgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNo IG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmll ZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIuIg0K DQpUb20NCg0KDQo+DQo+IFRoYW5rcywNCj4gSmluZ3JvbmcNCj4NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRvbSBIZXJiZXJ0DQo+IFNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIg MTUsIDIwMTggNzo0OSBBTQ0KPiBUbzogNm1hbiA8aXB2NkBpZXRmLm9yZz4NCj4gU3ViamVjdDog RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1oZXJiZXJ0LWlwdjYt dXBkYXRlLW9wdHMtMDAudHh0DQo+DQo+IEhlbGxvLA0KPg0KPiBJIHN1Ym1pdHRlZCBhIG5ldyB2 ZXJzaW9uIG9mIGRyYWZ0IHRvIHVwZGF0ZSBvcHRpb24gcmVxdWlyZW1lbnRzLg0KPiBTaW5jZSB0 aGlzIG5vdyBpbmNsdWRlcyB1cGRhdGVzIHRvIHJlcXVpcmVtZW50cyB0aGF0IGNvdmVyIGJvdGgg RGVzdE9wdHMgYW5kIEhCSCBvcHRpb25zLCBJIHJlbmFtZWQgdGhlIGRyYWZ0LiBPdGhlciBjaGFu Z2VzIGluY2x1ZGUgZmVlZGJhY2sgZnJvbSB0aGUgbGlzdC4gSSBhbHNvIGFkZGVkIGEgc2VjdGlv biBvbiBkZXRlY3RpbmcgdGhhdCBEZXN0aW5hdGlvbiBPcHRpb25zIHByZWNlZGUgYSBSb3V0aW5n IGhlYWRlciB3aGljaCBpcyBuZWVkZWQgaWYgdGhleSBhcmUgdG8gYmUgcHJvY2Vzc2VkIGRpZmZl cmVudGx5Lg0KPg0KPiBUb20NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tDQo+IEZyb206ICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBEYXRl OiBGcmksIFNlcCAxNCwgMjAxOCBhdCA0OjQzIFBNDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWhlcmJlcnQtaXB2Ni11cGRhdGUtb3B0cy0wMC50eHQN Cj4gVG86IFRvbSBIZXJiZXJ0IDx0b21AcXVhbnRvbml1bS5uZXQ+DQo+DQo+DQo+DQo+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oZXJiZXJ0LWlwdjYtdXBkYXRlLW9wdHMtMDAudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9tIEhlcmJlcnQgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBOYW1lOiAgICAgICAgICAgZHJhZnQtaGVy YmVydC1pcHY2LXVwZGF0ZS1vcHRzDQo+IFJldmlzaW9uOiAgICAgICAwMA0KPiBUaXRsZTogICAg ICAgICAgVXBkYXRlcyB0byBSZXF1aXJlbWVudHMgZm9yIElQdjYgT3B0aW9ucw0KPiBEb2N1bWVu dCBkYXRlOiAgMjAxOC0wOS0xNA0KPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+IFBhZ2VzOiAgICAgICAgICA2DQo+IFVSTDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhlcmJlcnQtaXB2Ni11cGRhdGUtb3B0cy0wMC50eHQNCj4g U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhl cmJlcnQtaXB2Ni11cGRhdGUtb3B0cy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1oZXJiZXJ0LWlwdjYtdXBkYXRlLW9wdHMtMDANCj4gSHRtbGl6 ZWQ6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVyYmVy dC1pcHY2LXVwZGF0ZS1vcHRzDQo+DQo+DQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50 IHVwZGF0ZXMgcmVxdWlyZW1lbnRzIGZvciBJUHY2IERlc3RpbmF0aW9uIGFuZCBIb3AtYnktDQo+ ICAgIEhvcCBPcHRpb25zLiBUaGUgcmVxdWlyZW1lbnRzIHRoYXQgb3B0aW9uIHR5cGUgYW5kIG9w dGlvbiBsZW5ndGgNCj4gICAgY2Fubm90IGNoYW5nZSBlbiByb3V0ZSwgYXMgd2VsbCBhcyB0aGUg cmVxdWlyZW1lbnRzIHRoYXQgb3B0aW9ucw0KPiAgICBjYW5ub3QgYmUgYWRkZWQgb3IgcmVtb3Zl ZCwgYXJlIG1hZGUgZXhwbGljaXQuIFRoZSBtZWFuaW5nIGFuZA0KPiAgICByZXF1aXJlbWVudHMg b2YgYSBEZXN0aW5hdGlvbiBPcHRpb24gbWFya2VkIGFzIGNoYW5nZWFibGUgYXJlDQo+ICAgIGNs YXJpZmllZC4gRmluYWxseSwgdGhlIHJlcXVpcmVtZW50IHRoYXQgYWxsIGRlc3RpbmF0aW9ucyBs aXN0ZWQgaW4gYQ0KPiAgICBSb3V0aW5nIGhlYWRlciBtdXN0IHByb2Nlc3Mgb3B0aW9ucyBpbiBh IERlc3RpbmF0aW9uIE9wdGlvbnMgaGVhZGVyDQo+ICAgIHByZWNlZGluZyB0aGUgUm91dGluZyBo ZWFkZXIgaXMgcmVsYXhlZC4NCj4NCj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBB ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Fri Sep 14 19:57:47 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB5130DE8 for ; Fri, 14 Sep 2018 19:57:44 -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 agxmdU1ElKZP for ; Fri, 14 Sep 2018 19:57:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 91105130DE5 for ; Fri, 14 Sep 2018 19:57:41 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 732B370C72FB0 for ; Sat, 15 Sep 2018 03:57:37 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 03:57:38 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Sat, 15 Sep 2018 10:57:28 +0800 From: Xiejingrong To: Tom Herbert CC: Fred Baker , IPv6 IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: RE: Modifiable Destination Options Thread-Topic: Modifiable Destination Options Thread-Index: AQHUDyzCtyJF2GU1mEayThLTBJ+Fi6R27zOAgABPLoCAbu1NQIAJzw4AgAEiZ9A= Date: Sat, 15 Sep 2018 02:57:27 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.com> References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] 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.29 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 Sep 2018 02:57:44 -0000 SGkgVG9tLA0KDQpJIGd1ZXNzIHRoZSBIQkggaGFkIGJlZW4gZGVwcmVjYXRlZCBhZnRlciB0aGUg UkZDODIwMCByZXF1aXJlZCB0aGUgZGVmYXVsdCBiZWhhdmlvciB0byBkaXNjYXJkIHRoZSBIQkgu IFBlciB0aGUgUkZDODIwMDoNCg0KICAgTk9URTogV2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRo YXQgYWxsIG5vZGVzIG11c3QgZXhhbWluZSBhbmQNCiAgIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3Ag T3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBleHBlY3RlZCB0aGF0IG5vZGVzDQogICBhbG9uZyBh IHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGggb25seSBleGFtaW5lIGFuZCBwcm9jZXNzIHRoZQ0KICAg SG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciBpZiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8g c28uDQoNCkFnYWluLCB0aGUgQklFUiBpcyBub3QgYSBob3AtYnktaG9wIGJlaGF2aW9yLCBiZWNh dXNlIGl0IG11c3Qgc3VwcG9ydCB0byBydW4gb3ZlciBzb21lIGZvcm0gb2YgdHVubmVscyBsaWtl IFNSSC4NCg0KQWxzbyBmcm9tIHRoZSBzZWN1cml0eSBzaWRlLCBmcm9tIHRoZSBmbGV4aWJpbGl0 eSBzaWRlLCBhbnkgSVB2NiBPcHRpb25zIGlzIGRlZmluZWQgaW4gc29tZSBwcmVjZWRpbmcgJ0Nv bnRleHQnIGlzIG11Y2ggYmV0dGVyIGluIG15IG9waW5pb24uIA0KDQpGb3IgQklFUiwgc3VjaCBh ICdDb250ZXh0JyBpcyB0aGUgTXVsdGljYXN0IERBIHdoaWNoIGRlZmluZWQgYnkgc29tZSBjb250 cm9sLXBsYW5lIG9yIG1hbmFnZS1wbGFuZSB0byBpbmRpY2F0aW5nIHRvIGNoZWNrIFdoYXQgRUgg KERlc3RPcHRIZHIpIGFuZCB3aGF0IFRMVnMgaW4gdGhlIEVIKHRoZS1vbmx5LUJJRVItVExWKS4N Cg0KRm9yIFNSSCwgc3VjaCBhICdDb250ZXh0JyBpcyB0aGUgVW5pY2FzdCBEQSB3aGljaCBkZWZp bmVkIGJ5IHNvbWUgY29udHJvbC1wbGFuZSBvciBtYW5hZ2UtcGxhbmUgdG8gaW5kaWNhdGluZyB0 byBjaGVjayB3aGF0IFRMViB0byBzdXBwb3J0IGFuZCBob3cgdG8gZGVhbCB3aXRoIHN1Y2ggVExW Lg0KDQpBbGwgc3VjaCAnQ29udGV4dCcgaXMgYSBsb2NhbCBiZWhhdmlvciwganVzdCBsaWtlIGhv dyB0aGUgUkZDODIwMCBjaGFuZ2VkIGZvciB0aGUgaGFuZGxpbmcgb2YgSEJIOiAiaWYgZXhwbGlj aXRseSBjb25maWd1cmVkIHRvIGRvIHNvIi4NCg0KSmluZ3JvbmcNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQu Y29tXSANClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTggMToyMyBBTQ0KVG86IFhp ZWppbmdyb25nIDx4aWVqaW5ncm9uZ0BodWF3ZWkuY29tPg0KQ2M6IEZyZWQgQmFrZXIgPGZyZWRi YWtlci5pZXRmQGdtYWlsLmNvbT47IElQdjYgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsg56We 5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4NClN1YmplY3Q6IFJlOiBNb2RpZmlhYmxlIERl c3RpbmF0aW9uIE9wdGlvbnMNCg0KT24gRnJpLCBTZXAgNywgMjAxOCBhdCAxMTo1NCBQTSwgWGll amluZ3JvbmcgPHhpZWppbmdyb25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+ IEkgdGhpbmsgdGhlIERlc3RpbmF0aW9uIE9wdGlvbnMgaXMgZGlmZmVyZW50IGZyb20gSEJILCB0 aG91Z2ggdGhleSBzaGFyZSAiVGhlIHNhbWUgT3B0aW9uIFR5cGUgbnVtYmVyaW5nIHNwYWNlIiwg YW5kIGhhdmUgdGhlIHNhbWUgIk1vZGlmaWFibGUgb3Igbm90IiBiaXQuDQo+DQo+IFRoZSBkcmFm dCA8ZHJhZnQteGllLTZtYW4tYmllci1lbmNhcHN1bGF0aW9uPiBtZWFucyB0byB1c2Ugc3VjaCBh ICJNb2RpZmlhYmxlIERlc3RpbmF0aW9uIE9wdGlvbnMiIHdpdGggYSBNdWx0aWNhc3QgQWRkcmVz cyBpbiB0aGUgSVB2NiBEQS4NCj4NCj4gTXkgdW5kZXJzdGFuZGluZyBhYm91dCB0aGUgImNoYW5n ZSBlbiByb3V0ZSB0byB0aGUgcGFja2V0J3MgZmluYWwgDQo+IGRlc3RpbmF0aW9uIiBpcyB0aGF0 LA0KPg0KPiAoMSkgRm9yIGEgTXVsdGljYXN0IEFkZHJlc3MgaW4gSVB2NiBEQSwgdGhlICJmaW5h bCBkZXN0aW5hdGlvbiIgaXMgdGhlIElQdjYgbm9kZShzKSB3aG8gZG9uJ3QgZm9yd2FyZCB0aGUg cGFja2V0IGFueW1vcmUuIEFuZCB0aHVzIHRoZSAiTW9kaWZpYWJsZSBEZXN0aW5hdGlvbiBPcHRp b25zIiBpcyByZXF1aXJlZC4NCj4NCj4gKDIpIElmIGlzIGFsc28gc3VpdGFibGUgZm9yIGNhc2Vz IHdoZW4gVW5pY2FzdCBBZGRyZXNzIGluIElQdjYgREEgYW5kIERlc3RpbmF0aW9uIE9wdGlvbnMg aXMgYWhlYWQgb2YgUm91dGluZyBoZWFkZXIuDQo+DQoNCkhpIFhpZWppbmdncm9uZywNCg0KSSBk b24ndCB0aGluayBpdCBzaG91bGQgbWF0dGVyIHdoZXRoZXIgdGhlIGZpbmFsIGRlc3RpbmF0aW9u IGlzIG11bHRpY2FzdCBvciB1bmljYXN0LiBUaGUgZmluYWwgZGVzdGluYXRpb24gaXMgYXQgdGhl IG5vZGUgdGhhdCBpcyBhZGRyZXNzZWQgaW4gdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MuIEluIHRo ZSBjYXNlIG9mIG11bHRpY2FzdCwgaXQncyBzaW1wbHkgdGhlIGVuZCBub2RlcyB0aGF0IHJlY2Vp dmUgdGhlIHBhY2tldHMgYXMgYWRkcmVzc2VkIGJ5IHRoZSBtdWx0aWNhc3QgYWRkcmVzcy4NCg0K SXQgaXMgdW5jbGVhciB0byBtZSBpZiBhIERlc3RpbmF0aW9uIE9wdGlvbiBpcyBhcHByb3ByaWF0 ZSBmb3IgQklFUi4NCkl0IHNlZW1zIGxpa2UgdGhlIHRhcmdldCBvZiB0aGUgaW5mb3JtYXRpb24g aXMgaW50ZXJtZWRpYXRlIHJvdXRlcnMgaW4gdGhlIHBhdGggdGhhdCBhcmUgbm90IGV4cGxpY2l0 bHkgYWRkcmVzc2VkIGJ5IHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIChpLmUuIHRoZXJlJ3Mgbm8g cm91dGluZyBoZWFkZXIgcHJlc2VudCB0aGF0IHdyaXRlcyBkZXN0aW5hdGlvbiBhZGRyZXNzZXMg ZW4gcm91dGUpLiBTaG91bGQgdGhpcyBiZSBhIEhvcC1ieS1Ib3Agb3B0aW9uIGluc3RlYWQ/DQoN ClRvbQ0KDQo+IFRvIHF1b3RlIHR3byBwYXJhZ3JhcGhzIG9mIFJGQzgyMDA6DQo+ICAgICAgIG5v dGUgMTogZm9yIG9wdGlvbnMgdG8gYmUgcHJvY2Vzc2VkIGJ5IHRoZSBmaXJzdCBkZXN0aW5hdGlv biB0aGF0DQo+ICAgICAgICAgICAgICAgYXBwZWFycyBpbiB0aGUgSVB2NiBEZXN0aW5hdGlvbiBB ZGRyZXNzIGZpZWxkIHBsdXMNCj4gICAgICAgICAgICAgICBzdWJzZXF1ZW50IGRlc3RpbmF0aW9u cyBsaXN0ZWQgaW4gdGhlIFJvdXRpbmcgaGVhZGVyLg0KPg0KPiAgICBUaGUgdGhpcmQtaGlnaGVz dC1vcmRlciBiaXQgb2YgdGhlIE9wdGlvbiBUeXBlIHNwZWNpZmllcyB3aGV0aGVyIG9yDQo+ICAg IG5vdCB0aGUgT3B0aW9uIERhdGEgb2YgdGhhdCBvcHRpb24gY2FuIGNoYW5nZSBlbiByb3V0ZSB0 byB0aGUNCj4gICAgcGFja2V0J3MgZmluYWwgZGVzdGluYXRpb24uDQo+DQo+IFRoYW5rcw0KPiBK aW5ncm9uZw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFtt YWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJlZCBCYWtlcg0KPiBT ZW50OiBTYXR1cmRheSwgSnVuZSAzMCwgMjAxOCA1OjM4IEFNDQo+IFRvOiBUb20gSGVyYmVydCA8 dG9tQGhlcmJlcnRsYW5kLmNvbT4NCj4gQ2M6IElQdjYgSVB2NiBMaXN0IDxpcHY2QGlldGYub3Jn Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4NCj4gU3ViamVjdDogUmU6IE1vZGlm aWFibGUgRGVzdGluYXRpb24gT3B0aW9ucw0KPg0KPg0KPg0KPj4gT24gSnVuIDI5LCAyMDE4LCBh dCA5OjU0IEFNLCDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPiB3cm90ZToNCj4+DQo+ PiBBdCBUaHUsIDI4IEp1biAyMDE4IDE1OjA5OjA1IC0wNzAwLA0KPj4gVG9tIEhlcmJlcnQgPHRv bUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KPj4NCj4+PiBJIGRvbid0IHNlZSB0aGF0IHRoYXQg c2V0dGluZyB0aGlzIGJpdCBmb3IgYSBEZXN0aW5hdGlvbiBPcHRpb24gaXMgDQo+Pj4gcHJvaGli aXRlZC4gU28gd2hhdCBpcyB0aGUgZWZmZWN0IG9mIHNldHRpbmcgYSBEZXN0aW5hdGlvbiBPcHRp b24gDQo+Pj4gdHlwZSB0byBiZSBtb2RpZmlhYmxlIGVuIHJvdXRlPw0KPg0KPiBJIHRob3VnaHQg dGhlIHBvaW50IG9mIGEgZGVzdGluYXRpb24gb3B0aW9uIHdhcyB0aGF0IGl0IHdhcyBvbmx5IGV2 YWx1YXRlZCBieSB0aGUgc3lzdGVtIGlkZW50aWZpZWQgYnkgdGhlIGRlc3RpbmF0aW9uIGFkZHJl c3M/IElmIGl0J3MgYmVpbmcgbW9kaWZpZWQgaW4gZmxpZ2h0LCB0aGF0IHNvdW5kcyBsaWtlIGl0 IGJlbG9uZ3MgaW4gdGhlIEhCSCBoZWFkZXIuDQo+DQo+Pj4gSXMgc2V0dGluZyBhIERlc3RpbmF0 aW9uIE9wdGlvbiB0byBiZSBjaGFuZ2VhYmxlIGVuIHJvdXRlIHZhbGlkPyBJIA0KPj4+IHN1cHBv c2UgdGhlIHRleHQgdGhhdCBleHRlbnNpb24gaGVhZGVycyBleGNlcHQgZm9yIEhCSCBjYW4ndCBi ZSANCj4+PiBwcm9jZXNzZWQgaW4gdHJhbnNpdCBpbXBsaWVzIHRoYXQgYSBETyBjYW4gbmV2ZXIg YmUgbW9kaWZpZWQgZW4gDQo+Pj4gcm91dGUgYW5kIHRydW1wcyB0aGUgRE8gY2hhbmdlYWJsZSBi aXQsIGJ1dCBhcmUgdGhlcmUgY2FzZSB3aGVyZSBpdCANCj4+PiBjb3VsZCBiZSBsZWdpdGltYXRl bHkgYmUgY2hhbmdlZCwgbWF5YmUgdGhlIGVuZCBob3N0IGlzIGFsbG93ZWQgdG8gDQo+Pj4gbW9k aWZ5IHRoZSBvcHRpb24gYmVmb3JlIGRlbGl2ZXJ5IHRvIHRoZSBhcHBsaWNhdGlvbj8NCj4+DQo+ PiBXaGVuIHVzZWQgd2l0aCBhIHJvdXRpbmcgaGVhZGVyPw0KPj4NCj4+IC0tDQo+PiBKSU5NRUks IFRhdHV5YQ0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+DQo= From nobody Fri Sep 14 20:31:53 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6174012F1A6 for ; Fri, 14 Sep 2018 20:31:52 -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 bRI-M2M7Vt21 for ; Fri, 14 Sep 2018 20:31:50 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CDE126CC7 for ; Fri, 14 Sep 2018 20:31:50 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id t84-v6so5233789pgb.5 for ; Fri, 14 Sep 2018 20:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dY4r+xXkfpW0rX+vSpnT9qdXmjVtob2jzdnGZls6ua4=; b=khweHud7CRady1H690JPjOWzHYChs3cL7FDNMtlpKdSHlEHSvlJvXzqE+BlLMqtgWN YgvaYiye/S7iTXZ4qArw8tNn9xGy/0+K0oxgdoi6ByOUIpMZzO+Y738x2JxsVfh7kLML DFNeC3VnLGj6GzkMOa6LI+ET1YW4rX2eFAccaoCkiggAwXcA11qawLZ4NC+vj42p+MQj pnoZfzNpdnMymnSM29TowaNL/EpUdg4B4qf0ljkMM2B1JDPEKvD4SpZtwsyVObiUF/e8 SJfuycebbXyUud/0QzBJX42ouXWg+UBrN6qT6h0WGpA4bjDDoG2vIdj4KtVAiw0CILMz WocQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dY4r+xXkfpW0rX+vSpnT9qdXmjVtob2jzdnGZls6ua4=; b=HzuhhYSs3NMsTdW33qtQFw64QNdFFad8211uj+SPHiLaDL0was2+P0LqtEem2GMHxE YB7UGdl+u0PKno4CkpNG2uxMmqIdgm8YxOQmT3Q03+v0OErzaGhTx1Mt7C8rEtYLYxSW ajMa16KsEDGBxCgUHr/7BXnoOmjnSIbAeu2KQE2uY8C7jZVGFGzdGo6DOWTIeaRadect CON0uC2A81FDAhtYtFA6OnsrJeUXq47U061QhIyUKJpqwZWyZMZynLnzO2uPsK/eP9pZ EAeVhphMRWRUI4C6UiSXjL7FZv0yFYAI0DV+4ZRV+y24b7iNsslhtPCpZQ97vdJdCh1k nrmw== X-Gm-Message-State: APzg51DaRhMwMKhaS8/fQw7u5OEt6I4Hf08XqGTMmjzfja0byjr530CW uIHKWqZoaBKXHKc2nZBVWRyz8e01 X-Google-Smtp-Source: ANB0VdYf/D1Q0nfF7im+imryKADisZra1abXp2y//vL1zHpqE5K4zvhUMKx0Pmk1D9lLa4CVL6j3Cw== X-Received: by 2002:a63:f26:: with SMTP id e38-v6mr13894755pgl.354.1536982309436; Fri, 14 Sep 2018 20:31:49 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id r17-v6sm12339809pff.50.2018.09.14.20.31.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 20:31:48 -0700 (PDT) Subject: Re: Modifiable Destination Options To: ipv6@ietf.org References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.com> From: Brian E Carpenter Message-ID: Date: Sat, 15 Sep 2018 15:31:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.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.29 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 Sep 2018 03:31:52 -0000 On 2018-09-15 14:57, Xiejingrong wrote: > Hi Tom, >=20 > I guess the HBH had been deprecated after the RFC8200 required the defa= ult behavior to discard the HBH. Per the RFC8200: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes= > along a packet's delivery path only examine and process the > Hop-by-Hop Options header if explicitly configured to do so. There is no mention of *discard* there. The forwarding node simply ignores the HBH header. Brian >=20 > Again, the BIER is not a hop-by-hop behavior, because it must support t= o run over some form of tunnels like SRH. >=20 > Also from the security side, from the flexibility side, any IPv6 Option= s is defined in some preceding 'Context' is much better in my opinion.=20 >=20 > For BIER, such a 'Context' is the Multicast DA which defined by some co= ntrol-plane or manage-plane to indicating to check What EH (DestOptHdr) a= nd what TLVs in the EH(the-only-BIER-TLV). >=20 > For SRH, such a 'Context' is the Unicast DA which defined by some contr= ol-plane or manage-plane to indicating to check what TLV to support and h= ow to deal with such TLV. >=20 > All such 'Context' is a local behavior, just like how the RFC8200 chang= ed for the handling of HBH: "if explicitly configured to do so". >=20 > Jingrong >=20 >=20 > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com]=20 > Sent: Saturday, September 15, 2018 1:23 AM > To: Xiejingrong > Cc: Fred Baker ; IPv6 IPv6 List ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > Subject: Re: Modifiable Destination Options >=20 > On Fri, Sep 7, 2018 at 11:54 PM, Xiejingrong w= rote: >> Hi all, >> >> I think the Destination Options is different from HBH, though they sha= re "The same Option Type numbering space", and have the same "Modifiable = or not" bit. >> >> The draft means to use such a "Mod= ifiable Destination Options" with a Multicast Address in the IPv6 DA. >> >> My understanding about the "change en route to the packet's final=20 >> destination" is that, >> >> (1) For a Multicast Address in IPv6 DA, the "final destination" is the= IPv6 node(s) who don't forward the packet anymore. And thus the "Modifia= ble Destination Options" is required. >> >> (2) If is also suitable for cases when Unicast Address in IPv6 DA and = Destination Options is ahead of Routing header. >> >=20 > Hi Xiejinggrong, >=20 > I don't think it should matter whether the final destination is multica= st or unicast. The final destination is at the node that is addressed in = the destination address. In the case of multicast, it's simply the end no= des that receive the packets as addressed by the multicast address. >=20 > It is unclear to me if a Destination Option is appropriate for BIER. > It seems like the target of the information is intermediate routers in = the path that are not explicitly addressed by the destination address (i.= e. there's no routing header present that writes destination addresses en= route). Should this be a Hop-by-Hop option instead? >=20 > Tom >=20 >> To quote two paragraphs of RFC8200: >> note 1: for options to be processed by the first destination tha= t >> appears in the IPv6 Destination Address field plus >> subsequent destinations listed in the Routing header. >> >> The third-highest-order bit of the Option Type specifies whether or= >> not the Option Data of that option can change en route to the >> packet's final destination. >> >> Thanks >> Jingrong >> >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker >> Sent: Saturday, June 30, 2018 5:38 AM >> To: Tom Herbert >> Cc: IPv6 IPv6 List ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= >> Subject: Re: Modifiable Destination Options >> >> >> >>> On Jun 29, 2018, at 9:54 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> >>> At Thu, 28 Jun 2018 15:09:05 -0700, >>> Tom Herbert wrote: >>> >>>> I don't see that that setting this bit for a Destination Option is=20 >>>> prohibited. So what is the effect of setting a Destination Option=20 >>>> type to be modifiable en route? >> >> I thought the point of a destination option was that it was only evalu= ated by the system identified by the destination address? If it's being m= odified in flight, that sounds like it belongs in the HBH header. >> >>>> Is setting a Destination Option to be changeable en route valid? I=20 >>>> suppose the text that extension headers except for HBH can't be=20 >>>> processed in transit implies that a DO can never be modified en=20 >>>> route and trumps the DO changeable bit, but are there case where it = >>>> could be legitimately be changed, maybe the end host is allowed to=20 >>>> modify the option before delivery to the application? >>> >>> When used with a routing header? >>> >>> -- >>> JINMEI, Tatuya >>> >>> -------------------------------------------------------------------- >>> 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 Fri Sep 14 20:58:33 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B90812F18C for ; Fri, 14 Sep 2018 20:58:31 -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 5j82AVv-Qrt8 for ; Fri, 14 Sep 2018 20:58:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 10D65127133 for ; Fri, 14 Sep 2018 20:58:29 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F1DA0A98164DD for ; Sat, 15 Sep 2018 04:58:25 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 04:58:26 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.129]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Sat, 15 Sep 2018 11:58:17 +0800 From: Xiejingrong To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Modifiable Destination Options Thread-Topic: Modifiable Destination Options Thread-Index: AQHUDyzCtyJF2GU1mEayThLTBJ+Fi6R27zOAgABPLoCAbu1NQIAJzw4AgAEiZ9D//4ekAIAAjMUQ Date: Sat, 15 Sep 2018 03:58:17 +0000 Message-ID: <16253F7987E4F346823E305D08F9115A99AEA8F5@nkgeml514-mbs.china.huawei.com> References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.217.214] 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.29 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 Sep 2018 03:58:31 -0000 DQpPSy4gVGhlIEhCSCBpcyBpZ25vcmVkIGJ5IGRlZmF1bHQuIFNvIHlvdSBzZWVtcyBub3Qgb3Bw b3NlZCB0byB0aGUgd29yZCBvZiAiZGVwcmVjYXRlZCIgOy0pDQoNCkppbmdyb25nDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50ZXINClNlbnQ6IFNhdHVyZGF5LCBT ZXB0ZW1iZXIgMTUsIDIwMTggMTE6MzIgQU0NClRvOiBpcHY2QGlldGYub3JnDQpTdWJqZWN0OiBS ZTogTW9kaWZpYWJsZSBEZXN0aW5hdGlvbiBPcHRpb25zDQoNCk9uIDIwMTgtMDktMTUgMTQ6NTcs IFhpZWppbmdyb25nIHdyb3RlOg0KPiBIaSBUb20sDQo+IA0KPiBJIGd1ZXNzIHRoZSBIQkggaGFk IGJlZW4gZGVwcmVjYXRlZCBhZnRlciB0aGUgUkZDODIwMCByZXF1aXJlZCB0aGUgZGVmYXVsdCBi ZWhhdmlvciB0byBkaXNjYXJkIHRoZSBIQkguIFBlciB0aGUgUkZDODIwMDoNCj4gDQo+ICAgIE5P VEU6IFdoaWxlIFtSRkMyNDYwXSByZXF1aXJlZCB0aGF0IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUg YW5kDQo+ICAgIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5v dyBleHBlY3RlZCB0aGF0IG5vZGVzDQo+ICAgIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0 aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlDQo+ICAgIEhvcC1ieS1Ib3AgT3B0aW9ucyBo ZWFkZXIgaWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KDQpUaGVyZSBpcyBubyBt ZW50aW9uIG9mICpkaXNjYXJkKiB0aGVyZS4gVGhlIGZvcndhcmRpbmcgbm9kZSBzaW1wbHkgaWdu b3JlcyB0aGUgSEJIIGhlYWRlci4NCg0KICAgIEJyaWFuDQoNCj4gDQo+IEFnYWluLCB0aGUgQklF UiBpcyBub3QgYSBob3AtYnktaG9wIGJlaGF2aW9yLCBiZWNhdXNlIGl0IG11c3Qgc3VwcG9ydCB0 byBydW4gb3ZlciBzb21lIGZvcm0gb2YgdHVubmVscyBsaWtlIFNSSC4NCj4gDQo+IEFsc28gZnJv bSB0aGUgc2VjdXJpdHkgc2lkZSwgZnJvbSB0aGUgZmxleGliaWxpdHkgc2lkZSwgYW55IElQdjYg T3B0aW9ucyBpcyBkZWZpbmVkIGluIHNvbWUgcHJlY2VkaW5nICdDb250ZXh0JyBpcyBtdWNoIGJl dHRlciBpbiBteSBvcGluaW9uLiANCj4gDQo+IEZvciBCSUVSLCBzdWNoIGEgJ0NvbnRleHQnIGlz IHRoZSBNdWx0aWNhc3QgREEgd2hpY2ggZGVmaW5lZCBieSBzb21lIGNvbnRyb2wtcGxhbmUgb3Ig bWFuYWdlLXBsYW5lIHRvIGluZGljYXRpbmcgdG8gY2hlY2sgV2hhdCBFSCAoRGVzdE9wdEhkcikg YW5kIHdoYXQgVExWcyBpbiB0aGUgRUgodGhlLW9ubHktQklFUi1UTFYpLg0KPiANCj4gRm9yIFNS SCwgc3VjaCBhICdDb250ZXh0JyBpcyB0aGUgVW5pY2FzdCBEQSB3aGljaCBkZWZpbmVkIGJ5IHNv bWUgY29udHJvbC1wbGFuZSBvciBtYW5hZ2UtcGxhbmUgdG8gaW5kaWNhdGluZyB0byBjaGVjayB3 aGF0IFRMViB0byBzdXBwb3J0IGFuZCBob3cgdG8gZGVhbCB3aXRoIHN1Y2ggVExWLg0KPiANCj4g QWxsIHN1Y2ggJ0NvbnRleHQnIGlzIGEgbG9jYWwgYmVoYXZpb3IsIGp1c3QgbGlrZSBob3cgdGhl IFJGQzgyMDAgY2hhbmdlZCBmb3IgdGhlIGhhbmRsaW5nIG9mIEhCSDogImlmIGV4cGxpY2l0bHkg Y29uZmlndXJlZCB0byBkbyBzbyIuDQo+IA0KPiBKaW5ncm9uZw0KPiANCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJl cnRsYW5kLmNvbV0NCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAxNSwgMjAxOCAxOjIzIEFN DQo+IFRvOiBYaWVqaW5ncm9uZyA8eGllamluZ3JvbmdAaHVhd2VpLmNvbT4NCj4gQ2M6IEZyZWQg QmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbT47IElQdjYgSVB2NiBMaXN0IA0KPiA8aXB2 NkBpZXRmLm9yZz47IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+DQo+IFN1YmplY3Q6 IFJlOiBNb2RpZmlhYmxlIERlc3RpbmF0aW9uIE9wdGlvbnMNCj4gDQo+IE9uIEZyaSwgU2VwIDcs IDIwMTggYXQgMTE6NTQgUE0sIFhpZWppbmdyb25nIDx4aWVqaW5ncm9uZ0BodWF3ZWkuY29tPiB3 cm90ZToNCj4+IEhpIGFsbCwNCj4+DQo+PiBJIHRoaW5rIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25z IGlzIGRpZmZlcmVudCBmcm9tIEhCSCwgdGhvdWdoIHRoZXkgc2hhcmUgIlRoZSBzYW1lIE9wdGlv biBUeXBlIG51bWJlcmluZyBzcGFjZSIsIGFuZCBoYXZlIHRoZSBzYW1lICJNb2RpZmlhYmxlIG9y IG5vdCIgYml0Lg0KPj4NCj4+IFRoZSBkcmFmdCA8ZHJhZnQteGllLTZtYW4tYmllci1lbmNhcHN1 bGF0aW9uPiBtZWFucyB0byB1c2Ugc3VjaCBhICJNb2RpZmlhYmxlIERlc3RpbmF0aW9uIE9wdGlv bnMiIHdpdGggYSBNdWx0aWNhc3QgQWRkcmVzcyBpbiB0aGUgSVB2NiBEQS4NCj4+DQo+PiBNeSB1 bmRlcnN0YW5kaW5nIGFib3V0IHRoZSAiY2hhbmdlIGVuIHJvdXRlIHRvIHRoZSBwYWNrZXQncyBm aW5hbCANCj4+IGRlc3RpbmF0aW9uIiBpcyB0aGF0LA0KPj4NCj4+ICgxKSBGb3IgYSBNdWx0aWNh c3QgQWRkcmVzcyBpbiBJUHY2IERBLCB0aGUgImZpbmFsIGRlc3RpbmF0aW9uIiBpcyB0aGUgSVB2 NiBub2RlKHMpIHdobyBkb24ndCBmb3J3YXJkIHRoZSBwYWNrZXQgYW55bW9yZS4gQW5kIHRodXMg dGhlICJNb2RpZmlhYmxlIERlc3RpbmF0aW9uIE9wdGlvbnMiIGlzIHJlcXVpcmVkLg0KPj4NCj4+ ICgyKSBJZiBpcyBhbHNvIHN1aXRhYmxlIGZvciBjYXNlcyB3aGVuIFVuaWNhc3QgQWRkcmVzcyBp biBJUHY2IERBIGFuZCBEZXN0aW5hdGlvbiBPcHRpb25zIGlzIGFoZWFkIG9mIFJvdXRpbmcgaGVh ZGVyLg0KPj4NCj4gDQo+IEhpIFhpZWppbmdncm9uZywNCj4gDQo+IEkgZG9uJ3QgdGhpbmsgaXQg c2hvdWxkIG1hdHRlciB3aGV0aGVyIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBpcyBtdWx0aWNhc3Qg b3IgdW5pY2FzdC4gVGhlIGZpbmFsIGRlc3RpbmF0aW9uIGlzIGF0IHRoZSBub2RlIHRoYXQgaXMg YWRkcmVzc2VkIGluIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLiBJbiB0aGUgY2FzZSBvZiBtdWx0 aWNhc3QsIGl0J3Mgc2ltcGx5IHRoZSBlbmQgbm9kZXMgdGhhdCByZWNlaXZlIHRoZSBwYWNrZXRz IGFzIGFkZHJlc3NlZCBieSB0aGUgbXVsdGljYXN0IGFkZHJlc3MuDQo+IA0KPiBJdCBpcyB1bmNs ZWFyIHRvIG1lIGlmIGEgRGVzdGluYXRpb24gT3B0aW9uIGlzIGFwcHJvcHJpYXRlIGZvciBCSUVS Lg0KPiBJdCBzZWVtcyBsaWtlIHRoZSB0YXJnZXQgb2YgdGhlIGluZm9ybWF0aW9uIGlzIGludGVy bWVkaWF0ZSByb3V0ZXJzIGluIHRoZSBwYXRoIHRoYXQgYXJlIG5vdCBleHBsaWNpdGx5IGFkZHJl c3NlZCBieSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyAoaS5lLiB0aGVyZSdzIG5vIHJvdXRpbmcg aGVhZGVyIHByZXNlbnQgdGhhdCB3cml0ZXMgZGVzdGluYXRpb24gYWRkcmVzc2VzIGVuIHJvdXRl KS4gU2hvdWxkIHRoaXMgYmUgYSBIb3AtYnktSG9wIG9wdGlvbiBpbnN0ZWFkPw0KPiANCj4gVG9t DQo+IA0KPj4gVG8gcXVvdGUgdHdvIHBhcmFncmFwaHMgb2YgUkZDODIwMDoNCj4+ICAgICAgIG5v dGUgMTogZm9yIG9wdGlvbnMgdG8gYmUgcHJvY2Vzc2VkIGJ5IHRoZSBmaXJzdCBkZXN0aW5hdGlv biB0aGF0DQo+PiAgICAgICAgICAgICAgIGFwcGVhcnMgaW4gdGhlIElQdjYgRGVzdGluYXRpb24g QWRkcmVzcyBmaWVsZCBwbHVzDQo+PiAgICAgICAgICAgICAgIHN1YnNlcXVlbnQgZGVzdGluYXRp b25zIGxpc3RlZCBpbiB0aGUgUm91dGluZyBoZWFkZXIuDQo+Pg0KPj4gICAgVGhlIHRoaXJkLWhp Z2hlc3Qtb3JkZXIgYml0IG9mIHRoZSBPcHRpb24gVHlwZSBzcGVjaWZpZXMgd2hldGhlciBvcg0K Pj4gICAgbm90IHRoZSBPcHRpb24gRGF0YSBvZiB0aGF0IG9wdGlvbiBjYW4gY2hhbmdlIGVuIHJv dXRlIHRvIHRoZQ0KPj4gICAgcGFja2V0J3MgZmluYWwgZGVzdGluYXRpb24uDQo+Pg0KPj4gVGhh bmtzDQo+PiBKaW5ncm9uZw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJl ZCBCYWtlcg0KPj4gU2VudDogU2F0dXJkYXksIEp1bmUgMzAsIDIwMTggNTozOCBBTQ0KPj4gVG86 IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPg0KPj4gQ2M6IElQdjYgSVB2NiBMaXN0 IDxpcHY2QGlldGYub3JnPjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4NCj4+IFN1 YmplY3Q6IFJlOiBNb2RpZmlhYmxlIERlc3RpbmF0aW9uIE9wdGlvbnMNCj4+DQo+Pg0KPj4NCj4+ PiBPbiBKdW4gMjksIDIwMTgsIGF0IDk6NTQgQU0sIOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUu YWQuanA+IHdyb3RlOg0KPj4+DQo+Pj4gQXQgVGh1LCAyOCBKdW4gMjAxOCAxNTowOTowNSAtMDcw MCwNCj4+PiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6DQo+Pj4NCj4+ Pj4gSSBkb24ndCBzZWUgdGhhdCB0aGF0IHNldHRpbmcgdGhpcyBiaXQgZm9yIGEgRGVzdGluYXRp b24gT3B0aW9uIGlzIA0KPj4+PiBwcm9oaWJpdGVkLiBTbyB3aGF0IGlzIHRoZSBlZmZlY3Qgb2Yg c2V0dGluZyBhIERlc3RpbmF0aW9uIE9wdGlvbiANCj4+Pj4gdHlwZSB0byBiZSBtb2RpZmlhYmxl IGVuIHJvdXRlPw0KPj4NCj4+IEkgdGhvdWdodCB0aGUgcG9pbnQgb2YgYSBkZXN0aW5hdGlvbiBv cHRpb24gd2FzIHRoYXQgaXQgd2FzIG9ubHkgZXZhbHVhdGVkIGJ5IHRoZSBzeXN0ZW0gaWRlbnRp ZmllZCBieSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcz8gSWYgaXQncyBiZWluZyBtb2RpZmllZCBp biBmbGlnaHQsIHRoYXQgc291bmRzIGxpa2UgaXQgYmVsb25ncyBpbiB0aGUgSEJIIGhlYWRlci4N Cj4+DQo+Pj4+IElzIHNldHRpbmcgYSBEZXN0aW5hdGlvbiBPcHRpb24gdG8gYmUgY2hhbmdlYWJs ZSBlbiByb3V0ZSB2YWxpZD8gSSANCj4+Pj4gc3VwcG9zZSB0aGUgdGV4dCB0aGF0IGV4dGVuc2lv biBoZWFkZXJzIGV4Y2VwdCBmb3IgSEJIIGNhbid0IGJlIA0KPj4+PiBwcm9jZXNzZWQgaW4gdHJh bnNpdCBpbXBsaWVzIHRoYXQgYSBETyBjYW4gbmV2ZXIgYmUgbW9kaWZpZWQgZW4gDQo+Pj4+IHJv dXRlIGFuZCB0cnVtcHMgdGhlIERPIGNoYW5nZWFibGUgYml0LCBidXQgYXJlIHRoZXJlIGNhc2Ug d2hlcmUgaXQgDQo+Pj4+IGNvdWxkIGJlIGxlZ2l0aW1hdGVseSBiZSBjaGFuZ2VkLCBtYXliZSB0 aGUgZW5kIGhvc3QgaXMgYWxsb3dlZCB0byANCj4+Pj4gbW9kaWZ5IHRoZSBvcHRpb24gYmVmb3Jl IGRlbGl2ZXJ5IHRvIHRoZSBhcHBsaWNhdGlvbj8NCj4+Pg0KPj4+IFdoZW4gdXNlZCB3aXRoIGEg cm91dGluZyBoZWFkZXI/DQo+Pj4NCj4+PiAtLQ0KPj4+IEpJTk1FSSwgVGF0dXlhDQo+Pj4NCj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBp cHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlIA0KPj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZA aWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZw0KQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Fri Sep 14 21:25:40 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AC9130DC6 for ; Fri, 14 Sep 2018 21:25:38 -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 CJHBnaoC4F9M for ; Fri, 14 Sep 2018 21:25:36 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D08E12F18C for ; Fri, 14 Sep 2018 21:25:36 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id j8-v6so5027681pll.12 for ; Fri, 14 Sep 2018 21:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=x890wv4sMnSVapcTPuUJ29cSjI/XiGSYC5ovRpikiKc=; b=mMh9s2HwLjGj+Gf4TyHrUQSU1M22JDrsP3H9IL09E1qajulD3MDm1UL7Is5S6znhID 5D0VHz48uJTk9Nr3lmLZdK3hssIg7Su6KlnE6mTnSH8AA+kjmVvYFiZp/2yVORQYYRbZ zBNOTD64M/T/elMN0njcl8Bn95GGhGEiYT78k5zkeTpFvJDCDJW8UyuSguvErd9jj5s/ ARYeVwW64U1Hw+gQ3mKbZEM5d0DR+B5xLTlmhv6H8jIZMrpkEQu1HyEtStW0NKT+P52Y Mep2PMhJxh90r3tdxHnpmKbSU0ghNaPF2wc4dgQctIZdYulWcAtIVuON40RNBg68HiYc peqQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x890wv4sMnSVapcTPuUJ29cSjI/XiGSYC5ovRpikiKc=; b=hSSM5347e8tpkPflJGJl8gkaNlq/d0utD/GKXnk04I36qzZbcE17LUqNZRzClZVj70 IIbg4JPiemGTqv3yo+q8oT0df5ZY98NuCu2IbKDrF8Y7/yc2U3MXlnHlA5XZQudP3hDq S4+gFDeHnI8c+YCl/ndcSd6H28592plJ2onFRewM9NiVfDTODizZeNwUfbmmL6NxfTvL 8G31341tBo8YDBgA8nGN7O0dOTpdrlhTWzaGnLIidLFcIYhbQgFGc6bnsdsFKdNPBzV1 fp/gipZcz3nLTbnIL++geQ9vlE/SSrNBYzjYA4omOQ6x1b+xzRluMbT8SEVNKiDFMxEr rADg== X-Gm-Message-State: APzg51CHLv4zSyooa9h2/5cKJMVMyu+kYdFKiAQ4EUSF90wOC5UwdG08 +EuWY363JpJTnFdYQjzP3/4wDotM X-Google-Smtp-Source: ANB0VdayJ+TNng/qVNI+WeGPTArLZTyRB4CoJL7JvidmwYBUxXbwRjtLdTOv5pBgQN75YxfPVz5B7Q== X-Received: by 2002:a17:902:8b8b:: with SMTP id ay11-v6mr14683255plb.1.1536985535263; Fri, 14 Sep 2018 21:25:35 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f13-v6sm8089706pgq.63.2018.09.14.21.25.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 21:25:34 -0700 (PDT) Subject: Re: Modifiable Destination Options To: Xiejingrong , "ipv6@ietf.org" References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8F5@nkgeml514-mbs.china.huawei.com> From: Brian E Carpenter Message-ID: <201dbcd3-d812-5f48-5c95-28e275ee59d1@gmail.com> Date: Sat, 15 Sep 2018 16:25:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <16253F7987E4F346823E305D08F9115A99AEA8F5@nkgeml514-mbs.china.huawei.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.29 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 Sep 2018 04:25:38 -0000 On 2018-09-15 15:58, Xiejingrong wrote: >=20 > OK. The HBH is ignored by default. So you seems not opposed to the word= of "deprecated" ;-) Well, we simply stated that it may not work as expected! That is not as s= trong as deprecation. I think the ITU is more fond of formal deprecation than t= he IETF. Brian =20 > Jingrong >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Saturday, September 15, 2018 11:32 AM > To: ipv6@ietf.org > Subject: Re: Modifiable Destination Options >=20 > On 2018-09-15 14:57, Xiejingrong wrote: >> Hi Tom, >> >> I guess the HBH had been deprecated after the RFC8200 required the def= ault behavior to discard the HBH. Per the RFC8200: >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that node= s >> along a packet's delivery path only examine and process the >> Hop-by-Hop Options header if explicitly configured to do so. >=20 > There is no mention of *discard* there. The forwarding node simply igno= res the HBH header. >=20 > Brian >=20 >> >> Again, the BIER is not a hop-by-hop behavior, because it must support = to run over some form of tunnels like SRH. >> >> Also from the security side, from the flexibility side, any IPv6 Optio= ns is defined in some preceding 'Context' is much better in my opinion.=20 >> >> For BIER, such a 'Context' is the Multicast DA which defined by some c= ontrol-plane or manage-plane to indicating to check What EH (DestOptHdr) = and what TLVs in the EH(the-only-BIER-TLV). >> >> For SRH, such a 'Context' is the Unicast DA which defined by some cont= rol-plane or manage-plane to indicating to check what TLV to support and = how to deal with such TLV. >> >> All such 'Context' is a local behavior, just like how the RFC8200 chan= ged for the handling of HBH: "if explicitly configured to do so". >> >> Jingrong >> >> >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Saturday, September 15, 2018 1:23 AM >> To: Xiejingrong >> Cc: Fred Baker ; IPv6 IPv6 List=20 >> ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 >> Subject: Re: Modifiable Destination Options >> >> On Fri, Sep 7, 2018 at 11:54 PM, Xiejingrong = wrote: >>> Hi all, >>> >>> I think the Destination Options is different from HBH, though they sh= are "The same Option Type numbering space", and have the same "Modifiable= or not" bit. >>> >>> The draft means to use such a "Mo= difiable Destination Options" with a Multicast Address in the IPv6 DA. >>> >>> My understanding about the "change en route to the packet's final=20 >>> destination" is that, >>> >>> (1) For a Multicast Address in IPv6 DA, the "final destination" is th= e IPv6 node(s) who don't forward the packet anymore. And thus the "Modifi= able Destination Options" is required. >>> >>> (2) If is also suitable for cases when Unicast Address in IPv6 DA and= Destination Options is ahead of Routing header. >>> >> >> Hi Xiejinggrong, >> >> I don't think it should matter whether the final destination is multic= ast or unicast. The final destination is at the node that is addressed in= the destination address. In the case of multicast, it's simply the end n= odes that receive the packets as addressed by the multicast address. >> >> It is unclear to me if a Destination Option is appropriate for BIER. >> It seems like the target of the information is intermediate routers in= the path that are not explicitly addressed by the destination address (i= =2Ee. there's no routing header present that writes destination addresses= en route). Should this be a Hop-by-Hop option instead? >> >> Tom >> >>> To quote two paragraphs of RFC8200: >>> note 1: for options to be processed by the first destination th= at >>> appears in the IPv6 Destination Address field plus >>> subsequent destinations listed in the Routing header. >>> >>> The third-highest-order bit of the Option Type specifies whether o= r >>> not the Option Data of that option can change en route to the >>> packet's final destination. >>> >>> Thanks >>> Jingrong >>> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker >>> Sent: Saturday, June 30, 2018 5:38 AM >>> To: Tom Herbert >>> Cc: IPv6 IPv6 List ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 >>> Subject: Re: Modifiable Destination Options >>> >>> >>> >>>> On Jun 29, 2018, at 9:54 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>> >>>> At Thu, 28 Jun 2018 15:09:05 -0700, >>>> Tom Herbert wrote: >>>> >>>>> I don't see that that setting this bit for a Destination Option is = >>>>> prohibited. So what is the effect of setting a Destination Option=20 >>>>> type to be modifiable en route? >>> >>> I thought the point of a destination option was that it was only eval= uated by the system identified by the destination address? If it's being = modified in flight, that sounds like it belongs in the HBH header. >>> >>>>> Is setting a Destination Option to be changeable en route valid? I = >>>>> suppose the text that extension headers except for HBH can't be=20 >>>>> processed in transit implies that a DO can never be modified en=20 >>>>> route and trumps the DO changeable bit, but are there case where it= =20 >>>>> could be legitimately be changed, maybe the end host is allowed to = >>>>> modify the option before delivery to the application? >>>> >>>> When used with a routing header? >>>> >>>> -- >>>> JINMEI, Tatuya >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>>> 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 Fri Sep 14 22:36:17 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66806130DF7; Fri, 14 Sep 2018 22:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 HNuwClnY0YXO; Fri, 14 Sep 2018 22:36:13 -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 6D884129C6B; Fri, 14 Sep 2018 22:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8071; q=dns/txt; s=iport; t=1536989773; x=1538199373; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z4CRhhVGUsl/jNbWw+oyvpmxfviXyI/sPpxR+VJ8YcY=; b=kj46UE20VF+mF0qXLvO8ItjTCAUHBfULZW59LPxSBZiqWRPVgWs0Y9Nx jxIphbeWWAgL6bLeGOdlUb6yXIsW2Xtig/HeXqTI1FTuE6mueutSYiT8a 0tMhbHWl8VGTXGf9MXznilDrsJbffpuUlB9wkuL/1vg+qzJrlQGa4cgKe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AACqmZxb/5JdJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFQgghlfyiDcogVjCqBaIEdkBSFOIF6CxgBCoRJAheDRyE?= =?us-ascii?q?0GAEDAQECAQECbRwMhTkCAQMBASFEBwsOAgIBCDUKAwICAhkMCxQRAgQOBYM?= =?us-ascii?q?hAYEdZA+oPIEuiggFBYpjF4FBP4ERKAwTghc1gxsBAQOBOD2CajGCJgKINoU?= =?us-ascii?q?VhWeJDAkChjqJWBePCItXiEkCERSBJR04gVVwFTsqAYJBixWFPm+ME4JLAQE?= X-IronPort-AV: E=Sophos;i="5.53,375,1531785600"; d="scan'208,217";a="449405305" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2018 05:36:08 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w8F5a84X002398 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Sep 2018 05:36:08 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.1395.4; Sat, 15 Sep 2018 00:36:07 -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.1395.000; Sat, 15 Sep 2018 00:36:07 -0500 From: "Rajiv Asati (rajiva)" To: JORDI PALET MARTINEZ CC: V6 Ops List , Mark Andrews , 6man WG , JORDI PALET MARTINEZ Subject: Re: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) Thread-Topic: [v6ops] NAT64 prefix configuration (was: Re: ipv6only-flag-02 security) Thread-Index: AQHUTBuxz+fz5iZxTkOc02qXaho5V6TwnE0AgAAN+ACAAAGugIAAEuwAgAAU6n8= Date: Sat, 15 Sep 2018 05:36:07 +0000 Message-ID: <946E75AE-DD4A-4421-858E-38946F3AA17A@cisco.com> References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <19297.1536689674@localhost> <69D95A4A-3C25-4987-B3E8-7203CEA48017@employees.org> <602A5DC3-7B86-4C55-8660-B1D7443218EA@gmail.com> <1BCD3EA0-C94A-48C5-8762-2C948BD36AE0@consulintel.es> <69A473AC-E52E-48E3-B31C-15C7E17C607F@isc.org> <86710663-6F7A-4A6E-8F46-C62D46DD0DDB@consulintel.es>, 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_946E75AEDD4A4421858E38946F3AA17Aciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 05:36:15 -0000 --_000_946E75AEDD4A4421858E38946F3AA17Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpCb3RoIE5BVDQ0IGFuZCBOQVQ2NCBhcmUgdHlwZXMgb2YgQ0dOLCBhcyBsb25nIGFzIHRoZXkg c2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIG91dGxpbmVkIGluIFJGQzY4ODguDQoNCi8vDQoNCkNh cnJpZXItR3JhZGUgTkFUIChDR04pOiAgQSBOQVQtYmFzZWQgW1JGQzI2NjM8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzI2NjM+XSBsb2dpY2FsIGZ1bmN0aW9uIHVzZWQNCiAgICAgIHRv IHNoYXJlIHRoZSBzYW1lIElQdjQgYWRkcmVzcyBhbW9uZyBzZXZlcmFsIHN1YnNjcmliZXJzLiAg QSBDR04NCiAgICAgIGlzIG5vdCBtYW5hZ2VkIGJ5IHRoZSBzdWJzY3JpYmVycy4NCg0KLy8NCg0K SSBzb21ld2hhdCBhZ3JlZSB3aXRoIE1hcmsuDQoNCkNoZWVycywNClJhaml2DQoNCk9uIFNlcCAx NSwgMjAxOCwgYXQgMToyMyBBTSwgTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPG1haWx0bzpt YXJrYUBpc2Mub3JnPj4gd3JvdGU6DQoNCg0KDQpPbiAxNSBTZXAgMjAxOCwgYXQgODoxMyBhbSwg Sk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPG1haWx0bzpq b3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4+IHdyb3RlOg0KDQpIaSBNYXJrLA0KDQpJdCBtYXkg ZGVwZW5kIG9uIHRoZSBzcGVjaWZpYyBDR04gaW1wbGVtZW50YXRpb24gcHJvdG9jb2wsIGJ1dCBp biBDR04geW91IHByZS1hbGxvY2F0ZSBhIGdpdmVuIG51bWJlciBvZiBwb3J0cyBwZXIgdXNlci4N Cg0KSXTigJlzIGRlZmluaXRlbHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuICBZb3UgY2FuIGRv IHRoZSBzYW1lIHRoaW5nIHdpdGggYSBOQVQ2NCBib3ggKElQdjYgcHJlZml4IHRvIElQdjQgPGFk ZHJlc3MscG9ydC1yYW5nZT4pLiAgSXTigJlzIGFsbCBhYm91dCBsb2dnaW5nIHRyYWRlIG9mZnMu ICBUaGVyZSBpcyBub3RoaW5nIGluIHRoZSB0d28gdGVjaG5vbG9naWVzIHJlcXVpcmluZyBpdCBv ciBwcm9oaWJpdGluZyBpdC4gIEluIG1hbnkgY2FzZXMgdGhvc2UgbG9nZ2luZyB0cmFkZSBvZmZz IGFyZSBkcml2ZW4gYnkgbGVnaXNsYXRpdmUgcmVxdWlyZW1lbnRzIHRvIGJlIGFibGUgdG8gdHJh Y2UgYmFjayB0byBzcGVjaWZpYyBjdXN0b21lcnMgZm9yIHRyYWZmaWMgdGhhdCBpcyB5ZWFycyBv bGQuDQoNCklzIG5vdCByZWxldmFudCBpZiB0aGF0IHVzZXIgYWN0dWFsbHkgdXNlcyBhbGwgdGhv c2UgcG9ydHMgb3IgbmVlZHMgbW9yZS4gVGhleSBhcmVuJ3QgYXZhaWxhYmxlIGZvciBvdGhlciB1 c2VycyBhbmQgZWFjaCB1c2VyIGhhcyBhIHNwZWNpZmljIGxpbWl0IG9uIHRoZSBudW1iZXIgb2Yg cG9ydHMuDQoNCkluIE5BVDY0LCB0aGUgcG9ydHMgZ2V0IGFsbG9jYXRlZCBvbiB0aGUgZmx5IGFz IG5lZWRlZCBmb3IgZWFjaCB1c2VyLiBTbyBJIHRoaW5rIGl0IGlzIGNsZWFyIHRoYXQgaXQgaXMg bXVjaCBtb3JlIGVmZmljaWVudC4NCg0KUmVnYXJzLA0KSm9yZGkNCi0tDQpNYXJrIEFuZHJld3Ms IElTQw0KMSBTZXltb3VyIFN0LiwgRHVuZGFzIFZhbGxleSwgTlNXIDIxMTcsIEF1c3RyYWxpYQ0K UEhPTkU6ICs2MSAyIDk4NzEgNDc0MiAgICAgICAgICAgICAgSU5URVJORVQ6IG1hcmthQGlzYy5v cmc8bWFpbHRvOm1hcmthQGlzYy5vcmc+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+ DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_946E75AEDD4A4421858E38946F3AA17Aciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdi YSgyNTUsIDI1NSwgMjU1LCAwKTsiPkJvdGggTkFUNDQgYW5kIE5BVDY0IGFyZSB0eXBlcyBvZiBD R04sIGFzIGxvbmcgYXMgdGhleSBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgb3V0bGluZWQgaW4g UkZDNjg4OC4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+Ly88YnI+DQo8ZGl2Pg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9u dCBmYWNlPSJVSUNURm9udFRleHRTdHlsZUJvZHkiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTog bm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Q2Fycmll ci1HcmFkZSBOQVQgKENHTik6ICBBIE5BVC1iYXNlZCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzI2NjMiIHRpdGxlPSImcXVvdDtJUCBOZXR3b3JrIEFkZHJlc3MgVHJh bnNsYXRvciAoTkFUKSBUZXJtaW5vbG9neSBhbmQgQ29uc2lkZXJhdGlvbnMmcXVvdDsiPlJGQzI2 NjM8L2E+XSBsb2dpY2FsIGZ1bmN0aW9uIHVzZWQNCiAgICAgIHRvIHNoYXJlIHRoZSBzYW1lIElQ djQgYWRkcmVzcyBhbW9uZyBzZXZlcmFsIHN1YnNjcmliZXJzLiAgQSBDR04NCiAgICAgIGlzIG5v dCBtYW5hZ2VkIGJ5IHRoZSBzdWJzY3JpYmVycy48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9kaXY+ DQo8ZGl2Pi8vPGJyPg0KPGJyPg0KSSBzb21ld2hhdCBhZ3JlZSB3aXRoIE1hcmsuJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjxkaXY+Q2hlZXJzLA0KPGRpdj5SYWppdiAmbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQpPbiBTZXAgMTUsIDIwMTgsIGF0IDE6MjMgQU0sIE1hcmsgQW5kcmV3 cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmthQGlzYy5vcmciPm1hcmthQGlzYy5vcmc8L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp dj48c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPk9uIDE1IFNlcCAyMDE4LCBhdCA4OjEzIGFtLCBKT1JESSBQQUxFVCBNQVJU SU5FWiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzIj5qb3Jk aS5wYWxldEBjb25zdWxpbnRlbC5lczwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SGkgTWFyayw8L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkl0IG1heSBk ZXBlbmQgb24gdGhlIHNwZWNpZmljIENHTiBpbXBsZW1lbnRhdGlvbiBwcm90b2NvbCwgYnV0IGlu IENHTiB5b3UgcHJlLWFsbG9jYXRlIGEgZ2l2ZW4gbnVtYmVyIG9mIHBvcnRzIHBlciB1c2VyLjwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SXTigJlz IGRlZmluaXRlbHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuICZuYnNwO1lvdSBjYW4gZG8gdGhl IHNhbWUgdGhpbmcgd2l0aCBhIE5BVDY0IGJveCAoSVB2NiBwcmVmaXggdG8gSVB2NCAmbHQ7YWRk cmVzcyxwb3J0LXJhbmdlJmd0OykuICZuYnNwO0l04oCZcyBhbGwgYWJvdXQgbG9nZ2luZyB0cmFk ZSBvZmZzLiAmbmJzcDtUaGVyZSBpcyBub3RoaW5nIGluIHRoZSB0d28gdGVjaG5vbG9naWVzIHJl cXVpcmluZyBpdCBvciBwcm9oaWJpdGluZyBpdC4gJm5ic3A7SW4gbWFueSBjYXNlcw0KIHRob3Nl IGxvZ2dpbmcgdHJhZGUgb2ZmcyBhcmUgZHJpdmVuIGJ5IGxlZ2lzbGF0aXZlIHJlcXVpcmVtZW50 cyB0byBiZSBhYmxlIHRvIHRyYWNlIGJhY2sgdG8gc3BlY2lmaWMgY3VzdG9tZXJzIGZvciB0cmFm ZmljIHRoYXQgaXMgeWVhcnMgb2xkLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SXMgbm90IHJlbGV2YW50IGlmIHRoYXQgdXNlciBh Y3R1YWxseSB1c2VzIGFsbCB0aG9zZSBwb3J0cyBvciBuZWVkcyBtb3JlLiBUaGV5IGFyZW4ndCBh dmFpbGFibGUgZm9yIG90aGVyIHVzZXJzIGFuZCBlYWNoIHVzZXIgaGFzIGEgc3BlY2lmaWMgbGlt aXQgb24gdGhlIG51bWJlciBvZiBwb3J0cy48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkluIE5BVDY0LCB0aGUgcG9ydHMgZ2V0IGFsbG9j YXRlZCBvbiB0aGUgZmx5IGFzIG5lZWRlZCBmb3IgZWFjaCB1c2VyLiBTbyBJIHRoaW5rIGl0IGlz IGNsZWFyIHRoYXQgaXQgaXMgbXVjaCBtb3JlIGVmZmljaWVudC48L3NwYW4+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlJlZ2Fycyw8L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Sm9yZGk8L3Nw YW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+LS0gPC9zcGFuPjxicj4NCjxzcGFuPk1hcmsg QW5kcmV3cywgSVNDPC9zcGFuPjxicj4NCjxzcGFuPjEgU2V5bW91ciBTdC4sIER1bmRhcyBWYWxs ZXksIE5TVyAyMTE3LCBBdXN0cmFsaWE8L3NwYW4+PGJyPg0KPHNwYW4+UEhPTkU6ICYjNDM7NjEg MiA5ODcxIDQ3NDIgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SU5URVJORVQ6IDxhIGhyZWY9Im1haWx0 bzptYXJrYUBpc2Mub3JnIj4NCm1hcmthQGlzYy5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjwv c3Bhbj48YnI+DQo8c3Bhbj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+DQo8c3Bhbj5JRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFp bHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPkFk bWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2PC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_946E75AEDD4A4421858E38946F3AA17Aciscocom_-- From nobody Sat Sep 15 08:58:40 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE689130DC4 for ; Sat, 15 Sep 2018 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 PuNXaku0O5_z for ; Sat, 15 Sep 2018 08:58:36 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572EB129619 for ; Sat, 15 Sep 2018 08:58:36 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id f62-v6so6857912qke.2 for ; Sat, 15 Sep 2018 08:58:36 -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=Nb/KVfAXv4aRVZQYokQ3R9TmtdZwfz7xaCUEydFg8Ws=; b=0umXN5AChSqddvKyZ/inH15hyMQ0niCCGNgvINrxPhmtaBUTbpxR0Tl7MekahE8TEG iddCmqjbEOLh0KfXQGrkzlDDFpk0tIIm/+Fdk6MCMbox9lLLh6GF/Exlf+LVLVbboFkO 03GFj/maiu5L76qRHz3Og1n8jyCEOReWGpWfJF+P6ful4l0S3C0GqLPufrzNwwBcq0hD 3HqHn/UcJ3tEbCGTXvfUtPSD499k+NBQpvdhZnqLv1ArdSw1DenqpuWidP2aHT2wO82I Ky7LdiY6tH6stX8EcCmgP9UrgEfnKi1j5YyzHvD5X3FuPblC8Udxexy7u2uxA2Yrrrv2 E01A== 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=Nb/KVfAXv4aRVZQYokQ3R9TmtdZwfz7xaCUEydFg8Ws=; b=UMw67ylAmSqIcIuaIw4CtDE6uRpXlg6jQYeM8bcDjmQTgxop+lCs5oLTO2LXpoNMG3 SFDKS+QXmVuRrgQZKa+rLc1wNlSuZ7+6aAKT21JL9ezkhFaUPt/WEod2/ptWmS+FDkLs NOVisCHtHK6tlvbHpCfYsgMup5gno7PPCE3rEgW1fs3JJcQtY97KlcqSFV2O7hU+Q6b2 0Zd1/8I76WWcFeRlP96Naxk0QKnsXHtgcyX0WixjbBYY6gFgxuoYMJHXX+iaJWa3RLpP cjvysZSvvedjxfILLr/mZQ+XKowkf0wd1fuRvSlTxGMc7Og/s/Tc7beiloqhkQm9/F1M NNSQ== X-Gm-Message-State: APzg51APf+yDKLNqIjG6DYYLFITLNgDHsOYX9GQiO/p4Y8LHfciWCczC gslFAtMLNjdTy5yqFJYR4jHUpbVqS7bmPMtWqNNKMA== X-Google-Smtp-Source: ANB0VdZXVqn8BPrFwxqHb0Z/tUID6CC1ZSJNS3HO+MZTiQ0l/esFe200BX2zAh0KVsnOPOH3VgqwJhJmwdTDwkGVolA= X-Received: by 2002:a37:4fcd:: with SMTP id d196-v6mr12190327qkb.323.1537027115184; Sat, 15 Sep 2018 08:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Sat, 15 Sep 2018 08:58:34 -0700 (PDT) In-Reply-To: <16253F7987E4F346823E305D08F9115A99AEA8F5@nkgeml514-mbs.china.huawei.com> References: <16253F7987E4F346823E305D08F9115A99AE8866@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8C4@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA8F5@nkgeml514-mbs.china.huawei.com> From: Tom Herbert Date: Sat, 15 Sep 2018 08:58:34 -0700 Message-ID: Subject: Re: Modifiable Destination Options To: Xiejingrong 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.29 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 Sep 2018 15:58:39 -0000 On Fri, Sep 14, 2018 at 8:58 PM, Xiejingrong wrote= : > > OK. The HBH is ignored by default. So you seems not opposed to the word o= f "deprecated" ;-) > Jingrong, Deprecation is not the intent. The change was an acknowledgement that many implementations do not conform, and will likely never conform, to the requirements. Relaxing the requirements in this way best preserves the utility of HBH, as opposed to other ad hoc behaviors of network devices that render them completely useless such as arbitrarily dropping packets with HBH. Tom > Jingrong > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Saturday, September 15, 2018 11:32 AM > To: ipv6@ietf.org > Subject: Re: Modifiable Destination Options > > On 2018-09-15 14:57, Xiejingrong wrote: >> Hi Tom, >> >> I guess the HBH had been deprecated after the RFC8200 required the defau= lt behavior to discard the HBH. Per the RFC8200: >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the >> Hop-by-Hop Options header if explicitly configured to do so. > > There is no mention of *discard* there. The forwarding node simply ignore= s the HBH header. > > Brian > >> >> Again, the BIER is not a hop-by-hop behavior, because it must support to= run over some form of tunnels like SRH. >> >> Also from the security side, from the flexibility side, any IPv6 Options= is defined in some preceding 'Context' is much better in my opinion. >> >> For BIER, such a 'Context' is the Multicast DA which defined by some con= trol-plane or manage-plane to indicating to check What EH (DestOptHdr) and = what TLVs in the EH(the-only-BIER-TLV). >> >> For SRH, such a 'Context' is the Unicast DA which defined by some contro= l-plane or manage-plane to indicating to check what TLV to support and how = to deal with such TLV. >> >> All such 'Context' is a local behavior, just like how the RFC8200 change= d for the handling of HBH: "if explicitly configured to do so". >> >> Jingrong >> >> >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Saturday, September 15, 2018 1:23 AM >> To: Xiejingrong >> Cc: Fred Baker ; IPv6 IPv6 List >> ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 >> Subject: Re: Modifiable Destination Options >> >> On Fri, Sep 7, 2018 at 11:54 PM, Xiejingrong wr= ote: >>> Hi all, >>> >>> I think the Destination Options is different from HBH, though they shar= e "The same Option Type numbering space", and have the same "Modifiable or = not" bit. >>> >>> The draft means to use such a "Modi= fiable Destination Options" with a Multicast Address in the IPv6 DA. >>> >>> My understanding about the "change en route to the packet's final >>> destination" is that, >>> >>> (1) For a Multicast Address in IPv6 DA, the "final destination" is the = IPv6 node(s) who don't forward the packet anymore. And thus the "Modifiable= Destination Options" is required. >>> >>> (2) If is also suitable for cases when Unicast Address in IPv6 DA and D= estination Options is ahead of Routing header. >>> >> >> Hi Xiejinggrong, >> >> I don't think it should matter whether the final destination is multicas= t or unicast. The final destination is at the node that is addressed in the= destination address. In the case of multicast, it's simply the end nodes t= hat receive the packets as addressed by the multicast address. >> >> It is unclear to me if a Destination Option is appropriate for BIER. >> It seems like the target of the information is intermediate routers in t= he path that are not explicitly addressed by the destination address (i.e. = there's no routing header present that writes destination addresses en rout= e). Should this be a Hop-by-Hop option instead? >> >> Tom >> >>> To quote two paragraphs of RFC8200: >>> note 1: for options to be processed by the first destination that >>> appears in the IPv6 Destination Address field plus >>> subsequent destinations listed in the Routing header. >>> >>> The third-highest-order bit of the Option Type specifies whether or >>> not the Option Data of that option can change en route to the >>> packet's final destination. >>> >>> Thanks >>> Jingrong >>> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker >>> Sent: Saturday, June 30, 2018 5:38 AM >>> To: Tom Herbert >>> Cc: IPv6 IPv6 List ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 >>> Subject: Re: Modifiable Destination Options >>> >>> >>> >>>> On Jun 29, 2018, at 9:54 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>> >>>> At Thu, 28 Jun 2018 15:09:05 -0700, >>>> Tom Herbert wrote: >>>> >>>>> I don't see that that setting this bit for a Destination Option is >>>>> prohibited. So what is the effect of setting a Destination Option >>>>> type to be modifiable en route? >>> >>> I thought the point of a destination option was that it was only evalua= ted by the system identified by the destination address? If it's being modi= fied in flight, that sounds like it belongs in the HBH header. >>> >>>>> Is setting a Destination Option to be changeable en route valid? I >>>>> suppose the text that extension headers except for HBH can't be >>>>> processed in transit implies that a DO can never be modified en >>>>> route and trumps the DO changeable bit, but are there case where it >>>>> could be legitimately be changed, maybe the end host is allowed to >>>>> modify the option before delivery to the application? >>>> >>>> When used with a routing header? >>>> >>>> -- >>>> JINMEI, Tatuya >>>> >>>> -------------------------------------------------------------------- >>>> 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Sep 15 09:04:10 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1BF130DC4 for ; Sat, 15 Sep 2018 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 QENiXIwA9j3M for ; Sat, 15 Sep 2018 09:04:06 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 97869129619 for ; Sat, 15 Sep 2018 09:04:06 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id g44-v6so11550553qtb.12 for ; Sat, 15 Sep 2018 09:04:06 -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=Vj4SirpopV/fFn3DYJNESKRfsdU5sJqFjBzY7VWNwjA=; b=DPPQmnCJdXCi/R+bGJMoFkBQUsGnWrhDXjrFdwmIdvr4RVtzmnXca9Bpp6BtEkVPiA cyzVGKTEHz7YYjwlO8hKVb9SGdpB+lIlGxzk3Y+Id75vKF0xZCxBmWFcqAkjsc2KTSRL A2Eb8NSPe7rh5Ddv7Dzj0rE3U07nnlMHUqUqs7FxTUCkNLcokx8DhlmFWdNk3NfYCsF2 ZtONippU0Wu3RHH1bLk1TkwWprmhXXUL2BxjE+VzXhphpa8F1PoJSfLR2wH27DeJ3B+R 9khoF3MV0oybGI6jzoeb//NetA1hIqgN79Aw6FogAwY+A+yNHAwXkabzIx9LoDYO2KbL ykzw== 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=Vj4SirpopV/fFn3DYJNESKRfsdU5sJqFjBzY7VWNwjA=; b=FMEUktj66ekhICRy3tYUuhOUaEIKQv/Wolz+30BpIEcJ3l13OBZynej9KUc7LKEEUS jH3BQwMYOozVGYSv91SHLpPWoC7//k1vshHymuxXNUg87VTY/u+1qJfqeHVrNn3M65Sg SsJnkjqUcuDV3we4mKU5BcYLYJ4B20eMXdPjFs3AXEXadUb97ayMtI86Cb2tzMY6SlhJ tAvdR/akNanwd53mY2lY1J/eWHsgsxYbFL40OEBz+i+d5qrY3e4RY4MWbGS3TG8rwzp4 lQkLmvkfhN4yG4bqLG3ZyANrY+U/p4Jkj6wscB7T2nMbkpdz787t1GGE1ILjz9TEQ9TQ TbmA== X-Gm-Message-State: APzg51BzNO84NrRAs6waCEGMCtU7mewpEv8rWvwuuvfI7P0O9f/JQJNl iQzRyche1KoNPD1aumtTymV/y6K7EMKpKFZ+Rkwgqw== X-Google-Smtp-Source: ANB0VdZzeTKF2MuQ8/BBHGfbZ5E0cM80RVYTJGApmU4RNVRRxw3DLaTF08FV/84SC5xl041B3eb3OF2CVcW5mc+T+q0= X-Received: by 2002:a0c:bd0e:: with SMTP id m14-v6mr12526890qvg.168.1537027445474; Sat, 15 Sep 2018 09:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2a94:0:0:0:0:0 with HTTP; Sat, 15 Sep 2018 09:04:04 -0700 (PDT) In-Reply-To: <16253F7987E4F346823E305D08F9115A99AEA865@nkgeml514-mbs.china.huawei.com> References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA865@nkgeml514-mbs.china.huawei.com> From: Tom Herbert Date: Sat, 15 Sep 2018 09:04:04 -0700 Message-ID: Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-00.txt To: Xiejingrong Cc: 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.29 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 Sep 2018 16:04:09 -0000 On Fri, Sep 14, 2018 at 6:52 PM, Xiejingrong wrote= : > Hi Tom, > > Suppose a network with these router nodes: CE1--PE1--P1-P2-P3-PE2--CE2. > PE1 impose an outer IPv6 Header on the customer IP packet, with a DestOpt= Hdr preceding a RoutingHdr, with the final Dest PE2, and the intermediate d= est P2. > P2 will have to keep the DestOptHdr because the DestOptHdr is preceding a= RoutingHdr. > PE2 will also keep the DestOptHdr first because the DestOptHdr is precedi= ng a RouthingHdr, and PE2 can't judge if it is the final dest until it chec= k the following RH in a detailed way, and I suppose it will not do. > Then PE2 goto the RH, and pop the RH according to the handling of RH itse= lf. > What is the time to remove the DestOptHdr that PE1 imposed ? > One may think that, after when RH is removed then the DestOptHdr should a= lso removed, but that will bring the handling of DestOptHdr to the handling= of RH. > Jingrong, If I understand your example correctly, PE1 is encapsulating packets from CE1 in IPv6 packets that have both a Routing header and Destination Options (or maybe even other extension headers). PE2 is the final destination of the encapsulating packet, so the IP in IP encapsulation is terminated there and the encapsulated packet continues on the CE2. "Popping the RH" really means terminating the IP encapsulation which means everything about the outer packet encapsulation created by PE1 is discarded (all headers from the outer IP header to the inner one.). So this isn't removing extension headers, it's just processing received a packet at its final destination (i.e. the tunnel end point in encapsulation). Tom > Jingrong > > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: Saturday, September 15, 2018 9:12 AM > To: Xiejingrong > Cc: 6man > Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-= 00.txt > > On Fri, Sep 14, 2018 at 6:08 PM, Xiejingrong wro= te: >> Hi Tom, >> >> I have read the fresh draft just now. >> I agree with you some of the good catch, "Intermediate destination nodes= may be closer in taxonomy to switches and routers than end hosts". >> But I did not agree with this point, "Allowing nodes to ignore options r= etains the primary value and usability of Destination Options preceding a R= outing header." >> Quite the contrary, I do think the "Destination Options preceding a Rout= ing header" should not happen absolutely." >> Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr c= an't be removed, but the RH can be popped by an router. How will that happe= n ? > > Xiejingrong, > > The routing header can't be removed either. Per RFC8200: > > "Extension headers (except for the Hop-by-Hop Options header) are not pro= cessed, inserted, or deleted by any node along a packet's delivery path, un= til the packet reaches the node (or each of the set of nodes, in the case o= f multicast) identified in the Destination Address field of the IPv6 header= ." > > Tom > > >> >> Thanks, >> Jingrong >> >> >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert >> Sent: Saturday, September 15, 2018 7:49 AM >> To: 6man >> Subject: Fwd: New Version Notification for >> draft-herbert-ipv6-update-opts-00.txt >> >> Hello, >> >> I submitted a new version of draft to update option requirements. >> Since this now includes updates to requirements that cover both DestOpts= and HBH options, I renamed the draft. Other changes include feedback from = the list. I also added a section on detecting that Destination Options prec= ede a Routing header which is needed if they are to be processed differentl= y. >> >> Tom >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Sep 14, 2018 at 4:43 PM >> Subject: New Version Notification for >> draft-herbert-ipv6-update-opts-00.txt >> To: Tom Herbert >> >> >> >> A new version of I-D, draft-herbert-ipv6-update-opts-00.txt >> has been successfully submitted by Tom Herbert and posted to the IETF re= pository. >> >> Name: draft-herbert-ipv6-update-opts >> Revision: 00 >> Title: Updates to Requirements for IPv6 Options >> Document date: 2018-09-14 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.t= xt >> Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-upda= te-opts/ >> Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-op= ts-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts >> >> >> Abstract: >> This document updates requirements for IPv6 Destination and Hop-by- >> Hop Options. The requirements that option type and option length >> cannot change en route, as well as the requirements that options >> cannot be added or removed, are made explicit. The meaning and >> requirements of a Destination Option marked as changeable are >> clarified. Finally, the requirement that all destinations listed in a >> Routing header must process options in a Destination Options header >> preceding the Routing header is relaxed. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Sat Sep 15 15:59:20 2018 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D3126CB6 for ; Sat, 15 Sep 2018 15:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT8fTJPodD4G for ; Sat, 15 Sep 2018 15:59:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D99E7130E5B for ; Sat, 15 Sep 2018 15:59:15 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1D75E4071BBD5 for ; Sat, 15 Sep 2018 23:59:11 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sat, 15 Sep 2018 23:59:12 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Sun, 16 Sep 2018 06:58:19 +0800 From: Xiejingrong To: Tom Herbert CC: 6man Subject: RE: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Topic: New Version Notification for draft-herbert-ipv6-update-opts-00.txt Thread-Index: AQHUTIWjzTO1UMf1YU+FkULBRRqNoaTwhbeg//99bYCAAIwdgIAAbQoAgAD52vc= Date: Sat, 15 Sep 2018 22:58:19 +0000 Message-ID: 280680C1-8ACC-4729-A4AB-E08C5F2D9FDD References: <153696859164.17684.17595091671180827282.idtracker@ietfa.amsl.com> <16253F7987E4F346823E305D08F9115A99AEA82B@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99AEA865@nkgeml514-mbs.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_280680C18ACC4729A4ABE08C5F2D9FDD_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2018 22:59:19 -0000 --_000_280680C18ACC4729A4ABE08C5F2D9FDD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes it is the case of a ipv6 tunnel end point, and the final dest. But the = final dest is a router instead of a host OS. IPv6 node is classified as hos= t or router and have different requirements. I belive host node can do the = final dest things as you described in the draft. But a tunnel endpoint rout= er can not do the final dest things right as you described in the 3 opinion= s to judge the final dest for a DestOptHdr preceding a RH. Jingrong From:Tom Herbert To:Xiejingrong, Cc:6man, Date:2018-09-16 00:04:22 Subject:Re: New Version Notification for draft-herbert-ipv6-update-opts-00.= txt On Fri, Sep 14, 2018 at 6:52 PM, Xiejingrong wrote= : > Hi Tom, > > Suppose a network with these router nodes: CE1--PE1--P1-P2-P3-PE2--CE2. > PE1 impose an outer IPv6 Header on the customer IP packet, with a DestOpt= Hdr preceding a RoutingHdr, with the final Dest PE2, and the intermediate d= est P2. > P2 will have to keep the DestOptHdr because the DestOptHdr is preceding a= RoutingHdr. > PE2 will also keep the DestOptHdr first because the DestOptHdr is precedi= ng a RouthingHdr, and PE2 can't judge if it is the final dest until it chec= k the following RH in a detailed way, and I suppose it will not do. > Then PE2 goto the RH, and pop the RH according to the handling of RH itse= lf. > What is the time to remove the DestOptHdr that PE1 imposed ? > One may think that, after when RH is removed then the DestOptHdr should a= lso removed, but that will bring the handling of DestOptHdr to the handling= of RH. > Jingrong, If I understand your example correctly, PE1 is encapsulating packets from CE1 in IPv6 packets that have both a Routing header and Destination Options (or maybe even other extension headers). PE2 is the final destination of the encapsulating packet, so the IP in IP encapsulation is terminated there and the encapsulated packet continues on the CE2. "Popping the RH" really means terminating the IP encapsulation which means everything about the outer packet encapsulation created by PE1 is discarded (all headers from the outer IP header to the inner one.). So this isn't removing extension headers, it's just processing received a packet at its final destination (i.e. the tunnel end point in encapsulation). Tom > Jingrong > > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: Saturday, September 15, 2018 9:12 AM > To: Xiejingrong > Cc: 6man > Subject: Re: New Version Notification for draft-herbert-ipv6-update-opts-= 00.txt > > On Fri, Sep 14, 2018 at 6:08 PM, Xiejingrong wro= te: >> Hi Tom, >> >> I have read the fresh draft just now. >> I agree with you some of the good catch, "Intermediate destination nodes= may be closer in taxonomy to switches and routers than end hosts". >> But I did not agree with this point, "Allowing nodes to ignore options r= etains the primary value and usability of Destination Options preceding a R= outing header." >> Quite the contrary, I do think the "Destination Options preceding a Rout= ing header" should not happen absolutely." >> Because, once you put a DestOptHdr preceding a RH, then the DestOptHdr c= an't be removed, but the RH can be popped by an router. How will that happe= n ? > > Xiejingrong, > > The routing header can't be removed either. Per RFC8200: > > "Extension headers (except for the Hop-by-Hop Options header) are not pro= cessed, inserted, or deleted by any node along a packet's delivery path, un= til the packet reaches the node (or each of the set of nodes, in the case o= f multicast) identified in the Destination Address field of the IPv6 header= ." > > Tom > > >> >> Thanks, >> Jingrong >> >> >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert >> Sent: Saturday, September 15, 2018 7:49 AM >> To: 6man >> Subject: Fwd: New Version Notification for >> draft-herbert-ipv6-update-opts-00.txt >> >> Hello, >> >> I submitted a new version of draft to update option requirements. >> Since this now includes updates to requirements that cover both DestOpts= and HBH options, I renamed the draft. Other changes include feedback from = the list. I also added a section on detecting that Destination Options prec= ede a Routing header which is needed if they are to be processed differentl= y. >> >> Tom >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Sep 14, 2018 at 4:43 PM >> Subject: New Version Notification for >> draft-herbert-ipv6-update-opts-00.txt >> To: Tom Herbert >> >> >> >> A new version of I-D, draft-herbert-ipv6-update-opts-00.txt >> has been successfully submitted by Tom Herbert and posted to the IETF re= pository. >> >> Name: draft-herbert-ipv6-update-opts >> Revision: 00 >> Title: Updates to Requirements for IPv6 Options >> Document date: 2018-09-14 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-herbert-ipv6-update-opts-00.t= xt >> Status: https://datatracker.ietf.org/doc/draft-herbert-ipv6-upda= te-opts/ >> Htmlized: https://tools.ietf.org/html/draft-herbert-ipv6-update-op= ts-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-update-opts >> >> >> Abstract: >> This document updates requirements for IPv6 Destination and Hop-by- >> Hop Options. The requirements that option type and option length >> cannot change en route, as well as the requirements that options >> cannot be added or removed, are made explicit. The meaning and >> requirements of a Destination Option marked as changeable are >> clarified. Finally, the requirement that all destinations listed in a >> Routing header must process options in a Destination Options header >> preceding the Routing header is relaxed. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- --_000_280680C18ACC4729A4ABE08C5F2D9FDD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes it is the case of a ipv6 tunnel end point, and the final dest. But= the final dest is a router instead of a host OS. IPv6 node is classified a= s host or router and have different requirements. I belive host node can do= the final dest things as you described in the draft. But a tunnel endpoint router can not do the final dest thing= s right as you described in the 3 opinions to judge the final dest for a De= stOptHdr preceding a RH.

Jingrong
From:Tom Herbert
To:Xiejingrong,
Cc:6man,
Date:2018-09-16 00:04:22
Subject:Re: New Version Notifica= tion for draft-herbert-ipv6-update-opts-00.txt

On Fri, Sep 14, 2018 at 6:52 PM, Xiejingrong <x= iejingrong@huawei.com> wrote:
> Hi Tom,
>
> Suppose a network with these router nodes: CE1--PE1--P1-P2-P3-PE2--CE2= .
> PE1 impose an outer IPv6 Header on the customer IP packet, with a Dest= OptHdr preceding a RoutingHdr, with the final Dest PE2, and the intermediat= e dest P2.
> P2 will have to keep the DestOptHdr because the DestOptHdr is precedin= g a RoutingHdr.
> PE2 will also keep the DestOptHdr first because the DestOptHdr is prec= eding a RouthingHdr, and PE2 can't judge if it is the final dest until it c= heck the following RH in a detailed way, and I suppose it will not do.
> Then PE2 goto the RH, and pop the RH according to the handling of RH i= tself.
> What is the time to remove the DestOptHdr that PE1 imposed ?
> One may think that, after when RH is removed then the DestOptHdr shoul= d also removed, but that will bring the handling of DestOptHdr to the handl= ing of RH.
>
Jingrong,

If I understand your example correctly, PE1 is encapsulating packets
from CE1 in IPv6 packets that have both a Routing header and
Destination Options (or maybe even other extension headers). PE2 is
the final destination of the encapsulating packet, so the IP in IP
encapsulation is terminated there and the encapsulated packet
continues on the CE2. "Popping the RH" really means terminating t= he IP
encapsulation which means everything about the outer packet
encapsulation created by PE1 is discarded (all headers from the outer
IP header to the inner one.). So this isn't removing extension
headers, it's just processing received a packet at its final
destination (i.e. the tunnel end point in encapsulation).

Tom

> Jingrong
>
> -----Original Message-----
> From: Tom Herbert [mailto:tom@h= erbertland.com]
> Sent: Saturday, September 15, 2018 9:12 AM
> To: Xiejingrong <xiejingrong@huawei.com>
> Cc: 6man <ipv6@ietf.org>
> Subject: Re: New Version Notification for draft-herbert-ipv6-update-op= ts-00.txt
>
> On Fri, Sep 14, 2018 at 6:08 PM, Xiejingrong <xiejingrong@huawei.co= m> wrote:
>> Hi Tom,
>>
>> I have read the fresh draft just now.
>> I agree with you some of the good catch, "Intermediate destin= ation nodes may be closer in taxonomy to switches and routers than end host= s".
>> But I did not agree with this point, "Allowing nodes to ignor= e options retains the primary value and usability of Destination Options pr= eceding a Routing header."
>> Quite the contrary, I do think the "Destination Options prece= ding a Routing header" should not happen absolutely."
>> Because, once you put a DestOptHdr preceding a RH, then the DestOp= tHdr can't be removed, but the RH can be popped by an router. How will that= happen ?
>
> Xiejingrong,
>
> The routing header can't be removed either. Per RFC8200:
>
> "Extension headers (except for the Hop-by-Hop Options header) are= not processed, inserted, or deleted by any node along a packet's delivery = path, until the packet reaches the node (or each of the set of nodes, in th= e case of multicast) identified in the Destination Address field of the IPv6 header."
>
> Tom
>
>
>>
>> Thanks,
>> Jingrong
>>
>>
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-b= ounces@ietf.org] On Behalf Of Tom Herbert
>> Sent: Saturday, September 15, 2018 7:49 AM
>> To: 6man <ipv6@ietf.org>
>> Subject: Fwd: New Version Notification for
>> draft-herbert-ipv6-update-opts-00.txt
>>
>> Hello,
>>
>> I submitted a new version of draft to update option requirements.<= br> >> Since this now includes updates to requirements that cover both De= stOpts and HBH options, I renamed the draft. Other changes include feedback= from the list. I also added a section on detecting that Destination Option= s precede a Routing header which is needed if they are to be processed differently.
>>
>> Tom
>>
>>
>>
>> ---------- Forwarded message ----------
>> From:  <internet-drafts@ietf.org>
>> Date: Fri, Sep 14, 2018 at 4:43 PM
>> Subject: New Version Notification for
>> draft-herbert-ipv6-update-opts-00.txt
>> To: Tom Herbert <tom@quantonium.net>
>>
>>
&g