From nobody Tue Aug 1 02:35:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E22132CA9 for ; Tue, 1 Aug 2017 02:35:00 -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 WVj6wOpwEW5n for ; Tue, 1 Aug 2017 02:34:59 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8CD132CB8 for ; Tue, 1 Aug 2017 02:34:59 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id t86so5581083pfe.2 for ; Tue, 01 Aug 2017 02:34:59 -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=23pDRWaaQIl9vuBcNWdsw9Md3t4Vdcmq2m5SQQ07mes=; b=MpFQgI1Oel7hJrv7futkUrXqiT2vlE8LWzIEpKKw3rTKZ0e8u4qjNjZDyUCMXLbNRB dQgCQfhkKgYjfqZGEnPyR8N6BE5e1tDR5HuFWzS9lmzmL1valTNGa/bxiMYpIQQYwIAS b9/rv9UdqulKoTmdMVJX1PTHpIX0RT6CobCXRTkttDq/w9GacgZ6JHhl9H1NxodWJyD2 B3cfEj8/I5zN+QDhZv0YYJKfNCGXqugkjSyxrObsI5F8WWto49vJQygwzrV3rIQKBihA zAm6aYWZPjWztpSgGJ0spIdVR2ww48OdSgTQFUb7inbcCEVXLi5QB2pN2t5HxpyBzVEy /WrQ== 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=23pDRWaaQIl9vuBcNWdsw9Md3t4Vdcmq2m5SQQ07mes=; b=iIiPYInZGJ3NQzcoy+EEqLUn5VLojb9WVwduPWyq94xKl3MVz1/+23zGV7SlZBZlmz 8itTh2PBavocUofswHZe45UY3dD3H/gvc1/62IztZXf/bGeFElbJU0isvrhZs3D9AIqd PA3+Y8ZziXBVzZEM7TRK8MDC8m9vDwB8GGVu4BBo7bci1O9YsaAlaMzniOrqKZP8p8fb UeAcrczpAGRBKvFDbsIhn28rca+whllzi+309U0CwtfKSfEIZpdlQrVnpmC8Js/nwJgL KIcFNK+kcr9wDF+YWAGYw8oShNgKsgDeDrhDYoCE4Wlg78ZQSLrJibKGI11nqw1FvDPh VhQA== X-Gm-Message-State: AIVw110Y/3JyZaXV2fhxCcKiu40pTIiHq/7GnmIYKTh4DmAZB2erfkRQ uHq4JKKt7LUGPivY9Jc= X-Received: by 10.99.189.10 with SMTP id a10mr15574868pgf.271.1501580098675; Tue, 01 Aug 2017 02:34:58 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id u26sm37147334pfi.140.2017.08.01.02.34.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 02:34:58 -0700 (PDT) From: DY Kim Content-Type: multipart/alternative; boundary="Apple-Mail=_442E609A-0BFD-4F62-B6F9-771B9EBC5156" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> To: v6ops@ietf.org Date: Tue, 1 Aug 2017 18:34:55 +0900 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:35:01 -0000 --Apple-Mail=_442E609A-0BFD-4F62-B6F9-771B9EBC5156 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99ve drafted a wild idea which might fall uneasy to most list = members. My knowledge is rather shallow, the draft might not be free = from technical flaws. Your critical comments are welcome. --- DY > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dykim-v6ops-sid6-00.txt > Date: 1 August 2017 at 18:32:04 GMT+9 > To: "DY Kim" >=20 >=20 > A new version of I-D, draft-dykim-v6ops-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. >=20 > Name: draft-dykim-v6ops-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2017-08-01 > Group: Individual Submission > Pages: 18 > URL: = https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.txt > Status: = https://datatracker.ietf.org/doc/draft-dykim-v6ops-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-v6ops-sid6-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00 >=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=_442E609A-0BFD-4F62-B6F9-771B9EBC5156 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99ve drafted a wild idea which might fall uneasy to most list members. = My knowledge is rather shallow, the draft might not be free from = technical flaws. Your critical comments are welcome.

---
DY




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-dykim-v6ops-sid6-00.txt
Date: = 1 August 2017 at 18:32:04 = GMT+9
To: = "DY Kim" <dykim6@gmail.com>

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

Name: = draft-dykim-v6ops-sid6
Revision: 00
Title:= = Subnet ID Deprecation for IPv6
Document date: = 2017-08-01
Group: Individual Submission
Pages:= = 18
URL: =            https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.= txt
Status: =         https://datatracker.ietf.org/doc/draft-dykim-v6ops-sid6/Htmlized:       https://tools.ietf.org/html/draft-dykim-v6ops-sid6-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00=


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=_442E609A-0BFD-4F62-B6F9-771B9EBC5156-- From nobody Tue Aug 1 03:13:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B963D132037 for ; Tue, 1 Aug 2017 03:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUF6rF-bE_5T for ; Tue, 1 Aug 2017 03:13:04 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0BB13203D for ; Tue, 1 Aug 2017 03:13:03 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u207so6870256ywc.3 for ; Tue, 01 Aug 2017 03:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z9ouWWVfNWfwO4yr5DnfIMO1LazT5hLVYMJ1+5Fpbgo=; b=mjritvY2QQMXZ9HoP33XSYhBb1cqU9CjCAe2/+HDXduYCzxfo2Cfgk+rO3u18/hSs8 8tOkEvYTvrm2snmupFuKpKsDTDg9YDPS0zX+aAjdOK2KFqyDcl/hTirolwu7CWoCC0q3 sUZBEqycHGn+wO+K2anDmU6Pn+JO0qFfS91SRLMyRx9FIoxjWRK61T1cQgsyFkjerv77 PTotg2b97h7kEcWLEqWBGmtTCFwOz8qlNdaZlNLS6YkMUbUcPcS4ZshR3m30UvaGB53k eTk9axEaWL/W393aZ1/Gk8h5MFeCnF8sAuQS0knRYgPHHw608l4baxGpdR1p6BdJr6ze FEXA== 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=Z9ouWWVfNWfwO4yr5DnfIMO1LazT5hLVYMJ1+5Fpbgo=; b=qGWNYGHabOJj6H50m7HXDBGZD5BAvbd+1dwCvb2h2giPmalQc9h7sG0OkmzGwgPqu4 he9jVAc5mvlJYENvkGDYg0JfAloTYKZo3AOxN4MnIwmyPt/bFsFDvBps0v93pfEqqErR kc0wAsidBmpXTFBXj4o9Qe4bDZ1s4lW8YJgzUR/RsouCcR2C9uxMpzne2pULyTLTNdbT G9UVTtygucAmNo+c/Zg/SninBJMCta1rlJ+KHw4Domj+ppoHL8FyI3GQkmoNLN9pbcuK 0W9iaTaePNU2zoQV+CH6/zjEVGlfnWdYIUWVQ9Oe/jTGStX4vs3/U8rciEO2eWN9j5sx fjsQ== X-Gm-Message-State: AIVw1102jAyId2kyHL7bZNWL9nJ0vSBhaB80d4sjWkkYe86YL8FsbF69 lA+XKT0HQMBDLZaC7HXmEsz7OUu+tLIMA5/R3w== X-Received: by 10.129.141.9 with SMTP id d9mr17200441ywg.116.1501582382590; Tue, 01 Aug 2017 03:13:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.38.74 with HTTP; Tue, 1 Aug 2017 03:12:42 -0700 (PDT) In-Reply-To: <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> From: Erik Kline Date: Tue, 1 Aug 2017 19:12:42 +0900 Message-ID: To: DY Kim Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e60128bbae90555ae64c0" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:13:06 -0000 --f403045e60128bbae90555ae64c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The subnet ID isn't really much of "a thing" from a protocol perspective to begin with, so I'm not sure saying this document is deprecating it is accurate. This document includes protocol changes, and as such should probably be run past 6man. I don't expect it to fair well, as (among other things) I expect site-local multicast DAD to be...problematic, at best. I, for one, would oppose this document. Section 4.7 is especially deplorab= le. On 1 August 2017 at 18:34, DY Kim wrote: > Hi, > > I=E2=80=99ve drafted a wild idea which might fall uneasy to most list mem= bers. My > knowledge is rather shallow, the draft might not be free from technical > flaws. Your critical comments are welcome. > > --- > DY > > > > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dykim-v6ops-sid6-00.txt > Date: 1 August 2017 at 18:32:04 GMT+9 > To: "DY Kim" > > > A new version of I-D, draft-dykim-v6ops-sid6-00.txt > has been successfully submitted by DY Kim and posted to the > IETF repository. > > Name: draft-dykim-v6ops-sid6 > Revision: 00 > Title: Subnet ID Deprecation for IPv6 > Document date: 2017-08-01 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.txt > Status: https://datatracker.ietf.org/doc/draft-dykim-v6ops-sid6/ > Htmlized: https://tools.ietf.org/html/draft-dykim-v6ops-sid6-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00 > > > 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 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045e60128bbae90555ae64c0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgrAKzdRjCNyEeCbxyfQJ5rRFJaurDRM/R xLfGNc+LySkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAx MTAxMzAzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAcW90cne0rXTH1nx3kTU6+EVWf40EL3gyyPfizl3HSRP3K21dWm BtW05ar4htsHtOe8DHw0ZIYWdMRcKQhyrXKtHoKpFQe2aoNm4ol4tamsXa0/fhzORjvNvhmxv8NQ E4oLXImQwublWMTQx+9D3lNcOIMN8jIv3WG5uygZd99Z3YTBSxBkAJ1y9fHaoeVBndhnp/I4osqa Bs1CSywUY+OM8QSqgodOkVpTQd2LAvjfTjLJsqOUFjQMf7k//9QZlLkfJ10gFa01c4ZH9rmr9ckX ZnjHp/pkAX1cIm2atXCR525yy1tRu6QkoGs53Zr+jVjFs1l1XXx6dvat2oRShe0= --f403045e60128bbae90555ae64c0-- From nobody Tue Aug 1 05:50:47 2017 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70DB132145 for ; Tue, 1 Aug 2017 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVewqPUytRt6 for ; Tue, 1 Aug 2017 05:50:45 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDA1132141 for ; Tue, 1 Aug 2017 05:50:42 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 77so7249766itj.1 for ; Tue, 01 Aug 2017 05:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=avNbVVEjGXdR9qoge24WToQzELkalWJJ7/yko8DiBr4=; b=CtwQGe0rvuRu+9vIm+bK0384YgGldN8PdnAAXqFT9FMdBhHGO5ydk2vLKZkoxHqz7w n4dSsE7qpRBlYRzrVbMv8fat1Gk6LRmhZz89UunMMrrjtmuEjLmEA1O4xoWVXj0kE+Yj D60V7dVcK8KE16G0ugNuse01a0SK2/Si/RiPR+6cM32RaIvsisFGUJhB78oEzzkJH3aW Vh2vfNk33RzbZoHxv6UlFDFbI5TiFC+TN/64nP7NcqShqdcAdWzS1JvvoEbuQ+LRpAPF KXSKJ0oubARRlTAOFGWxhbxwc1zm6/GI1A4tY31TC+qr0l9iZB4w2kJDLvmccEDs6+/H EjYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=avNbVVEjGXdR9qoge24WToQzELkalWJJ7/yko8DiBr4=; b=aRJ/Vr9l0+7pKI9H+PCOtVC7bLlAO03EuUQICejqbwU5QGQdsSGk3f9Ele+Xumuc+5 dVfhgZYhLtEquHikko1ix0yZhTKu2GIoRjurs3lf3cIP5v4pL5L/WXLyv4z1RAg7Q2Y9 mdm+hQrO6VMe+FhFqSXmzf5bgq5PdzzbenFkr1PwyHv+R5S1jzs0R0TXk4ZbgftijMh0 bm8GJQw7+PkIlFIexQl3pV4KfmlU2HFuy1GjUGZnWG3p8YLq7N/yxXwXnoX07nSBdSZn NAd0Q56DLhKPPdlEQMCmENVx1EkBoxUOAMBGGswCf+wPpQs1Zx7SCZpKftyV8BYOLMTM cOVA== X-Gm-Message-State: AIVw113r7YEPf7NFowK6jxJMlB3nD1jSWNh/pvYR530nfBN3alnzccTQ 1y2HeZIMau0vyQ== X-Received: by 10.36.16.143 with SMTP id 137mr1713430ity.154.1501591842065; Tue, 01 Aug 2017 05:50:42 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id r21sm707046ita.16.2017.08.01.05.50.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 05:50:41 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Alvarez, Pablo'" , "'IPv6 Ops WG'" References: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> In-Reply-To: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> Date: Tue, 1 Aug 2017 08:50:28 -0400 Message-ID: <013501d30ac4$c79fc200$56df4600$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHz4IkBavDQVhiNn9yksu65eu0kL6ItyEmw Content-Language: en-us Archived-At: Subject: Re: [v6ops] ICMP rate-limiting in draft-ietf-v6ops-ipv6rtr-reqs-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 12:50:46 -0000 > o SHOULD rate limit the generation of ICMP error messages > with a token bucket method as described in [RFC 4443]. > Rate limits SHOULD be narrow enough to (a) protect the > device's ability to generate packets and (b) reduce the > usefulness of ICMP error packets as part of a distributed > denial of service attack. Limits SHOULD be generous enough to > allow successful path MTU discovery and traceroute. For > example, in a small/mid-size device, the possible defaults > could be bucket size=3D100, refill rate=3D100/s. Larger devices > can afford more generous rate limits. I'm happy enough with this text -- I'll add it to my list for the next = revision. =F0=9F=98=8A Russ From nobody Tue Aug 1 06:24:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E8127868 for ; Tue, 1 Aug 2017 06:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf5_KxDPHalF for ; Tue, 1 Aug 2017 06:24:22 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FA0132165 for ; Tue, 1 Aug 2017 06:24:19 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id p68so9826052ywg.0 for ; Tue, 01 Aug 2017 06:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ibvpVuKpmJCOqw4f9kupkHPRWD8cuTwEDJRENR3d9pA=; b=n5gcqpitrs5CQbcKYNbFp9gfna5X+HzpWo64l0BMXa8TLHV/IWW47PFDcWSbpHQJss N1xLkHUvSBm8WEbBQ2Hg+YdaNMbWZ6PEgCCpXKCePo5PGQ4yBfkVSH1m1XSur2siHrRW w5vfk0o7+TzYwujBUiInGSKc1UVCHqm9EAUFDlHN5GiCSPPzErWlWiA39iU5buRr6bQD p76pul5FnBjGk3RmcuP963jK2PUbUir33kEwiN769OdRRq4P+oO1VX1XavJU0D2ANOYg 7H0CrCFpT2DdrsQz+us7rs31kjkiy+uOo65/lZe2RqLib3SOVrrEeHA9Mp3ES/4HHqhu j9rQ== 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=ibvpVuKpmJCOqw4f9kupkHPRWD8cuTwEDJRENR3d9pA=; b=sS3UgCrQrOgNedDvo6BVUApUFSsgEQNiisvvwjbU42ZToY4dCFJwj3R0pdw5yc0mpy f2YuN1tGNeT+wF2hL9axPQJtfHaB8tQMMtRHWTMxO5H2zxEFm2LZLYTIpq/eZQahPtPo VRCSMslie/vyWVUMTOX2+GOmmS7ySueadF4Q+XJ2fsAm8CEoyVSUmYuBLgcCF/eIRGCQ HteNwtGmpyBSQP0j2JJIriKverjXP9dJbCSxC2+dJJtJi+rlSP6ebZ3zewONHfTBZhWE I2mZxpGCSVzHnSmSNeo7p+hokKpAk5ZYKeHLS8QwOEMVxmKk4SubyaAb6PyZz6bxC0VI XB9w== X-Gm-Message-State: AIVw113h+K22UQCgA3lmO+y3HW6NjWfHpZGS94IeIsfocXCBPpTzCLnl 9lFkf+qGdWyeQqgT6uhb1jK2/KJKx6Zu X-Received: by 10.37.203.70 with SMTP id b67mr9083034ybg.209.1501593858437; Tue, 01 Aug 2017 06:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.38.74 with HTTP; Tue, 1 Aug 2017 06:23:57 -0700 (PDT) In-Reply-To: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> From: Erik Kline Date: Tue, 1 Aug 2017 22:23:57 +0900 Message-ID: To: DY Kim Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0566b08ff6120555b1109a" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:24:24 -0000 --94eb2c0566b08ff6120555b1109a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 1 August 2017 at 19:12, Erik Kline wrote: > The subnet ID isn't really much of "a thing" from a protocol > perspective to begin with, so I'm not sure saying this document is > deprecating it is accurate. > > This document includes protocol changes, and as such should probably > be run past 6man. > > I don't expect it to fair well, as (among other things) I expect > site-local multicast DAD to be...problematic, at best. > > I, for one, would oppose this document. Section 4.7 is especially deplor= able. Uncalled for; my apologies. I should simply say "objectionable". > On 1 August 2017 at 18:34, DY Kim wrote: >> Hi, >> >> I=E2=80=99ve drafted a wild idea which might fall uneasy to most list me= mbers. My >> knowledge is rather shallow, the draft might not be free from technical >> flaws. Your critical comments are welcome. >> >> --- >> DY >> >> >> >> >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-dykim-v6ops-sid6-00.txt >> Date: 1 August 2017 at 18:32:04 GMT+9 >> To: "DY Kim" >> >> >> A new version of I-D, draft-dykim-v6ops-sid6-00.txt >> has been successfully submitted by DY Kim and posted to the >> IETF repository. >> >> Name: draft-dykim-v6ops-sid6 >> Revision: 00 >> Title: Subnet ID Deprecation for IPv6 >> Document date: 2017-08-01 >> Group: Individual Submission >> Pages: 18 >> URL: >> https://www.ietf.org/internet-drafts/draft-dykim-v6ops-sid6-00.txt >> Status: https://datatracker.ietf.org/doc/draft-dykim-v6ops-sid6/ >> Htmlized: https://tools.ietf.org/html/draft-dykim-v6ops-sid6-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-dykim-v6ops-sid6-00 >> >> >> 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 submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> --94eb2c0566b08ff6120555b1109a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgnBGeoEIrARcbeWqiiiqvg6lempGFQ4hf sWHSQ2/PNmYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODAx MTMyNDE4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACoEhwHhdCIw3xTUtLV4LOqET6B0w3getma7TWI74JWdwRBGh3B5 9SJ5CfnWFrpLFXTFO4bRbj5IdfJL8iiV5gqpGlSIwwqHWgXHY7hW6/wt4M4812hH5qdxCc0dAA7I uRzLEG6EGD+i12xEMQrgqr4bfeyNxYgXVGDG4Qt6lRUC0Q8N1GAFmq0i9OjFCX/YenDiqnub9wYJ 8fAgMTi9IPt/ZkBt7bwgP22coanq/lkPH5rgXo8De2dZdoClDD6SWb6KAG1qv55lXgmVKWlG0s2Z EC1voDay0lSScNtMSwz3FTIu4I730z41NoA5EaMc4YVDY8ZMG93B4lJEbSagfB8= --94eb2c0566b08ff6120555b1109a-- From nobody Tue Aug 1 07:51:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D49F132151 for ; Tue, 1 Aug 2017 07:51: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 YEj3YB8J5KKW for ; Tue, 1 Aug 2017 07:51:48 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB709131B99 for ; Tue, 1 Aug 2017 07:51:47 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id 33so7870331wrz.4 for ; Tue, 01 Aug 2017 07:51:47 -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=CtQo4WEPttw/FSQDGNKQ1ea3DVWs/awIS6rF3OA+1/Y=; b=GRVA3DOObOERJ0xbaAhf1h+v/GG73+kjONeXehPT7MrJNBHciUQaYrNMEMWYi81Wb+ Ufl7aPdJqO7So/OhYL1r5CJrgYUSad4lgciSzGZ3bfYljcLBiT1RQpLjaHV3/xsGgefO fJZS5j8LgLbs37yY6GHcmRku+o3NFymJcePS/gby6AWPR8s7fe+jq6EgZ/fmpcgQ7utB ljGCaoOhYMFQK8hzdbhFKzSYLmMOGdhmEnmVeC0ATrqB9ZBEp1H101BnDnGItVu7p6hd L/W80MdaNO+dLzlI1HhgxjkOYiysbhY3JBZd3f7AQflXjDh+Y+hHGmAtFe9liVUsrur+ v8aw== 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=CtQo4WEPttw/FSQDGNKQ1ea3DVWs/awIS6rF3OA+1/Y=; b=qGedZ5t6gpqtfTmBoUczBaqQZlpV4G4e4dShtq9gvBrMoVpek6BpQFBhKfdfSxLwv9 pdpTlgagqcrmjh8IVW5MO+KiGT0z+qYaMDhq0B5DuwEaxSbUu58QJNuGe40StajG+I+H tgfWZjdcnRVVhYLCaMjIhbqQw8Nlgq188Hzf5q7OGJF+6xHkHVjJLwyCW+QkWuTPouKo iuMxlfRv/QRT7zPRshU1BgBQETDBvOyztyHcy/ONGedcZlfH5G6cCtQItQ7ynR47kFxP sn18NT9NjFPqhy9pST2AYoktPy4CjLT071IN40HgxldRnq+WBCejIzluofP3EMKywScJ 9L9A== X-Gm-Message-State: AIVw1131lrkcYc/wAPVSN0awn9JimFx+dJ7ogVLDZa/43MC5hPT3bxXI 6cs2awHSInRsAAdeo3U= X-Received: by 10.223.163.199 with SMTP id m7mr15478727wrb.128.1501599106146; Tue, 01 Aug 2017 07:51:46 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1c7c? ([2600:8802:5600:1e::1c7c]) by smtp.gmail.com with ESMTPSA id k13sm7352913wrd.4.2017.08.01.07.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 07:51:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: Date: Tue, 1 Aug 2017 07:51:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:51:49 -0000 On Aug 1, 2017, at 3:12 AM, Erik Kline wrote: > This document includes protocol changes, and as such should probably > be run past 6man. I have just read it. I would agree; it updates RFC 4291, and by = extension 4291bis, and should be discussed in the same context. We will = need to point 6man at it. That said, I'd suggest we collect operational viewpoints before we do = that. Erik has given his. Other comments on the draft? From nobody Tue Aug 1 07:52:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C2A132198 for ; Tue, 1 Aug 2017 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqATaRfNwTGz for ; Tue, 1 Aug 2017 07:51:53 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E5B132197 for ; Tue, 1 Aug 2017 07:51:52 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v105so7919358wrb.0 for ; Tue, 01 Aug 2017 07:51: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=4emGOBBE8BG/S6jRhUQ6Iz4pv7xKr2Us7UYP9aqSOwI=; b=lVuqxqGbR0BXo5rAwH0agiPUaXiAFnLIRnaeyOltRwaChpf2+EjlVAEHvVSKPrNaiK JobtPuWv9jlWYPpVuQS7p99cjHQ8odtjPNRj2kNq8DMbDPsvLOshkRsy1BFlmWl5EYEl FNtMMKgAf0oEizs/Pbn1CJA5MWf7JMr5YUe4M1A9r6LxLEPPqPF135UEzaNftwX0hXxi d2MzsEpb2D27Z0J/Rk9bR4jOr5YmAsCp5b330iL0vKPP9cK2Amk9WrygNEZc5D4tUDxh V0v5tb038mHK3rRtYrneY84dJYyI8zpJYo4tm/ucnULTvzVx9mMTtjp+JRD/6GkLhmBQ Abnw== 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=4emGOBBE8BG/S6jRhUQ6Iz4pv7xKr2Us7UYP9aqSOwI=; b=SPaYOm1BCiKDCJIM9o9fdL7jeY70ND07tE7eyeID2T4Vkhv7YIwpIWB4/sCt28dflF SzQIkFNWUbPELMzjy2FdJT/xclo0WtdFIKZMAlPdtq5a94kIgxNpR/hFzWhzgd/mfomP XtDWcQO17l7ViX35R16DEB/orssPs1JK+Pdwz+XCjvpxFk+KGQOjDnSECqRLqk5S+K/m WS68yC32cg7dVJoiM2izdNLu9g0ZEgj5E9sgXZzr3OoeCrV36ihbz+G8jMou8hgZutYQ 1KYEc+eYB49QLRPddmGqk71M6B461Fy9tdXbm6VoQdXOhT26Gw+hZaaDqQIsOpkmBkC2 UbEQ== X-Gm-Message-State: AIVw113ox3b0kH7vg7krLd458pmCWqFF0dnUModW4SxoyJZuQIKzmVLM RKR/KdqfbVaLMw== X-Received: by 10.223.134.39 with SMTP id 36mr15759220wrv.244.1501599111228; Tue, 01 Aug 2017 07:51:51 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1c7c? ([2600:8802:5600:1e::1c7c]) by smtp.gmail.com with ESMTPSA id k13sm7352913wrd.4.2017.08.01.07.51.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 07:51:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> Date: Tue, 1 Aug 2017 07:51:45 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: DY Kim X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:51:54 -0000 On Aug 1, 2017, at 2:34 AM, DY Kim wrote: > I=E2=80=99ve drafted a wild idea which might fall uneasy to most list = members. My knowledge is rather shallow, the draft might not be free = from technical flaws. Your critical comments are welcome. This draft reminds me of the behavior of DECNET IV, which had systems in = "areas" that were potentially discontigous and not on the same LAN, = which were then interconnected by intra-area and inter-area routers. = Often, every host was configured as an intra-area router, and knew the = path to every other host in the area as well as one or more inter-area = routers. When IS-IS was being designed, Digital took its experience in that and = designed two layers of routing - host to host (identified by the full = NSAP less the final NSEL) within the area, and area to area (using the = NSAP less the final NSEL and the Station Part) within the network. = Networks (identified by CLNS NSAPs without the last 9 octets) were = interconnected by a separate protocol similar to BGP. So, could this model work? Yes, it could, with the appropriate routing = protocol within the network identified by the prefix. Could it scale? I = would think that Digital's experience was that it could, with = appropriate operational management of the network to make that happen. That said, such a change would be a fairly violent change to the = structure of an IPv6 network. ND Host Solicitation and Announcement as = currently designed is mostly-pointless, and has to be replaced by = something conceptually similar to the intra-area level of IS-IS, using = one of several algorithms, and potentially different algorithms in = different areas. It changes the address from the address of an interface = to the address of a host - which is not automatically a bad idea (and = for many hosts is perhaps not even a change), but is different and needs = to be thought through. So from my perspective, this might be an interesting experiment, but I = couldn't recommend it for general deployment absent the supporting = routing work.= From nobody Tue Aug 1 12:26:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6952713215C for ; Tue, 1 Aug 2017 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsNSu37pXhsZ for ; Tue, 1 Aug 2017 12:26:47 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 02D93126C0F for ; Tue, 1 Aug 2017 12:26:46 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v71JN05Z001529; Tue, 1 Aug 2017 20:26:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=1d03LYGItekdAaaf9s6nUtkRZOf9pePk74raXhlane8=; b=aTAxz6/pSzl9WMSn15zhT6c4JFJ62OvE0FpP6sAbu46MvjnDZtlniME+xRsE3zDSJkX0 cg2QyXUPUKGLXA0tqfvu7XEf9HM3tABIjgEe5QTP9TmfA/i4L9PB/xHm/XZPfWf77yYI sssi45co1vcpXAx6zD/dh4IJKUGJXsjjEt5zoPYJ7SpklrygisakPIDTcN7WajT1aqZk rIUq6r1QMW6Kh2L/8IXbcDNTR0ebCdQ/F2ADfRw0U1ku4vRDKraE9zfwSlVx79dSlUTn Zzsf2Rez1kYL3TNKIssH3JmK36WPTmYIbo1JIUIASd6oR8hquKSp7bwOYviLVGFZ1RsQ vw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2c2sxnj2t1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Aug 2017 20:26:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v71JQXKY012530; Tue, 1 Aug 2017 15:26:43 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c0npvrk3m-1; Tue, 01 Aug 2017 15:26:43 -0400 Received: from [172.19.42.232] (unknown [172.19.42.232]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 0EEB020067; Tue, 1 Aug 2017 13:26:42 -0600 (MDT) To: Russ White <7riw77@gmail.com>, 'IPv6 Ops WG' References: <539ae305-841b-8020-e509-62135de04b4b@akamai.com> <013501d30ac4$c79fc200$56df4600$@gmail.com> From: "Alvarez, Pablo" Message-ID: Date: Tue, 1 Aug 2017 15:26:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <013501d30ac4$c79fc200$56df4600$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-01_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010315 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-01_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010314 Archived-At: Subject: Re: [v6ops] ICMP rate-limiting in draft-ietf-v6ops-ipv6rtr-reqs-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:26:48 -0000 Thanks, Russ. What about the clarification to the first bullet in #5.4 (I will save the discussion of ICMP ECHO filtering for a separate thread): ---- I would also like to suggest the following revisions to the first bullet, to clarify what types of packets should not be filtered: Proposed: o SHOULD NOT filter Destination Unreachable or Packet Too Big ICMP error messages by default, as this has negative impacts on many aspects of IPv6 operation, particularly path MTU discovery. Current draft: o SHOULD NOT filter ICMP unreachables by default, as this has negative impacts on many aspects of IPv6 operation, particularly path MTU ---- Best Pablo Alvarez On 8/1/17 8:50 AM, Russ White wrote: >> o SHOULD rate limit the generation of ICMP error messages >> with a token bucket method as described in [RFC 4443]. >> Rate limits SHOULD be narrow enough to (a) protect the >> device's ability to generate packets and (b) reduce the >> usefulness of ICMP error packets as part of a distributed >> denial of service attack. Limits SHOULD be generous enough to >> allow successful path MTU discovery and traceroute. For >> example, in a small/mid-size device, the possible defaults >> could be bucket size=100, refill rate=100/s. Larger devices >> can afford more generous rate limits. > I'm happy enough with this text -- I'll add it to my list for the next revision. > > 😊 > > Russ > From nobody Tue Aug 1 15:23:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD69129B62 for ; Tue, 1 Aug 2017 15:23:55 -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 KoNHh14XEvqW for ; Tue, 1 Aug 2017 15:23:54 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D007E126CD8 for ; Tue, 1 Aug 2017 15:23:54 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id t86so13095920pfe.2 for ; Tue, 01 Aug 2017 15:23: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=5Ck/mLaQJPGrCHy45m1osevuwpFuXBAwzizbMw7W8MA=; b=fhvdxKwcNcMhENitolrU6KYG7LjflNyEO+lKk0Z72rsyJksTFM+C7ckV/ByixKbwhn 0PpzJtP5xLH5+42eiP9sglAz0WRQ0K+l6bMCJl9Ngq4kHIHSYnzo+iEvX0SEqsJzq+i1 h82l0rZ7a57LySDd9JS9bFu7HSXUdWAMt//XcTGFlDzol0yXfpn5kdTfBSI0EG3P/mOv ozpZbqLou/lN/444nDE1J3TdDVu1T+fw9/WvHU42Bj7BSVFXlEgg7LfotiyKYxGqwk9R 235A5PjPOYDF7zHHE4aLMt5L/FefuEFtRgnPnprRlRt0rsTTW+f6RpHLhYpuXFDbFeL7 IcdQ== 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=5Ck/mLaQJPGrCHy45m1osevuwpFuXBAwzizbMw7W8MA=; b=GVqNjaZkUJyAbnUnpgfkbulfHDXSqbh+HlYWpY72PZi1f/EeQAzlUQzk1WSBERzORq v5naIBbvEuzIXuaAy1+QnN9zDuwvZ3Yiijr6ReZjpb1gAMjWP4JuaySskEPcpKpPvIMc gdv8hPr9jenq2+AQgdJBnEPN2JJAdVZmE6m2mHtxBe9ok7iOfrknA74ZkU/Sv0dnNcr1 guULbI6ZzlRoChZlzWj+PXZ7rRYEs0Zjb1d+obl3Rd34Wz8d8BjqDLsRpiZrp6FPuVJr x0XY4s/IOSGzkNqxlMk6w3ELRt95EQ8QBjG0PpFY5xQaQibTXMkvGktmzy+lsyWUby6x vulA== X-Gm-Message-State: AIVw113ErCRmFSAH5ZxwZO4C9q283meKwjQv9qkNyn/vTNdc9rvpMl1B yociLfe0AFF+Gg== X-Received: by 10.84.231.142 with SMTP id g14mr22620085plk.424.1501626234291; Tue, 01 Aug 2017 15:23:54 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id u67sm15112880pfd.164.2017.08.01.15.23.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 15:23:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 07:23:50 +0900 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Erik Kline X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:23:56 -0000 > On 1 Aug 2017, at 19:12, Erik Kline wrote: >=20 > The subnet ID isn't really much of "a thing" from a protocol > perspective to begin with Really? I think Subnet ID is what makes IPv6/IPv6 peculiar enough to = differentiate their networking paradigm from other architectures, and = that in a negative sense, at least to me. > This document includes protocol changes, and as such should probably > be run past 6man. I=E2=80=99m not that far to ask =E2=80=98change=E2=80=99 the protocols. = For now, I=E2=80=99m just seeking opinions from the operators or users = of the IPv6 networking=E2=80=A6 whether it=E2=80=99s any idea to pursue = further or is just another trash to throw right away. Only when there=E2=80=99d be some encouraging support for the trial, = bringing the material to 6man would make any sense, I=E2=80=99d think. > I expect > site-local multicast DAD to be...problematic, at best. Here=E2=80=99s where technical debate might be in place=E2=80=A6 > I, for one, would oppose this document. OK, got your opinion. > Section 4.7 is especially deplorable. Regretful. - DY - From nobody Tue Aug 1 15:31:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC60131CB2 for ; Tue, 1 Aug 2017 15:31:11 -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 Qo7e46i9DcWM for ; Tue, 1 Aug 2017 15:31:10 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95751131C8E for ; Tue, 1 Aug 2017 15:31:10 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id d67so13257880pfc.0 for ; Tue, 01 Aug 2017 15:31:10 -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=QvV1aAlwPNbcDMaeTVL6EP1xUsESP87cf7bigsjmOGk=; b=mZJNf+GxDgxgPPF8evoRnPa7VVQYkAzjBrU6ZKDpZYkczfI4U0DUx5F059IvnvRXe4 OIJkOucEutNB+8/nUlO/2NJtnK2p6d7FznCM+Jzpi0ukuDS5lEC0Llotyswa7NO589mB fBzuTDQoP0sxtk2Dlk9hYQiXZKA/0Z3Y0DDHN9XNt0ZKVGAzurW0mItK+qCTuyFNGmnw 4/5ENb3SGh6eOUnn2paoOuQcoYn+SRwbbddxESNULxrpdmcHkTvHhh5fMNzJzJw6XSAh YJFRAy3wzhkavWV1W2Pl32vsiKjZFGam8ZOpiQtaKOaBsQyVk38uQum99UCbcrG3vvoX meDw== 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=QvV1aAlwPNbcDMaeTVL6EP1xUsESP87cf7bigsjmOGk=; b=XYD2SablUA+7fTQU1EcADrA9ACDjqOFU7H0hmMYzvnpZ5Nr4LxBtesSE5W/R+srGod hrdNvthgdbPKs0Mko5Vd62r538SAKTV5enY9auMBwY4Eb5z0p6wGaIYguqSs1cI/1gVm CvTelofGnnAKPn033SNOq/6WJNp9U12u2qW0yVOtUwGUHTNgMfmu6eXpa/Skc/doBpLx D8C7z46G9Ty2+aj11IURmp/g+BuVY0vVO8zYe3vQmN65uH7F+K/Pv+vMjHeG9zQrmVSK hxdBJhu/QSqFiMXkkmaGcNc0B1Fhpa4gJ63scgdGDpkIVLgLSUfr6hqRPYN0SGU6eEgu psMg== X-Gm-Message-State: AIVw112/7Jj+Vj4Cpox00NQOY3G78/7zkd56FmsiuEhkXM8lN2zSFKBD v0HbQVT5XEJfxQ== X-Received: by 10.84.233.207 with SMTP id m15mr22738269pln.334.1501626670147; Tue, 01 Aug 2017 15:31:10 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id j29sm67720043pfj.68.2017.08.01.15.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 15:31:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 07:31:06 +0900 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:31:11 -0000 > On 1 Aug 2017, at 23:51, Fred Baker wrote: >=20 > On Aug 1, 2017, at 3:12 AM, Erik Kline wrote: >> This document includes protocol changes, and as such should probably >> be run past 6man. >=20 > I have just read it. I would agree; it updates RFC 4291, and by = extension 4291bis, and should be discussed in the same context. I=E2=80=99m afraid, not yet. RFC 4292 is the heart of IPv6, and trying = to change it before any strong consensus is built first would not be a = good idea. Also, I tried not to mean direct change of RFC 4291 (or -bis) but just = different =E2=80=98operational choice=E2=80=99 or =E2=80=98interpretation=E2= =80=99 of that base standard. If any, changes would be on ND and DAD, not directly on RFC 4291. > That said, I'd suggest we collect operational viewpoints before we do = that. That=E2=80=99s exactly what I=E2=80=99d be seeking at this stage. Thanks. - DY -= From nobody Tue Aug 1 16:01:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABAE131CEE for ; Tue, 1 Aug 2017 16:01:56 -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 mZ-ce1yLGQ8h for ; Tue, 1 Aug 2017 16:01:55 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 916AC126BF3 for ; Tue, 1 Aug 2017 16:01:55 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id c65so3879526pfl.0 for ; Tue, 01 Aug 2017 16:01:55 -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=x+oBRBbBRt5Dcc3WhYupTWTN5JWPQ032fwUxVWUeetM=; b=U0jZlU4pS5c3PK3rkBCk6YJxpLtZhlF0VOfsxiClZ35q6FK5tmOSRfM5FklmViZe8N +MHaLop4ttSvvmrq9ciIVaJp/3DrdH18gyfem0pfD20Z4zrpFGjW8OzUeY3Q4vVZD/2f MgrFP1C9QtrL/bc1+pVzNO6feidhCdw2v6jEgpvXUSTckehFJd7mFo5yEPFpVChGDOCf kC1gzTxra3PXnCN8eYEmG3V/paJhirG3I/IBZ2QqwmjSPouiTzvYL1x0xoYYQ7qn+YHK 6LmztBLoA7beY8QUd0gb1q/Rs0pghztbuScraNAc4CmNpVmWwFEoR+n+t4EiBIzC9BVz H64A== 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=x+oBRBbBRt5Dcc3WhYupTWTN5JWPQ032fwUxVWUeetM=; b=Ks4+2elHvQuFEJeuK1lavEyHnITd0dR6e3HiqjCNdwEt75LTCYmftSrs9Kon/gNRDD HGXe2Py2c/q/jGcFyRcBCnSijMROarKvcj8jEfzTFF1XhDMZj1qunXYbSu0RGXfPYpWj rkGPS2jKPb2eVyysU/IlDVhqDrww990n6+UcIC6DDNBcWyHo39kqb0dUJ//MEKj/nk9p rf+R+RrREGFcWziiPJLmr1XsAt0qlHksQV03fQ3AVUnn7NW3mB9vMydlDmok/JTDdShg 8QjgtxlL1MfX3ziLxuPmsTTrJuZRl5cqEzQwBpPn0qGY0yMzWylmR83jFNXcJQ9SO+XR O2Ig== X-Gm-Message-State: AIVw111HOws0ljw6Xmf5uWL1Mf4SL0HywnYbfOdkXmw2vzMhfop7/4ah CWX/RCevWRObqg== X-Received: by 10.99.130.72 with SMTP id w69mr21032380pgd.70.1501628515053; Tue, 01 Aug 2017 16:01:55 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id k185sm58669152pgc.31.2017.08.01.16.01.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 16:01:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 08:01:51 +0900 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 23:01:56 -0000 > On 1 Aug 2017, at 23:51, Fred Baker wrote: >=20 >=20 >=20 > On Aug 1, 2017, at 2:34 AM, DY Kim wrote: >> I=E2=80=99ve drafted a wild idea which might fall uneasy to most list = members. My knowledge is rather shallow, the draft might not be free = from technical flaws. Your critical comments are welcome. >=20 > >=20 > This draft reminds me of the behavior of DECNET IV, which had systems = in "areas" that were potentially discontigous and not on the same LAN, = which were then interconnected by intra-area and inter-area routers. = Often, every host was configured as an intra-area router, and knew the = path to every other host in the area as well as one or more inter-area = routers. In SID6, not every host is configured as a router. Some of the hosts = form a subnet (as usual, albeit with no extra explicit subnet ID) = managed by a DR. For communication with off-link hosts, the hosts in the = subnet would rely on the DR for relaying. > That said, such a change would be a fairly violent change to the = structure of an IPv6 network. Indeed, effectively=E2=80=A6 That=E2=80=99s why I said =E2=80=98wild=E2=80= =99. > It changes the address from the address of an interface to the address = of a host. This is exactly the core of my proposal, which I=E2=80=99m afraid might = be too hard/harsh for IP networking advocates to easily accept, I=E2=80=99= m afraid. But, were the IP address not the interface address but the node address, = would there have been such a hype or need for identifier/locator = separation efforts? What I wanted to show is that, if the address points = to the node (not to the interface), the problem space of the = identifier/locator separation could have been a non-problem at least = within a site. .. and what about the inter-site (inter-AS) mobility? We could live with = MIPv6 for that, since infrastructure-less e2e connection resilience in = that case would not be a compelling requirement for most networking. To be put in another way, I=E2=80=99m trying to say that IPv6 is just = fine and very fine only if the address is the node address. It doesn=E2=80= =99t need to be exposed to attacks by identifier/locator advocates. Any = identifier/locator proposals add substantial extra = infrastructure/complexity to IPv6 networking, and for that are almost = equivalent to change the whole of native IPv6 networking. My =E2=80=98wild= =E2=80=99 proposal for node address might not be as destructive to the = native IPv6. This is the message I=E2=80=99m trying to deliver. > So from my perspective, this might be an interesting experiment, but I = couldn't recommend it for general deployment absent the supporting = routing work. Although my document comments on protocol (ND and DAD) changes and = deployability, that=E2=80=99s not my intention to push too early for = that direction. All that material is just to demonstrate the technical = feasibility/implementability of my proposal, if people might want that = direction. All I=E2=80=99m seeking now at this stage is to see whether there=E2=80=99= d be any experts in the field who would find any bit of value in the = proposal and would be ready for =E2=80=98experimental=E2=80=99 = exploration. I=E2=80=99m not yet proposing any serious action. - DY - From nobody Tue Aug 1 18:42:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9F129B10 for ; Tue, 1 Aug 2017 18:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyfX3KIfCINa for ; Tue, 1 Aug 2017 18:42:12 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFC612942F for ; Tue, 1 Aug 2017 18:42:12 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id f21so12972252wrf.5 for ; Tue, 01 Aug 2017 18:42:12 -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=GksUMCbuoq+D6NZhUZONyFeO7s+mYNfYFJx71GwzXxM=; b=nGPT/3ZMpu2GQsFcju6Z1EynG2Rj0EUXO7etD1IH+QIn1GfyDBIXPXEkBF4ztiT2lR GNb7eY359yVfQUA8/pMFNX82Z68GgPx36Ik2FnvoLyF8Udz31t1E03aDYuaFY9ekb567 L6/WVIs+1aWtkFiehHPcJtugFLwLnY7dWTnzQIIAAkcq32SswTRI7CzSRT5ixLf9t/DF e0uqfs66jHUkCMk0Wk8ETI7J0HsQ6T7I4gcUhvg4ufmnzMUJM0SwhQWLT8fM0oyjqHiL k20e902tHPz+spvWgbnqbHixYaj5KITSnnzHBVFxcNhN5/JDE2SWEuWcIw58aQeoex4R Vcfg== 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=GksUMCbuoq+D6NZhUZONyFeO7s+mYNfYFJx71GwzXxM=; b=cSKhGL7NcZlajPcEChDpOaq9NthjhPaDJQn3WLwSKLj+LvO3FMKM1ihbTGedn8gxqv 6sWCpcthhYawQV4qQtDjwx03X4smkto0n6YZqfefJFYKx+JUpglDJLjeVAqQQ67OPHnC vW70CKp0b145r8N4XXNe1zs7Y7yEN3RciwlyCCR8oVdLwMUSIJbGOdu8dfk1rzcPYkc3 hbzvjQixMVYs9pi8i/luQOnMPIiq6/8X99omvL/eUkweq92uVSKfKF0y1Zya9AQHaOM8 iZGXhxpIiB7tqvLMFDZJxlHyBwc9NoUaAGN3WlHckb5XTk/4W0ugk9VZ3SQvfURzAW2K N3Mw== X-Gm-Message-State: AIVw110/R7HGSPfAIayLfAWfp4MxNmg+dAftsZHOaakN9yN0Ov2odw7M 4LkTsDNOCdiSDQ== X-Received: by 10.223.182.130 with SMTP id j2mr18920685wre.254.1501638131073; Tue, 01 Aug 2017 18:42:11 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1fcc? ([2600:8802:5600:1e::1fcc]) by smtp.gmail.com with ESMTPSA id k46sm16425294wre.1.2017.08.01.18.42.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 18:42:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: Date: Tue, 1 Aug 2017 18:42:04 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4722F8C3-2D81-4F05-8CB2-AA560B92C9B8@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: DY Kim X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 01:42:14 -0000 > On Aug 1, 2017, at 3:31 PM, DY Kim wrote: >=20 > Also, I tried not to mean direct change of RFC 4291 (or -bis) but just = different =E2=80=98operational choice=E2=80=99 or =E2=80=98interpretation=E2= =80=99 of that base standard. Well, again hat off, I think you didn't succeed. If devices are on = interfaces, ND (which is designed around shared LANs and therefore = interfaces) works. If devices simply "somewhere in a network" and the = network is other than trivial, you need something a lot more than ND, = something a lot more like IS-IS (although the algorithm could differ, = and could be different in various parts of the same network). We're in = the process of taking RFC 4291 to Internet Standard, which implies "no = changes other than removing features not proven interoperable". That's = not an "interpretation".= From nobody Tue Aug 1 22:55:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC331288B8 for ; Tue, 1 Aug 2017 22:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m4I-pcLoomU for ; Tue, 1 Aug 2017 22:55:06 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EB3126557 for ; Tue, 1 Aug 2017 22:55:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 60E18A6; Wed, 2 Aug 2017 07:55:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501653303; bh=xPFHYsg2fCoWKXgWBWyPGslEkhYN93IqCV/Nf6cjRy4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Us6SXF/rmVVxCNPXgtuqBPYBTjY4g3KK53H8jXHWUOHuVfiyBwJcWpHoK7LCMzvwk N4Yw9bb+6Cpm/SzReSRUUttx4Ka4TOvRHrWGeoxot2dt8k4vnr6Tatb6lHMykm1E9n U6zy0AdNiN/ONR3hORyLtkdvxpk8UnNOWxjdasDg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5C8D0A3; Wed, 2 Aug 2017 07:55:03 +0200 (CEST) Date: Wed, 2 Aug 2017 07:55:03 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: DY Kim , v6ops@ietf.org In-Reply-To: Message-ID: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 05:55:07 -0000 On Tue, 1 Aug 2017, Fred Baker wrote: > So from my perspective, this might be an interesting experiment, but I couldn't recommend it for general deployment absent the supporting routing work. I've seen proposals that have intersection with this proposal. There was work to support L3 mobility in for instance a home (by injecting host routes in the home IGP) as devices moved between L3 wifi APs. The whole proposal about whole /64 per host so this can be moved around also touches on areas close to this I-D. Here the entire /64 to a host is a similar idea that doesn't mean anything needs to change in the host. IS-IS and ES-IS has the interesting property of the end systems basically "registering" their addresses with the router, meaning the router doesn't have to do discovery. It already knows the systems on the wire. If we disregard "quiet systems", IPv6 also has this (there have been proposals that routers should not initiate ND, but instead rely on systems being alive and talking to the router so ND table is always populated). I-D-sid6 seems to propose moving addresses around. This is not compliant with RFC7934 (Host Address Availability Recommendations). However, combining things like I-D-unique-ipv6-prefix-per-host with I-D-pioxfolks-6man-pio-exclusive-bit with probably some other mechanism we don't have yet, we would gain "fast attach" with stable prefix to assign addresses out of. If we're moving prefixes around then we need to somehow be sure that the attaching party is actually who they claim to be, and we need them to start communicating very quickly after attachment. The 1s DAD delay is one problem in this that the PIO-X bit "fixes". What I'd like to see is a way to very quickly attach and start communicating. Brainstorming list of events: Device attaches to AP. Device sends some kind of cryptographic identifier/token/certificate saying "trust me based on this, I have this address" Router/AP checks certificate If accepted, install route towards MAC address of device. This route is then flooded in the IGP as well. Router sends RA (or something else), indicating that host now can use those addresses Device then periodically renews this cryptographic information somehow. I believe this can mean we have really really fast attachment of devices as they move around. I don't think we can make this work quickly enough if it involves RS, RA, DAD, DHCPv6 questions, ND lookups etc. It would also mean devices would have prefixes moved around, not addresses. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 2 00:13:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482E5131D1E for ; Wed, 2 Aug 2017 00:13:51 -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 YgS3QEmMBAX4 for ; Wed, 2 Aug 2017 00:13:50 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FC5131D19 for ; Wed, 2 Aug 2017 00:13:49 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id c14so17944923pgn.0 for ; Wed, 02 Aug 2017 00:13:49 -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=qh1yP//5vvBgzQvSgCaZ+MIDJQkCPGHLXzTaiF90/Cg=; b=iVwd4oJvHb6kQqcHhy082P8zwDD8FkhYhVLdvYQkxVWa+Iq8QPJY8GH9OkKy+pQjz3 o4VeulNVe+lOAosewKNsWZQat/XId/HnbPhllG7yd6+t5P6OuuH8x2DwtBLk3hxCgVj7 telDzeB6vtabYhGziQFDmc3z7yx3mUnF3Ph0jk6y62Gc4GhOXKcB+AQFYfaKEyJL5GNg HeEq7B/TRJmPS5ccKVxjSiAyAftFHlJk2ITTngAQhNYXSETmXe2qtLdTmGA2zwcQEwyQ buEP8VCekNM6odlN1kY30SvM6YV1Mx9eEA7kOoALLmK5FRttHR8fyjormRm1dWWLT1fW sJgw== 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=qh1yP//5vvBgzQvSgCaZ+MIDJQkCPGHLXzTaiF90/Cg=; b=olYSohLXrGw77o1BwVB7zJAL6WtaRyFDtuV7/HZQDF5Smf9+0FH63VeqXoORHD86xP F5KMxhkwGvS9Q2xRxZ/3dzuUNizG9QCNoN4B4s0YVwCDm8FoB4OPVOd7H5ExX7EAhpIp keaQbbvhFdQ98n7ocN/jJA0SXKUI1Trq3aBcaEAu0U4UXJXj70hzloDqaYh+yeoeYAY7 w8pDs7ZRMdBzqeMNeb47KBm7wl6rrvz2ZWDZL9pGOLAeW6wL3OOFtcaufY7BPgpe9APJ boDbVPJiDKc0ERgCLaz4dD21opP+yOvku5eQ049Uiy8vzOx86vZAf2DrfZmtVugriQax biLw== X-Gm-Message-State: AIVw111zhF13lj2fMQJC8oB2NY5GOwlCdYOYSUCcoaLDgnYVPBQzQGp8 4Il89+lqFWPWJqqLwm0= X-Received: by 10.84.224.207 with SMTP id k15mr24038068pln.108.1501658029469; Wed, 02 Aug 2017 00:13:49 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id u1sm42470875pfk.31.2017.08.02.00.13.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 00:13:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <4722F8C3-2D81-4F05-8CB2-AA560B92C9B8@gmail.com> Date: Wed, 2 Aug 2017 16:13:45 +0900 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <4722F8C3-2D81-4F05-8CB2-AA560B92C9B8@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:13:51 -0000 In line=E2=80=A6 --- DY > On 2 Aug 2017, at 10:42, Fred Baker wrote: >=20 > Well, again hat off, I think you didn't succeed. If devices are on = interfaces, ND (which is designed around shared LANs and therefore = interfaces) works. If devices simply "somewhere in a network" and the = network is other than trivial, you need something a lot more than ND, = something a lot more like IS-IS (although the algorithm could differ, = and could be different in various parts of the same network). Perhaps, something like ES-IS=E2=80=A6? > We're in the process of taking RFC 4291 to Internet Standard, which = implies "no changes other than removing features not proven = interoperable". That's not an "interpretation=E2=80=9D. OK=E2=80=A6 too late=E2=80=A6 ha..? BTW, it was a surprise to me that RFC 4291 is not yet an Internet = Standard, after all those 20 years=E2=80=A6 interesting. So, ideas like mine have to die or wait for the next round refreshing = (if any) of RFC 4291=E2=80=A6? One thing I=E2=80=99m concerned about (with no good reason?) is the = proliferation of identifier/locator separation protocols. On top of = that, people now even start adding a layer of =E2=80=98identity=E2=80=99 = (IDEAS BoF). Are these patchings the absolute inevitable? Couldn=E2=80=99t we thrive = just with native IPv6 and DNS for all those only if we tweak a little = bit on IPv6? Aren=E2=80=99t those patches going to make much of IPv6 = irrelevant as NAT did about IPv4? Regretful... From nobody Wed Aug 2 00:30:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC8E12EC3F for ; Wed, 2 Aug 2017 00:30:41 -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 n5MbndIRoojN for ; Wed, 2 Aug 2017 00:30:40 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 06849124234 for ; Wed, 2 Aug 2017 00:30:40 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id l64so5597845pge.2 for ; Wed, 02 Aug 2017 00:30:40 -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=Z2lTtwrSBF5iYnMQa5sGK9ljiBSg3xQc7vRTS/+pGPo=; b=lDniFFqDoRtHC+iKFeVhmc/F+hqcGv4p9i210LJd5LOvz/Gw0t6AH0qJdxyVEd7eOp T5E39rOOeSGZuncjWsf94mxjc9SHjh4H86ugypiH/t1h/q84oPRbr12J37fZ8KI2y9C8 HCsEUWSopk7sf0v1OuP9T4SfFyAuPC6STIShTAwDr9aVivS+pcQBYWmYht9xq+pTAEwn Zk4m6l0M2wpGFLEeuAUp3REkin0YZBi0lOHXIZ/thyqWdtYUPeWKNTKQxRZoODnFl0Xa LEWj4HEPv2UJDENwBcGrzrwI9/xeGs9ZbkaqWEsFsEdlgpA3bS1BJKh6vwXO7ILcA6Qf 4LbA== 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=Z2lTtwrSBF5iYnMQa5sGK9ljiBSg3xQc7vRTS/+pGPo=; b=BT8E6vBHDH/f7F88eMkzRQBaB4NaZdrdauxhxLDVCACCosSiSJGnDT+IdvJT+RiLEX aNF3Kga/sDwZxvX91BIg8T1xMfu05F4gTSmg5gWiMhTTywhSi34sgZ85oa4p6oIFZrJB ggvg4S/K4OxZ0XZYt2rlOxDH9t82lcD0lj/0c5dDnyJDQj1tdJesLV4ckdcyzJu1XxOL tm1euGA3yhkL4pQp5qyP0lCxZUhc5131l8tJwFC9+phjJ3U0TfhnHx7U8GPuuIZGJ/Sq ijxbeMZ+4BpMbsTGJ7/d5GPJxTy7RAiy3rNCLK4aki9SwShjgBgJG/C1K2tRaB9khnQS F9Yg== X-Gm-Message-State: AIVw111myM40i57EeuDzhTgCbzbxS4zvc6uuXrw31lrlM9s42iEWYHeS yx61IDkSxLObeQ== X-Received: by 10.84.132.76 with SMTP id 70mr24180540ple.7.1501659039587; Wed, 02 Aug 2017 00:30:39 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id u12sm5574619pgq.24.2017.08.02.00.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 00:30:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 16:30:36 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:30:41 -0000 Hi Mkikael, Your idea of certificate should be a good idea. But, I=E2=80=99d be curious why you think it would not work for moving = addresses? For example, in the basic mode of SID6, all intra-site nodes would share = the same prefix assigned to the site; say, this is 64-bits, without = losing generality. Each node would then register itself with the router = (with certificate) informing its node ID of 64 bits. When a node leaves its original subnet (or LAN) and attaches to another = router in the site, it would report its node ID (also repeating the = common prefix if appropriate) with the certificate to the visited = router. With the certificate verified, the new router would right away = acknowledge the successful attachment and would flood an associated link = update. Of course, the similar scenario works if the granularity is not the node = ID (effectively address) but the prefix. But again, there should no no = reason why the same scenario should not work for the granularity of = address. --- DY > On 2 Aug 2017, at 14:55, Mikael Abrahamsson wrote: >=20 > It would also mean devices would have prefixes moved around, not = addresses. From nobody Wed Aug 2 01:02:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C905A12EC4B for ; Wed, 2 Aug 2017 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuaZJZVicSio for ; Wed, 2 Aug 2017 01:02:54 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B45212F24E for ; Wed, 2 Aug 2017 01:02:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 89A95A6; Wed, 2 Aug 2017 10:02:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501660971; bh=Ej7I+TUTPtdZK6J2zCH9r3otqLMbn/n27Uyrm+tfwp4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lBWiEoQJxEZpjqE56xJFBdPONw7QekXZ8I0izc2q71EmmdzBx5bMQJ+ydQN8qtRkn iNzIf3q5cQnv5cqTe64v6vQeHPHi+GQpMHqMoC95usc6LqEASmQfSkvchCKeq8t9ba QsXthp57evpWkbH+58tZxBhRaiD4Zz7iFb0OJotk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 70869A2; Wed, 2 Aug 2017 10:02:51 +0200 (CEST) Date: Wed, 2 Aug 2017 10:02:51 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: Fred Baker , v6ops@ietf.org In-Reply-To: Message-ID: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1322841838-1501660971=:2387" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:02:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1322841838-1501660971=:2387 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 2 Aug 2017, DY Kim wrote: > But, I’d be curious why you think it would not work for moving > addresses? It works to move around addresses, it's just that best common practice is that a device should have lots of addresses. Seems more efficient to have a prefix to the device instead, not addresses. > For example, in the basic mode of SID6, all intra-site nodes would share > the same prefix assigned to the site; say, this is 64-bits, without > losing generality. Each node would then register itself with the router > (with certificate) informing its node ID of 64 bits. Then it would just have a single address, which would not follow RFC7934 (BCP204). I'm not saying it would not work, it's just not what we should do. If you told me the site has a /48, a 64 bit node ID, and each host now gets a /112, this would not go against RFC7934. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1322841838-1501660971=:2387-- From nobody Wed Aug 2 01:15:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565D126BF3 for ; Wed, 2 Aug 2017 01:15:10 -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 CfDXpCmuSuFB for ; Wed, 2 Aug 2017 01:15:09 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BBF131C04 for ; Wed, 2 Aug 2017 01:15:08 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so5728518pgd.1 for ; Wed, 02 Aug 2017 01:15: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=7JeTp0ynKPG7VNXpSmZpM8fgeEyBQYf9Dp8RwcpmpH8=; b=jOt47wXAqhY4fcQbbt7rwqqi5fJbcjlnIGOBtdKNNMw+h/GvPAC3AW5sy5EBh3bynE kBqZaNZlLjmshm/f41FMEG5qsz/ok4FVUITd+HFdzAgvPy8QYvN/wfk1uNizU8vJZ+Fl CQUf1IwwQhJBTHwihynPVSFm1xuoDV77BlrePYiz6FxL2u9gIWsuVoD1hzS4NWswsQre 5M7HN14cd4wwV61AIXi5v38S1pFHDGf0eFR7oxBabKfu8aAnWXft+wCHhRNz3GP2mjOW LKrXi+Ibd/rClzpbnld1+6p6GAPk32UzBGvxAWnjbFwwx8uFDD6VyxUcDQPJ1XFkxCWu nzUA== 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=7JeTp0ynKPG7VNXpSmZpM8fgeEyBQYf9Dp8RwcpmpH8=; b=XjH3y40y0MRtu3NKewDqVA+0WJHU7yDBiA/ig/CfYJh/JZ5m9/9D1BQnLgq8br1hYh dfs/ys3CU9qqAPdTFzQp6L5wuUevJpP2Pb3jpVXjR5QHlmQwIKhcMX3RwMCAXGvxIPUZ 3Ikp6CFF8cPqOQCu69rXs6jFEZxY9+dEQdtyb6+U4NNb4MnDbbs6L0UWh4xwB6GS3Ymm 8KBH/gYRDrELPAB1UQbEI15AUYEDrvcu8yKiyZ+dUK8Kek5DruETdrj/eX1xWVdBCD9i qIeIu04apj07VfygaYRhXyoOaTD9TPmVIF0iudZ1bxkeX4Dv1ZEuUpcDLF2+YWL6C1m6 dgrQ== X-Gm-Message-State: AIVw110P8LWD6QygoWJgrRjbAhal73jnXBGM3AEyh1mrR3PZKDgR8HB4 zmbOrVxTakWy3g== X-Received: by 10.99.9.67 with SMTP id 64mr22144868pgj.12.1501661708088; Wed, 02 Aug 2017 01:15:08 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id j124sm29242350pfc.78.2017.08.02.01.15.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 01:15:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 17:15:03 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <65B8D77A-7AAB-4309-8D1E-0608A67210A2@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:15:10 -0000 in line.. --- DY > On 2 Aug 2017, at 17:02, Mikael Abrahamsson wrote: >=20 > It works to move around addresses, it's just that best common practice = is that a device should have lots of addresses. > Then it would just have a single address, which would not follow = RFC7934 (BCP204). I was not properly attentive to RFC 7934. I do agree to moving prefix. Thanks for the pointer. From nobody Wed Aug 2 01:34:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A681131D26 for ; Wed, 2 Aug 2017 01:34:16 -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 LZBqOKkGrFgt for ; Wed, 2 Aug 2017 01:34:15 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66180131D0E for ; Wed, 2 Aug 2017 01:34:15 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id t83so5349681pfj.3 for ; Wed, 02 Aug 2017 01:34:15 -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=soUp1+WlVx2u/3IlHEs1nsxnfTsH53hfyZzAN1ghYRQ=; b=qlt0v2frRFGrurbPneM3AakpDUyJOyp8FCwFNH7PwdNj+emW3lbYmaGrYGtg3I9YZD SuemkIUnDWe9bQa5zYU4S/DxMQf/GghZ/r6lli1dmOhv8uvDAaeeBY/qg+yNcDFaLwfx OM4I6pLXfUDSAm4uWUxg6+CD5cmZldLa4PBDeatx8Ge2fj6Dnw/4qx/TpRJ7lGlOlilm iUSSzEGZv556EbVCUjk+JsNkdMY7L4cMHk2YPGOE518AfwsFjWM2dW7CKBlPbSRZZp/F Z0lIS/DB0TGiAY80zaBh2r3WBFv9D2CKTwimp/r5eW6Dz0Nzwj496Og4Pz8fOVYBPDg9 5azA== 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=soUp1+WlVx2u/3IlHEs1nsxnfTsH53hfyZzAN1ghYRQ=; b=VYL25Bjg4j2dpWklgp/M3e2QuWPgC+1X/RezpONG25nGazWmSTRN225d8lTHKDEMwm FLc1sQRJtedmOZn6Cr6t+TFNzyZiypsr1BaJIG0JrsU27IYEx4vhg+ZrnVyzzVwZ6XgH sayL/PGdJ4K/tsrjCfsBItJLAJ5o3muQ9sYUI+6iMS8EotR2sWxv0zJy0s7iCEuiFWVB jVGgt6fRmbXIPhLgZHDNZtGufYNUd6yDrMXqZgYOxiaXRHZlAbuqMp8HJAIAIt3yGROS deahOrtDtNWxod39ZthxnHzN1BQEanjCTRM+n0yiQBQf43nkJtPt8lSJdXOvSZxnQxjy N6ig== X-Gm-Message-State: AIVw1124RmRUrwX8j2JVJgJd7qQAikuEOdvpI5NVTUUE7x3DZN9zvSSm Oa38uPMYm5BBZg== X-Received: by 10.99.125.87 with SMTP id m23mr15953pgn.10.1501662854895; Wed, 02 Aug 2017 01:34:14 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id m2sm13349616pgs.72.2017.08.02.01.34.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 01:34:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 17:34:11 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B24024A-9419-482E-A564-FF6D54592B6E@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:34:16 -0000 I=E2=80=99m lost at your /112. Did you mean something like: site prefix: /48 node prefix: /64 node ID: 64 bits (can generate multiple 64-bit NIDs per prefix = /64). This arrangement would accommodate 2**16 nodes in a site. If one would like to have two-level routing for routing scalability, = then the 16 bits can be sliced like, e.g.,: site prefix: /48 area prefix: /48+n node prefix: /64-n node ID: 64 bits , with n =3D< 16. --- DY > On 2 Aug 2017, at 17:02, Mikael Abrahamsson wrote: >=20 > If you told me the site has a /48, a 64 bit node ID, and each host now = gets a /112, this would not go against RFC7934. From nobody Wed Aug 2 01:46:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA5A131D29 for ; Wed, 2 Aug 2017 01:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEE7-ut5R3QL for ; Wed, 2 Aug 2017 01:46:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA54131D32 for ; Wed, 2 Aug 2017 01:46:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 49798A6; Wed, 2 Aug 2017 10:46:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501663577; bh=YZVHx5AR7mvTtXxFfHiInp5STpriEaEMGC1E36Duh/w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WaSv3VFajIQI518LOid8n0RgV7wLZD1eiH+1yKKIgiLqD8yZZIR0SRVSx6+Sv0AEs 3BTjht3O6u+IxRBIKqKkiuAOBNNzaNEAHNXO0zsZQ+rJmQra7739QKV7yD2/Z1HjeI D2D/llcwxKuTccgbkV7BprGf+IyNM7rJDRMFJzDo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 471DBA3; Wed, 2 Aug 2017 10:46:17 +0200 (CEST) Date: Wed, 2 Aug 2017 10:46:17 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: Fred Baker , v6ops@ietf.org In-Reply-To: <6B24024A-9419-482E-A564-FF6D54592B6E@gmail.com> Message-ID: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <6B24024A-9419-482E-A564-FF6D54592B6E@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1898208539-1501663577=:2387" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:46:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1898208539-1501663577=:2387 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 2 Aug 2017, DY Kim wrote: > I’m lost at your /112. Did you mean something like: > > site prefix: /48 > node prefix: /64 > node ID: 64 bits (can generate multiple 64-bit NIDs per prefix /64). > > This arrangement would accommodate 2**16 nodes in a site. > > If one would like to have two-level routing for routing scalability, then the 16 bits can be sliced like, e.g.,: > > site prefix: /48 > area prefix: /48+n > node prefix: /64-n > node ID: 64 bits > > , with n =< 16. No, I meant site prefix /48, node ID 64 bits, node prefix 16 bits. I could live with cutting down the node ID size as well. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1898208539-1501663577=:2387-- From nobody Wed Aug 2 01:47:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FA6131C9D for ; Wed, 2 Aug 2017 01:47: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 4AsPthXICmV2 for ; Wed, 2 Aug 2017 01:47:13 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::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 994B1131D29 for ; Wed, 2 Aug 2017 01:47:13 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id t83so5378240pfj.3 for ; Wed, 02 Aug 2017 01:47: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=bdLfVjVLq5ABKbWShioSpcvb9CBphszo00DV204q/qE=; b=rvl0Wlonyq1+X60pcNP09Pvvas9XZAHAtz+4wAWdkd5s9QLoHeYYqaQtaj71HGgeSK AI2fSWTbE5Qn4PcaeGQ6SXSQZIHYnjnc3b/d4HmZrIoXnH7EnQpuR3326S40gjnMnMa5 06zXMsjnHsR/xqonc/fMmfqJjTYc3DuqPP+90h20RI+kL5KXSq/YMBCrfJt0Yq/7vWS8 1CoBQ7IIyolkdFiU3k0EBukowXvKRnWSIj27sKDEVJDkZWxto+vz5LsV7VQnHiVW4kFk vwMtAvvK6oBEzGHCdNAy9d0HwspZWjSL2MK/P+42fdSpbRLR/0dKE+IjR5Y2CDlQz/ZM svQQ== 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=bdLfVjVLq5ABKbWShioSpcvb9CBphszo00DV204q/qE=; b=gB+rphJyMhu66Gma+02Sa59kJ2BD4Nmp+rGS/ZPNLEgbaQ35+qD9A/Q4wOsDzQJ1lX NmgQWBKuM0wDE3dGFxXq/grsLjTm28i9qCVjK8YlDQWomlclleg8DC3d7G5JR7pQtSQH ZOZ+DCOWzTp927dOSzhSlc82NlqFXMw6FXJX4ZRZKGY+fra+J1ql7RFzb9JO/AcnR1RU pqadicU1ZzPrjZPBw2y2OPgRKIVMXRGmkl8+11i1umYTYfC/mYDT9YymP3NG7jif4zJc VEoc2ppid9nUcVSj3iLyJ8g6K1A1SNHTIVd6m3CDuEWODC5JwexxDrAkrGju+NrnG5Eh Greg== X-Gm-Message-State: AIVw113MZyOioZmncC00/OGSojcv47zwDQTrNOsJtuFouS8h91gQmpd4 WrW+49IkiISoFg== X-Received: by 10.84.217.74 with SMTP id e10mr10663901plj.410.1501663633173; Wed, 02 Aug 2017 01:47:13 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id 133sm5274104pge.29.2017.08.02.01.47.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 01:47:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Wed, 2 Aug 2017 17:47:09 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <64988E9D-D425-4CEC-B180-E90B8A80E191@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <6B24024A-9419-482E-A564-FF6D54592B6E@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:47:14 -0000 Got it. --- DY > On 2 Aug 2017, at 17:46, Mikael Abrahamsson wrote: > > No, I meant site prefix /48, node ID 64 bits, node prefix 16 bits. From nobody Wed Aug 2 01:59:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C772C131D32 for ; Wed, 2 Aug 2017 01:59:56 -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 p1e7y14dCHmz for ; Wed, 2 Aug 2017 01:59:55 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 D235B131D33 for ; Wed, 2 Aug 2017 01:59:55 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id t86so5401580pfe.1 for ; Wed, 02 Aug 2017 01:59:55 -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=64Z2lIt0ihDRkhupLSJi7Vo9QwPCqWdmHFvYthJcZdg=; b=Fc6rGilZBjk8ppXXKHkNTV07Id4T3OPMiHQ6lACY8Lw1v8xUkqKNPBuqz6y4/JeQmP UxayN7LCzZs/W5kM+PJhXTpZ2ihY5PA7e1ieXPLz+Q0YaHGtkIkqqTN7m16fZVVw9YS4 beHv2PEIQ8CgJzJ0EHxcwWFHAWWoHs+m1c3JYrabSy49HEX5j6Fdhgnsi1TyNfNdQpTA uwJzwKlDNU/19pXQaKbKR9P62g6dWUrrOl3jVHCq/lLNFfraNtASelUsw7XRhqvtndIe G8+M5WkQlHhq0zs0n/M8JQKbWilN8UIXQrDpPB+XVCyl/67M1Ud+X2+Jf65v5IjtabYE N6kw== 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=64Z2lIt0ihDRkhupLSJi7Vo9QwPCqWdmHFvYthJcZdg=; b=B/BDKLw+PtUhDAQMxfTN8SmjMLEKtXamnocqnVCXqRRWaRViy2eQA+OX5ZwqnwAYTg OlaazkZH2XE1Cg+SYRM2Z/GliXE3Nm4r0wD066wEmLFwyr5wqFR0Qvs8yVwnpyMUxpwU x4H8C3yV0C7Nj7tM+dfwwSLvjk+iZ1NmZsiL+rOjMwo4PdCndh5i8X1x3kmZzENu7UVp QA9I1gfIIe2PdSI+uqEYxGroy+sh4jOlUAstuNuGLOaz6e5BOKPUZdrRseHeoLoS6rOm J+0mtlCf2yaypXS0uwAjk9GjMhvk5wfzRjRbqeLW3geotGMDUYDUIaJlFNuj0dkCeuvm wYmw== X-Gm-Message-State: AIVw111OvPjrGKRUVsuGqRJhUfvfIrOysMC9zcbq19Ya3gcQuMMG72LY vnZ3HichGjjqrg== X-Received: by 10.99.54.9 with SMTP id d9mr21995838pga.195.1501664395373; Wed, 02 Aug 2017 01:59:55 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id g22sm7944283pgn.65.2017.08.02.01.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 01:59:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <64988E9D-D425-4CEC-B180-E90B8A80E191@gmail.com> Date: Wed, 2 Aug 2017 17:59:52 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <6B24024A-9419-482E-A564-FF6D54592B6E@gmail.com> <64988E9D-D425-4CEC-B180-E90B8A80E191@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:59:57 -0000 In the scenario we=E2=80=99re talking about (in which others in the list = might not be interested), considering that privacy is more with the node = prefix than with the node ID, a better arrangement could be: site prefix: /48 node prefix: /112 node ID: 16 bits Obfuscation of the node prefix is the order of 2**64 while each node can = have addresses (node IDs) as many as 2**16 (too many?). --- DY > On 2 Aug 2017, at 17:47, DY Kim wrote: >=20 > Got it. >=20 > --- > DY >=20 >> On 2 Aug 2017, at 17:46, Mikael Abrahamsson wrote: >>=20 >> No, I meant site prefix /48, node ID 64 bits, node prefix 16 bits. >=20 From nobody Wed Aug 2 04:47:19 2017 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF32131EBA for ; Wed, 2 Aug 2017 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctl-O_IS1Lgg for ; Wed, 2 Aug 2017 04:47:15 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE95132031 for ; Wed, 2 Aug 2017 04:47:15 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id p68so27302051ywg.0 for ; Wed, 02 Aug 2017 04:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=6nGA77wdIcr1HWVykNkVB4VCqeFj/NSNYt0w4m0zuWE=; b=oCsl1xQ9oWD9T1CfFJFiRAN2M9FH4bca7cQHJMvg3aj7vfmRYn+qG8IO4tLx60TJRm J6YmGzh460yT0xbe6GZHuPOp9/TLnegehnRJ0TMASrASJ39YAcxd1Tqqf7G98TpzfZT4 lxq5Csmk/PEOkPhNTW7MXaYivMMkljfTBlFZNrgvAnNa7tTWqV9KgeGujlDmWXn9w5zu bFGpUxbM6o+jiwnvDOcRTGgMjUTnShy6iqBO5McZUfoQuoBGZEcpcoooaMxBNNZyNgwN l2dxZGHzUe+SrvlfiPR3vaydoUQJyI074BUwsdeQMWtSYNW/FUpCwpslGskyrzaCTfiQ LjqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=6nGA77wdIcr1HWVykNkVB4VCqeFj/NSNYt0w4m0zuWE=; b=UffU/Kj08AWgfoGq53TGnbiYIjYjA/ENjWKUqdAk1HZh46eaUaWnap5mpncNDQ4gcY Yo9/WG1/DnhDP2PSjV6wPYJqXzLZvV75U39cx93HwSpwQZnTtmJP/A4Tgv41F0F8iU5f ZrS0PbPl4ty/e1dWqjsHWIXWzmbL8f00FPUzUK2YhN1dWVWmHw4f8nZMKWgW3r5Vh4Ho jax1FpC5sBwL0C+G66IBQFH5GVjO9rOMxO3fd5UBqjI4teKqXF2ol1JfgDfcQ61+U/Vq cHvUSJdwIctUXSu8pp7uQJdV/8TsELRltnuz/+HNiwwlab36/P/52BpBxlHcX+wDvPY2 KXRw== X-Gm-Message-State: AIVw1111HO7tWMl3kurGEnsdYD4YOL3EhlyaLJi8/0ckkZvIqg5Jwc8s Vixyisl7K7bFih+N X-Received: by 10.129.41.66 with SMTP id p63mr20455418ywp.143.1501674434789; Wed, 02 Aug 2017 04:47:14 -0700 (PDT) Received: from Russ ([2602:30a:2e5b:44d0:ad07:9684:5760:882e]) by smtp.gmail.com with ESMTPSA id z145sm3991598ywg.79.2017.08.02.04.47.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 04:47:14 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Fred Baker'" , References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> In-Reply-To: Date: Wed, 2 Aug 2017 07:47:11 -0400 Message-ID: <017901d30b85$14cf4440$3e6dccc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGR8d0tF4D4Yga/9KNB3Y01ywBAUALKfLjJAUaWXfoCepf58aK+wQ1A Content-Language: en-us Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 11:47:17 -0000 > I have just read it. I would agree; it updates RFC 4291, and by = extension > 4291bis, and should be discussed in the same context. We will need to = point > 6man at it. >=20 > That said, I'd suggest we collect operational viewpoints before we do = that. > Erik has given his. Other comments on the draft? I've just read this, and several (possibly incorrect) thoughts... So = take them with a grain of salt.=20 Essentially, this seems to entail host routing at the site level, unless = you do something like the original IS-IS level 2 with attached bit to = level 1's. This is actually okay/a good thing in many environments at = the site level. I think we way overblow the problems or running a lot of = prefixes in an IGP -- we've moved from 10-15 views of 100k routes being = "big" in 1996 to 200-250 views of 1.5 million routes being "big" today = (though I think there might be speakers with more). And yet, we still = have a minor heart attack when someone suggests we should be able to = carry 250k routes in EIGRP or IS-IS -- in fact, I've seen both done = quite well, and the open fabric work is specifically targeted at = 250-300k routes across 5k'ish nodes in a single flooding domain in a = variant of IS-IS. We seem to have upped our impression of BGP = incrementally without noticing, and not thought through the implications = on the IGP side. In fact, doing something like this could get rid of = much of the "let's stretch layer 2 for the one millionth time in yet = another creative (and probably harmful) way" we seem to be experiencing = right now. Good riddance, I would say -- stretched layer 2 is an = abomination that has been much more harmful than port NAT ever was. On the other hand, there are some places where you don't want to host = route, I think. Per link aggregation is still a good thing in many = cases. There are a range of solutions you could probably deploy to solve = this sort of problem -- for instance, you could solve this by treating = such situations as a single level 1 flooding domain from the link = state's perspective, a strange land where all the hosts expect addresses = with the same prefix to be on the same broadcast domain, because the = hosts don't support the requisite protocols. This would be useful in a = lot of situations, so this is something that would definitely need to be = looked in to and solved. For instance, no-one is (probably) going to = develop and deploy a host routing stack like ES-IS for mobile devices = (mobile phones, tablets, etc.). =20 There are some quibbles with this, however. The first is that we don't = need to set the SID to 0 to do any of this -- in fact, it seems like a = waste of good address space to do so. I know it feels like the IPv6 = address space is infinite right now, but it's really not. We need to be = careful here. IS-IS can provide a good analog here, as well. There are = two parts to the upper bits of the address, the HO-DSP and the area. = These are treated as one "thing" by every IS-IS deployment I know of, = and have been for years. Just eliminate the SID, rather than setting it = to 0. Push those bits into some other part of the address where they = will work for both possible deployment models. The second is this -- =3D=3D When a site is multihomed on multiple upstream networks, it would be = associated with multiple site prefixes and hence every intra-site node = would be associated with multiple addresses. For seamless = site-multihoming in such an instance, a node should be able to receive = inbound packets destined to any of its multiple addresses, and also be = able to source outbound packets with one of such multiple addresses as = appropriate [DASv6]. =3D=3D This is not a bad thing per se, but there is a configuration issue here = that needs to be addressed. Specifically, you cannot have partitions = within any upper bits of address space if you play this game. The = results are very bad. So this would need to be thought through, etc. On the routing side, I'm perfectly willing to work on a draft of a = protocol to solve the routing parts of this problem... Building a small, = lightweight protocol to gather local routing information for a host, is = very close to the MANET space; I can think of some folks who would be = really interested in working on such a thing from a research = perspective. If you combined such a thing with dynamic DNS (think ILNP), = you get lots more host mobility out of this sort of thing, as well, so = there is some thought that needs to be put in, in that direction. I would argue against doing anything with a tunneled overlay or overlay = routing protocol here -- I would rule that out from the first day of = work. Tunneled solutions are possible, but different; we're addicted to = overlays right now, it would be good to solve something without a = tunneled header for once. =F0=9F=98=8A So my initial thoughts are -- interesting, a lot more work than it looks = like, a lot of uphill battles, probably ultimately useful in at least = some environments, but we need to be careful to consider environments = where this would not be useful. =F0=9F=98=8A Russ From nobody Wed Aug 2 05:07:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBC5131D08 for ; Wed, 2 Aug 2017 05:07:07 -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 jxj9Marq1vyT for ; Wed, 2 Aug 2017 05:07:06 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 DC7CA12702E for ; Wed, 2 Aug 2017 05:07:05 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id 123so4500162pga.5 for ; Wed, 02 Aug 2017 05:07:05 -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=cShsUBAGzpA7u1bUVHonDJ/xWHoOPlim3Q+6wrw3jjI=; b=Jjn/Iml2zXQvg2QxrVHtlZuXGRwkk20djpF7RDw5DbqkPIVd5rpzUaVyJvoQirmODE IK5mLnbRuP7I2EFgd5WlNPVq2RxU2xk8Z2TDOZtYUjLr6nj0DFlFDZf3u+d2JRJXtMW6 8kfdrSkEaQIgo5NsUUNAp+MfV1XhRmjkze5qSnuDY/3grBA48t0c3dZWsKwAYtWd34gV 9uI2X1p5uwkehrSECwyPtZX3tTfMB9kGLT7oQXFneqamdq2q9gmNyowqLN3qoR+pWVT9 FLgg24MJmnPPmVOgIvJDQhSbY56Pbp3QhFueAjTvhKQfj65fqLMNDMal66IYRbgsQ1qF Dj0A== 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=cShsUBAGzpA7u1bUVHonDJ/xWHoOPlim3Q+6wrw3jjI=; b=S0n514unxFGA3+Bdq1Bfq4L+NXRBIbF9xH9koBPB31vjUi003uRBp1vcy+X9LQFOTy D1LbIMsQbN/eAQ5CC/BtOsqWxHYGeFAOnsQ+uafOohvCiN3VdMDIBb+lQ8C3pz43+AEn h80mVTz9Twd0+bguRYG0gCVREX1W1aojB3d3zv/GZ5W/jRGzpxrW1Y2bLdFUidtZeoyK NAzou9iJfNlCx0ZEEqDh3qvZZ4vXAQfGDmpmt1ypy4GdAaNWiy1lfXaeGOMnszt72vct rLD3z1+KIa1SA4sdcgKVi/aXT3hBhtF1DtXD7G8FSW6bpZ1Hz2dNm/fjdWUxUFPqvR1w 5NFw== X-Gm-Message-State: AIVw1121r5LxLVXLXoQLiSzFv/C1gYcNKD5EAsn3/vvQ8upW9TQrbp2N L9/+8X6ADpLJvg== X-Received: by 10.99.175.1 with SMTP id w1mr22943432pge.296.1501675624970; Wed, 02 Aug 2017 05:07:04 -0700 (PDT) Received: from [59.29.43.96] ([59.29.43.96]) by smtp.gmail.com with ESMTPSA id r73sm54915518pgr.32.2017.08.02.05.07.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 05:07:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <017901d30b85$14cf4440$3e6dccc0$@gmail.com> Date: Wed, 2 Aug 2017 21:07:00 +0900 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0AD35C89-7C6C-4F82-8B8A-A9D397767C7F@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <017901d30b85$14cf4440$3e6dccc0$@gmail.com> To: Russ White <7riw77@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 12:07:07 -0000 Hi Russ, Thanks for your comments. Two things: [Russ] =E2=80=9CJust eliminate the SID, rather than setting it to 0. = Push those bits into some other part of the address where they will work = for both possible deployment models.=E2=80=9D [DY] I agree. I started with nullifying it to be consistent with the = current IPv6 addressing model. But, just killing it and assign the bits = to either eastwards or westwards would be better. The idea of node = prefix as Mikael suggested would be an idea, too. [Russ] "a lot more work than it looks like, a lot of uphill battles, = probably ultimately useful in at least some environments, but we need to = be careful to consider environments where this would not be useful.=E2=80=9D= [DY] I fully agree. After all, I=E2=80=99m not such an expert in IPv6 = networking realities, so, in every pushing the idea forwards, it is = essential that real experts chip (jump) in to come up with neat = solutions. My trial in the draft should be too clumsy. As long as the = core message (on which I commented in a response to Fred) of mine would = be taken, I would be wholly open to expertise contributions or takeover. Thanks. --- DY > On 2 Aug 2017, at 20:47, Russ White <7riw77@gmail.com> wrote: >=20 >=20 >> I have just read it. I would agree; it updates RFC 4291, and by = extension >> 4291bis, and should be discussed in the same context. We will need to = point >> 6man at it. >>=20 >> That said, I'd suggest we collect operational viewpoints before we do = that. >> Erik has given his. Other comments on the draft? >=20 > I've just read this, and several (possibly incorrect) thoughts... So = take them with a grain of salt.=20 >=20 > Essentially, this seems to entail host routing at the site level, = unless you do something like the original IS-IS level 2 with attached = bit to level 1's. This is actually okay/a good thing in many = environments at the site level. I think we way overblow the problems or = running a lot of prefixes in an IGP -- we've moved from 10-15 views of = 100k routes being "big" in 1996 to 200-250 views of 1.5 million routes = being "big" today (though I think there might be speakers with more). = And yet, we still have a minor heart attack when someone suggests we = should be able to carry 250k routes in EIGRP or IS-IS -- in fact, I've = seen both done quite well, and the open fabric work is specifically = targeted at 250-300k routes across 5k'ish nodes in a single flooding = domain in a variant of IS-IS. We seem to have upped our impression of = BGP incrementally without noticing, and not thought through the = implications on the IGP side. In fact, doing something like this could = get rid of much of the "let's stretch layer 2 for the one millionth time = in yet another creative (and probably harmful) way" we seem to be = experiencing right now. Good riddance, I would say -- stretched layer 2 = is an abomination that has been much more harmful than port NAT ever = was. >=20 > On the other hand, there are some places where you don't want to host = route, I think. Per link aggregation is still a good thing in many = cases. There are a range of solutions you could probably deploy to solve = this sort of problem -- for instance, you could solve this by treating = such situations as a single level 1 flooding domain from the link = state's perspective, a strange land where all the hosts expect addresses = with the same prefix to be on the same broadcast domain, because the = hosts don't support the requisite protocols. This would be useful in a = lot of situations, so this is something that would definitely need to be = looked in to and solved. For instance, no-one is (probably) going to = develop and deploy a host routing stack like ES-IS for mobile devices = (mobile phones, tablets, etc.). =20 >=20 > There are some quibbles with this, however. The first is that we don't = need to set the SID to 0 to do any of this -- in fact, it seems like a = waste of good address space to do so. I know it feels like the IPv6 = address space is infinite right now, but it's really not. We need to be = careful here. IS-IS can provide a good analog here, as well. There are = two parts to the upper bits of the address, the HO-DSP and the area. = These are treated as one "thing" by every IS-IS deployment I know of, = and have been for years. Just eliminate the SID, rather than setting it = to 0. Push those bits into some other part of the address where they = will work for both possible deployment models. >=20 > The second is this -- >=20 > =3D=3D > When a site is multihomed on multiple upstream networks, it would be = associated with multiple site prefixes and hence every intra-site node = would be associated with multiple addresses. For seamless = site-multihoming in such an instance, a node should be able to receive = inbound packets destined to any of its multiple addresses, and also be = able to source outbound packets with one of such multiple addresses as = appropriate [DASv6]. > =3D=3D >=20 > This is not a bad thing per se, but there is a configuration issue = here that needs to be addressed. Specifically, you cannot have = partitions within any upper bits of address space if you play this game. = The results are very bad. So this would need to be thought through, etc. >=20 > On the routing side, I'm perfectly willing to work on a draft of a = protocol to solve the routing parts of this problem... Building a small, = lightweight protocol to gather local routing information for a host, is = very close to the MANET space; I can think of some folks who would be = really interested in working on such a thing from a research = perspective. If you combined such a thing with dynamic DNS (think ILNP), = you get lots more host mobility out of this sort of thing, as well, so = there is some thought that needs to be put in, in that direction. >=20 > I would argue against doing anything with a tunneled overlay or = overlay routing protocol here -- I would rule that out from the first = day of work. Tunneled solutions are possible, but different; we're = addicted to overlays right now, it would be good to solve something = without a tunneled header for once. =F0=9F=98=8A >=20 > So my initial thoughts are -- interesting, a lot more work than it = looks like, a lot of uphill battles, probably ultimately useful in at = least some environments, but we need to be careful to consider = environments where this would not be useful. >=20 > =F0=9F=98=8A >=20 > Russ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 2 06:46:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4112F280 for ; Wed, 2 Aug 2017 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktPFejg2KrLn for ; Wed, 2 Aug 2017 06:46:18 -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 276AC132085 for ; Wed, 2 Aug 2017 06:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501681576; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=nP8odYLz+o2+ngHnHise/s2OUgAJkr+SqTp3rZhv45s=; b=Lwb51HXz4ytu9DmieV78GJiw4Kiq3/d+U24GwVJ3j5d9DcJNP+R8DlFY3Qqxj+14Kvipf5KZIiEFrYgQyZD6CvvKFhVvWOJBtidugjVk9FPr7eUVHuEfr7x4mWdAS0gBbFJPYjx9EYucN/PkRF4JYYyQCQpC6jQnsQ1WvX0HvKM= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0152.outbound.protection.outlook.com [213.199.154.152]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-30-qVp9Fp1BPpa2xPHsBPjLng-1; Wed, 02 Aug 2017 14:46:12 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Wed, 2 Aug 2017 13:46:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.010; Wed, 2 Aug 2017 13:46:10 +0000 From: Tim Chown To: IPv6 Ops WG , 6man WG Thread-Topic: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) Thread-Index: AQHTC5Wy7f5vc2yinEOig6bEWwhs6g== Date: Wed, 2 Aug 2017 13:46:10 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0632; 20:WLK6uIdb5y5hVnljSjHDbOKDorFrjSF0bAuRO8e/9YKRPIwZ6uqxbhZYi/FlFhoDGChaoZqT2JETrP1FEGBVyohKbCRIoWHh2+BXW6FjOU213JY1OBxGFJI+MIO4lT17YF1geXW9T+Sze1wbIbrvIrfSKl/Es78yFqqRwdiT0nQ= x-ms-office365-filtering-correlation-id: f8506432-3101-4e45-adee-08d4d9acd592 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0632; x-ms-traffictypediagnostic: AM3PR07MB0632: x-exchange-antispam-report-test: UriScan:(43178223235956); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0632; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0632; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(24454002)(189002)(199003)(450100002)(478600001)(6436002)(74482002)(81156014)(3660700001)(81166006)(76176999)(305945005)(3280700002)(7736002)(8936002)(53546010)(50986999)(3846002)(68736007)(36756003)(38730400002)(106356001)(8676002)(86362001)(5660300001)(2906002)(105586002)(566174002)(93886004)(6246003)(50226002)(229853002)(6306002)(66066001)(6512007)(5250100002)(189998001)(6116002)(966005)(6486002)(101416001)(102836003)(83716003)(99286003)(6506006)(82746002)(72206003)(97736004)(25786009)(33656002)(14454004)(2950100002)(2900100001)(53936002)(57306001)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0632; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 13:46:10.6375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0632 X-MC-Unique: qVp9Fp1BPpa2xPHsBPjLng-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:46:20 -0000 Hi, > On 26 Jul 2017, at 22:44, Mark Smith wrote: >=20 > >=20 > No. On PPP you don't need DAD for LLA. >=20 > I think you now do per RFC8064/RFC7217. >=20 > I don't really understand the motivation for avoiding DAD. It's a very ma= rginal saving (1 packet) in comparison to the problems and time involved in= troubleshooting duplicate addresses. >=20 > In the scenario described, it can be much worse because there is likely a= non-technical end-user and a helpdesk involved in what can be an intermitt= ent and obscure fault (Helpdesks can be motivated to get the customer off t= he phone by saying "reboot the modem and call us back if you have more prob= lems", which doesn't prevent the fault re-occurring.) >=20 > I think absolute and consistent failure is much better and easier to trou= bleshoot than partial and intermittent failure when the cause is simple to = determine and discover. To step up back to the original question, what specific text or guidance sh= ould be in draft-ietf-v6ops-ipv6rtr-reqs-00, or even RFC6434-bis (hence my = interest), with respect to IPv6 CPEs shipping with IPv6 enabled by default? This is what the draft currently says about provisioning: https://tools.iet= f.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3 Is that sufficient?=20 Tim From nobody Wed Aug 2 08:15:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D813212C for ; Wed, 2 Aug 2017 08:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJN--p2esK95 for ; Wed, 2 Aug 2017 08:15:11 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5128E128C9C for ; Wed, 2 Aug 2017 08:15:11 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m85so44446131wma.1 for ; Wed, 02 Aug 2017 08:15: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 :content-transfer-encoding:reply-to:message-id:references:to; bh=FoeBkAOt8PYADA8WLobTOTITQUTECLjxauQp6XoBXtU=; b=YSukVtG1TCFErm36/MW1JiWKgCUqp+arLrAKxQIeluKGLiAKppn1KM5UdSafydQftD Wvb7/6epawPibGU7BfSKmhBsiBJsBFjVP7YNSB45afMdrlrj/KahEkVAkgH5vCCqMxPd oMT+tXJaM6xX/6sxB+qIkoh/oexgov24c3DPOzdIjpb9p2KSgO4E8X8RCKlgjIQ/J09i MhYNEDsOUAUSwLJPXstT33YDCKD7L1qaYG3XEDQDnYgsNRdne23QBxjN0JTgs+ZkPYMk +hWcOjkgqKM9/PuGTx+yKU861SfLYCTjFdQn8z52ZUhf1dbWpFr8C1TVDAg3uwlTQyeF p/PQ== 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 :content-transfer-encoding:reply-to:message-id:references:to; bh=FoeBkAOt8PYADA8WLobTOTITQUTECLjxauQp6XoBXtU=; b=GF9/0ig4iNFvrWhIVDOFeUx5udH61ZOchY2nE2RSt+Mhs3k9oAr4KlzyiVVZgRkRrO zIezuaCAppNIhRGl2puKyaTkikYkxTfQzqC8ZXpqxHjekGAodZj4hbJ3UfzEVNbLu+41 QfXu4XMzVVdlzqyJbDwftY5EQimC0r/oW4R021JWPiWDE1PrIz4BkQnzGhWTqm/yh1Fc uyYEyK59APKXoH2Kkq4jFuXmB11sgLKWIfDULaX4H/Xl0ZWyOJk1uQ9n20Zz75sCIQKm pkarNeyeS5aTqjHt1OISJRsMirZzuq66I6rL/yW9hQKWT6CXvUc2512Hl2qbznA9T6q+ iRFA== X-Gm-Message-State: AIVw111IQurAy0yJewVSnr/tJCRtB5HWjtIlBZpft3SGIqGIvFiJ6H8m KMJRV6cLP+MzD3d9+e0= X-Received: by 10.28.100.136 with SMTP id y130mr4035076wmb.60.1501686909699; Wed, 02 Aug 2017 08:15:09 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::19d9? ([2600:8802:5600:1e::19d9]) by smtp.gmail.com with ESMTPSA id 92sm6722950wrr.58.2017.08.02.08.15.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 08:15:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: <370B5AAA-1F88-408B-960A-8635586C1C4A@fugue.com> Date: Wed, 2 Aug 2017 08:14:49 -0700 Content-Transfer-Encoding: quoted-printable Reply-To: V6ops Chairs Message-Id: References: <20170730231102.1014.qmail@ary.lan> <21320.1501510627@obiwan.sandelman.ca> <6857AD5A-632E-4264-B76F-FFEC760E46A4@fugue.com> <62FE7E9A-9CC0-4DE6-93C6-61A08AC95281@consulintel.es> <787AE7BB302AE849A7480A190F8B93300A0155F5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <65D79ACB-372A-4978-9030-FFAB4967A2BD@consulintel.es> <20170801072139.316A7809B357@rock.dv.isc.org> <787AE7BB302AE849A7480A190F8B93300A0156BD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20170801145849.1660780A6174@rock.dv.isc.org> <5C3343EF-3724-4155-87BC-E169DFC38342@fugue.com> <79B094AE-8D4B-4E30-AC8F-7F74BE8C13D2@fugue.com> <30708801-142F-47C5-A154-15E9D3C5068D@fugue.com> <2017 0801232651.7E2FF80B1398@rock.dv.isc.org> <20170802013806.F222B80BCE0B@rock.dv.isc.org> <0B6948E6-4A40-4CA1-B22C-F1B822E97336@jisc.ac.uk> <370B5AAA-1F88-408B-960A-8635586C1C4A@fugue.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: [v6ops] "IPv6-only" v6ops interim? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:15:13 -0000 A question has come to me about a potential "IPv6-only" interim meeting, = which we would do by webex, probably in mid-September. Now if only there = was a single hour in which everyone in the world was likely to be = awake... I have included some of the remarks made in that context. I have set the "reply-to" to "v6ops-chairs", which is to say Ron, Lee, = and myself. I'd appreciate it if folks who wanted to post an internet = draft during August and discuss it in such an Interim would reply to the = chairs to tell us of their interest. On this list, I'd be happy to see = discussion of possible operational and protocol outcomes of such a = meeting, which might be distributed here, to 6man, or to sunset4 as = appropriate. > This long thread might make a nice topic for a v6ops interim, around = establishing and documenting best practice? Or are the various NAT64, = DSLite, MAP camps too far apart? > It's possible that the discussion has gone on so long because there's = no agreement on whether this is a v6ops issue or a sunset4 issue. To = me it's a sunset4 issue. So I see the value in it as helping to do = real-world gap analysis on what needs to be finished to make it possible = to turn off IPv4 on the wire. >=20 > It's possible that other participants in the discussion see it as more = of a question of best practices. But I don't actually see how we, the = IETF, can really weigh in on that topic right now. The reality is that = each of the transition technologies addresses a slightly different use = case. MAP addresses the "we need IPv4-as-a-service on the wire" use = case. NAT64 addresses the "we need IPv4-as-a-service without = IPv4-on-the-wire" use case. DS-Lite addresses the "we want to sell = really big machines in the data center" use case (sorry, couldn't = resist). > Another good interim topic would be on enterprise v6-only networking, = building on Marcus=E2=80=99 presentation, which I=E2=80=99ve attached as = you probably weren=E2=80=99t there. But I digress :) From nobody Wed Aug 2 14:01:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1457F132178; Wed, 2 Aug 2017 14:01:16 -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 e627vpN0Yvez; Wed, 2 Aug 2017 14:01:14 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92430132176; Wed, 2 Aug 2017 14:01:14 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id y129so25746589pgy.4; Wed, 02 Aug 2017 14:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+doTS0YpbX2J/TbPoWSlXzBTegIMTQZFDjN/6ZvDezA=; b=KlZIN76NDjW5itG5xHGRTMmSswSOPNC97mM5OTV24g1wc6pqlblzdj8b3p9wMslbl3 ZhIIF+iWs+RDWor3XLacBrPf+EZoMvuKaq1B+utjVp2ddo2VCbZUt2B2pG7H1nVFxkw9 2H0G/DK5GFrLWR4Hs4ucMBhKqIo73OFVRCYYLm0Ez2EBKcQStjNwFJ77L9k7D1UCaqJ+ XgVvdlxNfRHgu2bjAY10xjQcXA5VcyazShMQ1NckeOuGknT3fYoUvDsVhtEoB/FKWEBn tg/arEfXENd3QUKnrWCSaP62BOu7nyBw3BLz6OCKEbC2IrhaqV8SkQMQuIBrt6E6fFDM 7LeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+doTS0YpbX2J/TbPoWSlXzBTegIMTQZFDjN/6ZvDezA=; b=qLitqXpep7zotTgHtoYZk30tvdZH9d8hYnOO5V9LXUrDx6QGQH7CDbYPrT1uOiEnIO /8aiZRKZSkwqO91bUMDQdvm8DFE0c9BorAD9QE85Fff0hcgZMxSLhAGaR2fYvoynU7xB BvyCOm9q6Sg1h5NGM4zDJy1F1cTUhIZoQPeW96mlZVHLS+6CnWbI4SpzkgSt7f/UZYsB UT8Mmsec0encwDQKADEkrXbJUtycVeQhqabUZ7KsciT0Y38pUny0cpP+jXHG/wiOP7fv AM6TMAGYjvqZO2v78/Zlr06qBMG2fwbxwv0AxvVqCBzLJktgTVrcK3q05u5rsptrNIH7 9Feg== X-Gm-Message-State: AIVw112ZXdd2BUX6HOn/qckB4htuBgZdX4ww8+7xqjwXA27hnTtW+Exg lwoz2qrXu++SR8lv X-Received: by 10.84.224.141 with SMTP id s13mr26088581plj.212.1501707673198; Wed, 02 Aug 2017 14:01:13 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z66sm24366590pfi.137.2017.08.02.14.01.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 14:01:12 -0700 (PDT) To: Tim Chown , IPv6 Ops WG , 6man WG References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Cc: draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Message-ID: Date: Thu, 3 Aug 2017 09:01:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 21:01:16 -0000 On 03/08/2017 01:46, Tim Chown wrote: > Hi, > >> On 26 Jul 2017, at 22:44, Mark Smith wrote: >> >> >> >> No. On PPP you don't need DAD for LLA. >> >> I think you now do per RFC8064/RFC7217. >> >> I don't really understand the motivation for avoiding DAD. It's a very marginal saving (1 packet) in comparison to the problems and time involved in troubleshooting duplicate addresses. >> >> In the scenario described, it can be much worse because there is likely a non-technical end-user and a helpdesk involved in what can be an intermittent and obscure fault (Helpdesks can be motivated to get the customer off the phone by saying "reboot the modem and call us back if you have more problems", which doesn't prevent the fault re-occurring.) >> >> I think absolute and consistent failure is much better and easier to troubleshoot than partial and intermittent failure when the cause is simple to determine and discover. > > To step up back to the original question, what specific text or guidance should be in draft-ietf-v6ops-ipv6rtr-reqs-00, or even RFC6434-bis (hence my interest), with respect to IPv6 CPEs shipping with IPv6 enabled by default? > > This is what the draft currently says about provisioning: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3 > > Is that sufficient? This seems under-specified to me: "SLAAC MUST be able to be disabled by operators who prefer to use some other mechanism for address management and assignment (specifically for customer facing edge ports)." Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as configuring LL addresses goes. So it can't be "disabled" as such. I think this wants to say that it MUST be possible to configure RA/PIOs with A=0. In turn that means that RFC4861 MUST be supported - and that isn't even cited anywhere in the draft. Doh! An IPv6 router without RAs would be a strange beast. Brian From nobody Wed Aug 2 16:25:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7B1294A2 for ; Wed, 2 Aug 2017 16:25:22 -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 rAKYptnQD5rq for ; Wed, 2 Aug 2017 16:25:21 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8046D1241FC for ; Wed, 2 Aug 2017 16:25:21 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id v105so2075691wrb.0 for ; Wed, 02 Aug 2017 16:25:21 -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:reply-to :content-transfer-encoding:message-id:references:to; bh=7U6kKNm6eHuDANodIHSA/ct6JvneaWt+5DDmrCSQSl4=; b=NkSqp6wHtAp+GOYM43TVUgWC3iB7prJ4uwYGOZOyMeMTJH1O96ujjcPWHH+jIxdjyu c84XzALOyak4Y7h5vGXgw0kRQPJTnEqLYHFheleZX+Hb653ZC41zivD1hVkirkHPgMsi O5qHctLIXohLNaO2Wh934mNUzInoU+phQoDXrtERdvPtMGfio7i3B6kWDnxgpCTAd3fX krgKSTw5gE9oXV5NBfrpjoO+SFVIykCYqyQFBrjjWQDvnplEyFkf4P+cfv/ho0XR5rvy faJZONe1L77uC4qZDgYJjN6FhLLassM4CJsKVYP2yPi4i5UAnpaCehEDvAMwjCXbDgJP vQcA== 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 :reply-to:content-transfer-encoding:message-id:references:to; bh=7U6kKNm6eHuDANodIHSA/ct6JvneaWt+5DDmrCSQSl4=; b=ospfq3rDuAg7vf8+IZLgJPd9iyqJ55PrBH1Py10NHSASzZkSvEXSdvPG6zq8q1L7tk bEoYhx9KYgPOuRKl7mBy4f4g/lY/lnr69ooF4XesDkiGKHG4OSRtWPsV1tuA3SD/Ac42 sYhNC5HcDTZG567vw5tzDuj6HIFRqHry5KJvEmjvtWFI7dS8bgfLnAdVWObaheYaWLOh X8qJYdp7Beu7teaCXR2c46+fmMilO/Cf4bqLc53GWMFET9yYNV8MKr6JHBc2X2W6fdOP WbLbv2Xq+LLK/FIE9O7TSnfG+tnG7bX30XvLMj7zO04K15ZNufD6hl9qywvP52Lv0dZo bqrQ== X-Gm-Message-State: AIVw112bmEbFx0WhI2Us5ODhmnKMlHgR3K4Q6aGKZVJ034WXjX6eso8K wVKXtFrJ8DBAyaLI2ic= X-Received: by 10.223.179.27 with SMTP id j27mr17248651wrd.190.1501716319910; Wed, 02 Aug 2017 16:25:19 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::18db? ([2600:8802:5600:1e::18db]) by smtp.gmail.com with ESMTPSA id f47sm425583wrf.78.2017.08.02.16.25.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 16:25:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: <2D35DAA3-B6C7-4B63-AB59-90F9C920FB37@gmail.com> Date: Wed, 2 Aug 2017 16:25:03 -0700 Cc: tjw ietf , Warren Kumari , Suzanne Woolf Reply-To: dnsop-chairs@ietf.org, IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <293820B8-AAB0-4BD2-AD37-CD49BF558B61@gmail.com> References: <2D35DAA3-B6C7-4B63-AB59-90F9C920FB37@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [v6ops] v6ops review of draft-woodworth-bulk-rr X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:25:23 -0000 Folks:=20 I have a request from the dnsop chairs, trying to validate and get a = sense of a posted draft. If you have comments on it, please reply. Fred > On Aug 2, 2017, at 9:14 AM, Suzanne Woolf = wrote: >=20 > Hi, >=20 > This draft is a candidate for WG adoption in DNSOP, and we=E2=80=99re = having trouble telling how much support there is for it; it presents = some complications.=20 >=20 > We=E2=80=99re trying to get people to discuss other use cases, but the = one that has resonated with the WG is that the BULK RR would be used to = populate PTRs for IPv6 reverses. >=20 > It seems as if it would be helpful to get input from V6OPS types who = may not participate in DNSOP but may use such a feature=E2=80=A6.or even = be willing to say they won=E2=80=99t, or that they need certain things = from it that the initial implementation does or doesn=E2=80=99t meet. >=20 > Would you want such a request for review to come from the V6OPS = chairs, or us, or the authors? Anyone in particular (yes, besides you, = Lee) who should be begged personally to take a look at the draft? >=20 >=20 > thanks, > Suzanne >=20 From nobody Wed Aug 2 19:35:00 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0744129A96; Wed, 2 Aug 2017 19:34:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150172769887.5751.7103181202835281364@ietfa.amsl.com> Date: Wed, 02 Aug 2017 19:34:58 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 02:34:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-03.txt Pages : 14 Date : 2017-08-02 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 2 20:56:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22C51321E8; Wed, 2 Aug 2017 20:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz_eONUt5PlM; Wed, 2 Aug 2017 20:56:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F3120727; Wed, 2 Aug 2017 20:56:33 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id C3B10E6065; Thu, 3 Aug 2017 05:56:31 +0200 (CEST) Date: Thu, 03 Aug 2017 05:56:31 +0200 (CEST) Message-Id: <20170803.055631.74690322.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com Cc: Tim.Chown@jisc.ac.uk, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 03:56:36 -0000 > This seems under-specified to me: > "SLAAC MUST be able to be disabled by operators > who prefer to use some other mechanism for address management and > assignment (specifically for customer facing edge ports)." > > Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as > configuring LL addresses goes. So it can't be "disabled" as such. I think this > wants to say that it MUST be possible to configure RA/PIOs with A=0. Or configure no RAs at all. LL address generation is *not* dependent on RA (but *does* depend on NS/NA/DAD). It is perfectly possible to run IPv6 routing without RA (even if you don't normally want to do that). Check your nearest Juniper router if you doubt this is possible. Steinar Haug, AS2116 From nobody Wed Aug 2 22:34:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7D6131C8C; Wed, 2 Aug 2017 22:34:33 -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 bVWixjEvskfC; Wed, 2 Aug 2017 22:34:31 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E03131C31; Wed, 2 Aug 2017 22:34:31 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v77so2141838pgb.3; Wed, 02 Aug 2017 22:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VbNqVkvQP6BdLw17W8hjvzWpa4umOQRj3Y7orafXwms=; b=m6JFpJ2mFp17lQ4jr6bRZRth4qh50UcMkpuTrXBCwK0AHGa0UCaWJoWFjqNl0SDlmK 6Eq0QjUVSGTLcGZEQvOZKbZ/3khFaHf3PctgOmdnAefpSLaRvYmsZhX3k6Sf053OaDfZ rets72f4BfGxmoLcGZ4y9/GkQNlglF5/N5iYNvz69oP8QlYLLm1Pme3MoiJk+RlMCoUw oxD1VwZhrdhKSJQ0kzEEqOj9uXoROebZOHwsu/+GUSbM9/3WPnUM3eIJioXp1T7SGveJ qsmfEpbY1nYqv2T7uEY0Z065ZS5HRoI7GTxTqJFApioj0eknd1GqmJqvHeMxUvhPSBGX /vYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VbNqVkvQP6BdLw17W8hjvzWpa4umOQRj3Y7orafXwms=; b=QaH854m0l8JjVIUGo9RZmD3IWPEp/KOJV1/JxRdUgt6I4pVC3q4mvr2ZFD6rWHPXGV 7EdUbfc1/pHTBoVp7Hqj/zCWYBW/A6QuinNUEBUmlGQwoiFSDN4/48N9B6ffANITKbnR pa6h90Ey6sX5/8GAXIlC5TOKr1MbQ/7b62BCofIF6AoCkIutWj0LxPabeBGM/1mWkFbm aKT15pJRC56BqlRAWRshs3oT/b2fbyHpQZLk51hHQXYwl/9JLp1dVBjYGQE8YDn3sq4L CFicFiyQwZa1kh2tTGJIUAvuBwkMeRkwINaphaVx59K4b61hxSxHEzmI6t8gGwwPxyPH eJmQ== X-Gm-Message-State: AIVw1110aZGJr5pCVoDiaO/EwGRYqVs0o979GjRJasMT1wt5qLU7tLWj 7ltB7vXu1qQSl10a X-Received: by 10.99.149.6 with SMTP id p6mr486547pgd.412.1501738470887; Wed, 02 Aug 2017 22:34:30 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b4sm58200248pgc.9.2017.08.02.22.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 22:34:29 -0700 (PDT) To: sthaug@nethelp.no Cc: Tim.Chown@jisc.ac.uk, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org References: <20170803.055631.74690322.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 3 Aug 2017 17:34:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170803.055631.74690322.sthaug@nethelp.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:34:33 -0000 On 03/08/2017 15:56, sthaug@nethelp.no wrote: >> This seems under-specified to me: >> "SLAAC MUST be able to be disabled by operators >> who prefer to use some other mechanism for address management and >> assignment (specifically for customer facing edge ports)." >> >> Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as >> configuring LL addresses goes. So it can't be "disabled" as such. I think this >> wants to say that it MUST be possible to configure RA/PIOs with A=0. > > Or configure no RAs at all. LL address generation is *not* dependent > on RA (but *does* depend on NS/NA/DAD). > > It is perfectly possible to run IPv6 routing without RA (even if you > don't normally want to do that). Check your nearest Juniper router > if you doubt this is possible. Where does the default router address come from, then? Brian From nobody Wed Aug 2 22:41:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703621317A4; Wed, 2 Aug 2017 22:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUPEeNmEWScX; Wed, 2 Aug 2017 22:41:56 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9546126B6D; Wed, 2 Aug 2017 22:41:55 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 80so1709831uas.0; Wed, 02 Aug 2017 22:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VneExqkh+doZSkepI4MxxKmjsu9sMNnwYFT923vfNm8=; b=aUjW95zCNbBjUvGS2MLz/uuhtC/1Ffk4lSTQde1yezOAFKWLdX1BGmz5iHxzmvLIJt NFaKnTmCVRjIahij4hGUxmsHVQzlk4l0mYqVqv0GYDkHmIjFXaowhTlxA96WPK/pGQNi +8SI368ZsnfC2zNs9gmwx73PfvdPQdN8AFvqf0n7Y7y1g9erHdPtbHP9GeQ25ZCqQurL TlTwE8GvD56agxNHIJv2eMown9sG4sUtiJLUBFga4e9AVxklHc7wWUIeyDP2RfxL0fEH 7siQrw6ypsBtihSsjpYjNnvsTDkUhFVM0BF3LB59hoSpQPKZ5JoQUfOQbtgzQgQlZoBv ipjA== 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=VneExqkh+doZSkepI4MxxKmjsu9sMNnwYFT923vfNm8=; b=FDWIe5krKcERwgBhJPV/uGUSecgk2vCtlzkRH7v22B4iuTFKXjeYsxjUemmPKe7D/2 F7QrgjP+RxJquvv8AYMPc5V1lUd1PNN8imn+i0EN6uWFH7b4zBTcTppCkwvrfFtgx63j +Odxc9/JbYWKHLdU4DXcU3p4jFfm3bW712GvzBfmR7Z5EDNacI9B6/x+kCWnbQ+wrZdK SfMorjNsY96OXSn9Dm8auLpFeP2asrPDT6yXaa58wTV6XEDnhyGGvY8eOsVtmOeU536H KqA40bbSU9az+1dAiOlDtNIqYKbIlOajRmpR1YVLDVmCGqbmXu36taS32flm+UrH9yEa VIqg== X-Gm-Message-State: AIVw110StdMQOQNgvQ0Apz21I8XHJF//anlfqbkahH+r3/lKKh3sh04r FWPTO6/tAsf+vFgpqV8Onhy9xl2unQ== X-Received: by 10.176.8.81 with SMTP id b17mr370996uaf.82.1501738915083; Wed, 02 Aug 2017 22:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Wed, 2 Aug 2017 22:41:24 -0700 (PDT) In-Reply-To: References: <20170803.055631.74690322.sthaug@nethelp.no> From: Mark Smith Date: Thu, 3 Aug 2017 15:41:24 +1000 Message-ID: To: Brian E Carpenter Cc: sthaug@nethelp.no, v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:41:57 -0000 On 3 August 2017 at 15:34, Brian E Carpenter wrote: > On 03/08/2017 15:56, sthaug@nethelp.no wrote: >>> This seems under-specified to me: >>> "SLAAC MUST be able to be disabled by operators >>> who prefer to use some other mechanism for address management and >>> assignment (specifically for customer facing edge ports)." >>> >>> Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as >>> configuring LL addresses goes. So it can't be "disabled" as such. I think this >>> wants to say that it MUST be possible to configure RA/PIOs with A=0. >> >> Or configure no RAs at all. LL address generation is *not* dependent >> on RA (but *does* depend on NS/NA/DAD). >> >> It is perfectly possible to run IPv6 routing without RA (even if you >> don't normally want to do that). Check your nearest Juniper router >> if you doubt this is possible. > > Where does the default router address come from, then? > And potentially many other things: "IPv6 RAs Mostly Necessary" https://www.slideshare.net/MarkSmith214/ipv6-ras-mostly-necessary > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Aug 3 00:31:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EDC131D24 for ; Thu, 3 Aug 2017 00:30:53 -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, RP_MATCHES_RCVD=-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 oU0ETo6_0pGL for ; Thu, 3 Aug 2017 00:30:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA34A13231E for ; Thu, 3 Aug 2017 00:30:51 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3202C429FB for ; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1B226429F8; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 17AD935C43; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) Date: Thu, 3 Aug 2017 09:30:49 +0200 From: Gert Doering To: Brian E Carpenter Cc: sthaug@nethelp.no, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Message-ID: <20170803073048.GJ45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:30:54 -0000 Hi, On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: > > It is perfectly possible to run IPv6 routing without RA (even if you > > don't normally want to do that). Check your nearest Juniper router > > if you doubt this is possible. > > Where does the default router address come from, then? On the router? "OSPF, BGP, ..." On the host? "static route pointing to fe80::1%eth0" (which is the VRRP address of your upstream router pair) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Aug 3 00:42:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17565131D24 for ; Thu, 3 Aug 2017 00:42: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNzXy0YLrhR4 for ; Thu, 3 Aug 2017 00:42:39 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB49B126CB6 for ; Thu, 3 Aug 2017 00:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501746156; x=1502350956; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=cYb/0SKu9SVVUHXsyRCa2rb+B A3fvScM7JCet2GMqYw=; b=Vf0r3uzoAvoYDzrgc2meWG+KFuo/vU4n34eqi7Mfn NOMYy3Rqk21yODXFExNCxxY8TE+G5+XfwllubjqVzEFBkfjt1IP/lggoAOVddsWX JnPG2yQabloCY0YysDO2ZdejYqNjWgtURiEKB2RkCjPlo0GukyrAfm80lDXeyBrI uI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=XioAXlNmrHzy8qfmNQ/tztIwavEALVrn7rMI9/EVRLJS0VNyR46yjXFYb8+C asvcz8rQsT4HVYR0A3e+anxyVk5q6UMuMGHJmH5FH0YUadUmnTBjlYZUY KHX/hlOCL8eZEHdIPgON5TkwhOY+nl6I2xDgnhBQaRwyxU3Gt+VOcA=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 09:42:36 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 09:42:36 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493491.msg for ; Thu, 03 Aug 2017 09:42:35 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493491::BrGJF1ILwyKqEQxT:00000ezr X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 09:42:32 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-03.txt References: <150172769887.5751.7103181202835281364@ietfa.amsl.com> In-Reply-To: <150172769887.5751.7103181202835281364@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:42:41 -0000 I=E2=80=99ve read this document version, and I see there only a couple of w= ording improvements, no changes in the specs, so I will like to repeat my l= ast meeting opinion: It is ready to go for the last call. Saludos, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: jueves, 3 de agosto de 2017, 4:35 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-03.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Happy Eyeballs Version 2: Better Connectivity= Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-03.txt Pages : 14 Date : 2017-08-02 =20 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, client= s that attempt multiple connections in parallel have a higher chance o= f establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-03 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis-03 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ 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 use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 00:58:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AE113231F for ; Thu, 3 Aug 2017 00:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx9JdirJdgax for ; Thu, 3 Aug 2017 00:58:02 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87568126CB6 for ; Thu, 3 Aug 2017 00:58:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 18B74A6; Thu, 3 Aug 2017 09:57:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501747080; bh=FRLL9JTmFyoTZHxuu5x/PFNYfic5mtl3YUni4zI2x+M=; h=Date:From:To:Subject:From; b=R1w2lbh345JTZASncOw7afTRrlWZIL4AFfKMP3CPHaOlHduguXK0J5maDAEl4hnmm dPzFvfTBcLQxPW7lPQ35TFKathDOEnxdVnKh7jwYamaWH4/ttlS8mf65ih9nN0jDMn 50yYvxLAckmirp4QXS6U1H1G1ABhg5XmVbcI5CpY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F361AA2 for ; Thu, 3 Aug 2017 09:57:59 +0200 (CEST) Date: Thu, 3 Aug 2017 09:57:59 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:58:05 -0000 Hi, RFC7084: G-5: By default, if the IPv6 CE router is an advertising router and loses its IPv6 default router(s) and/or detects loss of connectivity on the WAN interface, it MUST explicitly invalidate itself as an IPv6 default router on each of its advertising interfaces by immediately transmitting one or more Router Advertisement messages with the "Router Lifetime" field set to zero [RFC4861]. "loses its IPv6 default router". Does this imply that if it receives a zero-lifetime RA on its WAN port, then it should perform above action? If this happens (there are no eligable routers on WAN anymore), should it also on its LAN ports send PIO with zero-lifetime/preferred for the DHCPv6-PD based prefixes it has been announcing, and invalidating the delegated PD? I think my question is: When receiving a zero-lifetime RA on WAN resulting in no router availabe on WAN, should this interface be considered "down", same as if the physical interface went down, and then all actions should be performed that are stated in RFC7084 for "WAN down" event? The context of my question is when receiving this RA on WAN: 09:54:25.400641 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::2200:ff:fe00:1 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64 hop limit 64, Flags [other stateful], pref low, router lifetime 30s, reachable time 0s, retrans time 0s source link-address option (1), length 8 (1): 20:00:00:00:00:01 0x0000: 2000 0000 0001 mtu option (5), length 8 (1): 1420 0x0000: 0000 0000 058c prefix info option (3), length 32 (4): 2003:1809:24:1500::/64, Flags [onlink, auto], valid time 60s, pref. time 50s 0x0000: 40c0 0000 003c 0000 0032 0000 0000 2003 0x0010: 1809 0024 1500 0000 0000 0000 0000 When no RA has been seen for 31 seconds (and router lifetime is now 0 as the 30s above has passed), should the router in question send (on LAN) an RA invalidating both itself as a router, and send 0 preferred lifetime for the PIOs/RIOs it's been advertising based on DHCPv6-PD prefix it has on the above WAN? >From what I can find in RFC7084, only the first part is specified, ie invalidating itself as a router. It doesn't invalidate the delegated prefix, neither from a DHCPv6 timer point of view, nor in its RAs advertised. >From how I read RFC7084, I can't blame the router vendor for doing the wrong thing... -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 01:03:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA506126CB6; Thu, 3 Aug 2017 01:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lNS7ibZgsnS; Thu, 3 Aug 2017 01:03:04 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF47C124234; Thu, 3 Aug 2017 01:03:03 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id q25so2824680uah.1; Thu, 03 Aug 2017 01:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Zldfp3GMYwHwmLnr03bcAbdzDF8f6y+4b2rNyTSrNc=; b=tOZJdvbb3L0XGO3E+e19L8NfmP7CS/fqyEkBjshFFiWzShwHh+DcXleTaPIV72m2nB yYP9f3RQdqVA43ZdTy5vsEB35Ihei6AkyhckjqwYeQpB7y+dGLMxErmqM7xd7YjgjrAU o1w1uJHjcFINjNptkKFzmSKH/TNmqvYpXMOXUkItwJNpfHbRxr/T54Q78yfJbfkmyrUX 2hMJ0Cz/IMgU7KvUJLkdR1mntHUDefJlS/1pa0fsnAn7CyqYpI95aFfdbArl1fJ8vg0o V0AS9eoZ+Uo7qoop5wFZMSMsdndABB1Hg6oMcnqyfROSIM9mq/wDRKSmnLZYd6ahHQJz qUDQ== 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=/Zldfp3GMYwHwmLnr03bcAbdzDF8f6y+4b2rNyTSrNc=; b=HeCSntLNgKEhVvLmExqwTR7kPaysc0cEyU0I0Zz3XK4MJf+9uvVZbBKZF3KWAX1jvm NwyDQBfWNeRzweJCrLs4Ks8dmnOPJ6FDbv9mbeslWErfe4gqyjId0tPuVE0TrqwRpHac bTOmYYa/bW6yGFG9qamOtptk7tMPJx/QRmK1pDC2fRgSxDqk4WvuhhaAl/ucPd5vbt6d yTfkM7aXqnusvdIyjg9Uk2rIzjr6lt/xYRTKIDngZUSUSRhkaBpAQAIqUVhft7QaOEr8 V2BVcni7lKa4g+MZWiCeU6pefrD1eew9z26yBkkszU2WVmHmBECBpXXQpisa52M1rcAY uPtA== X-Gm-Message-State: AIVw1126T/SZrkBOvytfLMWf4xETxgY5yMsbwJmpeGt0WdbzDFanmpvS fKd0cmhyycNXJ5j7P+4VL2tBnzw9Wg== X-Received: by 10.176.86.87 with SMTP id z23mr564915uaa.170.1501747383119; Thu, 03 Aug 2017 01:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 01:02:32 -0700 (PDT) In-Reply-To: <20170803073048.GJ45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> From: Mark Smith Date: Thu, 3 Aug 2017 18:02:32 +1000 Message-ID: To: Gert Doering Cc: Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:03:10 -0000 On 3 August 2017 at 17:30, Gert Doering wrote: > Hi, > > On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: >> > It is perfectly possible to run IPv6 routing without RA (even if you >> > don't normally want to do that). Check your nearest Juniper router >> > if you doubt this is possible. >> >> Where does the default router address come from, then? > > On the router? "OSPF, BGP, ..." > > On the host? "static route pointing to fe80::1%eth0" (which is the VRRP > address of your upstream router pair) > I suppose there should also be a knob to turn neighbor resolution off too, so that people can exclusively use statically configured ND cache entries in routers. Regards, Mark. From nobody Thu Aug 3 01:12:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1885132322 for ; Thu, 3 Aug 2017 01:12:01 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0n4hoQ3zxKg for ; Thu, 3 Aug 2017 01:12:00 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34DF132329 for ; Thu, 3 Aug 2017 01:11:59 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9FEC7429FE for ; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8AC45429FC; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8704935DFC; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) Date: Thu, 3 Aug 2017 10:11:57 +0200 From: Gert Doering To: Mark Smith Cc: Gert Doering , Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Message-ID: <20170803081157.GP45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJT2ufQLhymvxlcq" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:12:02 -0000 --IJT2ufQLhymvxlcq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 03, 2017 at 06:02:32PM +1000, Mark Smith wrote: > >> > It is perfectly possible to run IPv6 routing without RA (even if you > >> > don't normally want to do that). Check your nearest Juniper router > >> > if you doubt this is possible. > >> > >> Where does the default router address come from, then? > > > > On the router? "OSPF, BGP, ..." > > > > On the host? "static route pointing to fe80::1%eth0" (which is the VR= RP > > address of your upstream router pair) >=20 > I suppose there should also be a knob to turn neighbor resolution off > too, so that people can exclusively use statically configured ND cache > entries in routers. That's a different bag of worms, but indeed, a knob to replace NS/NA with something reasonable would be good. "Static ND cache" is not an exactly common request, though - but in a fully pre-defined scenario (think=20 industrial ethernet which already does away with MAC learning), this has benefits. Seriously: RAs for default router announcement work nicely for certain use cases, and are just not good enough for others, like "fast and=20 well-defined failover among multiple default gateways". But do not let me stop you from ridiculing other people's use cases - this is part of what has made IPv6 such a tremendous success, so by all means, give us more of it. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --IJT2ufQLhymvxlcq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmC2soACgkQ31bAZeTO f8XeGw//fztavJvLbBM1F341vD/7eYw1418oLqr+yV/408jGdzWR+0TWM9c4agZ3 j2xxZWT211SrGSxalF3KiFs5PLl3CmqJn8PGNG5GNbe9yF2JGuzm/ghgCeG3SfIi Ig2IjGONlBF+e2IUoM6o8KXGsUexY3bNDNqlO/goyv9hbpkYAwSC6L8QSJEu3zPA g1TJSXu5qHQLMxn09Fwh7Hha5Oezk73chc/nErSlnsoagX04PqO0XcAsr+VxBBqL D4Avk4oORY3QahKEvDNzJCgGo7LalKMxZmZMIm7ghO4mPPceONtYgqGHBDwRAm3J ZIS1J8TCQ97xnL3L0WqG1hTHpaQVMnfiHXB3nHY/ghATum4XcO+Z93R/t1fQjv6r uSBaw8Zf2OVqS+2//nLYYhRGJwjVwYaGcOjpUd4VIK1b9livSsmPOOZLn7p4Ps9g axeYEIddi4LIJmAafPYUZ/Zf9fnDgYK1Zljzw42ZlfmNXiSogvxXS7LXnRs3zwGx TvA3VA4DdqUPJQlC8W2CN7fvwkB/og9gXZ0d0KuxIUxKA+TyvL59P1vgu1kmW7Pz H+5vCDx5OYAVfglnISeMoCjdPoRo/yVPPd4+AeEkFhq7LHLOJfgUEaFfstQfu8gx l/Q7Sq+tHOh+22g7EncVC4ypaWbiwc6UQUEoAvuC4u4C2KmknXg= =Orm1 -----END PGP SIGNATURE----- --IJT2ufQLhymvxlcq-- From nobody Thu Aug 3 01:31:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E7132326 for ; Thu, 3 Aug 2017 01:31: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr4JOl2eiDIN for ; Thu, 3 Aug 2017 01:31:36 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818A4131D25 for ; Thu, 3 Aug 2017 01:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501749093; x=1502353893; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=IT7subziWKbHXSSNG1gfrTyjG tbCAKCAetNF2LT+N7c=; b=tESYC18NoZLe5QFbQZRzWYaJ87mVqarYGiSzNNduk ORT4a9+GwBLecNTi8lJ/IHkWy65hytYmsotoxgOoQqr1HSWvHZ2MWK98W034Gafr fxICwzh0cdzzh2dtPok7NC3P9ZYCle1V1zxCSm0A7kvZ1cUMC4Gly7wHi3ANMw56 U0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=XwdX9FGAqXH7RZCFri4vM4YUOL3+5uMl9W0GjHEYigbFuJYP06zkLqENh5Nr gZR0NrBwB26ktDdSj0OwJT/e8Vv0vCbsfm3NWjMMBUC/XFOBf1LZSo2p6 4c3X/FThFfw71/mcSZVSbWP2Eq3052hRz9DuqabD6OM76VDp7pUoFU=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 10:31:33 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 10:31:33 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493518.msg for ; Thu, 03 Aug 2017 10:31:32 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493518::IuyMMR2m9bucBBjy:00002bOb X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 10:31:28 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> In-Reply-To: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:31:38 -0000 Hi, I=E2=80=99ve posted a new version of this document. https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ Comments welcome! Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: jueves, 3 de agosto de 2017, 10:28 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt =20 A new version of I-D, draft-palet-v6ops-ipv6-only-01.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-ipv6-only Revision: 01 Title: IPv6-only Terminology Definition Document date: 2017-08-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= ipv6-only-01.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6= -only/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only= -01 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -ipv6-only-01 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-i= pv6-only-01 =20 Abstract: This document clarify the terminology regarding the usage of expressions such as "IPv6-only", in order to avoid confusions when using them in IETF and other documents, in reference to what is the actual functionalities being used (not the actual protocol support). =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 01:48:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38D2132326 for ; Thu, 3 Aug 2017 01:47:58 -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 IzJ9pivkQgbK for ; Thu, 3 Aug 2017 01:47:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAE13232C for ; Thu, 3 Aug 2017 01:47:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ddBnM-0000GEC; Thu, 3 Aug 2017 10:47:52 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> In-reply-to: Your message of "Thu, 03 Aug 2017 10:31:28 +0200 ." <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> Date: Thu, 03 Aug 2017 10:47:52 +0200 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:47:59 -0000 > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > Comments welcome! There is nothing IPv6-only about NAT64. So please stop doing this. The only definition of IPv6-only that makes sense in the long term is when there is no access to the IPv4 network at all. That is literally IPv6-only. Anything else is just bound to confuse people outside our small group. What we are discussing are IPv4 over IPv6 tunneling/translation techniques. From nobody Thu Aug 3 01:54:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5061321F5 for ; Thu, 3 Aug 2017 01:54:13 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPRPVlZTVENP for ; Thu, 3 Aug 2017 01:54:11 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7EF126CC4 for ; Thu, 3 Aug 2017 01:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501750450; x=1502355250; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=oqofhCZxwDbOPd6jpQp+ItIFU inM0BcX4qL+nlZzFng=; b=s+eD5pLQFi2gGGW2nUuAG9nXi0tvrBIiQU2alKJ3n 1GK42Lz9yRFvKdW7NWMVzhXqVF5idBjL/WZYpI2O3QDKjhCYuvr/H56mYzsAnOzU 514Y58p9fGSTytv/iaOPOgu4U8emVoVKi/FGVMydf2QCVW0Sm7yWrqMvhJvVn/Ev MM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=blsiQTD/vgdgVsHnlx079wHbWoyIz8U2R9Uk/jHnFLanj9wJ8d/dafvcZpSO y5KduplKX9zmdJbaG6/4tXaCtk8A4MqGXu/RBA0UOHTqDSeTMRTT5tkBC 97W/xIS779iWheO+yDAQgz4o1q0492ypLZk1K/RMSbOBjaxBlfd1oA=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 10:54:10 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 10:54:09 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493548.msg for ; Thu, 03 Aug 2017 10:54:09 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493548::QqZbPXL6bakNq0AR:00006k9o X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 10:54:08 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:54:13 -0000 I don=E2=80=99t agree. As one of the co-chairs confirmed in the last meeting (and actually somehow= called for this work), many folks even within IETF/v6ops are using IPv6-on= ly for very different things. This is creating in many situations conversations that talk about different= issues but we don=E2=80=99t realize it until we wasted too much time. I th= ink there is a need to make sure that we all use the same terminology. So, this is not about NAT64, it is about the correct usage of IPv6-only, sc= oping it to the right part/s of the network or even the complete network en= d-to-end. Anyway, let=E2=80=99s see others opinions. Regards, Jordi =20 -----Mensaje original----- De: en nombre de Philip Homburg Responder a: Fecha: jueves, 3 de agosto de 2017, 10:47 Para: CC: Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6= -only-01.txt > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ >=20 > Comments welcome! =20 There is nothing IPv6-only about NAT64. So please stop doing this. =20 The only definition of IPv6-only that makes sense in the long term is w= hen there is no access to the IPv4 network at all. That is literally IPv6-o= nly. =20 Anything else is just bound to confuse people outside our small group. =20 What we are discussing are IPv4 over IPv6 tunneling/translation techniq= ues. =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 02:32:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B145E128C81; Thu, 3 Aug 2017 02:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtLl8JFhznNp; Thu, 3 Aug 2017 02:32:39 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27216126CC4; Thu, 3 Aug 2017 02:32:39 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id q25so3636771uah.1; Thu, 03 Aug 2017 02:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o0FK8XoKFvwtp+bfdxsVr57CTPlRfkgoVxTzPIZOv6g=; b=eJOT4T8AMa4ceeUReZONuPiUYeT+nOogT6dI8b1YzuVdY3TiFlUJNwFTT94ooq7hnr yW3NIAyBb8z7BF2Hq4audqOSlgzP5pgGVazNZSV8lItIInPa1A7K/fAvVF0vaRD0DKKX EdrNBh7t+z0pdBhi38gMjyptDHrtap9kTOFlKECL8JyXs9hqwd8bcUDQQKOqvRUnNvQr F/PqH6mhsRtkSBCQJZSjgH/Nmt+hArvhEHZ0toYnZFhMnOH8M4tOP3Yr2Xwco9o8/XC3 k5LPGdLr94Wa/sAXp8p7l6Y8Jk3G/NB2A879QPkvIrca9SyAG833u9Q2nbt3A4jrI9Jd oYXw== 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=o0FK8XoKFvwtp+bfdxsVr57CTPlRfkgoVxTzPIZOv6g=; b=Qn2OvCCd3sQ3Jj7Y8XKTtdtGi/6sOMIE95yj5PtBQadzouEIRumN3X00vQOKQ1d/mO 2zAIaKGNwa18zUbyvygt058SraKLJqfeGOeoPLBPkxHVFbFLrhUZFv8zCRsvhXwwZQLE UNJZ3DvIOaExNittxBvHFqO9kMVMzrYtDLzx1zYyi4rnDOpj5fwY+/PVnGYkMyTGSt3N LeEPZQV3zOGbbJoroI2H6gWijuhEYZ+HrcRqONaBrWQwmV628LCIN0betzmVLTzchb1f OZZD+pRzFH3vm1h+AxOove9dZGIsDrS+OiOBphNyjR9rassV3Sw1W5KEj2lGrclY3386 I2RA== X-Gm-Message-State: AIVw111v9WjO3KpUMaVM0SQgNbjb00ZqCjhiavdTx1bYTphFNSGMrSqk 5YyBXHVvtAqj3Nc2+wV6ngzj74JHIw== X-Received: by 10.159.52.79 with SMTP id s15mr725421uab.157.1501752758169; Thu, 03 Aug 2017 02:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 02:32:07 -0700 (PDT) In-Reply-To: <20170803081157.GP45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> <20170803081157.GP45648@Space.Net> From: Mark Smith Date: Thu, 3 Aug 2017 19:32:07 +1000 Message-ID: To: Gert Doering Cc: Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 09:32:41 -0000 On 3 August 2017 at 18:11, Gert Doering wrote: > Hi, > > On Thu, Aug 03, 2017 at 06:02:32PM +1000, Mark Smith wrote: >> >> > It is perfectly possible to run IPv6 routing without RA (even if you >> >> > don't normally want to do that). Check your nearest Juniper router >> >> > if you doubt this is possible. >> >> >> >> Where does the default router address come from, then? >> > >> > On the router? "OSPF, BGP, ..." >> > >> > On the host? "static route pointing to fe80::1%eth0" (which is the VRRP >> > address of your upstream router pair) >> >> I suppose there should also be a knob to turn neighbor resolution off >> too, so that people can exclusively use statically configured ND cache >> entries in routers. > > That's a different bag of worms, but indeed, a knob to replace NS/NA with > something reasonable would be good. "Static ND cache" is not an exactly > common request, though - but in a fully pre-defined scenario (think > industrial ethernet which already does away with MAC learning), this > has benefits. > It would be an alternative method of mitigating ND cache attacks, which are exploiting dynamic ND cache entry creation. > > Seriously: RAs for default router announcement work nicely for certain > use cases, and are just not good enough for others, like "fast and > well-defined failover among multiple default gateways". > That's what VRRP, HSRP or GLBP are for. VRRP supporting IPv6 was specified in 2010 in RFC5798, and a search shows that Cisco have supported IPv6 in HSRP and GLBP since 2011. RAs plus NUD is going to be a poor mans or better than nothing VRRP. There was no such equivalent functionality in base IPv4. The out of the box IPv6 functionality is not better than VRRP/HSPR/GLBP, however it is better than IPv4's. > But do not let me stop you from ridiculing other people's use cases I usually understand the use cases, however I don't understand why the methods used in IPv6 must be the IPv4 methods, even though IPv6 methods exist and are deployed and are working for many people. People usually don't actually describe why the existing and widely deployed IPv6 methods cannot be used. They just assert it must be the way IPv4 worked. It's understandable because of familiarity, however things can't be improved without things being changed. Sometimes they also assert what they're objecting to is "religion". Asserting it is "religion" is implying that there was no objective or rational reasoning behind the decision (there always is), which is really just resorting to an ad hominem attack on the person they disagree with and also those who made those design and protocol decisions. Things should always be objectively evaluated here. I think blindly carrying over IPv4's practices and methods to IPv6 is closer to religion than anything that appears in IPv6 - it is saying "even though the situation and requirements have changed, we believe the old ways are and will always be the best ways". I think that is a very subjective approach. > - this > is part of what has made IPv6 such a tremendous success, so by all means, > give us more of it. > The best way to prove the IPv6 methods don't work is to deploy the IPv6 methods as they stand. If they fail, document the environment they failed in and how. Come back with that evidence, which may provide a solid reason to change how IPv6 works in that specific regard. Regards, Mark. From nobody Thu Aug 3 02:35:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372B0131D25 for ; Thu, 3 Aug 2017 02:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCNrHaAgHMKh for ; Thu, 3 Aug 2017 02:35:03 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08048131C3A for ; Thu, 3 Aug 2017 02:35:03 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id m85so10208157wma.1 for ; Thu, 03 Aug 2017 02:35:02 -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-transfer-encoding:content-language; bh=1kcV0+v8oklF+jJd7Dn858O09QKy4t00s4nvoAWBtKA=; b=oc4EWdqt7RYytQdp8D6dUSRSgA4WA9G8NqQIY5T/74+HDZ6+Z97k4Yw3j1Zc337yKC UOA9b5iGmLUon5jkd5zDJ7mk6l+yyXQBomaVuqiMJK+W02px/15y/C3od9EXgzyXhZWi iU2WIxin38z+OMJC1Q0dYopweImz/DL/+OtaGubgXuhrRxfU98XG7gQc1CGT4Ys23BI9 a/6G3BlhcpZZ7cu2QROaydUxOXRyFKUBD0uhRVnyuSQRyiQmpxpA9OCzdIVkpaxqXGCE i4AolAoU8N2xDUzR6EUS0YUK18Um/FphU9jpk+TGwz5Wt4nTP0RIzJKx2424XS/OahQr hFJQ== 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-transfer-encoding :content-language; bh=1kcV0+v8oklF+jJd7Dn858O09QKy4t00s4nvoAWBtKA=; b=Rv4lZy4TqUxzx6L4AxOJnSTeJTIPC0nPD0sYYBeaDYmcLYbZtmg3tIm50HCW3Oe6vv fRURJKWmRyvqxwk+07XIC/7ypbFOii1jevT9nUwywLwNd9tB15hPzYkITy97whAnGY8F 2OHD4ORdOdN/uAigDh07Ut1xaEo54B6u+eks21569VA3iVBb5s/V6qxNDzzP+LCP9xFy XwYWmbPTlKUuOWh9ScNcSJkLcNaL1AebTxOyQ2lie9/FEjV/W6wUpz5jL0To+YSCoHCh SwqOcQrTi/k4oXrnvKaHw52DSfPl9borgArAVgrsxt0PCTJpWNQlJEjnlYtR7JMrmjc6 vLEg== X-Gm-Message-State: AIVw112gxvoASLZPvMpvA66+Z12scNlXKA4nBH2kRHyn3O8HqebWCNo8 1JGe4hr0oWz0TFUh+ORyxg== X-Received: by 10.80.136.99 with SMTP id c32mr1253233edc.171.1501752901305; Thu, 03 Aug 2017 02:35:01 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:a4be:3fb9:bf20:21d0]) by smtp.gmail.com with ESMTPSA id n12sm881971edd.4.2017.08.03.02.35.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 02:35:00 -0700 (PDT) To: jordi.palet@consulintel.es, v6ops@ietf.org References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> From: Stephen Strowes Message-ID: <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> Date: Thu, 3 Aug 2017 11:34:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 09:35:05 -0000 I agree with this line: "we MUST NOT use the terminology "IPv6-only" in a generic way". Agreed. I find that expanding "IPv6-only" to include mechanisms such as NAT64 is contradictory and confusing. I don't think it's useful to state, for example, that an "IPv6-only access network" MAY have means to access the IPv4 network. But I do think it's useful to state that a network is, say, IPv6+NAT64. S. On 03/08/2017 10:54, JORDI PALET MARTINEZ wrote: > I don’t agree. > > As one of the co-chairs confirmed in the last meeting (and actually somehow called for this work), many folks even within IETF/v6ops are using IPv6-only for very different things. > > This is creating in many situations conversations that talk about different issues but we don’t realize it until we wasted too much time. I think there is a need to make sure that we all use the same terminology. > > So, this is not about NAT64, it is about the correct usage of IPv6-only, scoping it to the right part/s of the network or even the complete network end-to-end. > > Anyway, let’s see others opinions. > > Regards, > Jordi > > > -----Mensaje original----- > De: en nombre de Philip Homburg > Responder a: > Fecha: jueves, 3 de agosto de 2017, 10:47 > Para: > CC: > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > > > Comments welcome! > > There is nothing IPv6-only about NAT64. So please stop doing this. > > The only definition of IPv6-only that makes sense in the long term is when > there is no access to the IPv4 network at all. That is literally IPv6-only. > > Anything else is just bound to confuse people outside our small group. > > What we are discussing are IPv4 over IPv6 tunneling/translation techniques. > > > > > ********************************************** > 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 confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 3 03:50:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32376131D2C for ; Thu, 3 Aug 2017 03:50: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swcpBYI17dNP for ; Thu, 3 Aug 2017 03:50:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C8E131D27 for ; Thu, 3 Aug 2017 03:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501757419; x=1502362219; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=8gOAX5kuWDpXEwvCrYzmy6mFZ z8bRHm4TjQndvh+INI=; b=GgPHGpsHOQ/RG2L07oek3uqzh8UXxXeGdC/tC6PwC uaI3IHLrwmYNOJCbn70sT7qbEGHu0l2vxPKTnRyH8KWE5cwD76g4/zq+/eIR4+gm zdj3+NwEl2YptotgrCGNXV8fwR6gOS85lUzzKkej9cb/+oFiDbydEXYx4oOTaE5U q8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=KVcJ4oMTCpIY4DZcqGySxAXBUe9GFeTSoHJRAD9LOZqlwzonxhu+PYpCxZ6h 265hYiUH6ShZzySwgph4iodyufxTSO04/nD9Yw3MZUwbo6BNUVpxlgeoZ 3VDpy3FxuFh8FHwY3Flxl5rZEDZFa+p74AhSvFCghlMIlQfPD+77Q4=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 12:50:19 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 12:50:18 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493610.msg for ; Thu, 03 Aug 2017 12:50:18 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493610::/JDrKYj6mnnOPOBQ:00000QSq X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 12:50:14 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> In-Reply-To: <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 10:50:25 -0000 Hi Stephen, Thanks for your input. However, I=E2=80=99ve a question regarding your last paragraph, just in cas= e I=E2=80=99m not getting it correctly. If we state something such as =E2=80=9CIPv6+specific transition=E2=80=9D me= chanism (your example IPv6+NAT64), we can have =E2=80=9Ctons=E2=80=9D of po= ssible variations, instead of half a dozen or so, and in some cases, the tr= ansition mechanism can be deployed in different parts of the network (the N= AT64 can be in the core, upstream router, etc.). So I think that speaking a= bout a specific mechanism instead of which part of the network is IPv6-only= . You see my point or I=E2=80=99m missing anything? Saying it in another way, do you think the actual examples referring to wha= t specific part of the network are IPv6-only, is fine or that will miss a r= elevant part of the picture somehow? Regards, Jordi =20 -----Mensaje original----- De: Stephen Strowes Responder a: Fecha: jueves, 3 de agosto de 2017, 11:35 Para: , Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6= -only-01.txt I agree with this line: =20 "we MUST NOT use the terminology "IPv6-only" in a generic way". =20 Agreed. I find that expanding "IPv6-only" to include mechanisms such as= =20 NAT64 is contradictory and confusing. =20 I don't think it's useful to state, for example, that an "IPv6-only=20 access network" MAY have means to access the IPv4 network. But I do=20 think it's useful to state that a network is, say, IPv6+NAT64. =20 S. =20 =20 On 03/08/2017 10:54, JORDI PALET MARTINEZ wrote: > I don=E2=80=99t agree. > > As one of the co-chairs confirmed in the last meeting (and actually s= omehow called for this work), many folks even within IETF/v6ops are using I= Pv6-only for very different things. > > This is creating in many situations conversations that talk about dif= ferent issues but we don=E2=80=99t realize it until we wasted too much time= . I think there is a need to make sure that we all use the same terminology= . > > So, this is not about NAT64, it is about the correct usage of IPv6-on= ly, scoping it to the right part/s of the network or even the complete netw= ork end-to-end. > > Anyway, let=E2=80=99s see others opinions. > > Regards, > Jordi > =20 > > -----Mensaje original----- > De: en nombre de Philip Homburg > Responder a: > Fecha: jueves, 3 de agosto de 2017, 10:47 > Para: > CC: > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6op= s-ipv6-only-01.txt > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > > > Comments welcome! > =20 > There is nothing IPv6-only about NAT64. So please stop doing thi= s. > =20 > The only definition of IPv6-only that makes sense in the long te= rm is when > there is no access to the IPv4 network at all. That is literally= IPv6-only. > =20 > Anything else is just bound to confuse people outside our small = group. > =20 > What we are discussing are IPv4 over IPv6 tunneling/translation = techniques. > =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 confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 03:59:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900112708C for ; Thu, 3 Aug 2017 03:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Q_gszs5kEe for ; Thu, 3 Aug 2017 03:59:05 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE27131D2C for ; Thu, 3 Aug 2017 03:59:05 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a77so5352638qkb.0 for ; Thu, 03 Aug 2017 03:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TE5xiwIuy3nSqevMcAns7usytGpCaGtKupnYFfCiHMc=; b=g/TASz3sjBQRQUdejyrAKu+CL05aXjhD0Xsp8mfB/nTu65oRI8ZC94Zj48ZziATZJY gsYxyXPjoxzBa8m/mGPCF0XEB+46zMHnpJTqUxYsLndl5d9cREGKfxS8inxqxx37Fntn uUUsPZHqP3DR/qLjZAgIInxpoGTn4OEIFZeAg= 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=TE5xiwIuy3nSqevMcAns7usytGpCaGtKupnYFfCiHMc=; b=uob8QkhfftfvwYz3d8c2j6IvMA2BWFrYGNMek+MWRheoqOYk1whrwRtZ8M1836qy9O wEo7VsFVQTPXmTZn2VVV5c7zHhtyUGMxVqUOTTot2vpiAKYzdFDcHXj3422qCZO368r8 u1nzrSZOeabMTM+/a8wevXjWC5wYjlsJe37qzUZLQls8h/QYetMC0Jjv/6KgCozMo+qm 3+O5DT4iFgxHEaqihecvOUWaPuGQNhf6JNlaERSSLMzeex/4u7KnjbSCumQ591xwNrim IYeyEZ8jja6iyXpqRULldFNm+kO0Gjqww+E88LiiJssHoaxI6B+yrfdv/Q0LCpn+Gh+D LDyw== X-Gm-Message-State: AHYfb5jtC2WZ9iem6mmQXIntQXHsQ6uqFZNBP5w0MsOOvSLOr2O2MV74 LQj7/qy4x8ri7OerdTO74l4CHuSW7eCR X-Received: by 10.55.3.130 with SMTP id 124mr1647689qkd.31.1501757944784; Thu, 03 Aug 2017 03:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.91 with HTTP; Thu, 3 Aug 2017 03:58:44 -0700 (PDT) In-Reply-To: References: From: Timothy Winters Date: Thu, 3 Aug 2017 06:58:44 -0400 Message-ID: To: Mikael Abrahamsson Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="001a114c96e4d687e60555d74490" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 10:59:09 -0000 --001a114c96e4d687e60555d74490 Content-Type: text/plain; charset="UTF-8" Hi Mikael, On Thu, Aug 3, 2017 at 3:57 AM, Mikael Abrahamsson wrote: > > Hi, > > RFC7084: > > G-5: By default, if the IPv6 CE router is an advertising router and > loses its IPv6 default router(s) and/or detects loss of > connectivity on the WAN interface, it MUST explicitly > invalidate itself as an IPv6 default router on each of its > advertising interfaces by immediately transmitting one or more > Router Advertisement messages with the "Router Lifetime" field > set to zero [RFC4861]. > > "loses its IPv6 default router". Does this imply that if it receives a > zero-lifetime RA on its WAN port, then it should perform above action? > > If this happens (there are no eligable routers on WAN anymore), should it > also on its LAN ports send PIO with zero-lifetime/preferred for the > DHCPv6-PD based prefixes it has been announcing, and invalidating the > delegated PD? > It doesn't invalidate the PIO for IA_PD, it does send an RA with router lifetime of 0 on the LAN. The logic behind not invalidating the PIO is devices on the LAN might be communicating using the global addresses and that should still work. > > I think my question is: > > When receiving a zero-lifetime RA on WAN resulting in no router availabe > on WAN, should this interface be considered "down", same as if the physical > interface went down, and then all actions should be performed that are > stated in RFC7084 for "WAN down" event? > > > The context of my question is when receiving this RA on WAN: > > 09:54:25.400641 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) > fe80::2200:ff:fe00:1 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, > length 64 > hop limit 64, Flags [other stateful], pref low, router lifetime > 30s, reachable time 0s, retrans time 0s > source link-address option (1), length 8 (1): 20:00:00:00:00:01 > 0x0000: 2000 0000 0001 > mtu option (5), length 8 (1): 1420 > 0x0000: 0000 0000 058c > prefix info option (3), length 32 (4): 2003:1809:24:1500::/64, > Flags [onlink, auto], valid time 60s, pref. time 50s > 0x0000: 40c0 0000 003c 0000 0032 0000 0000 2003 > 0x0010: 1809 0024 1500 0000 0000 0000 0000 > > When no RA has been seen for 31 seconds (and router lifetime is now 0 as > the 30s above has passed), should the router in question send (on LAN) an > RA invalidating both itself as a router, and send 0 preferred lifetime for > the PIOs/RIOs it's been advertising based on DHCPv6-PD prefix it has on the > above WAN? > A CE Router should transmits a RA with a lifetime 0 on the LAN after the WAN times out. The IA_PD (DHCPV6) address aren't affected by this action. > > From what I can find in RFC7084, only the first part is specified, ie >> > invalidating itself as a router. It doesn't invalidate the delegated > prefix, neither from a DHCPv6 timer point of view, nor in its RAs > advertised. > > From how I read RFC7084, I can't blame the router vendor for doing the >> > wrong thing... > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114c96e4d687e60555d74490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mikael,

On Thu, Aug 3, 2017 at 3:57 AM, Mikael Abrahamsson <sw= mike@swm.pp.se> wrote:

Hi,

RFC7084:

=C2=A0 =C2=A0G-5:=C2=A0 By default, if the IPv6 CE router is an advertising= router and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loses its IPv6 default router(s) and/or d= etects loss of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connectivity on the WAN interface, it MUS= T explicitly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0invalidate itself as an IPv6 default rout= er on each of its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advertising interfaces by immediately tra= nsmitting one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Router Advertisement messages with the &q= uot;Router Lifetime" field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set to zero [RFC4861].

"loses its IPv6 default router". Does this imply that if it recei= ves a zero-lifetime RA on its WAN port, then it should perform above action= ?

If this happens (there are no eligable routers on WAN anymore), should it a= lso on its LAN ports send PIO with zero-lifetime/preferred for the DHCPv6-P= D based prefixes it has been announcing, and invalidating the delegated PD?=
It doesn't invalidate the PIO for IA_PD, it does = send an RA with router lifetime of 0 on the LAN.=C2=A0 The logic behind not= invalidating the PIO is devices on the LAN might be communicating using th= e global addresses and that should still work.=C2=A0

I think my question is:

When receiving a zero-lifetime RA on WAN resulting in no router availabe on= WAN, should this interface be considered "down", same as if the = physical interface went down, and then all actions should be performed that= are stated in RFC7084 for "WAN down" event?
=C2=A0

The context of my question is when receiving this RA on WAN:

09:54:25.400641 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) = fe80::2200:ff:fe00:1 > ff02::1: [icmp6 sum ok] ICMP6, router advertiseme= nt, length 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hop limit 64, Flags [other stateful], pref low,= router lifetime 30s, reachable time 0s, retrans time 0s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source link-address option (1), length 8= (1): 20:00:00:00:00:01
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000:=C2=A0 2000 0000 0001
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mtu option (5), length 8 (1):=C2=A0 1420=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000:=C2=A0 0000 0000 058c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix info option (3), length 32 (4): 2= 003:1809:24:1500::/64, Flags [onlink, auto], valid time 60s, pref. time 50s=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000:=C2=A0 40c0 0000 003c 0000= 0032 0000 0000 2003
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0010:=C2=A0 1809 0024 1500 0000= 0000 0000 0000

When no RA has been seen for 31 seconds (and router lifetime is now 0 as th= e 30s above has passed), should the router in question send (on LAN) an RA = invalidating both itself as a router, and send 0 preferred lifetime for the= PIOs/RIOs it's been advertising based on DHCPv6-PD prefix it has on th= e above WAN?
A CE Router should transmits a RA with a = lifetime 0 on the LAN after the =C2=A0WAN times out. =C2=A0 The IA_PD (DHCP= V6) address aren't affected by this action.

>From what I can find in RFC7084, only the first part is specified, ie
invalidating itself as a router. It doesn't invalidate the delegated pr= efix, neither from a DHCPv6 timer point of view, nor in its RAs advertised.=

>From how I read RFC7084, I can't blame the router vendor for doing the =
wrong thing...

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--

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

--001a114c96e4d687e60555d74490-- From nobody Thu Aug 3 04:40:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD37131EA0 for ; Thu, 3 Aug 2017 04:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcPBHZzeHZdu for ; Thu, 3 Aug 2017 04:40:28 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDA3131DAC for ; Thu, 3 Aug 2017 04:40:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1F795A6; Thu, 3 Aug 2017 13:40:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501760426; bh=mSgL7co3WGb3JXkLl5RpE3XfmfhBYnWvJOlmzCSNRcw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=s6Df+hz+mkNuqp+GRdk/G0yn297UHlkFYRleuDOh7jMAAikdmjTYVt1iNihSQnVwl F+kBNKbEZ29M10+TIyRlZzPLGmYpbw2o/jWuXhfTHJ3m3y89+vJFZM3wGNCcoQ6uZz fzCaGWT6WnQb1iHGSY0HO9wJA4lkiA9Gg0F1rSMo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0852BA3; Thu, 3 Aug 2017 13:40:26 +0200 (CEST) Date: Thu, 3 Aug 2017 13:40:26 +0200 (CEST) From: Mikael Abrahamsson To: Timothy Winters cc: IPv6 Operations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 11:40:31 -0000 On Thu, 3 Aug 2017, Timothy Winters wrote: > It doesn't invalidate the PIO for IA_PD, it does send an RA with router > lifetime of 0 on the LAN. The logic behind not invalidating the PIO is > devices on the LAN might be communicating using the global addresses and > that should still work. Ok, makes sense. Causes me problems though. > A CE Router should transmits a RA with a lifetime 0 on the LAN after the > WAN times out. The IA_PD (DHCPV6) address aren't affected by this action. The problem here is that when the WAN connectivity is then re-provisioned and it starts to receive RAs from a different router, it never invalidates the PD. It just keeps sitting there until it times out. This is typically after 120 seconds (we have pretty low timers on that thing as well). So basically I have no way to cut down the time it takes to get things going again below the 3-5 minutes I am at right now. (the use-case is that we have a customer service portal the customer ends up in if there is no service configured on the port, and I'm trying to cut down the time it takes for everything to settle down again in fully working "Internet mode" which involves asking for new PD, letting old one time out etc. Now, if I could only do PD with a mechanism where I can immediately update the host that "this is not valid anymore" instead of waiting for the device to poll, or the resource times out. :( -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 04:55:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5666131EAA for ; Thu, 3 Aug 2017 04:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7R6Xg2KoQTi for ; Thu, 3 Aug 2017 04:55:17 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5159C131EA7 for ; Thu, 3 Aug 2017 04:55:17 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t201so13136492wmt.1 for ; Thu, 03 Aug 2017 04:55:17 -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-transfer-encoding:content-language; bh=lC5fUDwWjUcUESEqUD5lh/AJhbxj7DdkKLwy0ymoY9I=; b=mB7a9Su5gxmvM99tvau3X3TIbejJl+hTN2Bpjl0NylLoayUedbFO0aZVsTp4qQr9Uv ANGw/TWf7mTHZJCdFe+0DWPtPg0mBXKH9EiKQ/5Kmkei8DMdhAaqLuHRyEqWc7vLcQf8 H8olOv/kW8KXFVuPAZarfv3oVSLIeB0JGs+bG0f0wIMiTuJk4QzUvjOYVb+1zPgShXwQ 5/ddCYQHO0vLc8esKod7E4NH9Kn88vGX8hNiy7ym7OvjkKadostI1Bb1RN/h2pZpKCGd GJctQQksatphnhvmInG0TcvCFXKWEqkVhDge2Og9gvVbmPj+vggC4MYN3z16lH1zpKu7 sQ9g== 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-transfer-encoding :content-language; bh=lC5fUDwWjUcUESEqUD5lh/AJhbxj7DdkKLwy0ymoY9I=; b=BGvDLD/O5Qkd9aOycFsilZOfo0lzYAyKWNuByE8Y66C9o0TQCb8wbCvdXUOH1XQtxG I00cUXCIgBKdblXfxNxlABAG/zoXDZM/UbZ/GwWgGiAms+3oFq2ESmlRkY/Y9vLRhwQk q0hnHYSeV4giLYi32oAtx8fDg/58YvCtzCw8320Z1xXUjKoOHLoHyzaqEChwsKhS1EPW 6fe1cdFNzOim+tdxtv25pbjid5LxNUcLZzCq908rJMi4MHp312PvtA17kTccgrfqWPZm EfzeSYsqFmcaTsCiLXoWZY2z65t9r3Vq9QClH7FBjldoEHcS4KOmfbNLyf0lL4j2Xkpg 8VEg== X-Gm-Message-State: AIVw110RRAiwzEsozUEUVvOLyZX2BSKI4nCK4GhlqXVi8uzpjEmnQHd/ E/JeajVooJ0TvegIUjk= X-Received: by 10.80.172.37 with SMTP id v34mr1599728edc.141.1501761315536; Thu, 03 Aug 2017 04:55:15 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:a4be:3fb9:bf20:21d0]) by smtp.gmail.com with ESMTPSA id v5sm943850ede.75.2017.08.03.04.55.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 04:55:15 -0700 (PDT) To: jordi.palet@consulintel.es, v6ops@ietf.org References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> From: Stephen Strowes Message-ID: Date: Thu, 3 Aug 2017 13:55:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 11:55:20 -0000 Hi, On 03/08/2017 12:50, JORDI PALET MARTINEZ wrote: > However, I’ve a question regarding your last paragraph, just in case I’m not getting it correctly. > > If we state something such as “IPv6+specific transition” mechanism (your example IPv6+NAT64), we can have “tons” of possible variations, instead of half a dozen or so, and in some cases, the transition mechanism can be deployed in different parts of the network (the NAT64 can be in the core, upstream router, etc.). So I think that speaking about a specific mechanism instead of which part of the network is IPv6-only. You see my point or I’m missing anything? I see your point but I'm not suggesting a combinatorial approach to describing networks. I am suggesting that if you describe an IPv6 network which offers a means to reach v4 networks as "IPv6-only", then the terminology is wrong. Section 5 refers to cellular networks, devices, and transition technologies. Although I know I can look at some of these networks and describe traffic in and out of my device as being IPv6-only, to refer to those networks as "IPv6-only" would be misleading. I can't imagine that description would ever be useful to folks outside of some very specific contexts. S. > > > -----Mensaje original----- > De: Stephen Strowes > Responder a: > Fecha: jueves, 3 de agosto de 2017, 11:35 > Para: , > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt > > I agree with this line: > > "we MUST NOT use the terminology "IPv6-only" in a generic way". > > Agreed. I find that expanding "IPv6-only" to include mechanisms such as > NAT64 is contradictory and confusing. > > I don't think it's useful to state, for example, that an "IPv6-only > access network" MAY have means to access the IPv4 network. But I do > think it's useful to state that a network is, say, IPv6+NAT64. > > S. > > > On 03/08/2017 10:54, JORDI PALET MARTINEZ wrote: > > I don’t agree. > > > > As one of the co-chairs confirmed in the last meeting (and actually somehow called for this work), many folks even within IETF/v6ops are using IPv6-only for very different things. > > > > This is creating in many situations conversations that talk about different issues but we don’t realize it until we wasted too much time. I think there is a need to make sure that we all use the same terminology. > > > > So, this is not about NAT64, it is about the correct usage of IPv6-only, scoping it to the right part/s of the network or even the complete network end-to-end. > > > > Anyway, let’s see others opinions. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: en nombre de Philip Homburg > > Responder a: > > Fecha: jueves, 3 de agosto de 2017, 10:47 > > Para: > > CC: > > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt > > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > > > > > Comments welcome! > > > > There is nothing IPv6-only about NAT64. So please stop doing this. > > > > The only definition of IPv6-only that makes sense in the long term is when > > there is no access to the IPv4 network at all. That is literally IPv6-only. > > > > Anything else is just bound to confuse people outside our small group. > > > > What we are discussing are IPv4 over IPv6 tunneling/translation techniques. > > > > > > > > > > ********************************************** > > 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 confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > ********************************************** > 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 confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 3 05:05:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78013235B for ; Thu, 3 Aug 2017 05:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpneFvPJGIzw for ; Thu, 3 Aug 2017 05:05:41 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D17132359 for ; Thu, 3 Aug 2017 05:05:41 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id a18so6162500qta.0 for ; Thu, 03 Aug 2017 05:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1nDUAV3S1YpY79+iwvEjqWZYghq1G0ufOYfOMhj7wBg=; b=bZpOoKQjMFh+C6bR4AOSungjPSjN44Vap2uK81r40/dA8mRxvF3dpRZTcxJ69XlYE2 UBsQwgbFKykPG3ltadRsJViMoY91DS+rknmOsZ67O7eC0DqLl2A9l0L39fHjwQiMaLGq +88Pc69XOhu6o96EA+s1+ag5bpewgJUE/4exY= 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=1nDUAV3S1YpY79+iwvEjqWZYghq1G0ufOYfOMhj7wBg=; b=sIc4eXul+Xr0ruR8knSjA+JGMIwkrOdm8bPPr7zJ2zzdpOuI5fC/dOHrVfBg0ky/lF t/zQnTg3itg6qe35F1IKIucnSQGEU+oaMIKZrjiltJYaBYnDYhsKXwPH/rnpmFtBYehQ Q9PUNJ27oiM8JxDkSDFYNC385eYlj+K7HpQqPcTEk1zMveZhLEGC7SspkNki7lSfoCVo 2Q8zsTsGLRBUGo60e/AT8TwBeJTkhFF4dmt+koW2NwkOmFtojBnSgQ/u/sUMhmjnK346 XBSeW+YDYdeBvQD2Wl5tNPaelyrQfbCd+vbWqMD7I8YFQfCo2GZs+1ENDwq5+jThd/ZT /KYA== X-Gm-Message-State: AIVw113RWq5/Pc7S5dPGFRCW+KHqCu5/cNvTiWEmKoTv/wbEL8Jsdud9 gXFp5j0n+8I0atW/a1YloZ+Lo15HdABFNgQ= X-Received: by 10.200.0.65 with SMTP id i1mr1830764qtg.193.1501761940751; Thu, 03 Aug 2017 05:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.91 with HTTP; Thu, 3 Aug 2017 05:05:19 -0700 (PDT) In-Reply-To: References: From: Timothy Winters Date: Thu, 3 Aug 2017 08:05:19 -0400 Message-ID: To: Mikael Abrahamsson Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="f403045ee68e0424c80555d83322" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:05:43 -0000 --f403045ee68e0424c80555d83322 Content-Type: text/plain; charset="UTF-8" Hi Mikael, Yea there isn't much that can be done if IA_PD has been invalidated other then timeout. Meaning the DHCPv6 Server needs to give it a IA_PD lifetime of 0. A DHCPv6 Reconfigure/Rebind it will still keep the IA_PD until it times out unless a server explicitly times it out. A solution that comes to mind, is a host gets two global addresses it might help in the future if they implemented something like ( https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01). A Host would choose the lifetime with a higher lifetime. Regards, Tim On Thu, Aug 3, 2017 at 7:40 AM, Mikael Abrahamsson wrote: > On Thu, 3 Aug 2017, Timothy Winters wrote: > > It doesn't invalidate the PIO for IA_PD, it does send an RA with router >> lifetime of 0 on the LAN. The logic behind not invalidating the PIO is >> devices on the LAN might be communicating using the global addresses and >> that should still work. >> > > Ok, makes sense. Causes me problems though. > > A CE Router should transmits a RA with a lifetime 0 on the LAN after the >> WAN times out. The IA_PD (DHCPV6) address aren't affected by this >> action. >> > > The problem here is that when the WAN connectivity is then re-provisioned > and it starts to receive RAs from a different router, it never invalidates > the PD. It just keeps sitting there until it times out. This is typically > after 120 seconds (we have pretty low timers on that thing as well). > > So basically I have no way to cut down the time it takes to get things > going again below the 3-5 minutes I am at right now. (the use-case is that > we have a customer service portal the customer ends up in if there is no > service configured on the port, and I'm trying to cut down the time it > takes for everything to settle down again in fully working "Internet mode" > which involves asking for new PD, letting old one time out etc. > > Now, if I could only do PD with a mechanism where I can immediately update > the host that "this is not valid anymore" instead of waiting for the device > to poll, or the resource times out. :( > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --f403045ee68e0424c80555d83322 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mikael,

Yea there isn't much tha= t can be done if IA_PD has been invalidated other then timeout. =C2=A0 =C2= =A0Meaning the DHCPv6 Server needs to give it a IA_PD lifetime of 0. =C2=A0= A DHCPv6 Reconfigure/Rebind it will still keep the IA_PD until it times ou= t unless a server explicitly times it out.

A solut= ion that comes to mind, is a host gets two global addresses it might help i= n the future if they implemented something like (https://tools.ietf.org= /html/draft-linkova-v6ops-conditional-ras-01). =C2=A0 A Host would choo= se the lifetime with a higher lifetime.

Regards,
Tim

On Thu, Aug 3, 2017 at 7:40 AM, Mikael Abrahamsson <swmike@swm.pp.se= > wrote:
O= n Thu, 3 Aug 2017, Timothy Winters wrote:

It doesn't invalidate the PIO for IA_PD, it does send an RA with router= lifetime of 0 on the LAN.=C2=A0 The logic behind not invalidating the PIO = is devices on the LAN might be communicating using the global addresses and= that should still work.

 Ok, makes sense. Causes me problems though.

A CE Router should transmits a RA with a lifetime 0 on the LAN after the WAN times out.=C2=A0 =C2=A0The IA_PD (DHCPV6) address aren't affected b= y this action.

 The problem here is that when the WAN connectivity is then re-provisioned a= nd it starts to receive RAs from a different router, it never invalidates t= he PD. It just keeps sitting there until it times out. This is typically af= ter 120 seconds (we have pretty low timers on that thing as well).

So basically I have no way to cut down the time it takes to get things goin= g again below the 3-5 minutes I am at right now. (the use-case is that we h= ave a customer service portal the customer ends up in if there is no servic= e configured on the port, and I'm trying to cut down the time it takes = for everything to settle down again in fully working "Internet mode&qu= ot; which involves asking for new PD, letting old one time out etc.

Now, if I could only do PD with a mechanism where I can immediately update = the host that "this is not valid anymore" instead of waiting for = the device to poll, or the resource times out. :(


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se



--
=

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

--f403045ee68e0424c80555d83322-- From nobody Thu Aug 3 05:11:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CC413203D for ; Thu, 3 Aug 2017 05:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xNptxHHhf9u for ; Thu, 3 Aug 2017 05:11:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA5F13202D for ; Thu, 3 Aug 2017 05:11:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 59204A6; Thu, 3 Aug 2017 14:11:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501762291; bh=tm0dagxyR4vOA+BeroXWaTQMnNyatyemJxvGZI6uiz0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2ozs/tl9Jbqa9QIcMOprVQuJf78PkvB/VzzP6vJJISBFRvWI1335Pv0yo/P5qFA+4 aYH2LWeD8+jnTjfBP80CAgzuUkiPYUO7/OcOPPG7JwSjNIIFgxjchNkV90s7xrUWf2 0h6Dv5u5mRf7gMN6XWl3TugUhATJ8cXCiltEN+pE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3F93EA3; Thu, 3 Aug 2017 14:11:31 +0200 (CEST) Date: Thu, 3 Aug 2017 14:11:31 +0200 (CEST) From: Mikael Abrahamsson To: Timothy Winters cc: IPv6 Operations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:11:35 -0000 On Thu, 3 Aug 2017, Timothy Winters wrote: > A solution that comes to mind, is a host gets two global addresses it > might help in the future if they implemented something like ( > https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01). A > Host would choose the lifetime with a higher lifetime. Yes, you're right, as soon as a new PD is available and PIOs are sent for that, hosts will start to use those addresses instead. The problem is that the DHCPv6-PD request process isn't triggered by WAN router RA timing out and potentially new router RAs showing up with different prefix? What controls the PD timeout is its own timers, and as far as I know, this is in no way affected by what RAs are seen on WAN. It would be an operational change to say "look, if WAN prefix changed, perhaps you should re-do the PD request process just in case?" This would require no protocol change, it's just a recommendation based on what's seen on the WAN? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 05:12:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2545131D38 for ; Thu, 3 Aug 2017 05:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDIO6IjUz3tk for ; Thu, 3 Aug 2017 05:12:02 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B3E129AF6 for ; Thu, 3 Aug 2017 05:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501762320; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=E6Q4AVvm5QuYZwNuO9/32LcBEfaMV6J2kTlHHQdmhwI=; b=axcCAsSgYabxUb/zX9NiK+zuQ3KwtuBwbckATqlZgoXObllLcsLdaYUQO3ciV1Mxni4tqv7vIiPLL8UN+tBU5beLM8xzJ47TKqM2jRpqjhaM1xW+PFhmBhwtmcvwMuxAC4Qo2bbVsx6bbQoBSWGEsDqD+V1JXqFGaqUyE+r46nE= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0149.outbound.protection.outlook.com [213.199.154.149]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-83-Lq7AtavVOSW99Sg-aUW9GQ-1; Thu, 03 Aug 2017 13:11:55 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0693.eurprd07.prod.outlook.com (10.160.6.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Thu, 3 Aug 2017 12:11:54 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.010; Thu, 3 Aug 2017 12:11:53 +0000 From: Tim Chown To: Stephen Strowes CC: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt Thread-Index: AQHTDDL87xkCaiH0dkKYEdIWB35TqKJyUiMWgAABmQCAAAtqgIAAFQYAgAASKQCAAASmAA== Date: Thu, 3 Aug 2017 12:11:53 +0000 Message-ID: References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:2c19:c7da:71cb:5b8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0693; 20:ofzHmi0WoCHI8tnt3yoYZkEDJh2FppcyUiInwpgMZSvId4OYPn1z20wK195kGOh1YoUfhCDW6XsnxYbf5ittTgRlOfCoQQnOLeb9Yvr2hMmaxW3nX/id4Gpgp3RWhQBjon56PUUWcaXkw+dhgxCXeRLMz0W1BZGR6JyGqq7A9Xk= x-ms-office365-filtering-correlation-id: 6493b976-6bdf-4097-e80b-08d4da68d452 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0693; x-ms-traffictypediagnostic: AM3PR07MB0693: x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0693; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0693; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(189002)(24454002)(59124004)(51444003)(199003)(52314003)(3280700002)(478600001)(7736002)(7110500001)(97736004)(5890100001)(5250100002)(189998001)(74482002)(229853002)(53546010)(14454004)(36756003)(86362001)(8676002)(2900100001)(82746002)(966005)(6116002)(5660300001)(72206003)(230783001)(6506006)(83716003)(6486002)(102836003)(105586002)(33656002)(6246003)(4326008)(53936002)(15650500001)(2420400007)(53386004)(110136004)(38730400002)(93886004)(101416001)(39060400002)(6306002)(6436002)(106356001)(2950100002)(81156014)(68736007)(81166006)(54906002)(10710500007)(25786009)(42882006)(305945005)(50226002)(8936002)(3660700001)(99286003)(76176999)(2906002)(6916009)(57306001)(6512007)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0693; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 12:11:53.8645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0693 X-MC-Unique: Lq7AtavVOSW99Sg-aUW9GQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:12:06 -0000 T24gMyBBdWcgMjAxNywgYXQgMTI6NTUsIFN0ZXBoZW4gU3Ryb3dlcyA8c3RlcGhlbi5zdHJvd2Vz QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IE9uIDAzLzA4LzIwMTcgMTI6NTAs IEpPUkRJIFBBTEVUIE1BUlRJTkVaIHdyb3RlOg0KPj4gSG93ZXZlciwgSeKAmXZlIGEgcXVlc3Rp b24gcmVnYXJkaW5nIHlvdXIgbGFzdCBwYXJhZ3JhcGgsIGp1c3QgaW4gY2FzZSBJ4oCZbSBub3Qg Z2V0dGluZyBpdCBjb3JyZWN0bHkuDQo+PiANCj4+IElmIHdlIHN0YXRlIHNvbWV0aGluZyBzdWNo IGFzIOKAnElQdjYrc3BlY2lmaWMgdHJhbnNpdGlvbuKAnSBtZWNoYW5pc20gKHlvdXIgZXhhbXBs ZSBJUHY2K05BVDY0KSwgd2UgY2FuIGhhdmUg4oCcdG9uc+KAnSBvZiBwb3NzaWJsZSB2YXJpYXRp b25zLCBpbnN0ZWFkIG9mIGhhbGYgYSBkb3plbiBvciBzbywgYW5kIGluIHNvbWUgY2FzZXMsIHRo ZSB0cmFuc2l0aW9uIG1lY2hhbmlzbSBjYW4gYmUgZGVwbG95ZWQgaW4gZGlmZmVyZW50IHBhcnRz IG9mIHRoZSBuZXR3b3JrICh0aGUgTkFUNjQgY2FuIGJlIGluIHRoZSBjb3JlLCB1cHN0cmVhbSBy b3V0ZXIsIGV0Yy4pLiBTbyBJIHRoaW5rIHRoYXQgc3BlYWtpbmcgYWJvdXQgYSBzcGVjaWZpYyBt ZWNoYW5pc20gaW5zdGVhZCBvZiB3aGljaCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGlzIElQdjYtb25s eS4gWW91IHNlZSBteSBwb2ludCBvciBJ4oCZbSBtaXNzaW5nIGFueXRoaW5nPw0KPiANCj4gSSBz ZWUgeW91ciBwb2ludCBidXQgSSdtIG5vdCBzdWdnZXN0aW5nIGEgY29tYmluYXRvcmlhbCBhcHBy b2FjaCB0byBkZXNjcmliaW5nIG5ldHdvcmtzLg0KPiANCj4gSSBhbSBzdWdnZXN0aW5nIHRoYXQg aWYgeW91IGRlc2NyaWJlIGFuIElQdjYgbmV0d29yayB3aGljaCBvZmZlcnMgYSBtZWFucyB0byBy ZWFjaCB2NCBuZXR3b3JrcyBhcyAiSVB2Ni1vbmx5IiwgdGhlbiB0aGUgdGVybWlub2xvZ3kgaXMg d3JvbmcuDQo+IA0KPiBTZWN0aW9uIDUgcmVmZXJzIHRvIGNlbGx1bGFyIG5ldHdvcmtzLCBkZXZp Y2VzLCBhbmQgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMuIEFsdGhvdWdoIEkga25vdyBJIGNhbiBs b29rIGF0IHNvbWUgb2YgdGhlc2UgbmV0d29ya3MgYW5kIGRlc2NyaWJlIHRyYWZmaWMgaW4gYW5k IG91dCBvZiBteSBkZXZpY2UgYXMgYmVpbmcgSVB2Ni1vbmx5LCB0byByZWZlciB0byB0aG9zZSBu ZXR3b3JrcyBhcyAiSVB2Ni1vbmx5IiB3b3VsZCBiZSBtaXNsZWFkaW5nLiBJIGNhbid0IGltYWdp bmUgdGhhdCBkZXNjcmlwdGlvbiB3b3VsZCBldmVyIGJlIHVzZWZ1bCB0byBmb2xrcyBvdXRzaWRl IG9mIHNvbWUgdmVyeSBzcGVjaWZpYyBjb250ZXh0cy4NCg0KSSBzdXBwb3NlIGFub3RoZXIgd2F5 IG9mIGxvb2tpbmcgYXQgaXQgaXMgdG8gYXNrIG9uIHdoaWNoIGVsZW1lbnRzIG9mIGEgbmV0d29y ayBJUHY0IHN1cHBvcnQgY2FuIGJlIGRyb3BwZWQsIHNvIHRoYXQgb25seSBJUHY2IHBhY2tldHMg YXJlIGNhcnJpZWQsIGFuZCBvbmx5IElQdjYgbmVlZHMgdG8gYmUgY29uZmlndXJlZCBhbmQgbWFu YWdlZC4NCg0KSW4gdGhhdCBzZW5zZSwgYSBuZXR3b3JrIGNhbiBiZSAiSVB2NiBvbmx54oCdIGV2 ZW4gdGhvdWdoIGN1c3RvbWVyIElQdjQgdHJhZmZpYyBpcyBiZWluZyB0dW5uZWxsZWQgb3IgdHJh bnNsYXRlZCAoZWl0aGVyIGRvdWJsZSB3aXRoIENMQVQsIG9yIHNpbmdsZSB3aXRoIEROUzY0IHNo ZW5hbmlnYW5zKSB0aHJvdWdoIGl0Lg0KDQpUaW0NCg0KPiANCj4+ICANCj4+IC0tLS0tTWVuc2Fq ZSBvcmlnaW5hbC0tLS0tDQo+PiBEZTogU3RlcGhlbiBTdHJvd2VzIDxzdGVwaGVuLnN0cm93ZXNA Z21haWwuY29tPg0KPj4gUmVzcG9uZGVyIGE6IDxzdGVwaGVuLnN0cm93ZXNAZ21haWwuY29tPg0K Pj4gRmVjaGE6IGp1ZXZlcywgMyBkZSBhZ29zdG8gZGUgMjAxNywgMTE6MzUNCj4+IFBhcmE6IDxq b3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4sIDx2Nm9wc0BpZXRmLm9yZz4NCj4+IEFzdW50bzog UmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGFsZXQt djZvcHMtaXB2Ni1vbmx5LTAxLnR4dA0KPj4gDQo+PiAgICAgSSBhZ3JlZSB3aXRoIHRoaXMgbGlu ZToNCj4+ICAgICAgICAgICJ3ZSBNVVNUIE5PVCB1c2UgdGhlIHRlcm1pbm9sb2d5ICJJUHY2LW9u bHkiIGluIGEgZ2VuZXJpYyB3YXkiLg0KPj4gICAgICAgICAgQWdyZWVkLiBJIGZpbmQgdGhhdCBl eHBhbmRpbmcgIklQdjYtb25seSIgdG8gaW5jbHVkZSBtZWNoYW5pc21zIHN1Y2ggYXMNCj4+ICAg ICBOQVQ2NCBpcyBjb250cmFkaWN0b3J5IGFuZCBjb25mdXNpbmcuDQo+PiAgICAgICAgICBJIGRv bid0IHRoaW5rIGl0J3MgdXNlZnVsIHRvIHN0YXRlLCBmb3IgZXhhbXBsZSwgdGhhdCBhbiAiSVB2 Ni1vbmx5DQo+PiAgICAgYWNjZXNzIG5ldHdvcmsiIE1BWSBoYXZlIG1lYW5zIHRvIGFjY2VzcyB0 aGUgSVB2NCBuZXR3b3JrLiBCdXQgSSBkbw0KPj4gICAgIHRoaW5rIGl0J3MgdXNlZnVsIHRvIHN0 YXRlIHRoYXQgYSBuZXR3b3JrIGlzLCBzYXksIElQdjYrTkFUNjQuDQo+PiAgICAgICAgICBTLg0K Pj4gICAgICAgICAgICAgICBPbiAwMy8wOC8yMDE3IDEwOjU0LCBKT1JESSBQQUxFVCBNQVJUSU5F WiB3cm90ZToNCj4+ICAgICA+IEkgZG9u4oCZdCBhZ3JlZS4NCj4+ICAgICA+DQo+PiAgICAgPiBB cyBvbmUgb2YgdGhlIGNvLWNoYWlycyBjb25maXJtZWQgaW4gdGhlIGxhc3QgbWVldGluZyAoYW5k IGFjdHVhbGx5IHNvbWVob3cgY2FsbGVkIGZvciB0aGlzIHdvcmspLCBtYW55IGZvbGtzIGV2ZW4g d2l0aGluIElFVEYvdjZvcHMgYXJlIHVzaW5nIElQdjYtb25seSBmb3IgdmVyeSBkaWZmZXJlbnQg dGhpbmdzLg0KPj4gICAgID4NCj4+ICAgICA+IFRoaXMgaXMgY3JlYXRpbmcgaW4gbWFueSBzaXR1 YXRpb25zIGNvbnZlcnNhdGlvbnMgdGhhdCB0YWxrIGFib3V0IGRpZmZlcmVudCBpc3N1ZXMgYnV0 IHdlIGRvbuKAmXQgcmVhbGl6ZSBpdCB1bnRpbCB3ZSB3YXN0ZWQgdG9vIG11Y2ggdGltZS4gSSB0 aGluayB0aGVyZSBpcyBhIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgd2UgYWxsIHVzZSB0aGUgc2Ft ZSB0ZXJtaW5vbG9neS4NCj4+ICAgICA+DQo+PiAgICAgPiBTbywgdGhpcyBpcyBub3QgYWJvdXQg TkFUNjQsIGl0IGlzIGFib3V0IHRoZSBjb3JyZWN0IHVzYWdlIG9mIElQdjYtb25seSwgc2NvcGlu ZyBpdCB0byB0aGUgcmlnaHQgcGFydC9zIG9mIHRoZSBuZXR3b3JrIG9yIGV2ZW4gdGhlIGNvbXBs ZXRlIG5ldHdvcmsgZW5kLXRvLWVuZC4NCj4+ICAgICA+DQo+PiAgICAgPiBBbnl3YXksIGxldOKA mXMgc2VlIG90aGVycyBvcGluaW9ucy4NCj4+ICAgICA+DQo+PiAgICAgPiBSZWdhcmRzLA0KPj4g ICAgID4gSm9yZGkNCj4+ICAgICA+DQo+PiAgICAgPg0KPj4gICAgID4gLS0tLS1NZW5zYWplIG9y aWdpbmFsLS0tLS0NCj4+ICAgICA+IERlOiA8cGNoLWI3OTAwRkEzREB1LTEucGhpY29oLmNvbT4g ZW4gbm9tYnJlIGRlIFBoaWxpcCBIb21idXJnIDxwY2gtdjZvcHMtN0B1LTEucGhpY29oLmNvbT4N Cj4+ICAgICA+IFJlc3BvbmRlciBhOiA8cGNoLXY2b3BzLTdAdS0xLnBoaWNvaC5jb20+DQo+PiAg ICAgPiBGZWNoYToganVldmVzLCAzIGRlIGFnb3N0byBkZSAyMDE3LCAxMDo0Nw0KPj4gICAgID4g UGFyYTogPHY2b3BzQGlldGYub3JnPg0KPj4gICAgID4gQ0M6IDxqb3JkaS5wYWxldEBjb25zdWxp bnRlbC5lcz4NCj4+ICAgICA+IEFzdW50bzogUmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcGFsZXQtdjZvcHMtaXB2Ni1vbmx5LTAxLnR4dA0KPj4gICAg ID4NCj4+ICAgICA+ICAgICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1wYWxldC12Nm9wcy1pcHY2LW9ubHkvDQo+PiAgICAgPiAgICAgID4NCj4+ICAgICA+ICAgICAg PiBDb21tZW50cyB3ZWxjb21lIQ0KPj4gICAgID4NCj4+ICAgICA+ICAgICAgVGhlcmUgaXMgbm90 aGluZyBJUHY2LW9ubHkgYWJvdXQgTkFUNjQuIFNvIHBsZWFzZSBzdG9wIGRvaW5nIHRoaXMuDQo+ PiAgICAgPg0KPj4gICAgID4gICAgICBUaGUgb25seSBkZWZpbml0aW9uIG9mIElQdjYtb25seSB0 aGF0IG1ha2VzIHNlbnNlIGluIHRoZSBsb25nIHRlcm0gaXMgd2hlbg0KPj4gICAgID4gICAgICB0 aGVyZSBpcyBubyBhY2Nlc3MgdG8gdGhlIElQdjQgbmV0d29yayBhdCBhbGwuIFRoYXQgaXMgbGl0 ZXJhbGx5IElQdjYtb25seS4NCj4+ICAgICA+DQo+PiAgICAgPiAgICAgIEFueXRoaW5nIGVsc2Ug aXMganVzdCBib3VuZCB0byBjb25mdXNlIHBlb3BsZSBvdXRzaWRlIG91ciBzbWFsbCBncm91cC4N Cj4+ICAgICA+DQo+PiAgICAgPiAgICAgIFdoYXQgd2UgYXJlIGRpc2N1c3NpbmcgYXJlIElQdjQg b3ZlciBJUHY2IHR1bm5lbGluZy90cmFuc2xhdGlvbiB0ZWNobmlxdWVzLg0KPj4gICAgID4NCj4+ ICAgICA+DQo+PiAgICAgPg0KPj4gICAgID4NCj4+ICAgICA+ICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+ICAgICA+IElQdjQgaXMgb3Zlcg0KPj4gICAg ID4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+PiAgICAgPiBodHRwOi8v d3d3LmNvbnN1bGludGVsLmVzDQo+PiAgICAgPiBUaGUgSVB2NiBDb21wYW55DQo+PiAgICAgPg0K Pj4gICAgID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hp Y2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMg aW50ZW5kZWQgdG8gYmUgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJv dmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBh bnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBwcm9o aWJpdGVkLg0KPj4gICAgID4NCj4+ICAgICA+DQo+PiAgICAgPg0KPj4gICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAgICA+IHY2b3BzIG1h aWxpbmcgbGlzdA0KPj4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4+ICAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4+ICAgICAgICAgIA0KPj4gDQo+PiAN Cj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IElQ djQgaXMgb3Zlcg0KPj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+PiBo dHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQo+PiBUaGUgSVB2NiBDb21wYW55DQo+PiANCj4+IFRo aXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRv IGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMg aW5mb3JtYXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4+ IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQo= From nobody Thu Aug 3 05:25:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD8131ECE for ; Thu, 3 Aug 2017 05:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 e9RI5ut6CvCv for ; Thu, 3 Aug 2017 05:24:59 -0700 (PDT) Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) (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 79729131EB9 for ; Thu, 3 Aug 2017 05:24:58 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id v73COtDj001556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Aug 2017 08:24:55 -0400 Received: (qmail 15798 invoked by uid 0); 3 Aug 2017 12:24:55 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 3 Aug 2017 12:24:55 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 03 Aug 2017 08:24:49 -0400 From: Lee Howard To: Nick Hilliard , Fred Baker CC: IPv6 Ops WG , 6man WG , Message-ID: Thread-Topic: [v6ops] Turning on IPv6 Routers References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> In-Reply-To: <5970CB51.3090806@foobar.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:25:01 -0000 On 7/20/17, 5:25 PM, "v6ops on behalf of Nick Hilliard" wrote: >Fred Baker wrote: >> "If IPv4 router operation is enabled by default, enable IPv6 router >> operation by default." > >this is undoubtedly well-intentioned, and the idealist bit in me >sympathises with the principal. However with my enable hat on, a >recommendation like this isn't going to fix any problem associated with >ipv6 adoption. I completely disagree, but it=E2=80=99s dependent on where the router exists. For a home gateway router, =E2=80=9CIPv6 on by default=E2=80=9D would increase the numb= er of people using IPv6, although I have no way to estimate the impact. For an enterprise edge router, =E2=80=9CIPv6 on by default=E2=80=9D might accidentally = get IPv6 deployed. There=E2=80=99s potential risk if =E2=80=9CIPv6 firewall on by default=E2=80= =9D isn=E2=80=99t also enabled, but this is mentioned in the Security Considerations section. In data centers and core networks, there isn=E2=80=99t a strong case either way, because those configurations should be tightly managed, and accidentally enabling IPv6 is unlikely to leak anywhere else. > >The problems with ipv6 adoption revolve entirely around cost/benefit. Well, yes, but not always in the way I think you mean it. Tens of millions of people use IPv6 daily without ever having done a cost-benefit analysis. >Pressing problems still include things that should have been resolved >years ago, e.g. vendors charging extra for ipv6 support (today's >bugbear: provisioning system vendors, please note that charging extra >for basic ipv6 functionality is destructive in the long term and >corrosive for your customer relationships) Yeah, that=E2=80=99s a bad vendor relationship, and a vendor doing that must be pretty confident that their customer otherwise loves their product and isn=E2=80=99t tempted to find an alternative vendor. > >As a separate issue, from an operational point of view, implicit >enabling of functionality in one area when it's explicitly enabled in >another is something that needs to be handled carefully because >otherwise you can end up violating the principal of least astonishment. Anyone astonished by IPv6 working needs to be astonished. Lee > >Nick > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Aug 3 05:43:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5650131D32 for ; Thu, 3 Aug 2017 05:43:15 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCG0x2PFZqYK for ; Thu, 3 Aug 2017 05:43:14 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC7E131EB3 for ; Thu, 3 Aug 2017 05:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501764189; x=1502368989; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=mgZ1AeK1tU+3smhxWAGebX8wk thqKXfj8kRLY5/dJ3s=; b=hgab40mkippeOhIKD9ZgU77NZ1auCu3kx2GDNQNAw mYECzWrA1FETKhDvfi3p5KnGSjnf+0DZDM2Svv0o4lgVFVfBB7TxcvQ71LbK5yB0 Hlmtw8SpT31b3AgYwC9unDMPwphSzMcpiltD4RRapSXbX6uuevV3bNcFaFJ0X6vO dw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=e3F88/JvLEI/pyIElw4qwliqEcObi8GXiQK87vfHERzHTvWS+mlEJKSXx7Yd 9tdXask9oXbhvo+FzJyI6+cJ2cxeYWaP+zLjx2l/7sjREE2DSEVJO1Nx3 vkGbEZ3UP2A7Zcggbx3AC3XEMKJHbcDCDuVtASbCR0upYLLyYWrxLo=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 14:43:09 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 14:43:09 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493724.msg for ; Thu, 03 Aug 2017 14:43:08 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493724::2u8gc5tKV4T817Lm:00000gV5 X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 14:43:05 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:43:16 -0000 I suppose another way of looking at it is to ask on which elements of a net= work IPv4 support can be dropped, so that only IPv6 packets are carried, an= d only IPv6 needs to be configured and managed. In that sense, a network can be "IPv6 only=E2=80=9D even though customer IP= v4 traffic is being tunnelled or translated (either double with CLAT, or si= ngle with DNS64 shenanigans) through it. =20 [Jordi] This is actually the way I=E2=80=99m looking at it: If the access n= etwork is IPv6-only, it means IPv4 is not configured/managed there, but of = course, there may be IPv4 traffic carried out in IPv6 packets. =E2=80=A6 so not sure if I=E2=80=99m not using the right wording if folks = didn=E2=80=99t got it? =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 05:45:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCDB131EA7 for ; Thu, 3 Aug 2017 05:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvvUbat3eaH5 for ; Thu, 3 Aug 2017 05:45:21 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 388FF128961 for ; Thu, 3 Aug 2017 05:45:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z18so6584542qka.4 for ; Thu, 03 Aug 2017 05:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=inbbfGmW0SQijN2UhGCm3pcZV5Tp5iWnCfZLkhCjrV4=; b=LSRpNuDVBYy97bp/YxSJT071zWnxq7ZM+6z5HMg9U0ccg60HTjiKf7Z4HQhz5LDuGz XFDw2S0U+21Db/zxLP8kurGxqAJIC3Y9BkeYvRlqnWEiobbzX+Xt/8Nwz/Tup6tNWrGK O6zqHxmi76JRLP8qt564FYIDP6IcTn9s+Azc0= 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=inbbfGmW0SQijN2UhGCm3pcZV5Tp5iWnCfZLkhCjrV4=; b=LZz/j124jjOof4OoHvW3jGDw3yy/XshrnStfEj7F6WGWlkmx5+kCBCZzhWtBMjWRPu OTH/Xk+4S4FWvP7HvkxCATHTm2tnWYFZppk1YZByfpdVJWRDCSejez78phmdTmB9YhSD lbHPhr8xlQDMppSO2+cYmHk9094okhRQyLPbhvN4DJKE/97NZ5FWyeDN7TbIh1CguFjk HSEwkEqYzJYZGkNYq01AEU1Np3u4UlQHJx6ULglum0LLpfc6qZFoetVrxjg9iSYDjsQQ +hdnZxAakk5BfNLlX6kw/75ACwTzXWy3YKrhFPkBlJIrh7zXHnapZHBjiGY+qwfUVVoZ AJew== X-Gm-Message-State: AHYfb5iziIevPdC2WKJ9n4/UmLl46kJdtXSfOF+eXKaK9JKVIJXufe8M jVCV0+8O5nPcgWDFLbvSOfvSzy6VcxSw9P4= X-Received: by 10.55.104.149 with SMTP id d143mr2157431qkc.344.1501764320304; Thu, 03 Aug 2017 05:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.91 with HTTP; Thu, 3 Aug 2017 05:44:59 -0700 (PDT) In-Reply-To: References: From: Timothy Winters Date: Thu, 3 Aug 2017 08:44:59 -0400 Message-ID: To: Mikael Abrahamsson Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c059d80d940570555d8c09b" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:45:23 -0000 --94eb2c059d80d940570555d8c09b Content-Type: text/plain; charset="UTF-8" Hi Mikael, So 3315bis is attempting to address this exact issue, Section 18.2.12. Which basically says if you think a link may have changed you should probably should check for updated information. Does the DHCPv6 Server know to set the old Prefix to zero in this use case? If not, that won't help since it will still need to time-out. Regards, Tim On Thu, Aug 3, 2017 at 8:11 AM, Mikael Abrahamsson wrote: > On Thu, 3 Aug 2017, Timothy Winters wrote: > > A solution that comes to mind, is a host gets two global addresses it >> might help in the future if they implemented something like ( >> https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01). A >> Host would choose the lifetime with a higher lifetime. >> > > Yes, you're right, as soon as a new PD is available and PIOs are sent for > that, hosts will start to use those addresses instead. The problem is that > the DHCPv6-PD request process isn't triggered by WAN router RA timing out > and potentially new router RAs showing up with different prefix? > > What controls the PD timeout is its own timers, and as far as I know, this > is in no way affected by what RAs are seen on WAN. > > It would be an operational change to say "look, if WAN prefix changed, > perhaps you should re-do the PD request process just in case?" This would > require no protocol change, it's just a recommendation based on what's seen > on the WAN? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --94eb2c059d80d940570555d8c09b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mikael,
=C2=A0 =C2=A0 So 3315bis is attempting to a= ddress this exact issue, Section 18.2.12.=C2=A0 Which basically says if you= think a link may have changed you should probably should check for updated= information. =C2=A0 Does the DHCPv6 Server know to set the old Prefix to z= ero in this use case? =C2=A0 If not, that won't help since it will stil= l need to time-out.
=C2=A0 =C2=A0=C2=A0
Regards,
<= div>Tim

On Thu, Aug 3, 2017 at 8:11 AM, Mikael Abrahamsson <= swmike@swm.pp.se&= gt; wrote:
On Thu= , 3 Aug 2017, Timothy Winters wrote:

A solution that comes to mind, is a host gets two global addresses it might= help in the future if they implemented something like ( https://tools.ietf.org/html/draft-linkova-v6ops= -conditional-ras-01).=C2=A0 A Host would choose the lifetime with = a higher lifetime.

Yes, you're right, as soon as a new PD is available and PIOs are sent f= or that, hosts will start to use those addresses instead. The problem is th= at the DHCPv6-PD request process isn't triggered by WAN router RA timin= g out and potentially new router RAs showing up with different prefix?

What controls the PD timeout is its own timers, and as far as I know, this = is in no way affected by what RAs are seen on WAN.

It would be an operational change to say "look, if WAN prefix changed,= perhaps you should re-do the PD request process just in case?" This w= ould require no protocol change, it's just a recommendation based on wh= at's seen on the WAN?


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se



--
=

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

--94eb2c059d80d940570555d8c09b-- From nobody Thu Aug 3 05:50:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BE912EBF9 for ; Thu, 3 Aug 2017 05:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wongUyakOaxs for ; Thu, 3 Aug 2017 05:50:18 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE15131F23 for ; Thu, 3 Aug 2017 05:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15488; q=dns/txt; s=iport; t=1501764609; x=1502974209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=F216gvNIALqd6ebL6DDR49708fFMO++POgeo5Wp9+Co=; b=FkkZ/fkRCowL5D2D8ORI0B2b7mO3P1w/dh8mg4HY/F5CMSEWut+NhwHD dNW4a0/1U7sRomJAeJXUVXNNEgztrnxp+OYpIBiq/uccjxE10M4iHKmvY bwk+cM0C/FMhho7bUZYnKtpnN+Eqcfwuv4if2NSna4Cct2VB8quX3+F2k 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQAKG4NZ/5BdJa1cDgwBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJva2RtJweOCJAHgW6QYoUzDoIELIUbAhqEIz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDI1YQAgEIDgMDAQIoAwICAjAUCQgCBAENBRuJMGQJB6xfgiYlAosnA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYMoggKDWoJ8gTyDBAESAQk2FoJdMIIxBZ9?= =?us-ascii?q?9AodRjFqSSIwqK4krAR84fwt3FVsBgkeCSYE4P3YNAYcWgSOBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208,217";a="463868906" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2017 12:50:07 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v73Co7Xg020905 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 12:50:07 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 07:50:07 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 07:50:07 -0500 From: "Bernie Volz (volz)" To: Timothy Winters , Mikael Abrahamsson CC: IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agA== Date: Thu, 3 Aug 2017 12:50:07 +0000 Message-ID: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: multipart/alternative; boundary="_000_61BA6CDC7B3645D8820A4CAE747DC246ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:50:20 -0000 --_000_61BA6CDC7B3645D8820A4CAE747DC246ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kLCBpZiB5b3UgcHJlZmVyIGRpZmZlcmVudCB3b3JkaW5nIGluIHRoaXMgMzMxNWJpcyBzZWN0 aW9uLCBub3figJlzIHRoZSB0aW1lIHRvIHJhaXNlIHRoYXQgYXMgd2UgaG9wZSB0byBzZW5kIHRo aXMgb24gc2hvcnRlciAodGhlcmUgd2lsbCBiZSBhIC0xMCBiZWZvcmUgd2UgZG8gdGhhdCkuDQoN Cg0KICAqICAgQmVybmllDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgVGltb3RoeSBXaW50ZXJzIDx0d2ludGVyc0Bpb2wudW5oLmVkdT4NCkRhdGU6 IFRodXJzZGF5LCBBdWd1c3QgMywgMjAxNyBhdCA4OjQ0IEFNDQpUbzogTWlrYWVsIEFicmFoYW1z c29uIDxzd21pa2VAc3dtLnBwLnNlPg0KQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgUkZDNzA4 NCBHLTUgcmVxdWlyZW1lbnQNCg0KSGkgTWlrYWVsLA0KICAgIFNvIDMzMTViaXMgaXMgYXR0ZW1w dGluZyB0byBhZGRyZXNzIHRoaXMgZXhhY3QgaXNzdWUsIFNlY3Rpb24gMTguMi4xMi4gIFdoaWNo IGJhc2ljYWxseSBzYXlzIGlmIHlvdSB0aGluayBhIGxpbmsgbWF5IGhhdmUgY2hhbmdlZCB5b3Ug c2hvdWxkIHByb2JhYmx5IHNob3VsZCBjaGVjayBmb3IgdXBkYXRlZCBpbmZvcm1hdGlvbi4gICBE b2VzIHRoZSBESENQdjYgU2VydmVyIGtub3cgdG8gc2V0IHRoZSBvbGQgUHJlZml4IHRvIHplcm8g aW4gdGhpcyB1c2UgY2FzZT8gICBJZiBub3QsIHRoYXQgd29uJ3QgaGVscCBzaW5jZSBpdCB3aWxs IHN0aWxsIG5lZWQgdG8gdGltZS1vdXQuDQoNClJlZ2FyZHMsDQpUaW0NCg0KT24gVGh1LCBBdWcg MywgMjAxNyBhdCA4OjExIEFNLCBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U8 bWFpbHRvOnN3bWlrZUBzd20ucHAuc2U+PiB3cm90ZToNCk9uIFRodSwgMyBBdWcgMjAxNywgVGlt b3RoeSBXaW50ZXJzIHdyb3RlOg0KQSBzb2x1dGlvbiB0aGF0IGNvbWVzIHRvIG1pbmQsIGlzIGEg aG9zdCBnZXRzIHR3byBnbG9iYWwgYWRkcmVzc2VzIGl0IG1pZ2h0IGhlbHAgaW4gdGhlIGZ1dHVy ZSBpZiB0aGV5IGltcGxlbWVudGVkIHNvbWV0aGluZyBsaWtlICggaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxpbmtvdmEtdjZvcHMtY29uZGl0aW9uYWwtcmFzLTAxKS4gIEEgSG9z dCB3b3VsZCBjaG9vc2UgdGhlIGxpZmV0aW1lIHdpdGggYSBoaWdoZXIgbGlmZXRpbWUuDQoNClll cywgeW91J3JlIHJpZ2h0LCBhcyBzb29uIGFzIGEgbmV3IFBEIGlzIGF2YWlsYWJsZSBhbmQgUElP cyBhcmUgc2VudCBmb3IgdGhhdCwgaG9zdHMgd2lsbCBzdGFydCB0byB1c2UgdGhvc2UgYWRkcmVz c2VzIGluc3RlYWQuIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIERIQ1B2Ni1QRCByZXF1ZXN0IHBy b2Nlc3MgaXNuJ3QgdHJpZ2dlcmVkIGJ5IFdBTiByb3V0ZXIgUkEgdGltaW5nIG91dCBhbmQgcG90 ZW50aWFsbHkgbmV3IHJvdXRlciBSQXMgc2hvd2luZyB1cCB3aXRoIGRpZmZlcmVudCBwcmVmaXg/ DQoNCldoYXQgY29udHJvbHMgdGhlIFBEIHRpbWVvdXQgaXMgaXRzIG93biB0aW1lcnMsIGFuZCBh cyBmYXIgYXMgSSBrbm93LCB0aGlzIGlzIGluIG5vIHdheSBhZmZlY3RlZCBieSB3aGF0IFJBcyBh cmUgc2VlbiBvbiBXQU4uDQoNCkl0IHdvdWxkIGJlIGFuIG9wZXJhdGlvbmFsIGNoYW5nZSB0byBz YXkgImxvb2ssIGlmIFdBTiBwcmVmaXggY2hhbmdlZCwgcGVyaGFwcyB5b3Ugc2hvdWxkIHJlLWRv IHRoZSBQRCByZXF1ZXN0IHByb2Nlc3MganVzdCBpbiBjYXNlPyIgVGhpcyB3b3VsZCByZXF1aXJl IG5vIHByb3RvY29sIGNoYW5nZSwgaXQncyBqdXN0IGEgcmVjb21tZW5kYXRpb24gYmFzZWQgb24g d2hhdCdzIHNlZW4gb24gdGhlIFdBTj8NCg0KDQotLQ0KTWlrYWVsIEFicmFoYW1zc29uICAgIGVt YWlsOiBzd21pa2VAc3dtLnBwLnNlPG1haWx0bzpzd21pa2VAc3dtLnBwLnNlPg0KDQoNCg0KLS0N Cg0KTm93IG9mZmVyaW5nIHRlc3RpbmcgZm9yIFNETiBhcHBsaWNhdGlvbnMgYW5kIGNvbnRyb2xs ZXJzIGluIG91ciBTRE4gc3dpdGNoIHRlc3QgYmVkLiBMZWFybiBtb3JlIHRvZGF5IGh0dHA6Ly9i aXQubHkvU0ROX0lPTFBSDQo= --_000_61BA6CDC7B3645D8820A4CAE747DC246ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3476C720BC4C564A82ED65D9A653FAA1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJcGFub3NlLTE6MiA0 IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk5MzAyNjI5OTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjU0NTgwODc2IDI5NzE5NTk0OCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kLCBpZiB5b3UgcHJlZmVyIGRpZmZl cmVudCB3b3JkaW5nIGluIHRoaXMgMzMxNWJpcyBzZWN0aW9uLCBub3figJlzIHRoZSB0aW1lIHRv IHJhaXNlIHRoYXQgYXMgd2UgaG9wZSB0byBzZW5kIHRoaXMgb24gc2hvcnRlciAodGhlcmUgd2ls bCBiZSBhIC0xMCBiZWZvcmUgd2UgZG8gdGhhdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnY2 b3BzICZsdDt2Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgVGltb3RoeSBX aW50ZXJzICZsdDt0d2ludGVyc0Bpb2wudW5oLmVkdSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1 cnNkYXksIEF1Z3VzdCAzLCAyMDE3IGF0IDg6NDQgQU08YnI+DQo8Yj5UbzogPC9iPk1pa2FlbCBB YnJhaGFtc3NvbiAmbHQ7c3dtaWtlQHN3bS5wcC5zZSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O3Y2b3BzQGlldGYub3JnJnF1b3Q7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFt2Nm9wc10gY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgUkZDNzA4NCBHLTUg cmVxdWlyZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIE1pa2FlbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBTbyAzMzE1YmlzIGlzIGF0dGVtcHRpbmcgdG8g YWRkcmVzcyB0aGlzIGV4YWN0IGlzc3VlLCBTZWN0aW9uIDE4LjIuMTIuJm5ic3A7IFdoaWNoIGJh c2ljYWxseSBzYXlzIGlmIHlvdSB0aGluayBhIGxpbmsgbWF5IGhhdmUgY2hhbmdlZCB5b3Ugc2hv dWxkIHByb2JhYmx5IHNob3VsZCBjaGVjayBmb3IgdXBkYXRlZCBpbmZvcm1hdGlvbi4gJm5ic3A7 IERvZXMgdGhlIERIQ1B2NiBTZXJ2ZXIga25vdyB0byBzZXQgdGhlIG9sZA0KIFByZWZpeCB0byB6 ZXJvIGluIHRoaXMgdXNlIGNhc2U/ICZuYnNwOyBJZiBub3QsIHRoYXQgd29uJ3QgaGVscCBzaW5j ZSBpdCB3aWxsIHN0aWxsIG5lZWQgdG8gdGltZS1vdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGltPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg QXVnIDMsIDIwMTcgYXQgODoxMSBBTSwgTWlrYWVsIEFicmFoYW1zc29uICZsdDs8YSBocmVmPSJt YWlsdG86c3dtaWtlQHN3bS5wcC5zZSIgdGFyZ2V0PSJfYmxhbmsiPnN3bWlrZUBzd20ucHAuc2U8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIFRodSwgMyBBdWcgMjAxNywg VGltb3RoeSBXaW50ZXJzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkEgc29sdXRpb24gdGhhdCBjb21lcyB0byBtaW5kLCBpcyBhIGhvc3Qg Z2V0cyB0d28gZ2xvYmFsIGFkZHJlc3NlcyBpdCBtaWdodCBoZWxwIGluIHRoZSBmdXR1cmUgaWYg dGhleSBpbXBsZW1lbnRlZCBzb21ldGhpbmcgbGlrZSAoDQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbGlua292YS12Nm9wcy1jb25kaXRpb25hbC1yYXMtMDEiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5rb3Zh LXY2b3BzLWNvbmRpdGlvbmFsLXJhcy0wMTwvYT4pLiZuYnNwOyBBIEhvc3Qgd291bGQgY2hvb3Nl IHRoZSBsaWZldGltZSB3aXRoIGEgaGlnaGVyIGxpZmV0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KWWVzLCB5b3UncmUgcmlnaHQs IGFzIHNvb24gYXMgYSBuZXcgUEQgaXMgYXZhaWxhYmxlIGFuZCBQSU9zIGFyZSBzZW50IGZvciB0 aGF0LCBob3N0cyB3aWxsIHN0YXJ0IHRvIHVzZSB0aG9zZSBhZGRyZXNzZXMgaW5zdGVhZC4gVGhl IHByb2JsZW0gaXMgdGhhdCB0aGUgREhDUHY2LVBEIHJlcXVlc3QgcHJvY2VzcyBpc24ndCB0cmln Z2VyZWQgYnkgV0FOIHJvdXRlciBSQSB0aW1pbmcgb3V0IGFuZCBwb3RlbnRpYWxseSBuZXcgcm91 dGVyIFJBcyBzaG93aW5nDQogdXAgd2l0aCBkaWZmZXJlbnQgcHJlZml4Pzxicj4NCjxicj4NCldo YXQgY29udHJvbHMgdGhlIFBEIHRpbWVvdXQgaXMgaXRzIG93biB0aW1lcnMsIGFuZCBhcyBmYXIg YXMgSSBrbm93LCB0aGlzIGlzIGluIG5vIHdheSBhZmZlY3RlZCBieSB3aGF0IFJBcyBhcmUgc2Vl biBvbiBXQU4uPGJyPg0KPGJyPg0KSXQgd291bGQgYmUgYW4gb3BlcmF0aW9uYWwgY2hhbmdlIHRv IHNheSAmcXVvdDtsb29rLCBpZiBXQU4gcHJlZml4IGNoYW5nZWQsIHBlcmhhcHMgeW91IHNob3Vs ZCByZS1kbyB0aGUgUEQgcmVxdWVzdCBwcm9jZXNzIGp1c3QgaW4gY2FzZT8mcXVvdDsgVGhpcyB3 b3VsZCByZXF1aXJlIG5vIHByb3RvY29sIGNoYW5nZSwgaXQncyBqdXN0IGEgcmVjb21tZW5kYXRp b24gYmFzZWQgb24gd2hhdCdzIHNlZW4gb24gdGhlIFdBTj8NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLSA8YnI+DQpNaWth ZWwgQWJyYWhhbXNzb24mbmJzcDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86c3dtaWtl QHN3bS5wcC5zZSIgdGFyZ2V0PSJfYmxhbmsiPnN3bWlrZUBzd20ucHAuc2U8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5Ob3cgb2ZmZXJpbmcg dGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNETiBz d2l0Y2ggdGVzdCBiZWQuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPkxlYXJuIG1vcmUgdG9kYXkN CjxhIGhyZWY9Imh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L2JpdC5seS9TRE5fSU9MUFI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_61BA6CDC7B3645D8820A4CAE747DC246ciscocom_-- From nobody Thu Aug 3 05:52:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAC128961 for ; Thu, 3 Aug 2017 05:52: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THsy8cspFZOo for ; Thu, 3 Aug 2017 05:52:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA1F12702E for ; Thu, 3 Aug 2017 05:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501764740; x=1502369540; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Du5yjRiSh7ebljPok879nHKmr yFM4w+YPuVwCBk1fiQ=; b=prVCfncQ2XILWzEi/6MLvn0JHdHabr6TDysiUkoe6 5dUhF/51oJcclW0urYhDQq/Nv/p9Ck/0mcPydMYmeUWX0MaMId3e3MziOWlObQUw TP1DdajiW+iAfOjCzc8NLP2TzjFnb9pEquA6QpAMzkD3hAqlRLb3VZGYibnXwv5/ n4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gfbs/ImzK7rVwz8s4sYloQt0NxB1LpwyEMGQUbU/c1PHeF5KeOoF0ndGhYFU k7jObg1D6k2eThN3bOPO2cE1rLc8I4TBqtswul6oxXLPK7VvMTLjUkGO3 iCwzZfv/nJJbZdUlN1Vx6CZCXrzmvRhDJPR4OkbJK+DURYmCMOgaXk=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 14:52:20 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 14:52:19 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493737.msg for ; Thu, 03 Aug 2017 14:52:19 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493737::SustWuMX8E2Y103L:0000A+z3 X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 14:52:18 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <736B2ADF-C0C6-4BFB-9D4E-546C1DA57358@consulintel.es> Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:52:24 -0000 I think I found the way to make it more clear for the next version. I have changed the last paragraph in section 2 from: From that perspective, we define the "IPv6-only" status depending on if there is actual layer-2 forwarding of IPv4. To: From that perspective, we define the "IPv6-only" status in a given pa= rt(s)=20 of a network, depending on if there is actual layer-2 forwarding of I= Pv4, so=20 IPv4 is not configured neither managed. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Responder a: Fecha: jueves, 3 de agosto de 2017, 14:43 Para: "v6ops@ietf.org" Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6= -only-01.txt I suppose another way of looking at it is to ask on which elements of a= network IPv4 support can be dropped, so that only IPv6 packets are carried= , and only IPv6 needs to be configured and managed. =20 In that sense, a network can be "IPv6 only=E2=80=9D even though custome= r IPv4 traffic is being tunnelled or translated (either double with CLAT, o= r single with DNS64 shenanigans) through it. =20 [Jordi] This is actually the way I=E2=80=99m looking at it: If the acce= ss network is IPv6-only, it means IPv4 is not configured/managed there, but= of course, there may be IPv4 traffic carried out in IPv6 packets. =E2=80=A6 so not sure if I=E2=80=99m not using the right wording if fo= lks didn=E2=80=99t got it? =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =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 =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the individ= ual(s) named above. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, including attached files, is prohibited. =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 05:55:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B24131FD4 for ; Thu, 3 Aug 2017 05:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-4VJUls7ZlE for ; Thu, 3 Aug 2017 05:55:52 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0748131FE6 for ; Thu, 3 Aug 2017 05:55:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E1607A6; Thu, 3 Aug 2017 14:55:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501764950; bh=/yawwRMepRZarOeA3UxS5WvMQcBul60R7ydV9CNcijc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eOcg0kB3CtIrXyFvLPRNOF0yaz6QdBeGGN+OPW9RC+74/qTutZqX5ziU2p90zkhck IN7L/r+kLdSsAtqqWQ8uBE3f8MY/zwXFVc8lJEKiwsjDDpCAT7fkyPcbKoc/gFlAHX 74II8LV2TxBrM/SmC9PioSNSOTgrem5C6eVgJk18= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C9B85A3; Thu, 3 Aug 2017 14:55:50 +0200 (CEST) Date: Thu, 3 Aug 2017 14:55:50 +0200 (CEST) From: Mikael Abrahamsson To: Timothy Winters cc: IPv6 Operations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:55:55 -0000 On Thu, 3 Aug 2017, Timothy Winters wrote: > Hi Mikael, > So 3315bis is attempting to address this exact issue, Section 18.2.12. > Which basically says if you think a link may have changed you should > probably should check for updated information. Does the DHCPv6 Server > know to set the old Prefix to zero in this use case? If not, that won't > help since it will still need to time-out. No, the old DHCPv6-PD server is now gone, not available anymore, will never answer you again. The link now has a brand new DHCPv6-PD server you can ask for completely different prefixes, which it will happily give you. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 06:02:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E5E131EB1 for ; Thu, 3 Aug 2017 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2hK8PoVKyM8 for ; Thu, 3 Aug 2017 06:02:37 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBB112702E for ; Thu, 3 Aug 2017 06:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501765356; x=1502370156; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=mLy4jnoMrCu1zW3gjCyy83LCS Ml2GO9sfnlS0tJebWw=; b=Ivk65jpZGZAojj8BL57SnlNpGbuHh4Bdv6uFzIn3H mddL2FiWGGxE44jw3k1Tbkza3en5l+s5jnKG5f2dkz9Qd7lH4Y4ho7BwxQoAOPYq KZGDV3DnCMSLo6/iyUtRFIHOywPiuMjJaftqkxmGPnYvJHzpdKrHd8RNZ33AZWuE P8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Np34VuhLCP1qFaNJ+23NkQowlaX7LMXhPYlWmPtQT1eZOZR5RVxDOQtrXAKf O45GujkKYgRhsOnOYibcMTkZQED0eSsL4OzRjjtehSl8IJhmI6ONGX+yd zcHclDXqgOz8XUCdKNTU1CAJyvoAjiBxOCQ/ywP/d6B1ZVOQN1TIJU=; X-MDAV-Processed: mail.consulintel.es, Thu, 03 Aug 2017 15:02:35 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 03 Aug 2017 15:02:34 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005493742.msg for ; Thu, 03 Aug 2017 15:02:34 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170803:md50005493742::+DIcraSpU9AObq3z:00003DzT X-Return-Path: prvs=138830808b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Thu, 03 Aug 2017 15:02:30 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:02:44 -0000 Hi Stephen, Now I see your point, but I think is clear reading the text I just posted: From that perspective, we define the "IPv6-only" status in a given pa= rt(s) of a network, depending on if there is actual layer-2 forwarding of I= Pv4, so IPv4 is not configured neither managed. What I=E2=80=99m going to do is to take that paragraph out of the actual = =E2=80=9Ccontext=E2=80=9D section, and create a new one to stress it: =E2= =80=9CDefinition of IPv6-only=E2=80=9D. Furthermore, what I=E2=80=99ve at section 5 is referring to a specific part= , IPv6-only WAN, and again I read it correctly (others may tell if I=E2=80= =99m wrong), because the example of an IPv6-only cellular WAN/access networ= k is a network that is transporting only IPv6 at layer-2. -----Mensaje original----- De: Stephen Strowes Responder a: Fecha: jueves, 3 de agosto de 2017, 13:55 Para: , Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6= -only-01.txt Hi, =20 On 03/08/2017 12:50, JORDI PALET MARTINEZ wrote: > However, I=E2=80=99ve a question regarding your last paragraph, just = in case I=E2=80=99m not getting it correctly. > > If we state something such as =E2=80=9CIPv6+specific transition=E2=80= =9D mechanism (your example IPv6+NAT64), we can have =E2=80=9Ctons=E2=80=9D= of possible variations, instead of half a dozen or so, and in some cases, = the transition mechanism can be deployed in different parts of the network = (the NAT64 can be in the core, upstream router, etc.). So I think that spea= king about a specific mechanism instead of which part of the network is IPv= 6-only. You see my point or I=E2=80=99m missing anything? =20 I see your point but I'm not suggesting a combinatorial approach to=20 describing networks. =20 I am suggesting that if you describe an IPv6 network which offers a=20 means to reach v4 networks as "IPv6-only", then the terminology is wron= g. =20 Section 5 refers to cellular networks, devices, and transition=20 technologies. Although I know I can look at some of these networks and= =20 describe traffic in and out of my device as being IPv6-only, to refer t= o=20 those networks as "IPv6-only" would be misleading. I can't imagine that= =20 description would ever be useful to folks outside of some very specific= =20 contexts. =20 S. =20 =20 =20 > =20 > > -----Mensaje original----- > De: Stephen Strowes > Responder a: > Fecha: jueves, 3 de agosto de 2017, 11:35 > Para: , > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6op= s-ipv6-only-01.txt > > I agree with this line: > =20 > "we MUST NOT use the terminology "IPv6-only" in a generic way". > =20 > Agreed. I find that expanding "IPv6-only" to include mechanisms = such as > NAT64 is contradictory and confusing. > =20 > I don't think it's useful to state, for example, that an "IPv6-o= nly > access network" MAY have means to access the IPv4 network. But I= do > think it's useful to state that a network is, say, IPv6+NAT64. > =20 > S. > =20 > =20 > On 03/08/2017 10:54, JORDI PALET MARTINEZ wrote: > > I don=E2=80=99t agree. > > > > As one of the co-chairs confirmed in the last meeting (and act= ually somehow called for this work), many folks even within IETF/v6ops are = using IPv6-only for very different things. > > > > This is creating in many situations conversations that talk ab= out different issues but we don=E2=80=99t realize it until we wasted too mu= ch time. I think there is a need to make sure that we all use the same term= inology. > > > > So, this is not about NAT64, it is about the correct usage of = IPv6-only, scoping it to the right part/s of the network or even the comple= te network end-to-end. > > > > Anyway, let=E2=80=99s see others opinions. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: en nombre de Philip Homburg= > > Responder a: > > Fecha: jueves, 3 de agosto de 2017, 10:47 > > Para: > > CC: > > Asunto: Re: [v6ops] FW: New Version Notification for draft-pal= et-v6ops-ipv6-only-01.txt > > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6= -only/ > > > > > > Comments welcome! > > > > There is nothing IPv6-only about NAT64. So please stop do= ing this. > > > > The only definition of IPv6-only that makes sense in the = long term is when > > there is no access to the IPv4 network at all. That is li= terally IPv6-only. > > > > Anything else is just bound to confuse people outside our= small group. > > > > What we are discussing are IPv4 over IPv6 tunneling/trans= lation techniques. > > > > > > > > > > ********************************************** > > 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 priv= ileged or confidential. The information is intended to be for the use of th= e individual(s) named above. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, including attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > =20 > =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 confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 3 06:25:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786CF12702E for ; Thu, 3 Aug 2017 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 e0pknzU42dYa for ; Thu, 3 Aug 2017 06:25:28 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 0C8F4126C23 for ; Thu, 3 Aug 2017 06:25:26 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id C713DC0D9D for ; Thu, 3 Aug 2017 08:07:42 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6AEDEC0D9A; Thu, 3 Aug 2017 08:07:41 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2F95692079; Thu, 3 Aug 2017 09:07:41 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EE1F692057; Thu, 3 Aug 2017 09:07:40 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.87]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Thu, 3 Aug 2017 09:07:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=heBMdqaES+qxgi0D//ObzbVYAXhO2rtjypRdPNOAh9A=; b=mHcBX2IkQ4PtIONp8D8rehcQ8gXOIPOw9BcFkowPQQwmBmm2REmQID3TN86d1q/GE3mrO26v9QdaUScbBpoWVwc9ymx5D++kga1H9oRGpmaFAumiuxOQlSlt8vg6oC6ihx4Rhff+qos5bqgu0Bw3wq44mXc2l3cZMjaMKgcBmxM= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 13:07:39 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 13:07:39 +0000 From: "Ackermann, Michael" To: Lee Howard , Nick Hilliard , Fred Baker CC: IPv6 Ops WG , 6man WG , "draft-ietf-6man-rfc6434-bis@ietf.org" Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWxnLK4tXfb/J0eDXgJbGwTvdaJypCaAgAALLVA= Date: Thu, 3 Aug 2017 13:07:39 +0000 Message-ID: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:RpApsfpfHToiR1aCMO32LTkRPXJqlgSnRvww6b1effWKiBwmai5qAYncYefn6RECvGbQeW/lCduBgZJr5kTYeyXVfRxclT5Sf81PN/stwKEQcrcYdeWRumhHB8SQbMAa9K2Dtq3bf22bQrJ7m0KdUHqjD5yFh3zWy8diLRiMjTI= x-ms-office365-filtering-correlation-id: c4d62c0e-c021-4711-ce97-08d4da709e99 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39830400002)(39400400002)(24454002)(189002)(377454003)(13464003)(199003)(4326008)(80792005)(25786009)(8676002)(101416001)(33656002)(478600001)(77096006)(189998001)(6436002)(229853002)(72206003)(86362001)(305945005)(97736004)(7736002)(2900100001)(6506006)(966005)(55016002)(38730400002)(6246003)(2950100002)(6116002)(102836003)(53546010)(3846002)(66066001)(106356001)(7696004)(2906002)(5660300001)(3660700001)(3280700002)(39060400002)(9686003)(74316002)(105586002)(6306002)(68736007)(53936002)(14454004)(54906002)(50986999)(8936002)(54356999)(99286003)(81156014)(81166006)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 13:07:39.6013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 4f985c0c-8936-4bd8-bf23-0e377d80b178 X-VPM-MSG-ID: 29ef2b8a-3667-4d63-a000-8af4c7b39130 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:25:29 -0000 SnVzdCBhIHF1aWNrIDIgY2VudHMgZnJvbSB0aGUgRW50ZXJwcmlzZSBwZXJzcGVjdGl2ZS4g DQoNClVuZm9ydHVuYXRlbHkgKElNSE8pLCAgbW9zdCBFbnRlcnByaXNlcyBleHByZXNzbHkg YW5kIHB1cnBvc2VseSB0dXJuIElQdjYgb2ZmIGluIHJvdXRlcnMuICAgICBBcyBtZW50aW9u ZWQsICB0aGUgYnVzaW5lc3MgY2FzZShzKSBhcmUgc3RpbGwgbm90IG9idmlvdXMgYW5kIGl0 IGlzIHRodXMgc2VlbiBvbmx5IGFzIGV4Y2Vzc2l2ZSB0cmFmZmljIGFuZCBwb3RlbnRpYWwg cHJvYmxlbXMuICANCg0KUGxlYXNlIGRvbid0IHNob290IHRoZSBtZXNzZW5nZXIuICANCg0K VGhhbmtzDQoNCk1pa2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVl IEhvd2FyZA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzLCAyMDE3IDg6MjUgQU0NClRvOiBO aWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc+OyBGcmVkIEJha2VyIDxmcmVkYmFrZXIu aWV0ZkBnbWFpbC5jb20+DQpDYzogSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgNm1h biBXRyA8aXB2NkBpZXRmLm9yZz47IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gVHVybmluZyBvbiBJUHY2IFJvdXRlcnMNCg0K DQoNCk9uIDcvMjAvMTcsIDU6MjUgUE0sICJ2Nm9wcyBvbiBiZWhhbGYgb2YgTmljayBIaWxs aWFyZCINCjx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNrQGZvb2Jh ci5vcmc+IHdyb3RlOg0KDQo+RnJlZCBCYWtlciB3cm90ZToNCj4+ICJJZiBJUHY0IHJvdXRl ciBvcGVyYXRpb24gaXMgZW5hYmxlZCBieSBkZWZhdWx0LCBlbmFibGUgSVB2NiByb3V0ZXIg DQo+PiBvcGVyYXRpb24gYnkgZGVmYXVsdC4iDQo+DQo+dGhpcyBpcyB1bmRvdWJ0ZWRseSB3 ZWxsLWludGVudGlvbmVkLCBhbmQgdGhlIGlkZWFsaXN0IGJpdCBpbiBtZSANCj5zeW1wYXRo aXNlcyB3aXRoIHRoZSBwcmluY2lwYWwuICBIb3dldmVyIHdpdGggbXkgZW5hYmxlIGhhdCBv biwgYSANCj5yZWNvbW1lbmRhdGlvbiBsaWtlIHRoaXMgaXNuJ3QgZ29pbmcgdG8gZml4IGFu eSBwcm9ibGVtIGFzc29jaWF0ZWQgd2l0aA0KPmlwdjYgYWRvcHRpb24uDQoNCkkgY29tcGxl dGVseSBkaXNhZ3JlZSwgYnV0IGl04oCZcyBkZXBlbmRlbnQgb24gd2hlcmUgdGhlIHJvdXRl ciBleGlzdHMuDQpGb3IgYSBob21lIGdhdGV3YXkgcm91dGVyLCDigJxJUHY2IG9uIGJ5IGRl ZmF1bHTigJ0gd291bGQgaW5jcmVhc2UgdGhlIG51bWJlciBvZiBwZW9wbGUgdXNpbmcgSVB2 NiwgYWx0aG91Z2ggSSBoYXZlIG5vIHdheSB0byBlc3RpbWF0ZSB0aGUgaW1wYWN0Lg0KDQpG b3IgYW4gZW50ZXJwcmlzZSBlZGdlIHJvdXRlciwg4oCcSVB2NiBvbiBieSBkZWZhdWx04oCd IG1pZ2h0IGFjY2lkZW50YWxseSBnZXQNCklQdjYgZGVwbG95ZWQuIFRoZXJl4oCZcyBwb3Rl bnRpYWwgcmlzayBpZiDigJxJUHY2IGZpcmV3YWxsIG9uIGJ5IGRlZmF1bHTigJ0NCmlzbuKA mXQgYWxzbyBlbmFibGVkLCBidXQgdGhpcyBpcyBtZW50aW9uZWQgaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCkluIGRhdGEgY2VudGVycyBhbmQgY29yZSBu ZXR3b3JrcywgdGhlcmUgaXNu4oCZdCBhIHN0cm9uZyBjYXNlIGVpdGhlciB3YXksIGJlY2F1 c2UgdGhvc2UgY29uZmlndXJhdGlvbnMgc2hvdWxkIGJlIHRpZ2h0bHkgbWFuYWdlZCwgYW5k IGFjY2lkZW50YWxseSBlbmFibGluZyBJUHY2IGlzIHVubGlrZWx5IHRvIGxlYWsgYW55d2hl cmUgZWxzZS4NCg0KPg0KPlRoZSBwcm9ibGVtcyB3aXRoIGlwdjYgYWRvcHRpb24gcmV2b2x2 ZSBlbnRpcmVseSBhcm91bmQgY29zdC9iZW5lZml0Lg0KDQpXZWxsLCB5ZXMsIGJ1dCBub3Qg YWx3YXlzIGluIHRoZSB3YXkgSSB0aGluayB5b3UgbWVhbiBpdC4NClRlbnMgb2YgbWlsbGlv bnMgb2YgcGVvcGxlIHVzZSBJUHY2IGRhaWx5IHdpdGhvdXQgZXZlciBoYXZpbmcgZG9uZSBh IGNvc3QtYmVuZWZpdCBhbmFseXNpcy4NCg0KPlByZXNzaW5nIHByb2JsZW1zIHN0aWxsIGlu Y2x1ZGUgdGhpbmdzIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiByZXNvbHZlZCANCj55ZWFycyBh Z28sIGUuZy4gdmVuZG9ycyBjaGFyZ2luZyBleHRyYSBmb3IgaXB2NiBzdXBwb3J0ICh0b2Rh eSdzDQo+YnVnYmVhcjogcHJvdmlzaW9uaW5nIHN5c3RlbSB2ZW5kb3JzLCBwbGVhc2Ugbm90 ZSB0aGF0IGNoYXJnaW5nIGV4dHJhIA0KPmZvciBiYXNpYyBpcHY2IGZ1bmN0aW9uYWxpdHkg aXMgZGVzdHJ1Y3RpdmUgaW4gdGhlIGxvbmcgdGVybSBhbmQgDQo+Y29ycm9zaXZlIGZvciB5 b3VyIGN1c3RvbWVyIHJlbGF0aW9uc2hpcHMpDQoNClllYWgsIHRoYXTigJlzIGEgYmFkIHZl bmRvciByZWxhdGlvbnNoaXAsIGFuZCBhIHZlbmRvciBkb2luZyB0aGF0IG11c3QgYmUgcHJl dHR5IGNvbmZpZGVudCB0aGF0IHRoZWlyIGN1c3RvbWVyIG90aGVyd2lzZSBsb3ZlcyB0aGVp ciBwcm9kdWN0IGFuZCBpc27igJl0IHRlbXB0ZWQgdG8gZmluZCBhbiBhbHRlcm5hdGl2ZSB2 ZW5kb3IuDQoNCj4NCj5BcyBhIHNlcGFyYXRlIGlzc3VlLCBmcm9tIGFuIG9wZXJhdGlvbmFs IHBvaW50IG9mIHZpZXcsIGltcGxpY2l0IA0KPmVuYWJsaW5nIG9mIGZ1bmN0aW9uYWxpdHkg aW4gb25lIGFyZWEgd2hlbiBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiANCj5hbm90aGVy IGlzIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGhhbmRsZWQgY2FyZWZ1bGx5IGJlY2F1 c2UgDQo+b3RoZXJ3aXNlIHlvdSBjYW4gZW5kIHVwIHZpb2xhdGluZyB0aGUgcHJpbmNpcGFs IG9mIGxlYXN0IGFzdG9uaXNobWVudC4NCg0KQW55b25lIGFzdG9uaXNoZWQgYnkgSVB2NiB3 b3JraW5nIG5lZWRzIHRvIGJlIGFzdG9uaXNoZWQuDQoNCkxlZQ0KDQoNCj4NCj5OaWNrDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52 Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnDQpBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hv bSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZp ZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5m b3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBl bGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNv cGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBD YXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5k IGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGll bGQgQXNzb2NpYXRpb24uCg== From nobody Thu Aug 3 06:34:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8F9132023 for ; Thu, 3 Aug 2017 06:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3d8OKoCVlVp for ; Thu, 3 Aug 2017 06:34:05 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0816132004 for ; Thu, 3 Aug 2017 06:34:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BF5EDA3; Thu, 3 Aug 2017 15:34:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501767240; bh=xSGHZzuqrBqSeLJqMdkH0aJZmgGX0oNZAodRF5NgwBQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DTAfGZw8ZWXHtEOmcKRgArADNr3dvjNvSY7dGWvNsah8uhSeLzW0U+MreVQy0H5LC bwejKPHaCE3MJQDvTL+6E4MpY+rBla0QE+Y564IZtDmuaMXnXVBM4KQuPQOBuvM6ZK GkWXZPP9Pr3pmDhkTJajAQiCDK0Q3MEmm0epl/RY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A78B9A2; Thu, 3 Aug 2017 15:34:00 +0200 (CEST) Date: Thu, 3 Aug 2017 15:34:00 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: Timothy Winters , IPv6 Operations In-Reply-To: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-465193425-1501767240=:2261" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:34:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-465193425-1501767240=:2261 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > And, if you prefer different wording in this 3315bis section, now’s the > time to raise that as we hope to send this on shorter (there will be a > -10 before we do that). https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09#section-18.2.12 If the client has any valid delegated prefixes obtained from the DHCP server, the client MUST initiate a Rebind/Reply message exchange as described in Section 18.2.5, with the exception that the retransmission parameters should be set as for the Confirm message (see Section 18.2.3). The client includes IA_NAs, IA_TAs, and IA_PDs, along with the associated leases, in its Rebind message. >From what I can tell, the events are like this in my current implementation: 15:00:05 client does renew, and receives Reply. 15:00:35 client does renew, and receives Reply. 15:01:00 port is reprovisioned, we now see RAs from different router(there is no 0-lifetime RA sent from old router before this) 15:01:05 client does renew, no answer 15:01:15 client does renew, no answer 15:01:35 client does renew, no answer 15:01:35 client does renew, no answer 15:01:35 client does rebind, no answer 15:01:44 client does rebind, no answer 15:02:03 client does rebind, no answer 15:02:35 client does rebind, no answer 15:02:35 client does solicit, and receives advertise 15:02:37 client does request, and receives reply After 15:01:00 there is a new DHCPv6-PD server available. 15:01:00 both WAN router and HGW does DAD and at 15:01:01 the new GUA based on the new RA/PIO is ready to go and since it has a higher preferred lifetime, it'll be used from now on. At around 15:01:31 I guess the old router is no longer counted as valid, at at 15:01:57 (one minute after the last RA seen from old server) means that PIO is no longer valid. It then takes DHCPv6 processing 15:02:36 until it goes into solicit and acquires a new PD plus other parameters. Now, I am no DHCPv6 expert, but would it hurt to go into solicit a lot earlier than it does in my timeline described before, when WAN RAs change enough? I know we might not want to invalidate the old prefix based on this, but what would potentially go wrong if the device went into solicit much earlier in the above process? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-465193425-1501767240=:2261-- From nobody Thu Aug 3 06:47:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABA3132368 for ; Thu, 3 Aug 2017 06:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDv0uPB3nH4t for ; Thu, 3 Aug 2017 06:47:08 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64842132364 for ; Thu, 3 Aug 2017 06:47:08 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m85so15890836wma.1 for ; Thu, 03 Aug 2017 06:47: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-transfer-encoding:content-language; bh=X1R35V3lZ+QkvrKq+aIcE/EK5Qy/HyDM9NlzohaIlDI=; b=bJ9OYtKFk50spJVgRTbrpSEqnYULp3amkKlcWP//Ab9Va1aFZ4kF5n4CnUv1xfP7xf 6WsAlu58JebqnX3vWwJ5Y0OD0AUqOgWlbx83VXONRztFBWGwxJDGmqVjfygCI/n/Ex/O 5e2535YHOGZ97gQh6fvoHaxd9PBzP+trQ/7N6XNF62xR7Ihk/cl81GLJID7slCPwRzbz Mk94wDanUVa7DLe7vrnyTK0KHAJVfjfUH2Hu6FsVWxjWmLLvX/JCc7TqMpgG2KlEOazd G7v/QzhAZ8FsWYEnG4DPGGaCXKfjeUGcIfaYD9vuMBEQolK2W/PuK4zeFoVxsOYSeF3k CyKw== 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-transfer-encoding :content-language; bh=X1R35V3lZ+QkvrKq+aIcE/EK5Qy/HyDM9NlzohaIlDI=; b=VQ9WnXt5v0kWovhpb5WsMPwxXD1GT5qxbMDq/vT1Qnrmm1Z6EAPZoWFHay8AidPOrG y0so9lPKpkePawT7cVpoE+hh+kuAHxLSu29TPNYwbErKkQre6eL8PBePtvl9ZxW69LL5 2ExYDTVXTMt3Wlgefk2VjapW53MB5xC6QvpFplUaOBcb9yOPRkc7bNC5LfoZepONVWR+ CPmvWpr97Slb2nJm1qnTMAk36QSO3G4gU7qqyPpHBhhc6PJsxgV4e0m5vwwfQXEBUaNW Pm+qapx5A1pXdgFmv9r4q6uTteCffDXAOlSqf8MSv1KU/zBBTO0g7ywMzZnsT60kBmm2 H4BQ== X-Gm-Message-State: AIVw110W4exNkjBQHdBH+aakty0uwhOabeluL4/K36GzjDsl4V8jW8/s jrWkNy0ycV11Dttb7dlSdA== X-Received: by 10.80.148.107 with SMTP id q40mr1957021eda.28.1501768026573; Thu, 03 Aug 2017 06:47:06 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:a4be:3fb9:bf20:21d0]) by smtp.gmail.com with ESMTPSA id x6sm1862800eda.33.2017.08.03.06.47.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 06:47:05 -0700 (PDT) To: Tim Chown Cc: "jordi.palet@consulintel.es" , "v6ops@ietf.org" References: <150174892257.9756.3478156248483230302.idtracker@ietfa.amsl.com> <8F324817-3646-4990-8DE0-DE1D47328927@consulintel.es> <4d100273-5dc3-0426-04f8-4197dd813cdf@gmail.com> From: Stephen Strowes Message-ID: Date: Thu, 3 Aug 2017 15:47:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:47:10 -0000 On 03/08/2017 14:11, Tim Chown wrote: > I suppose another way of looking at it is to ask on which elements of a network IPv4 support can be dropped, so that only IPv6 packets are carried, and only IPv6 needs to be configured and managed. This would be a nice characterisation. And when cast in that light, strongly related to parts of https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis S. >>> >>> -----Mensaje original----- >>> De: Stephen Strowes >>> Responder a: >>> Fecha: jueves, 3 de agosto de 2017, 11:35 >>> Para: , >>> Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt >>> >>> I agree with this line: >>> "we MUST NOT use the terminology "IPv6-only" in a generic way". >>> Agreed. I find that expanding "IPv6-only" to include mechanisms such as >>> NAT64 is contradictory and confusing. >>> I don't think it's useful to state, for example, that an "IPv6-only >>> access network" MAY have means to access the IPv4 network. But I do >>> think it's useful to state that a network is, say, IPv6+NAT64. >>> S. >>> On 03/08/2017 10:54, JORDI PALET MARTINEZ wrote: >>> > I don’t agree. >>> > >>> > As one of the co-chairs confirmed in the last meeting (and actually somehow called for this work), many folks even within IETF/v6ops are using IPv6-only for very different things. >>> > >>> > This is creating in many situations conversations that talk about different issues but we don’t realize it until we wasted too much time. I think there is a need to make sure that we all use the same terminology. >>> > >>> > So, this is not about NAT64, it is about the correct usage of IPv6-only, scoping it to the right part/s of the network or even the complete network end-to-end. >>> > >>> > Anyway, let’s see others opinions. >>> > >>> > Regards, >>> > Jordi >>> > >>> > >>> > -----Mensaje original----- >>> > De: en nombre de Philip Homburg >>> > Responder a: >>> > Fecha: jueves, 3 de agosto de 2017, 10:47 >>> > Para: >>> > CC: >>> > Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt >>> > >>> > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ >>> > > >>> > > Comments welcome! >>> > >>> > There is nothing IPv6-only about NAT64. So please stop doing this. >>> > >>> > The only definition of IPv6-only that makes sense in the long term is when >>> > there is no access to the IPv4 network at all. That is literally IPv6-only. >>> > >>> > Anything else is just bound to confuse people outside our small group. >>> > >>> > What we are discussing are IPv4 over IPv6 tunneling/translation techniques. >>> > >>> > >>> > >>> > >>> > ********************************************** >>> > 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 confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. >>> > >>> > >>> > >>> > _______________________________________________ >>> > v6ops mailing list >>> > v6ops@ietf.org >>> > https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >>> ********************************************** >>> 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 confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 3 07:16:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C01132424 for ; Thu, 3 Aug 2017 07:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ_5C5aLeYcr for ; Thu, 3 Aug 2017 07:16:43 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D05B132088 for ; Thu, 3 Aug 2017 07:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6114; q=dns/txt; s=iport; t=1501769803; x=1502979403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Zyc11tOTNAt03RtkakD/STFwAFY0O121QFpsGJQZ7AM=; b=HjArdW6U0e8WhvE7NMNZ5OqXkX+J8y+4MHQE1vkYZgglGjELohIbCWKy doSgk7bSqo0WxR43uy47GNof1zg/rc3NELVrgO3mAUej83SF72RCvEk+Z QOP+34JGLGw/S5+grizESrVhUNijCjmeBirjM+N7wwIezx+VQQIeEd62I E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAD4L4NZ/4MNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbScHjgiQB4FulhUOggQuhRkCGoQjPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIxE3DgUHBAIBCA4DBAEBAwIjAwICAjAUAQgIAgQOBQiKHwgQrQ2CJotPA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdggKDL4MngTyDBAEMBgEHAoMpgmE?= =?us-ascii?q?FiWSIb40qAodRjFGSUZYAAR84fwt3FYVgHIFndgEBhxQOF4EMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208";a="464262347" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 14:16:42 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v73EGge7029074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:16:42 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 09:16:41 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 09:16:41 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson CC: Timothy Winters , IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IIA= Date: Thu, 3 Aug 2017 14:16:41 +0000 Message-ID: <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:16:45 -0000 TWlrYWVsOg0KDQpJIGFzc3VtZSB5b3VyICJjbGllbnQiIGhlcmUgaXMgdGhlIERIQ1B2NiBjbGll bnQgb24gdGhlIFdBTiBsaW5rPw0KDQpJdCBsb29rcyBsaWtlIHRoZSBsaWZldGltZXMgZm9yIERI Q1B2NiBQRCB3ZXJlIGZhaXJseSBzaG9ydD8NCg0KMTU6MDA6MDUgY2xpZW50IGRvZXMgcmVuZXcs IGFuZCByZWNlaXZlcyBSZXBseS4NCjE1OjAwOjM1IGNsaWVudCBkb2VzIHJlbmV3LCBhbmQgcmVj ZWl2ZXMgUmVwbHkuDQoxNTowMTowMCBwb3J0IGlzIHJlcHJvdmlzaW9uZWQsIHdlIG5vdyBzZWUg UkFzIGZyb20gZGlmZmVyZW50IHJvdXRlcih0aGVyZSBpcyBubyAwLWxpZmV0aW1lIFJBIHNlbnQg ZnJvbSBvbGQgcm91dGVyIGJlZm9yZSB0aGlzKQ0KMTU6MDE6MDUgY2xpZW50IGRvZXMgcmVuZXcs IG5vIGFuc3dlcg0KDQpBbmQsIHRodXMgSSB0aGluayB0aGUgZXZlbnQgYXQgMTU6MDE6MDAgZGlk IG5vdCB0cmlnZ2VyIGFueXRoaW5nIHNwZWNpYWwuDQoNClRoZSAzMzE1YmlzIGhhcyBuZXcgdGV4 dCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJp cy0wOSNzZWN0aW9uLTE4LjIuMTI6DQoNCiAgIElmIG5vdCBhc3NvY2lhdGVkIHdpdGggb25lIG9m IHRoZSBhYm92ZSBtZW50aW9uZWQgY29uZGl0aW9ucywgYQ0KICAgY2xpZW50IE1BWSBpbml0aWF0 ZSBhIFJlbmV3L1JlcGx5IGV4Y2hhbmdlIChhcyBpZiB0aGUgVDEgdGltZQ0KICAgZXhwaXJlZCkg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMTguMi40IG9yIGFuIEluZm9ybWF0aW9uLVJlcXVlc3Qv DQogICBSZXBseSBleGNoYW5nZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxOC4yLjYgaWYgdGhl IGNsaWVudCBkZXRlY3RzIGENCiAgIHNpZ25pZmljYW50IGNoYW5nZSByZWdhcmRpbmcgdGhlIHBy ZWZpeGVzIGF2YWlsYWJsZSBvbiB0aGUgbGluayAod2hlbg0KICAgbmV3IGFyZSBhZGRlZCBvciBl eGlzdGluZyBhcmUgZGVwcmVjYXRlZCkgYXMgdGhpcyBtYXkgaW5kaWNhdGUgYQ0KICAgY29uZmln dXJhdGlvbiBjaGFuZ2UuICBIb3dldmVyLCBhIGNsaWVudCBNVVNUIHJhdGUgbGltaXQgc3VjaA0K ICAgYXR0ZW1wdHMgdG8gYXZvaWQgZmxvb2RpbmcgYSBzZXJ2ZXIgd2l0aCByZXF1ZXN0cyB3aGVu IHRoZXJlIGFyZSBsaW5rDQogICBpc3N1ZXMgKGZvciBleGFtcGxlLCBvbmx5IGRvaW5nIG9uZSBv ZiB0aGVzZSBhdCBtb3N0IGV2ZXJ5IDMwDQogICBzZWNvbmRzKS4NCg0KQnV0IHBlcmhhcHMgdGhp cyByZWNvbW1lbmRhdGlvbiB0byB1c2UgUmVuZXcvUmVwbHkgaXMgZmxhd2VkIGlmIHRoZSBvbGQg KFdBTikgcm91dGVyIGlzIGdvbmU/IFdlIHdlcmUgdGhpbmtpbmcgdGhhdCB0aGlzIHdhcyBtb3Jl IGxpa2VseSBhIHNpdHVhdGlvbiB3aGVyZSBhIG5ldyBwcmVmaXggd2FzIGFkZGVkLCBvciBzb21l IHByZWZpeGVzIHdlcmUgcmVtb3ZlZC4gV2UgaGFkIGZpZ3VyZWQgYSBjaGFuZ2Ugb2Ygcm91dGVy IHdvdWxkIGxpa2VseSBpbnZvbHZlIGEgbGluayByZWNvbm5lY3Rpb24gKHdoaWNoIGRvZXMgdHJp Z2dlciBSZWJpbmQvUmVwbHkgYXMgZWFybGllciBpbiB0aGF0IGFib3ZlIHJlZmVyZW5jZWQgc2Vj dGlvbikuIEJ1dCBpdCBsb29rcyBsaWtlIGluIHlvdXIgY2FzZSB0aGVyZSBpcyBubyBsaW5rIGNo YW5nZS4gQW5kLCBldmVuIGlmIHRoZSBjbGllbnQgZGV0ZWN0ZWQgYSAic2lnbmlmaWNhbnQgY2hh bmdlIiwgdGhlIFJlbmV3IHdvdWxkIGZhaWwgaWYgdGhhdCByb3V0ZXIgaXMgZ29uZS4NCg0KLSBC ZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pa2FlbCBBYnJhaGFt c3NvbiBbbWFpbHRvOnN3bWlrZUBzd20ucHAuc2VdIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAw MywgMjAxNyA5OjM0IEFNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4N CkNjOiBUaW1vdGh5IFdpbnRlcnMgPHR3aW50ZXJzQGlvbC51bmguZWR1PjsgSVB2NiBPcGVyYXRp b25zIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGNsYXJpZmljYXRpb24g cmVnYXJkaW5nIFJGQzcwODQgRy01IHJlcXVpcmVtZW50DQoNCk9uIFRodSwgMyBBdWcgMjAxNywg QmVybmllIFZvbHogKHZvbHopIHdyb3RlOg0KDQo+IEFuZCwgaWYgeW91IHByZWZlciBkaWZmZXJl bnQgd29yZGluZyBpbiB0aGlzIDMzMTViaXMgc2VjdGlvbiwgbm934oCZcyANCj4gdGhlIHRpbWUg dG8gcmFpc2UgdGhhdCBhcyB3ZSBob3BlIHRvIHNlbmQgdGhpcyBvbiBzaG9ydGVyICh0aGVyZSB3 aWxsIA0KPiBiZSBhDQo+IC0xMCBiZWZvcmUgd2UgZG8gdGhhdCkuDQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTA5I3NlY3Rpb24tMTguMi4x Mg0KDQogICAgSWYgdGhlIGNsaWVudCBoYXMgYW55IHZhbGlkIGRlbGVnYXRlZCBwcmVmaXhlcyBv YnRhaW5lZCBmcm9tIHRoZSBESENQDQogICAgc2VydmVyLCB0aGUgY2xpZW50IE1VU1QgaW5pdGlh dGUgYSBSZWJpbmQvUmVwbHkgbWVzc2FnZSBleGNoYW5nZSBhcw0KICAgIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDE4LjIuNSwgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgdGhlDQogICAgcmV0cmFuc21p c3Npb24gcGFyYW1ldGVycyBzaG91bGQgYmUgc2V0IGFzIGZvciB0aGUgQ29uZmlybSBtZXNzYWdl DQogICAgKHNlZSBTZWN0aW9uIDE4LjIuMykuICBUaGUgY2xpZW50IGluY2x1ZGVzIElBX05Bcywg SUFfVEFzLCBhbmQNCiAgICBJQV9QRHMsIGFsb25nIHdpdGggdGhlIGFzc29jaWF0ZWQgbGVhc2Vz LCBpbiBpdHMgUmViaW5kIG1lc3NhZ2UuDQoNCkZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGUgZXZl bnRzIGFyZSBsaWtlIHRoaXMgaW4gbXkgY3VycmVudA0KaW1wbGVtZW50YXRpb246DQoNCjE1OjAw OjA1IGNsaWVudCBkb2VzIHJlbmV3LCBhbmQgcmVjZWl2ZXMgUmVwbHkuDQoxNTowMDozNSBjbGll bnQgZG9lcyByZW5ldywgYW5kIHJlY2VpdmVzIFJlcGx5Lg0KMTU6MDE6MDAgcG9ydCBpcyByZXBy b3Zpc2lvbmVkLCB3ZSBub3cgc2VlIFJBcyBmcm9tIGRpZmZlcmVudCByb3V0ZXIodGhlcmUgaXMg bm8gMC1saWZldGltZSBSQSBzZW50IGZyb20gb2xkIHJvdXRlciBiZWZvcmUgdGhpcykNCjE1OjAx OjA1IGNsaWVudCBkb2VzIHJlbmV3LCBubyBhbnN3ZXINCjE1OjAxOjE1IGNsaWVudCBkb2VzIHJl bmV3LCBubyBhbnN3ZXINCjE1OjAxOjM1IGNsaWVudCBkb2VzIHJlbmV3LCBubyBhbnN3ZXINCjE1 OjAxOjM1IGNsaWVudCBkb2VzIHJlbmV3LCBubyBhbnN3ZXINCjE1OjAxOjM1IGNsaWVudCBkb2Vz IHJlYmluZCwgbm8gYW5zd2VyDQoxNTowMTo0NCBjbGllbnQgZG9lcyByZWJpbmQsIG5vIGFuc3dl cg0KMTU6MDI6MDMgY2xpZW50IGRvZXMgcmViaW5kLCBubyBhbnN3ZXINCjE1OjAyOjM1IGNsaWVu dCBkb2VzIHJlYmluZCwgbm8gYW5zd2VyDQoxNTowMjozNSBjbGllbnQgZG9lcyBzb2xpY2l0LCBh bmQgcmVjZWl2ZXMgYWR2ZXJ0aXNlDQoxNTowMjozNyBjbGllbnQgZG9lcyByZXF1ZXN0LCBhbmQg cmVjZWl2ZXMgcmVwbHkNCg0KQWZ0ZXIgMTU6MDE6MDAgdGhlcmUgaXMgYSBuZXcgREhDUHY2LVBE IHNlcnZlciBhdmFpbGFibGUuIDE1OjAxOjAwIGJvdGggV0FOIHJvdXRlciBhbmQgSEdXIGRvZXMg REFEIGFuZCBhdCAxNTowMTowMSB0aGUgbmV3IEdVQSBiYXNlZCBvbiB0aGUgbmV3IFJBL1BJTyBp cyByZWFkeSB0byBnbyBhbmQgc2luY2UgaXQgaGFzIGEgaGlnaGVyIHByZWZlcnJlZCBsaWZldGlt ZSwgaXQnbGwgYmUgdXNlZCBmcm9tIG5vdyBvbi4gQXQgYXJvdW5kIDE1OjAxOjMxIEkgZ3Vlc3Mg dGhlIG9sZCByb3V0ZXIgaXMgbm8gbG9uZ2VyIGNvdW50ZWQgYXMgdmFsaWQsIGF0IGF0IDE1OjAx OjU3IChvbmUgbWludXRlIGFmdGVyIHRoZSBsYXN0IFJBIHNlZW4gZnJvbSBvbGQgc2VydmVyKSBt ZWFucyB0aGF0IFBJTyBpcyBubyBsb25nZXIgdmFsaWQuDQoNCkl0IHRoZW4gdGFrZXMgREhDUHY2 IHByb2Nlc3NpbmcgMTU6MDI6MzYgdW50aWwgaXQgZ29lcyBpbnRvIHNvbGljaXQgYW5kIGFjcXVp cmVzIGEgbmV3IFBEIHBsdXMgb3RoZXIgcGFyYW1ldGVycy4NCg0KTm93LCBJIGFtIG5vIERIQ1B2 NiBleHBlcnQsIGJ1dCB3b3VsZCBpdCBodXJ0IHRvIGdvIGludG8gc29saWNpdCBhIGxvdCBlYXJs aWVyIHRoYW4gaXQgZG9lcyBpbiBteSB0aW1lbGluZSBkZXNjcmliZWQgYmVmb3JlLCB3aGVuIFdB TiBSQXMgY2hhbmdlIGVub3VnaD8gSSBrbm93IHdlIG1pZ2h0IG5vdCB3YW50IHRvIGludmFsaWRh dGUgdGhlIG9sZCBwcmVmaXggYmFzZWQgb24gdGhpcywgYnV0IHdoYXQgd291bGQgcG90ZW50aWFs bHkgZ28gd3JvbmcgaWYgdGhlIGRldmljZSB3ZW50IGludG8gc29saWNpdCBtdWNoIGVhcmxpZXIg aW4gdGhlIGFib3ZlIHByb2Nlc3M/DQoNCi0tIA0KTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWls OiBzd21pa2VAc3dtLnBwLnNlDQo= From nobody Thu Aug 3 07:30:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A1132367 for ; Thu, 3 Aug 2017 07:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiItPZ0bv05Z for ; Thu, 3 Aug 2017 07:30:33 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FF513235E for ; Thu, 3 Aug 2017 07:30:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 40036A6; Thu, 3 Aug 2017 16:30:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501770630; bh=UglaPyf9zvmCuGSW1L8JlEx6uzqET7bYee6Aqx4eKYU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=cJ+9zU04lTzVp3ufeqtqlmqEiO4AWDgP35g+uS4gZOK8A/ZZsod/0BdJnuPs+cC+J 8KWiYtrD+suVi7Cd0ESrbgiOIkku80plzAcXiyX3JpLUZtDqth7hqfCWXoA1nLVkV7 hKmr0/7kDSkIGgkmE1l7N3R1GfNrrNsvrRdG32Y8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3A9D4A3; Thu, 3 Aug 2017 16:30:30 +0200 (CEST) Date: Thu, 3 Aug 2017 16:30:30 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: Timothy Winters , IPv6 Operations In-Reply-To: <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:30:35 -0000 On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > But perhaps this recommendation to use Renew/Reply is flawed if the old > (WAN) router is gone? We were thinking that this was more likely a > situation where a new prefix was added, or some prefixes were removed. > We had figured a change of router would likely involve a link > reconnection (which does trigger Rebind/Reply as earlier in that above > referenced section). But it looks like in your case there is no link > change. And, even if the client detected a "significant change", the > Renew would fail if that router is gone. Correct. The port is completely reprovisioned, and there is no physical link indication that this has happened. The only indication to the client is that it's now receiving RAs with a completely different subnet from another router, and the old router (after 30 second) is no longer valid. I consider this a significant enough change that I'd like for the DHCPv6-PD requestor (client) to go into solicit mode. However, I don't know the implications of this on normal operation. What is the downside of going into solicit mode in case the old DHCPv6 server is still there? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 07:34:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EE3132385 for ; Thu, 3 Aug 2017 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE2Yg52BbOsx for ; Thu, 3 Aug 2017 07:34:10 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C84132381 for ; Thu, 3 Aug 2017 07:34:10 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id p3so8608721qtg.2 for ; Thu, 03 Aug 2017 07:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=04CoDtNZ04mFZv0eRhWPQnXcZkKgprgG7tZ//3mrIBY=; b=ojFqadq0TNTbkds2PYD3/aD/DD5Ze42WRd7iDFp/iaM91GwDhIvzFpLrWjqRPkPIeE SFwrmHR13zBZfp05kJTqRyTiTXzYGzfGB9NEC8rf9f8ZicwmLTqawJz8D5X/5hMTlzhG Qtl3ICaT6dM4YjKvBTUdZDYpKM1S+RvrD1uyFg3O4yXG/3ASluL7ClVVzScVve+oDm0u tTY0+/yMQ43HHMQbSLxBQXh8DqU2g8arXGmhjVMT/J/KgISDDKB1X7mARCCoVaU4xgHS g250vHZ+v2a3lPZFuIatSBsoS7wrYn6t+kgjPWFLLTUpTkg73HGPI9bmHYe9pqSDo0Of FgXQ== 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=04CoDtNZ04mFZv0eRhWPQnXcZkKgprgG7tZ//3mrIBY=; b=SR3D8zPA8tbdW9LmI6EYYcJWESLHcVLz1miPrTE/SGFEpIqcpTOnEvsn+QbEbK/dg7 Wb5ePj2eKQar6DwVuJaYtqAC/4NT+K6LvGzc6I6rZgNoFSvgdzhJGIMS5oNmLSXHH7cD QmC7QpCsqHQI9YKAl5bdJF4JcwscKaawKwPY9WKQdTGY1VVC2qBeSeMgMSF1tgiS9Bin Ff/dSxnQ3W+jMTLHfAK+QGNDt+//jO6r47dFymd6j4Fb/dn56FntdOBUf7SpzNfMCKko o/D4OKouKDnNo43k+bDh3BFQQBkFfQaUGXjLzwIOWt2TS4AvNnW5Ci5Q089uvvqPtgEC m8+Q== X-Gm-Message-State: AHYfb5jPd2Ak/6Cx9DvM2ncPFgOW0R24771pP/AVI7gVXkDUTW2I4Lj4 psVDZtzo/pzl0jae X-Received: by 10.237.63.163 with SMTP id s32mr2520000qth.61.1501770849503; Thu, 03 Aug 2017 07:34:09 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k29sm12792973qtb.13.2017.08.03.07.34.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 07:34:08 -0700 (PDT) From: Ted Lemon Message-Id: <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_09D45EFF-CF9F-4F62-821F-FAB62B79686A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 10:34:07 -0400 In-Reply-To: Cc: "Bernie Volz (volz)" , IPv6 Operations To: Mikael Abrahamsson References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:34:12 -0000 --Apple-Mail=_09D45EFF-CF9F-4F62-821F-FAB62B79686A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson = wrote: > Correct. The port is completely reprovisioned, and there is no = physical link indication that this has happened. The only indication to = the client is that it's now receiving RAs with a completely different = subnet from another router, and the old router (after 30 second) is no = longer valid. This is a pretty broken situation. Can you talk more about this use = case? That said, I think your point is valid: if the RA for the old prefix = goes away, and there's a new prefix being advertised, the client should = be trying to get a new address. But why are you even doing DHCP = allocation on this link? It seems like the use case for DHCP = allocation is on a thoroughly managed network, where we would = essentially never see a flash renumber event. --Apple-Mail=_09D45EFF-CF9F-4F62-821F-FAB62B79686A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
Correct. The port = is completely reprovisioned, and there is no physical link indication = that this has happened. The only indication to the client is that it's = now receiving RAs with a completely different subnet from another = router, and the old router (after 30 second) is no longer = valid.

This is a pretty broken situation.   Can = you talk more about this use case?

That said, I think your point is valid: = if the RA for the old prefix goes away, and there's a new prefix being = advertised, the client should be trying to get a new address.   But = why are you even doing DHCP allocation on this link?   It seems = like the use case for DHCP allocation is on a thoroughly managed = network, where we would essentially never see a flash renumber = event.

= --Apple-Mail=_09D45EFF-CF9F-4F62-821F-FAB62B79686A-- From nobody Thu Aug 3 07:36:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D851323AB for ; Thu, 3 Aug 2017 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMA-3gAS_UKI for ; Thu, 3 Aug 2017 07:36:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51D5132007 for ; Thu, 3 Aug 2017 07:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2255; q=dns/txt; s=iport; t=1501770998; x=1502980598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aUMblZGal5Ni0n2HcuhSM0DrU6gDK6tqkonQSZiw1pk=; b=isugxuUuShh0P9F7NywpK7yM3gJKXKTBa84rr09Kl6v6U7s6zGSzdEME SVdwuFiKwrjSCaS4KwyfolIfAcPwvr4nAjfxOkVMK2GfSIj8JUMgQuq/c PzukUCKTkBFvAlwwmGrcazvJWPgH8SUidO/vvSmdk/MWC6BSDS9IKb8fu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAAC7NINZ/4ENJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBUScHjgiQB4FulhUOggSFRwKEPT8YAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CATo/BQcEAgEIDgMEAQEfCQcyFAkIAgQOBQiKHwivTYtPAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYMoggKGVoE8gwQBEgEHAoYKBZ99ApQiklGWAAEfOH8LdxWHY3a?= =?us-ascii?q?HJIEjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208";a="464273481" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 14:36:13 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v73EaDLr028972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:36:13 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 09:36:12 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 09:36:12 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson CC: Timothy Winters , IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IICAAFqpAP//rHkA Date: Thu, 3 Aug 2017 14:36:12 +0000 Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:36:40 -0000 While it could take an additional set of round trip messages, the Rebind/Re= ply would be better since it would not involve to "stop" using the existing= address/delegated prefixes that a Solicit would entail. And, in many cases= we might expect that the original router is still there? So, I think the g= eneral case should be Rebind/Reply (which might be successful or result in = Solicit/Reply after several attempts). But perhaps the client can be smarter about this if it doesn't have any (DH= CPv6 assigned) address/delegated prefixes (i.e., they might have been depre= cated) then going to Solicit directly would of course be better. - Bernie -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Thursday, August 03, 2017 10:31 AM To: Bernie Volz (volz) Cc: Timothy Winters ; IPv6 Operations Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > But perhaps this recommendation to use Renew/Reply is flawed if the=20 > old > (WAN) router is gone? We were thinking that this was more likely a=20 > situation where a new prefix was added, or some prefixes were removed. > We had figured a change of router would likely involve a link=20 > reconnection (which does trigger Rebind/Reply as earlier in that above=20 > referenced section). But it looks like in your case there is no link=20 > change. And, even if the client detected a "significant change", the=20 > Renew would fail if that router is gone. Correct. The port is completely reprovisioned, and there is no physical lin= k indication that this has happened. The only indication to the client is t= hat it's now receiving RAs with a completely different subnet from another = router, and the old router (after 30 second) is no longer valid. I consider this a significant enough change that I'd like for the DHCPv6-PD= requestor (client) to go into solicit mode. However, I don't know the impl= ications of this on normal operation. What is the downside of going into so= licit mode in case the old DHCPv6 server is still there? --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 07:41:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65AE13203D for ; Thu, 3 Aug 2017 07:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzLcni5-IR0l for ; Thu, 3 Aug 2017 07:41:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB80132474 for ; Thu, 3 Aug 2017 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12862; q=dns/txt; s=iport; t=1501771302; x=1502980902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q4DqF+6kMpBt26e76BI4F8yujE+g1vvpruLW7vWUn5k=; b=UbQWevNoij2YPrggUYmjwoy6kFbPW5Yfo9h1+h4NpAHjMuNV+OgS4Vfi gKefaRAXuHC2ExhMrqEhBpEkW5+xF/adaTQdOYTXZnh/6sVg0zykgUQUS L2ud5hSE/P69EORWdyEaft827+agZxtxT45bQ2VRujNRxzIe/6CD3lqpC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAACeNYNZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG0nB44IkAaBbpBihTOCEoVHAoQ9PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMtTBACAQgOAwQBASgHMhQJCAIEAQ0FCIlDZK9Ni04BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgyiCAoZWgTyDIUyFPgWffQKUIpJRlgABHziBCncVhWAcgWd?= =?us-ascii?q?2iEeBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208,217";a="465420278" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2017 14:41:41 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v73EffJt027776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:41:41 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 09:41:40 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 09:41:40 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Mikael Abrahamsson CC: IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IICAAFqpAIAAAQOA//+sw4A= Date: Thu, 3 Aug 2017 14:41:40 +0000 Message-ID: <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> In-Reply-To: <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.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: [10.98.1.198] Content-Type: multipart/alternative; boundary="_000_0bbb770f87534cac9d1b021f78c4d1f1XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:41:44 -0000 --_000_0bbb770f87534cac9d1b021f78c4d1f1XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted: Agreed it would be interesting to understand exactly why this happens. I could see this occurring in cases where a subscriber is moved for some re= ason, but that should be a rare event and hopefully planned (i.e., use much= shorter lifetimes). And, that may be exactly what was happening here as th= e PD lifetimes were rather short. What's a bit odd in Mikael's timeline: 15:01:35 client does renew, no answer 15:01:35 client does rebind, no answer 15:01:44 client does rebind, no answer 15:02:03 client does rebind, no answer 15:02:35 client does rebind, no answer 15:02:35 client does solicit, and receives advertise Is why there was nothing received to the Rebind requests (these would have = been multicast)? This should have gone to all servers and hence triggered a= response from the DHCP server. In theory, new configuration should have been available closer to 15:01:35,= almost a minute earlier than it was? - Bernie From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, August 03, 2017 10:34 AM To: Mikael Abrahamsson Cc: Bernie Volz (volz) ; IPv6 Operations Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson > wrote: Correct. The port is completely reprovisioned, and there is no physical lin= k indication that this has happened. The only indication to the client is t= hat it's now receiving RAs with a completely different subnet from another = router, and the old router (after 30 second) is no longer valid. This is a pretty broken situation. Can you talk more about this use case? That said, I think your point is valid: if the RA for the old prefix goes a= way, and there's a new prefix being advertised, the client should be trying= to get a new address. But why are you even doing DHCP allocation on this= link? It seems like the use case for DHCP allocation is on a thoroughly = managed network, where we would essentially never see a flash renumber even= t. --_000_0bbb770f87534cac9d1b021f78c4d1f1XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted:

 

Agreed it would be interesting to und= erstand exactly why this happens.

 

I could see this occurring in cases w= here a subscriber is moved for some reason, but that should be a rare event= and hopefully planned (i.e., use much shorter lifetimes). And, that may be exactly what was happening here as the PD lif= etimes were rather short.

 

What’s a bit odd in Mikael̵= 7;s timeline:

 

15:01:35 client does renew, no answer<= /p>

15:01:35 client does rebind, no answer=

15:01:44 client does rebind, no answer=

15:02:03 client does rebind, no answer=

15:02:35 client does rebind, no answer=

15:02:35 client does solicit, and receives advert= ise

 

Is why there was nothing received to = the Rebind requests (these would have been multicast)? This should have gon= e to all servers and hence triggered a response from the DHCP server.

 

In theory, new configuration should h= ave been available closer to 15:01:35, almost a minute earlier than it was?=

 

-   =        Bernie

 

From: Ted Lemon [mailto:mellon@fugue= .com]
Sent: Thursday, August 03, 2017 10:34 AM
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Bernie Volz (volz) <volz@cisco.com>; IPv6 Operations <v= 6ops@ietf.org>
Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement=

 

On Aug 3, 2017, at 10:30 AM, Mikael Abrahamsson <= swmike@swm.pp.se> wrote:

Correct. The port is completely reprovisioned, and= there is no physical link indication that this has happened. The only indi= cation to the client is that it's now receiving RAs with a completely different subnet from another router, and the old ro= uter (after 30 second) is no longer valid.

 

This is a pretty broken situation.   Can you ta= lk more about this use case?

 

That said, I think your point is valid: if the RA fo= r the old prefix goes away, and there's a new prefix being advertised, the = client should be trying to get a new address.   But why are you even d= oing DHCP allocation on this link?   It seems like the use case for DHCP allocation is on a thoroughly managed net= work, where we would essentially never see a flash renumber event.

 

--_000_0bbb770f87534cac9d1b021f78c4d1f1XCHALN003ciscocom_-- From nobody Thu Aug 3 08:32:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2101323B7 for ; Thu, 3 Aug 2017 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkMDNpLqVAw3 for ; Thu, 3 Aug 2017 08:32:39 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D6D1323B0 for ; Thu, 3 Aug 2017 08:32:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C0363A6; Thu, 3 Aug 2017 17:32:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501774356; bh=cqHCRUdbp8GUvfAWXVqxsQR65Ol3uVdLO0fIArRyMu0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=aBAtZBfS0mM3TDmGCp1k+ffhz5x+QXKnA4gXnFVHZqc5DiW0oLeOpaMXOVa0CRsOf bR6naGnc9FIFP+LTm+j2dJf0ACmIBhv62VT24ZE/lrLGmDFdgF+Uwcm/w1v1EH9yNg OgY8qyyDZeOcRySp/ayMsdvzIis8K0G4kkXLj328= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A8CFFA3; Thu, 3 Aug 2017 17:32:36 +0200 (CEST) Date: Thu, 3 Aug 2017 17:32:36 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon cc: "Bernie Volz (volz)" , IPv6 Operations In-Reply-To: <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:32:41 -0000 On Thu, 3 Aug 2017, Ted Lemon wrote: > This is a pretty broken situation. Can you talk more about this use > case? C1-RG-L2-R1 C1 = Customer computer RG = Residential Gateway (RFC7084 style device) L2 = L2 aggregation switch R1 = L3 aggregation device. R1 can either be in "L2 tunneling mode" to somewhere, or it's a regular router, sending RAs. When customer doesn't have any serivice, R1 is in "L2 tunneling mode" to a cloud based signup portal. This portal sends RAs, handled DHCPv6-PD, over the tunnel. Customer presses "signup" to a service. R1 is now reprovisioned into L3 mode and starts sending RAs, is a DHCPv6 relay etc. RG has no idea this happened, because it's connected to L2 switch that doesn't go "down". > That said, I think your point is valid: if the RA for the old prefix > goes away, and there's a new prefix being advertised, the client should > be trying to get a new address. But why are you even doing DHCP > allocation on this link? It seems like the use case for DHCP allocation > is on a thoroughly managed network, where we would essentially never see > a flash renumber event. We have no other mechanism to hand out prefixes apart from DHCPv6-PD. I'd be happy to deprecate that and create ND based method. Right now I am not great fan of DHCP. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 08:41:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CC61324A5 for ; Thu, 3 Aug 2017 08:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AFUoYPFYKl2 for ; Thu, 3 Aug 2017 08:41:24 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171631324D1 for ; Thu, 3 Aug 2017 08:41:24 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CCF0A6; Thu, 3 Aug 2017 17:41:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501774882; bh=XGscB5n0OCW5XdGqDyVfFocdUHuLZQSNVqaq9sgQ7Fc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FyDnUzsolAqRaY4cPxx17fHARKPZzUmQoRrCUrQ8RBN0ibs61rOkB0uDS9WY9uc/b CTbWfQoozNehwQjLDLCXNHNMmUa/lxJdF1ZJbTvKcNMlWGEy15//g1CAlZwtZXGVQR b5ZZOSioge5pem23iq5DIdwu9UXOz9Yje06/Qh1Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 78513A3; Thu, 3 Aug 2017 17:41:22 +0200 (CEST) Date: Thu, 3 Aug 2017 17:41:22 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: Timothy Winters , IPv6 Operations In-Reply-To: Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:41:25 -0000 On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > While it could take an additional set of round trip messages, the > Rebind/Reply would be better since it would not involve to "stop" using > the existing address/delegated prefixes that a Solicit would entail. So it can never go into solicit without stopping to use the allocated resources? Isn't there a way to use DHCPv6 client to "discover" all DHCPv6 relays/servers existing on the link, without stopping to use all current resources earlier handed out via DHCPv6? Because if it did, it could run this "what DHCPv6 based servers are there out there?" and if the old one isn't available, my RA based resources are now no longer valid, perhaps this is a good indication that my DHCPv6 based resources are no longer valid either, and I should stop using them? At least this could be a use-case for an RFC7084 type device on its WAN port, this might not make the most sense for other use-cases. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 08:45:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA56132586 for ; Thu, 3 Aug 2017 08:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PHd21GqrLHx for ; Thu, 3 Aug 2017 08:45:28 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9FE13200C for ; Thu, 3 Aug 2017 08:45:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A6DCEA6; Thu, 3 Aug 2017 17:45:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501775126; bh=etPh5E4L3yqyEZU8OrNgh61QMPqfjGKLic8znoWzWy0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=i4InELni8CYpdBzo4rJvuEADfHip+u0BDwwBHV2cxlNZ/cf8jo4AgUXNZ27KqdIlu qoZZm8fneRCyT4r5HVtzFzMcgCQ3ttB0r1jSYHypv78q9463tN+/MJVxSWoTgvTDNi ZxMoxZXYwKTvgrbrsatapWJsjdjjm2FhLp7Hi0fk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A3F88A3; Thu, 3 Aug 2017 17:45:26 +0200 (CEST) Date: Thu, 3 Aug 2017 17:45:26 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: Ted Lemon , IPv6 Operations In-Reply-To: <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:45:29 -0000 On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > > Is why there was nothing received to the Rebind requests (these would > have been multicast)? This should have gone to all servers and hence > triggered a response from the DHCP server. The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst address ff02::1:2 So yes, looks like multicast to me. The rebind and solicits look identical from a src/dst/mac point of view. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 08:50:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13E132344 for ; Thu, 3 Aug 2017 08:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEzQryDo6_D0 for ; Thu, 3 Aug 2017 08:50:11 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07041131FC7 for ; Thu, 3 Aug 2017 08:50:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9EA95A6; Thu, 3 Aug 2017 17:50:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501775408; bh=Jafau1a0XD+kF1sHfR4jYEpTu3yptzcmo+kiFmCpOEA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mYNuGrProTJjmRUFAEBJ0GBe3FBNQpt1cwtFdcUxGJMBX5GJnf460SG+MY0o7BWNz eYm+viqZOtObXsLZWBp4V3m4YL4x4lscxmeqRIYjWpl6BO1P0eYwz9vOqJMq+26GK+ a4YCyJQEoOO1BVAqDVwVdxneLlINaKZ8xyrsM22g= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9BF6FA3; Thu, 3 Aug 2017 17:50:08 +0200 (CEST) Date: Thu, 3 Aug 2017 17:50:08 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: IPv6 Operations In-Reply-To: Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:50:12 -0000 On Thu, 3 Aug 2017, Mikael Abrahamsson wrote: > On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: >> >> Is why there was nothing received to the Rebind requests (these would have >> been multicast)? This should have gone to all servers and hence triggered a >> response from the DHCP server. > > The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst address > ff02::1:2 > > So yes, looks like multicast to me. The rebind and solicits look identical > from a src/dst/mac point of view. Just to clarify. The signup portal has completely different prefixes in its PD pool compared to the active port DHCPv6 PD pool. So after reprovisioning of the port the RG is doing rebind for IA_PD prefix that no DHCPv6 server/relay on the link is configured to serve. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 09:00:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F98132429 for ; Thu, 3 Aug 2017 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtHqTfnQ4X5x for ; Thu, 3 Aug 2017 09:00:39 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FEC132110 for ; Thu, 3 Aug 2017 09:00:39 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id s6so10245856qtc.1 for ; Thu, 03 Aug 2017 09:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HlnQXDJg61JiVGuL8SlfjRo2whOM6kRCP/uRZN/gJCY=; b=yf9mpjJz3bGfmiZXGv8t6RTcRI8FnGwEi0l89XayCIS7NXeWvMN/xGTLFwUCwid6cj rce+BjuQgGvXZJbkqtMeG2WSh64kl+q8ulVssyZVP4e3HaTz00kt5LXZmUdRVk9n1Zia 4IHpTzMz/hWPFQA/tzeh4ff6dLM56YAZaAc6JuE+DqGngXWKGc+eOL+9FLUEC5Bc1mNd wus2sSnR+GjTuGeBJU/LEQvCOMeOGHfCoYiH0pMCkguNiIrVK1+NZ4FY/jc2BK/YVd1n 0hjZzXCDXWvJcwsf+DvNhCwvp7DhFEEDDolkBjbY+a/DVDaO48nBakDv1gyOJlAHdJ7i 5H+A== 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=HlnQXDJg61JiVGuL8SlfjRo2whOM6kRCP/uRZN/gJCY=; b=XOwboZtl278c7HnujPhnQ5Fyan6uohZBLilGCRZ55834IwUMpYUNn6qGcd1wPdCRjG ytB6spP9nx/PyA1JXW7xPmlCLT+2kuwXf2xKJKPtbcj9TTue2K5nOFrzMghuY29ctAnz yA5T5lZjLHRCDK3OIt1ZJ4y1lUwvy+pV+a18yJffPaHs4+0VVXbavTfdR+39G2jJ9BO+ RLxpiWQU90Ponu4pnjvaXiQ0fbcvD66KcpVgoVUBiw0/B8UDUymzFc93+XnailL4SYSg EUvvhi3SwtUQ+Rpz+OnU5ZzU54oJk1cw0fcQhYTc+cAfsinE2z4m7dFKVWevqSDPm1lC 2w1w== X-Gm-Message-State: AIVw110upvwq6TxbH/MawyHIWSmOKMjWDyhqF9R+PYla7SNRnx20NccC /KdvuSjTHKxq7BAfKa3uSA== X-Received: by 10.237.40.69 with SMTP id r63mr3007467qtd.72.1501776038081; Thu, 03 Aug 2017 09:00:38 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id v64sm25298827qkd.96.2017.08.03.09.00.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 09:00:36 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1517C1B2-8790-4B79-963C-B0457C3D9207" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 12:00:35 -0400 In-Reply-To: Cc: "Bernie Volz (volz)" , IPv6 Operations To: Mikael Abrahamsson References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:00:41 -0000 --Apple-Mail=_1517C1B2-8790-4B79-963C-B0457C3D9207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson = wrote: > Just to clarify. The signup portal has completely different prefixes = in its PD pool compared to the active port DHCPv6 PD pool. So after = reprovisioning of the port the RG is doing rebind for IA_PD prefix that = no DHCPv6 server/relay on the link is configured to serve. If your DHCP server were configured correctly, it would respond to the = Rebind indicating that the lifetime of the sign-on mode prefix is zero. = Also, now that I think about it, aren't Renews multicast as well?= --Apple-Mail=_1517C1B2-8790-4B79-963C-B0457C3D9207 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
Just to clarify. = The signup portal has completely different prefixes in its PD pool = compared to the active port DHCPv6 PD pool. So after reprovisioning of = the port the RG is doing rebind for IA_PD prefix that no DHCPv6 = server/relay on the link is configured to serve.

If = your DHCP server were configured correctly, it would respond to the = Rebind indicating that the lifetime of the sign-on mode prefix is zero. =   Also, now that I think about it, aren't Renews multicast as = well?
= --Apple-Mail=_1517C1B2-8790-4B79-963C-B0457C3D9207-- From nobody Thu Aug 3 09:05:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8DB132543 for ; Thu, 3 Aug 2017 09:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKxPXQ535EhM for ; Thu, 3 Aug 2017 09:05:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A07213253F for ; Thu, 3 Aug 2017 09:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1372; q=dns/txt; s=iport; t=1501776318; x=1502985918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=arkXSQODQy000oPu8wACt//dBBlXxsrZa5k3UH7fHFY=; b=gswRATwVNRJ2msfxrvUcKZ24J6bJXYZSSCpxG9b0s8mjFMgMNY5ZNlvd 7ioYldiXQHTDcSh4QAS3INkXkMqiKUJaBk9yBpgGXE/NoACeqCK0LdHH/ tgA4j6R6u+FD6fhbK5qrcEgGyaR+nyQ6Xw/BdMJ+nA1GmQAL5L39sh9rd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACfSINZ/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgiQB4FulhUOggQuhRkChD4/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAzo/DAQCAQgOAwQBAQEeCQcyFAkIAgQOBQiKJxCvW4tNAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWDKIIChlaBPIMEARIBCYYKBZ99AodRjFGSUZYAAR84fwt?= =?us-ascii?q?3FYdjdgEBhyKBI4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208";a="60292804" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 16:05:17 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v73G5Hot019475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 16:05:17 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 11:05:16 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 11:05:16 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson CC: Ted Lemon , IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IICAAFqpAIAAAQOA//+sw4AADOU/AAAJ8iNA Date: Thu, 3 Aug 2017 16:05:16 +0000 Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:05:20 -0000 Yeah, that seems rather odd as to why the "new" DHCP server didn't respond = to the Rebind requests with something - likely it should have reported NoBi= nding or a Reply with 0 lifetimes and perhaps a new delegated prefix. It is possible (see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-0= 9#section-18.2.12) that the server chose to drop the Rebind as that is an o= ption. However, it does have consequences as you can see so is generally no= t the best choice. You might contact the server vendor to see about this? - Bernie -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Thursday, August 03, 2017 11:45 AM To: Bernie Volz (volz) Cc: Ted Lemon ; IPv6 Operations Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: > > Is why there was nothing received to the Rebind requests (these would=20 > have been multicast)? This should have gone to all servers and hence=20 > triggered a response from the DHCP server. The rebind requests were sent to MAC 33:33:00:01:00:02 with IPv6 dst addres= s ff02::1:2 So yes, looks like multicast to me. The rebind and solicits look identical = from a src/dst/mac point of view. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 09:07:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806F313242D for ; Thu, 3 Aug 2017 09:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx5FGzMSZXBf for ; Thu, 3 Aug 2017 09:07:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DEA13210F for ; Thu, 3 Aug 2017 09:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8804; q=dns/txt; s=iport; t=1501776431; x=1502986031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5IAYYNFA8OLrzDKdUNILSUNsA4HijSbao8LZlm9T5EM=; b=ZT8Fxyyx1kYe1RMKaQQkqVrDepvruPcuFfMs7Wby5h2P+qV0WNS+ls7V NdPrh8yW/BMhLmWDwUc7Puk9Efz/3CwKUhyS8HlcAUIdgEGuUZIm3yAyv Nyf83uyl2ResahvU81jFdOgB5KyeGJLNwBtVT+FfANXBSfJE+sOSXWGV+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAAChSYNZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG0nB44IkAeBbpBihTOCEoVHAoQ+PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBLUwFCwIBCA4DBAEBKAcyFAkIAgQBDQUIiUNcCK9li00BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgyiCAoMugyiBPIMhPBCFPgWffQKUIpJRlgABHziBCnc?= =?us-ascii?q?Vh2N2iEeBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208,217";a="465464345" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 16:07:10 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v73G7AU9013583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 16:07:10 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 11:07:09 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 11:07:09 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Mikael Abrahamsson CC: IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IICAAFqpAIAAAQOA//+sw4AADOU/AAAAKgUAAABdb4AACkqRAA== Date: Thu, 3 Aug 2017 16:07:09 +0000 Message-ID: <5794a3faa9ed42ab874dd91b89cb3751@XCH-ALN-003.cisco.com> References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: multipart/alternative; boundary="_000_5794a3faa9ed42ab874dd91b89cb3751XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:07:15 -0000 --_000_5794a3faa9ed42ab874dd91b89cb3751XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Also, now that I think about it, aren't Renews multicast as well? Yes, they are. But include a server-id option and so if the DHCPv6 server a= t the other end has also changed, this would not match and thus drops the p= acket. I have assumed that is the case here. - Bernie From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, August 03, 2017 12:01 PM To: Mikael Abrahamsson Cc: Bernie Volz (volz) ; IPv6 Operations Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson > wrote: Just to clarify. The signup portal has completely different prefixes in its= PD pool compared to the active port DHCPv6 PD pool. So after reprovisionin= g of the port the RG is doing rebind for IA_PD prefix that no DHCPv6 server= /relay on the link is configured to serve. If your DHCP server were configured correctly, it would respond to the Rebi= nd indicating that the lifetime of the sign-on mode prefix is zero. Also,= now that I think about it, aren't Renews multicast as well? --_000_5794a3faa9ed42ab874dd91b89cb3751XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Also, now that I think ab= out it, aren't Renews multicast as well?

 

Yes, they are. But include a server-i= d option and so if the DHCPv6 server at the other end has also changed, thi= s would not match and thus drops the packet. I have assumed that is the case here.

 

-   =        Bernie

 

From: Ted Lemon [mailto:mellon@fugue= .com]
Sent: Thursday, August 03, 2017 12:01 PM
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Bernie Volz (volz) <volz@cisco.com>; IPv6 Operations <v= 6ops@ietf.org>
Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement=

 

On Aug 3, 2017, at 11:50 AM, Mikael Abrahamsson <= swmike@swm.pp.se> wrote:

Just to clarify. The signup portal has completely = different prefixes in its PD pool compared to the active port DHCPv6 PD poo= l. So after reprovisioning of the port the RG is doing rebind for IA_PD prefix that no DHCPv6 server/relay on the link i= s configured to serve.

 

If your DHCP server were configured correctly, it wo= uld respond to the Rebind indicating that the lifetime of the sign-on mode = prefix is zero.   Also, now that I think about it, aren't Renews multi= cast as well?

--_000_5794a3faa9ed42ab874dd91b89cb3751XCHALN003ciscocom_-- From nobody Thu Aug 3 09:16:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9FE1325CE for ; Thu, 3 Aug 2017 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbuURM9_Mlbr for ; Thu, 3 Aug 2017 09:16:42 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DFE1325D1 for ; Thu, 3 Aug 2017 09:16:42 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 226E6A7; Thu, 3 Aug 2017 18:16:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501777000; bh=ucB8FvLHgyN/jcGpPydaZqGAMTSi1oeE1L9tNcNbNM4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GD93/CxEv7mi07VsX/o3qYV1t0n6H710RC7oZpl6/TcFFUiHfi/0A3IKW1PeEzw/5 q5djXotd7f+Gm6wDsHGtro2RkOlmmTBpfnJLDXJGTishbcLqJ5hSUx4qnnHVEHfUnf WzRCA9cY2mUUb+UmDqQzcj0OhHjQAlY9HtQp93Bs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2054DA6; Thu, 3 Aug 2017 18:16:40 +0200 (CEST) Date: Thu, 3 Aug 2017 18:16:40 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: Ted Lemon , IPv6 Operations In-Reply-To: <5794a3faa9ed42ab874dd91b89cb3751@XCH-ALN-003.cisco.com> Message-ID: References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> <5794a3faa9ed42ab874dd91b89cb3751@XCH-ALN-003.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:16:43 -0000 On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: >> Also, now that I think about it, aren't Renews multicast as well? > > Yes, they are. But include a server-id option and so if the DHCPv6 > server at the other end has also changed, this would not match and thus > drops the packet. I have assumed that is the case here. I do not see any server-id option in the DHCPv6 part of the rebind. The renew XID is different from the rebind XID. The renew has a server-id, the rebind does not. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 09:47:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5E132093 for ; Thu, 3 Aug 2017 09:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-TquZZHSKCR for ; Thu, 3 Aug 2017 09:47:57 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1630D1320D0 for ; Thu, 3 Aug 2017 09:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1046; q=dns/txt; s=iport; t=1501778877; x=1502988477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jmy4WuD8xcWQZy3RWP/71l9pd/RAUQo+Qw7kZU9STkQ=; b=DfmxGASOsFZGl276ncPEzo6I0sX6VrCpwuxvh8gpi1IE6mqOF9zNsBKz 5iFX2UQ1Yaelazff001Ukw1MxFkQ0VXKwJEEAnTBePqtiApBK0u3gbmb9 RVmsnJt01JxIlpB4Jox3XFWevFoRRcit1ZkWkYZ7LalslB8hUOtwthgBQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQBxU4NZ/4sNJK1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBUScHjgiQB4FulhUOggSFRwKEPj8YAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CATo/DAQCAQgOAwQBAR8JBzIUCQgCBA4FCIofCK9fi0wBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyiCAoZWgTyDBAESAQmGCgWffQKUIpJRlgABHzh/C3cVhWAcgWd?= =?us-ascii?q?2hxWBI4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,317,1498521600"; d="scan'208";a="463996012" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Aug 2017 16:47:38 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v73GlcVQ022020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 16:47:38 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 11:47:38 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 11:47:38 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson CC: Ted Lemon , IPv6 Operations Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyymcAgAALpwCAAAb0gIAAAbuAgAAJWoD//75agIAAT1gA//+1IICAAFqpAIAAAQOA//+sw4AADOU/AAAAKgUAAABdb4AACkqRAP//sikAgABLaUA= Date: Thu, 3 Aug 2017 16:47:38 +0000 Message-ID: <903060c87ef7438a88eecb95d36e55b9@XCH-ALN-003.cisco.com> References: <61BA6CDC-7B36-45D8-820A-4CAE747DC246@cisco.com> <67ca98866bf347af9e7dbcebc34363b4@XCH-ALN-003.cisco.com> <5662B9F9-D027-497D-B1A4-4E7639EA0B12@fugue.com> <0bbb770f87534cac9d1b021f78c4d1f1@XCH-ALN-003.cisco.com> <5794a3faa9ed42ab874dd91b89cb3751@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:47:58 -0000 >I do not see any server-id option in the DHCPv6 part of the rebind. Renew would have server-id; Rebind would NOT have server-id. Sorry if that = wasn't clear. - Bernie -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Thursday, August 03, 2017 12:17 PM To: Bernie Volz (volz) Cc: Ted Lemon ; IPv6 Operations Subject: RE: [v6ops] clarification regarding RFC7084 G-5 requirement On Thu, 3 Aug 2017, Bernie Volz (volz) wrote: >> Also, now that I think about it, aren't Renews multicast as well? > > Yes, they are. But include a server-id option and so if the DHCPv6=20 > server at the other end has also changed, this would not match and=20 > thus drops the packet. I have assumed that is the case here. I do not see any server-id option in the DHCPv6 part of the rebind. The renew XID is different from the rebind XID. The renew has a server-id, = the rebind does not. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 11:46:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B29120721 for ; Thu, 3 Aug 2017 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEPM4d7DP-bg for ; Thu, 3 Aug 2017 11:46:36 -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 D57A81200F3 for ; Thu, 3 Aug 2017 11:46:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 8C8FF1BC37 for ; Thu, 3 Aug 2017 18:46:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Thu, 3 Aug 2017 19:46:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62B73844-D9BC-451F-A2FD-27C754A77B05@thehobsons.co.uk> References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 18:46:38 -0000 "Ackermann, Michael" wrote: > Just a quick 2 cents from the Enterprise perspective.=20 >=20 > Unfortunately (IMHO), most Enterprises expressly and purposely turn = IPv6 off in routers. As mentioned, the business case(s) are still = not obvious and it is thus seen only as excessive traffic and potential = problems. =46rom my perspective in a small It services business, that's the case. = WHile many, probably all, client sites will be running IPv6 at a LL = level - I don't think that any of them realise it's there, and all of = them would probably turn the feature off if a router defaulted to = providing IPv6 connectivity on the grounds of "too complicated". I'll add that IME very few small business networks have things like = properly setup DNS, so it's really really common to have to access = things by IP address. > Please don't shoot the messenger. =20 I'm not, I think I'm stood there alongside you as a wider target.= From nobody Thu Aug 3 13:23:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632E0131BBF; Thu, 3 Aug 2017 13:23: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 ZVYzjSTo49aP; Thu, 3 Aug 2017 13:23:25 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8153B1317C1; Thu, 3 Aug 2017 13:23:25 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id y129so10383811pgy.4; Thu, 03 Aug 2017 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qod4kIY0Y+Ys43MyLsz64IubOf6m5jZLHcWdAo8mYSQ=; b=I/SQE/5K7ef1Zqr89K8+FpMRqFGp5I5Qx8RHA7JDi3s6ANso+C1vtx7OXFp6QCAWVs kjplIGQMEHYNQWtlOdHmRBs0P2t6chj4Grxk9he/Vb6eqNdNE8JCmVQ6iXMC2OuuWh5q Eh4y7YjPArm6XXBOHeYGFTIfJaWUmg6gaJr9c7qiWlcpieJbx41mwZ6PeE06/W49ibNw SBFUmM2qC3jJXGhwfSuw/2rnMEnx2CYoBKqAIHpsFU0aalNMm7hQiwHNzxgt4JiXwFss Q7WPmmCmg58LUlcGy54gm0m4IIoF3aTQ0/ShEb55b40e1bFanTHn0AtPFpeh8QX6qdt2 fxDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qod4kIY0Y+Ys43MyLsz64IubOf6m5jZLHcWdAo8mYSQ=; b=YUexYp9xekecYouqYbcKwQshPDlW14ZxlqjMbldsjMLFygMjskeUIgun42AHzX/a8z MhuOyX/rvUw7L1fdW2Kowi+0WYb29ZvtjiLARC6gXKTn/rw+7hPfb0RDfxequt2VPC1j 7neqmkmBCg6fFz+RJr6fzkVRFnFB4OuNu5rnSPctFbd3B+1upu2biUtq1dzaSnECDS2a j1pw1LbwzH0Uu71X/qlhcHji3VLVbBCYo8M0/LpCrlTHbBbJI5CumiScTFuKIoiSCm2g +VBGV6+eaRwvHCR7+x2KelG8hJec7xpTr8WFxthr+mNZ3W34Wv/KCisXjBuWQOjCAR5Q 4e/A== X-Gm-Message-State: AIVw113GJyxWQbzCxGr/0E+22AX2LV1kypPvuLZbgdHjn3GslOWjSRVs 6/Lo4QCCF5RIGpxv X-Received: by 10.84.233.195 with SMTP id m3mr50037pln.292.1501791804807; Thu, 03 Aug 2017 13:23:24 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z189sm56208003pgb.12.2017.08.03.13.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 13:23:24 -0700 (PDT) To: Mark Smith , Gert Doering Cc: v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <652bfd39-82f5-8737-9feb-dd79a55f37c1@gmail.com> Date: Fri, 4 Aug 2017 08:23:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 20:23:28 -0000 On 03/08/2017 20:02, Mark Smith wrote: > On 3 August 2017 at 17:30, Gert Doering wrote: >> Hi, >> >> On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: >>>> It is perfectly possible to run IPv6 routing without RA (even if you >>>> don't normally want to do that). Check your nearest Juniper router >>>> if you doubt this is possible. >>> >>> Where does the default router address come from, then? >> >> On the router? "OSPF, BGP, ..." >> >> On the host? "static route pointing to fe80::1%eth0" (which is the VRRP >> address of your upstream router pair) >> > > I suppose there should also be a knob to turn neighbor resolution off > too, so that people can exclusively use statically configured ND cache > entries in routers. Once you say "static" and "configured" you're outside the scope of default behaviour and automatic configuration. If that's in scope for the draft, fine, but it needs to be described much more explicitly than a throw-away line like "SLAAC MUST be able to be disabled by operators who prefer to use some other mechanism..." which is what I was commenting on. Remember that the section of the draft including that text is titled "Supporting Zero Touch Provisioning for Connected Devices". And (for example) VRRP isn't mentioned anywhere in the draft. (https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs in case anybody has lost track.) Brian From nobody Thu Aug 3 13:50:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A98131CED for ; Thu, 3 Aug 2017 13:50: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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXw4s6JQLJGz for ; Thu, 3 Aug 2017 13:50:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35550131CA2 for ; Thu, 3 Aug 2017 13:50:51 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3C83042A36 for ; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1F3B342A31; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1B63B6E62E; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) Date: Thu, 3 Aug 2017 22:50:50 +0200 From: Gert Doering To: Mark Smith Cc: Gert Doering , Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Message-ID: <20170803205049.GD45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> <20170803081157.GP45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K+aa9f6bMAfttVCD" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Turning on IPv6 Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 20:50:54 -0000 --K+aa9f6bMAfttVCD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 03, 2017 at 07:32:07PM +1000, Mark Smith wrote: > >> > On the host? "static route pointing to fe80::1%eth0" (which is the= VRRP > >> > address of your upstream router pair) [..] > > Seriously: RAs for default router announcement work nicely for certain > > use cases, and are just not good enough for others, like "fast and > > well-defined failover among multiple default gateways". >=20 > That's what VRRP, HSRP or GLBP are for. VRRP supporting IPv6 was > specified in 2010 in RFC5798, and a search shows that Cisco have > supported IPv6 in HSRP and GLBP since 2011. >=20 > RAs plus NUD is going to be a poor mans or better than nothing VRRP. > There was no such equivalent functionality in base IPv4. The out of > the box IPv6 functionality is not better than VRRP/HSPR/GLBP, however > it is better than IPv4's. Which is exactly what I've been saying as a possible reason why people are running without default-route-from-RA. =20 So it seems I am misunderstanding your point. [..] > > But do not let me stop you from ridiculing other people's use cases >=20 > I usually understand the use cases, however I don't understand why the > methods used in IPv6 must be the IPv4 methods, even though IPv6 > methods exist and are deployed and are working for many people. We do use the IPv6 method: HSRP with an IPv6 LLA (because that *is* "the IPv6 method", as on all but one platform Cisco's HSRP for IPv6 does not permit configuring a GUA as HSRP address, which would be "the IPv4 way"). We've done RA based failover, and it was far too slow and far too=20 non-deterministic ("honour router priorities? why?") to be satisfying. [..] > > is part of what has made IPv6 such a tremendous success, so by all mean= s, > > give us more of it. >=20 > The best way to prove the IPv6 methods don't work is to deploy the > IPv6 methods as they stand. If they fail, document the environment > they failed in and how. Come back with that evidence, which may > provide a solid reason to change how IPv6 works in that specific > regard. While I agree with you, this is just so slightly straying off the original question I've replied to... And yes, I've tried most of "the IPv6 ways" to get things done, and my dislike is growing. Like, how comes there is no remote ARP attack on=20 anything, but multiple router platforms are vulnerable to remote ND attacks... (not speaking of neighbor cache exhaustion, but of the incoming queue saturation by bogus packets coming from anywhere bug). Using ICMP with (among others) GUAs for IPv6 ND was a tremendously bad idea. First you open an attack surface for off-link attacks, and then you hope that implementations would be able to do hopcount=3D255 filtering= =20 early enough that you do not drown out legitimate packets in a rate- limited queue later on... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --K+aa9f6bMAfttVCD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmDjKcACgkQ31bAZeTO f8Vy6Q//S/JifdSnY7Xhj+tUhAhS8FVzdrAbh7QAVAiHJeuwsXSn3w2JYmcx0QSW h1OPKIzebTSLskA1yfP8POz5G19Yebdkj91i89wDpKKy5Q8AWsYlbhxsUGMfhusf T5KQcneIunNFTYHy1ZH9sxJMcuZfeKeLV3x7FS312ZvsWAVzKSbXObwrebXra7vN mGSgT+FbJIm+nMwdb+30AQ1a1NfBZh7WTT1sU4U4qW1J+fl1CdoypOsYZwU3kzOR 6q4Dulfmc06W2qFbWY9/D6icexd3bDPgKYHnh7zPlZJJJMQR8WFK4kzErvshqFcb Py9pRPJk7IRuy3t731/vEmGXBd43auxGaMEkgzMcoe6DC7QtJZxu79Er8ILkkUKp SgtA7DqqH8E3KuCrtlEDL+nHulIdjpdclI2569minPpNmN8P+8hm96tPJNCjA3BF s231wjHdT/bfNmH6xfpW46vUwA2OMvdE2+OY7rB/JAEURJMtKedGrL8QOQufDyEA MLWrT2/oqruQ68VBGUCMSnhb0PzQjRhH1LLmRIMPg9na9yTgM2lFr8E36L9ooNgB de1wVQcp1aUHY4r1zPH9ukI0SETbUGXkHVu1QM3hqJJD4Nf4wpF89nnsOErS/TIN Ogy4zmk1pUWUnZLcm4yt4cHU6YDF+Kt8TZGKhPnmff5m3a7NBEs= =+eg7 -----END PGP SIGNATURE----- --K+aa9f6bMAfttVCD-- From nobody Thu Aug 3 15:02:42 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F286D131C32; Thu, 3 Aug 2017 15:02:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: v6ops@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150179774694.7100.15043779550485158536@ietfa.amsl.com> Date: Thu, 03 Aug 2017 15:02:26 -0700 Archived-At: Subject: [v6ops] Genart telechat review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 22:02:27 -0000 Reviewer: Joel Halpern Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 Reviewer: Joel Halpern Review Date: 2017-08-03 IETF LC End Date: 2017-06-06 IESG Telechat date: 2017-08-17 Summary: This document is ready for publication as a Best Common practice RFC< although there are some issues to be considered. Major issues: N/A Minor issues: The issue of status for the document (BCP vs Informational) is for the IESG to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chosen throughout the document makes it appear that the underlying decision about such a deployment is also a recommended practice. Nits/editorial comments: N/A From nobody Thu Aug 3 16:07:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7102B131C3B for ; Thu, 3 Aug 2017 16:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSLjOZKaHsit for ; Thu, 3 Aug 2017 16:07:49 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AAA129B5B for ; Thu, 3 Aug 2017 16:07:49 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id g71so324772ioe.5 for ; Thu, 03 Aug 2017 16:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KHNpRLHbWXhbh6+7iTaZmc8cj5qNNE03pE0R69M/Nlo=; b=brL0me3Gp1k8eY59tu33l15XO3eClUcPmhmxAP3F2Ic6ifj9i4prQMW9ZjRC6GmCwV MRuiryWpK4x/83xVXFW217giNe7vJ+hcgblVH6eeuHPvY5NWqtUQNqAeCtGBHnvtgAgm x+coBrmE/6CepexcnEzwjbR53b4Bq6h7/aaCjOyqwI1jtiTq95iI9rE+I8clhxUwVrDd ESJ5wi+miObgZcnn4Lld7xOEN1G6vWb5YuyvOPtiQc3OYzJ5VOzmDNANMDP602Q0bjOC ev+q6ag845P8MnmaLCzPV2Ch2P8LThJOkjURML20I+Li+M7zIqWzvp3Y+qXn/e1O1IVn HJfA== 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=KHNpRLHbWXhbh6+7iTaZmc8cj5qNNE03pE0R69M/Nlo=; b=G4B7Yrg1ZF4MXzGDoDGNMEmgcI7YLx01W5d/wvQl1K2EHm78nUdCuBzOMQkVOGC6s7 +7aBxf54uk0gnOzdK/HDEI689Htu29Dlw0N/1Sh6TUKi9NTDvA8FJTDmiflaDVTzgONt kZwloL0TM+lJ/pL/BJ/KiayWpDC4QQLArsm61viYc/+otQGuoAZf9h5G/E8hfG447061 C/PoixFuI1M03SCbhARLvWNOF1QkCL+C95AgT4CwJmHo5S5/zPiLStjxHYWa0Ii7wamT IySmhA6r0uKtbyP3C4lGfB+nYnbdeUnYkXGDrh/rgYpnglnCwU7Ht3P7+8/jrDA/XpcO 4gUw== X-Gm-Message-State: AHYfb5huO1IcHQub3x2yQ8o7gRa+Y7gBtGPw1CfdCrsjBwLjhR7YrFVY IJOUnMRlaIQoaL6FM8lQmz8VNKFj5hbF X-Received: by 10.107.9.195 with SMTP id 64mr567799ioj.72.1501801667877; Thu, 03 Aug 2017 16:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 3 Aug 2017 16:07:39 -0700 (PDT) Received: by 10.107.27.203 with HTTP; Thu, 3 Aug 2017 16:07:39 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 4 Aug 2017 01:07:39 +0200 Message-ID: To: Mikael Abrahamsson Cc: Timothy Winters , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113eb696f076f40555e172bf" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 23:07:51 -0000 --001a113eb696f076f40555e172bf Content-Type: text/plain; charset="UTF-8" On 3 Aug 2017 15:56, "Mikael Abrahamsson" wrote: Does the DHCPv6 Server > know to set the old Prefix to zero in this use case? If not, that won't > help since it will still need to time-out. > No, the old DHCPv6-PD server is now gone, not available anymore, will never answer you again. The link now has a brand new DHCPv6-PD server you can ask for completely different prefixes, which it will happily give you. This sort of thing is precisely why DHCPv6 is not a good protocol to configure dynamic networks such as home networks. In DHCPv6, it's very hard to change anything dynamically because it's driven by client requests. Mechanisms to tell clients to ask again exist (e.g., RECONFIGURE), but clients apparently mostly don't support them. Additionally, one of the advantages of DHCPv6 over other forms of configuration is the ability to do centralised management - but that advantage is hard or impossible to achieve when things change, because the DHCPv6 server would need to listen to all relevant configuration or topology changes that could affect client addresses in order to properly update clients. For example, imagine a network using multiprocessor multi-prefix multihoming such as a homenet or a network using the SADR multihoming drafts bring worked on in the routing and v6ops working groups. In such networks, when an upstream goes down the network needs to deprecate all the IP addresses in a certain prefix. Having the DHCPv6 server keep track of all link changes and issue RECONFIGUREs doesn't scale, and it's not even possible at all if the DHCPv6 server is partitioned from the clients. Finally, I'm not even sure if RECONFIGURE works at all if the original server is gone/crashed. DHCP works well in IPv4 because we rarely change things - you're always 192.168.0.113/20, and your default gateway is always 192.168.15.254. When anything changes, the network handles it using NAT or VRRP. That model can't provide end-to-end connectivity in a network that changes. Perhaps we need a draft to explain this? It's fine to use DHCPv6 to configure things that never change, such as static DNS addresses that are anycasted and never renumbered. But it might not be obvious to administrators that if your network changes *and* you need end-to-end connectivity, DHCPv6 doesn't handle that well -or at all. --001a113eb696f076f40555e172bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 3 Aug 2017 15:56, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
Does th= e DHCPv6 Server
know to set the old Prefix to zero in this use case?=C2=A0 =C2=A0If not, th= at won't
help since it will still need to time-out.

No, the old DHCPv6-PD server is now gone, not available anymore, will never= answer you again. The link now has a brand new DHCPv6-PD server you can as= k for completely different prefixes, which it will happily give you.

This sort o= f thing is precisely why DHCPv6 is not a good protocol to configure dynamic= networks such as home networks.

In DHCPv6, it's very hard to change anything dynamically beca= use it's driven by client requests. Mechanisms to tell clients to ask a= gain exist (e.g., RECONFIGURE), but clients apparently mostly don't sup= port them.=C2=A0

Additio= nally, one of the advantages of DHCPv6 over other forms of configuration is= the ability to do centralised management - but that advantage is hard or i= mpossible to achieve when things change, because the DHCPv6 server would ne= ed to listen to all relevant configuration or topology changes that could a= ffect client addresses in order to properly update clients. For example, im= agine a network using multiprocessor multi-prefix multihoming such as a hom= enet or a network using the SADR multihoming drafts bring worked on in the = routing and v6ops working groups. In such networks, when an upstream goes d= own the network needs to deprecate all the IP addresses in a certain prefix= . Having the DHCPv6 server keep track of all link changes and issue RECONFI= GUREs doesn't scale, and it's not even possible at all if the DHCPv= 6 server is partitioned from the clients.

=
Finally, I'm not even sure if RECONFIGURE works at al= l if the original server is gone/crashed.

=
DHCP works well in IPv4 because we rarely change things = =C2=A0- you're always 192.168.0.113= /20, and your default gateway is always 192.168.15.254. When anything c= hanges, the network handles it using NAT or VRRP. That model can't prov= ide end-to-end connectivity in a network that changes.

Perhaps we need a draft to explain this? It&= #39;s fine to use DHCPv6 to configure things that never change, such as sta= tic DNS addresses that are anycasted and never renumbered. But it might not= be obvious to administrators that if your network changes *and* you need e= nd-to-end connectivity, DHCPv6 doesn't handle that well -or at all.
--001a113eb696f076f40555e172bf-- From nobody Thu Aug 3 17:04:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6760E131FD0 for ; Thu, 3 Aug 2017 17:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc0C5Mjj339I for ; Thu, 3 Aug 2017 17:04:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66546131FEE for ; Thu, 3 Aug 2017 17:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8018; q=dns/txt; s=iport; t=1501805088; x=1503014688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=75xx9Fhp/uZKg1Pcuc+9HUc85ewiFV8KOhFjpY7QKSQ=; b=EoR61xatYI3ZeIXHmACKtDsr0kv6V3XxD4ct5V0byyDzCuywf933VilM icgeoaaWcIqnpvYxgaQP/BL++nWKK6Q6zTY6kQN4JqJR85lkDXRoxyniD ikd3iLbQnZkMbjw8niF/pNIuNYWuWV05S4CcxyMWPOo92XDncHcZnEcx/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWBABfuYNZ/5ldJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbSeOD5AJgUyDCI18hTOBMwNcIQEKhRsChD8/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkCAQMBAUoiCxACAQgTLAclAgsUEQIEDgWJS18FEKxJgySED4cyAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYMoggKDLysLgnGBPIMhg1mCMQWffQKHUYNMiQ6CD5A?= =?us-ascii?q?5iV6CdxCJGwEPEDhMPncVSRIBhH8RgXd2AYksAQEB?= X-IronPort-AV: E=Sophos;i="5.41,318,1498521600"; d="scan'208,217";a="461319874" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 00:04:47 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7404lsK030354 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 00:04:47 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 3 Aug 2017 19:04:46 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 3 Aug 2017 19:04:46 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti CC: Mikael Abrahamsson , "v6ops@ietf.org WG" Thread-Topic: [v6ops] clarification regarding RFC7084 G-5 requirement Thread-Index: AQHTDC5ENU7Gcge71keU4F/6qEr3wKJyl3BOgAD+n4D//7wlWQ== Date: Fri, 4 Aug 2017 00:04:46 +0000 Message-ID: <8276B3B2-EABB-4212-B327-8A076AC61EC1@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8276B3B2EABB4212B3278A076AC61EC1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 00:04:50 -0000 --_000_8276B3B2EABB4212B3278A076AC61EC1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, we know your position. In this case it looks like it is more likely an implementation issue/decisi= on on the (new) server not to respond as it should. And, we are trying to make sure the updated standard encourages using appro= priate input and actions when changes are noticed. - Bernie (from iPad) On Aug 3, 2017, at 7:08 PM, Lorenzo Colitti > wrote: On 3 Aug 2017 15:56, "Mikael Abrahamsson" > wrote: Does the DHCPv6 Server know to set the old Prefix to zero in this use case? If not, that won't help since it will still need to time-out. No, the old DHCPv6-PD server is now gone, not available anymore, will never= answer you again. The link now has a brand new DHCPv6-PD server you can as= k for completely different prefixes, which it will happily give you. This sort of thing is precisely why DHCPv6 is not a good protocol to config= ure dynamic networks such as home networks. In DHCPv6, it's very hard to change anything dynamically because it's drive= n by client requests. Mechanisms to tell clients to ask again exist (e.g., = RECONFIGURE), but clients apparently mostly don't support them. Additionally, one of the advantages of DHCPv6 over other forms of configura= tion is the ability to do centralised management - but that advantage is ha= rd or impossible to achieve when things change, because the DHCPv6 server w= ould need to listen to all relevant configuration or topology changes that = could affect client addresses in order to properly update clients. For exam= ple, imagine a network using multiprocessor multi-prefix multihoming such a= s a homenet or a network using the SADR multihoming drafts bring worked on = in the routing and v6ops working groups. In such networks, when an upstream= goes down the network needs to deprecate all the IP addresses in a certain= prefix. Having the DHCPv6 server keep track of all link changes and issue = RECONFIGUREs doesn't scale, and it's not even possible at all if the DHCPv6= server is partitioned from the clients. Finally, I'm not even sure if RECONFIGURE works at all if the original serv= er is gone/crashed. DHCP works well in IPv4 because we rarely change things - you're always 19= 2.168.0.113/20, and your default gateway is always= 192.168.15.254. When anything changes, the network handles it using NAT or= VRRP. That model can't provide end-to-end connectivity in a network that c= hanges. Perhaps we need a draft to explain this? It's fine to use DHCPv6 to configu= re things that never change, such as static DNS addresses that are anycaste= d and never renumbered. But it might not be obvious to administrators that = if your network changes *and* you need end-to-end connectivity, DHCPv6 does= n't handle that well -or at all. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8276B3B2EABB4212B3278A076AC61EC1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lorenzo, we know your position.

In this case it looks like it is more likely= an implementation issue/decision on the (new) server not to respond as it = should.

And, we are trying to make sure the updated = standard encourages using appropriate input and actions when changes are no= ticed.

- Bernie (from iPad)

On Aug 3, 2017, at 7:08 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On 3 Aug 2017 15:56, "Mikael Abrahamsson&qu= ot; <swmike@swm.pp.se> wrote:
Does the DHCPv6 Server
know to set the old Prefix to zero in this use case?   If not, th= at won't
help since it will still need to time-out.

No, the old DHCPv6-PD server is now gone, not available anymore, will never= answer you again. The link now has a brand new DHCPv6-PD server you can as= k for completely different prefixes, which it will happily give you.

This sort of thing is precisely why DHCPv6 is not a good = protocol to configure dynamic networks such as home networks.

In DHCPv6, it's very hard to change anything dynamically = because it's driven by client requests. Mechanisms to tell clients to ask a= gain exist (e.g., RECONFIGURE), but clients apparently mostly don't support= them. 

Additionally, one of the advantages of DHCPv6 over other = forms of configuration is the ability to do centralised management - but th= at advantage is hard or impossible to achieve when things change, because t= he DHCPv6 server would need to listen to all relevant configuration or topology changes that could affect client= addresses in order to properly update clients. For example, imagine a netw= ork using multiprocessor multi-prefix multihoming such as a homenet or a ne= twork using the SADR multihoming drafts bring worked on in the routing and v6ops working groups. In such ne= tworks, when an upstream goes down the network needs to deprecate all the I= P addresses in a certain prefix. Having the DHCPv6 server keep track of all= link changes and issue RECONFIGUREs doesn't scale, and it's not even possible at all if the DHCPv6 server is p= artitioned from the clients.

Finally, I'm not even sure if RECONFIGURE works at all if= the original server is gone/crashed.

DHCP works well in IPv4 because we rarely change things &= nbsp;- you're always 192.168.0.113/20, and your default = gateway is always 192.168.15.254. When anything changes, the network handle= s it using NAT or VRRP. That model can't provide end-to-end connectivity in= a network that changes.

Perhaps we need a draft to explain this? It's fine to use= DHCPv6 to configure things that never change, such as static DNS addresses= that are anycasted and never renumbered. But it might not be obvious to ad= ministrators that if your network changes *and* you need end-to-end connectivity, DHCPv6 doesn't handle that= well -or at all.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_8276B3B2EABB4212B3278A076AC61EC1ciscocom_-- From nobody Thu Aug 3 18:06:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596F313201F for ; Thu, 3 Aug 2017 18:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuWcSJYPSYKF for ; Thu, 3 Aug 2017 18:06:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7250C12778D for ; Thu, 3 Aug 2017 18:06:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 030BDA6; Fri, 4 Aug 2017 03:06:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501808797; bh=wPUgIoxwHYNwsb4mmwsKfnAzArxhOQa7KOJFvqzNxRA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LFd3wEGZ932qKoMM9V9ASju2/RogoxUO7zlMQq822exZs/CitUDeAVtz/2CQWK2Si moN1DV7WmIBpYMsJhhpdxVvOYPRt3VjarAWBH5GPtMPl0wk2RgFsb2mGe9soVlYd6h RYC/iQJ4rsLJcffrWCFB8inqv10x+ZX1OX3HHrwE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DE0FBA3; Fri, 4 Aug 2017 03:06:36 +0200 (CEST) Date: Fri, 4 Aug 2017 03:06:36 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" cc: "v6ops@ietf.org WG" In-Reply-To: <8276B3B2-EABB-4212-B327-8A076AC61EC1@cisco.com> Message-ID: References: , <8276B3B2-EABB-4212-B327-8A076AC61EC1@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 01:06:41 -0000 On Fri, 4 Aug 2017, Bernie Volz (volz) wrote: > In this case it looks like it is more likely an implementation > issue/decision on the (new) server not to respond as it should. If we could send zero-lifetime RA before reconfiguring, the RA controlled part of this could be up and running again in a few seconds. Even if DHCPv6 worked perfectly according to standards, it would as far as I understand not be up and running again in under a minute (instead of the two minutes I'm currently seeing). We are investigating why the rebind isn't answered, so we can cut a minute of the time here. But I have no way to signal to the DHCPv6-PD client in the RG that it should drop all resources NOW and go back into solicit. Some people think this is a feature, because it means you can't "DoS" an entire LAN segment with a single packet. There are always pro:s and con:s. So I'm in agreement with Lorenzo here. DHCP is not well suited for fast-flux environments because it's driven by device polling and there is no push. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 18:25:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA413203B for ; Thu, 3 Aug 2017 18:25:13 -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 GzHx-Nf2fNsy for ; Thu, 3 Aug 2017 18:25:12 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A72132035 for ; Thu, 3 Aug 2017 18:25:12 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id d67so1652234pfc.0 for ; Thu, 03 Aug 2017 18:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/idXt17bI7lErX24d5AipZcbPFd6d7XUf2z9DM/CE5U=; b=CS4VuxH4WID7HVtFqv0qeac9WSmKy9Ubd6q6MCZf/ujXBHdLny0+BZK6A7Tu8CHzTA uErkzDe8USmTMBE3df1LobnBp+qHAJK8RAzOgg7Fxs0mf3XAXtwmyEOkl3/xAXG8oeqU QBpGQhDD/nE/n3wSG+2nk7xHhyL5Qt8gqY24OoUJhhpjaLYbfR7buamjkFCQMa+xGic6 LxWUoY0bR45XxlqCty6ChNXkWn5VTP3oxbiUmiq5KlQURYWgcnsYfMCVZYh/JgZ6Gdgy KgOXZnRfitiPao34LdNQcsTIZ6kKdFkISpcjekIjkYbYMUn65TKl0xK+SVRg4eyRB1m7 0hoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/idXt17bI7lErX24d5AipZcbPFd6d7XUf2z9DM/CE5U=; b=WFfgF8BjAiapbQwZUmU45lMGC/bhHz8jwLanWOcy8KU+W23D8U7XRIO2yduPpqB2mp 9IgsMSqtDL+GQz4FlRxsE5uX2sP1McbZ8pkWzaPAlek8YdPoiuNI8FviSGjKM3qe3vIR LtiYz/YoOroTNRcGoC6Q8gSL4GMRAjZ2HYmoo7bPuZzqjXt7xhQYC9NTVI6Wwu/qYVSL p1uuSQ/JCYtuVxm8AzN+A80sb7uq9hybDnelUUkHx03vJ1zZzKVD0/6TqprpwImpvnXz f5vItSSfMyvW9zdtDRcfWLqebUplyqYUkLAkB4lH/9NkIETLjf/d0ikEhmhdaHahMtNv jWjQ== X-Gm-Message-State: AIVw1123DggNBFd+XfaXrAjB6PGmllDAjzl41pHKtHOCEhg8vDcHRZTw 5T33p4VG+iLK2UXs9WM= X-Received: by 10.99.174.78 with SMTP id e14mr630460pgp.75.1501809911467; Thu, 03 Aug 2017 18:25:11 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id t77sm331720pfj.9.2017.08.03.18.25.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 18:25:10 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 Aug 2017 10:25:08 +0900 References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> To: v6ops@ietf.org In-Reply-To: <150148445751.17707.15424999122129322815@ietfa.amsl.com> Message-Id: <2E470571-1620-4527-9489-D4D953000040@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 01:25:14 -0000 At the end of Sec. 4, it reads: "After the UE/subscriber received the RA, and the associated flags, it will assign itself a 128 bit IPv6 address using SLAAC. Since the address is composed by the UE/subscriber device itself, it will need to verify that the address is unique on the shared network. The UE/ subscriber will for that purpose, perform Duplicate Address Detection algorithm. This will occur for each address the UE attempts to utilize on the shared provider managed network.=E2=80=9D Now the each device has a unique prefix, there=E2=80=99d be no chance = that 128 bit addresses generated by different devices should collide. Do = we need DAD here? --- DY > On 31 Jul 2017, at 16:00, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Pages : 8 > Date : 2017-07-31 >=20 > Abstract: > In some IPv6 environments, the need has arisen for hosts to be able > to utilize a unique IPv6 prefix, even though the link or media may = be > shared. Typically hosts (subscribers) on a shared network, either > wired or wireless, such as Ethernet, WiFi, etc., will acquire unique > IPv6 addresses from a common IPv6 prefix that is allocated or > assigned for use on a specific link. >=20 > In most deployments today, IPv6 address assignment from a single = IPv6 > prefix on a shared network is done by either using IPv6 stateless > address auto-configuration (SLAAC) and/or stateful DHCPv6. While > this is still viable and operates as designed, there are some large > scale environments where this concept introduces significant > performance challenges and implications, specifically related to = IPv6 > router and neighbor discovery. >=20 > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 3 18:28:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443B8129B14 for ; Thu, 3 Aug 2017 18:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3jEL-2Su3VG for ; Thu, 3 Aug 2017 18:28:09 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6413127978 for ; Thu, 3 Aug 2017 18:28:09 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id s6so1941993qtc.1 for ; Thu, 03 Aug 2017 18:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PWPciBY9jaZ4ecnmCHftQAa0D3sMLOcsHnwpOx8BYxU=; b=AS/eOVzQXzY/Y8c+C40vC82H8IflxoVme895JwX7jogjVH88MhXstuZXZ5KWC86ECU U+mYAYn0mzl+flJGOPAKq+yHZkBHryQ2Z0XM4KyiFGE1ke/mCNJuh7f7sPal7yo78njL AbsZT60OSdV9OWZBxu0ReL49IkqsEDyRRdR6oWSlyVlVsDeBN6uGcYco7eusLkvUXYgK 7tqDyDjQ70o3tRoPhPMSyWnGYIpYDCxuwamQgQiF/tv+Gla1SJ/AjwXOyV0uI/5E1I78 8tZzRwo92KSRdVRCP0HOuFpv5r7HVjGMVYHLoFAWWgG6Sgb5acw48VLsaB3nGudCEtrL zuLA== 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=PWPciBY9jaZ4ecnmCHftQAa0D3sMLOcsHnwpOx8BYxU=; b=IHBaVRd89/XmnuoHzA0JrbnqYB/vFTAuBI+cmaY6l0+QPaHUzAgHv327CwtPBh6WXm Hd+4LBAjXSpFjwH3Zbkw22iiLKcvz+nvd9xSDkd8dZHPLnUFhVa+RPZ6oH51exqarVj2 Cz1G61skGo49uZDfCrkiWnl+et6i6j+H2oPn24ccMtmFkz3XOnlxwbgv2l6PxlrGaKeh VkMiYocqJXtCWz/jBpduXo9RD+xwvIjumD/dhgSwHPUonYzjDXMa+7IU+fyjJtKhseAm 3KqsCYr4DxpZlx0w6n0XI7NuzQhU2OwTLm46aySb0WYKIpIdyKYVvGberIZyO6Wtrhtg nj9g== X-Gm-Message-State: AHYfb5hBYO7yfnc5vNG4npALuBaqPfkv+Ulgcdqth1ELA9ecvefUMk5G e6TzeDrW/tKHxF3S X-Received: by 10.237.57.199 with SMTP id m65mr927346qte.243.1501810088837; Thu, 03 Aug 2017 18:28:08 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id p1sm262068qke.16.2017.08.03.18.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 18:28:08 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D232B80B-7CB1-44D3-85FE-483AAF52FC09" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 21:28:04 -0400 In-Reply-To: Cc: "Bernie Volz (volz)" , "v6ops@ietf.org WG" To: Mikael Abrahamsson References: <8276B3B2-EABB-4212-B327-8A076AC61EC1@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 01:28:11 -0000 --Apple-Mail=_D232B80B-7CB1-44D3-85FE-483AAF52FC09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 3, 2017, at 9:06 PM, Mikael Abrahamsson wrote: > If we could send zero-lifetime RA before reconfiguring, the RA = controlled part of this could be up and running again in a few seconds. Why can't you? --Apple-Mail=_D232B80B-7CB1-44D3-85FE-483AAF52FC09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 3, 2017, at 9:06 PM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
If we could send = zero-lifetime RA before reconfiguring, the RA controlled part of this = could be up and running again in a few seconds.

Why = can't you?

= --Apple-Mail=_D232B80B-7CB1-44D3-85FE-483AAF52FC09-- From nobody Thu Aug 3 18:39:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9A13203F for ; Thu, 3 Aug 2017 18:39:27 -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, 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 H9b-Rc7BlKK9 for ; Thu, 3 Aug 2017 18:39:25 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBF112EB9B for ; Thu, 3 Aug 2017 18:39:25 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id v77so1681574pgb.3 for ; Thu, 03 Aug 2017 18:39:25 -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=Dywhx+R8FKYp0WqweghgHLaD4TmBgKtTG50O5uZozLc=; b=XJJm6LbWQ7+vQ2r7i/AiwbY2S4vvsUef29ll4OrEi/L2q+Dn7v5XxfizPJwJZ+ZC9T W8+WqhIXfLz36mg1pjEqgQMfx4nAmzOADG0DpkL94fLOsPURarFNG9znAeT/desg+r14 8AUYuMoqW80md0eXzqhwFtOjveOV2ASbjsia47c3fppwpqvvjHIzmtKLXXn8zylCB23M QKUfTzMV7j35iAh0IsiC6y9DmbN1Etxuz5UehtmFDitzu6onTwZ+0hCEB/VLuB5BVUTM SG2RXVGmiRFimhBhNPoG/TGU3yAiYWJnAPYwHo9KtLU6QEUHXgzKJmxraSACcHDFlPgS zo+g== 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=Dywhx+R8FKYp0WqweghgHLaD4TmBgKtTG50O5uZozLc=; b=PbdvrqD5EPIXngCAK3Ci7skJQxWYgBPQtRIjEIEceiXkpSB+rfTlfuBOflXNNtX0Ok ilyN12KpNFCtP5xhYZXm1ihHBDijGb18M5zVVqk7eWMKeZTC29usuLSgrqnjVBz+2agr x2WjKl7yvaFb3c24ZtezXYKjIMms+8PUQ0fIYkAxpQjfVa8RWL9FyjSpR4esM/g3cjZV uwuig6QWPZgU6aB8Z//14N/tcMa8DJnbSqZX2rVd/YWsjJuFBuv+sKxvrGViQK9ligXz rhzG+L0n05p3+fS7aE4BjXzCCicGds0BribXLicFqK1HI3PvRfefi5S8wRkD8Jeh4emW SSYQ== X-Gm-Message-State: AIVw111tpbp23Uu9+kRyVb28TcUrMDtRn8TqrvdTjmn+dPa64keursSX hIKm1varx6VyQLguWGE= X-Received: by 10.101.85.79 with SMTP id t15mr659012pgr.95.1501810764878; Thu, 03 Aug 2017 18:39:24 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id t64sm276540pgd.80.2017.08.03.18.39.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 18:39:24 -0700 (PDT) From: DY Kim Content-Type: multipart/alternative; boundary="Apple-Mail=_A373228E-2754-49AE-979F-337F0AE696A1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <8737A9C8-F798-4503-99C7-ADBD5B220759@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> To: v6ops@ietf.org Date: Fri, 4 Aug 2017 10:39:21 +0900 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 01:39:27 -0000 --Apple-Mail=_A373228E-2754-49AE-979F-337F0AE696A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the 2nd para of Sec. 4, it reads: "The Unique IPv6 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the First Hop Provider Router or from a centrally allocated pool.=E2=80=9D In the case the prefix is assigned from a centrally allocated pool, does = this scenario include the following cases?: o all prefixes assigned to devices on the same shared network = may not be aggregatable into a single shorter prefix. o /64 prefixes may be assigned randomly to different devices on = different share network. --- DY > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [v6ops] I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Date: 31 July 2017 at 16:00:57 GMT+9 > To: > Cc: v6ops@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Pages : 8 > Date : 2017-07-31 >=20 > Abstract: > In some IPv6 environments, the need has arisen for hosts to be able > to utilize a unique IPv6 prefix, even though the link or media may = be > shared. Typically hosts (subscribers) on a shared network, either > wired or wireless, such as Ethernet, WiFi, etc., will acquire unique > IPv6 addresses from a common IPv6 prefix that is allocated or > assigned for use on a specific link. >=20 > In most deployments today, IPv6 address assignment from a single = IPv6 > prefix on a shared network is done by either using IPv6 stateless > address auto-configuration (SLAAC) and/or stateful DHCPv6. While > this is still viable and operates as designed, there are some large > scale environments where this concept introduces significant > performance challenges and implications, specifically related to = IPv6 > router and neighbor discovery. >=20 > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A373228E-2754-49AE-979F-337F0AE696A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the 2nd para of Sec. 4, it reads:

"The Unique IPv6 prefix can be derived = from a locally managed
   pool or aggregate = IPv6 block assigned to the First Hop Provider
  =  Router or from a centrally allocated pool.=E2=80=9D

In the case the prefix = is assigned from a centrally allocated pool, does this scenario include = the following cases?:

= o all prefixes assigned to devices on the same shared network may = not be aggregatable into a single shorter prefix.
= o /64 prefixes may be assigned randomly to different devices on = different share network.

---
DY






Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = [v6ops] I-D = Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Date: = 31 July 2017 at 16:00:57 = GMT+9
To: = <i-d-announce@ietf.org>
Cc: v6ops@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IPv6 = Operations WG of the IETF.

=        Title =           : Unique = IPv6 Prefix Per Host
=        Authors =         : John Jason = Brzozowski
=             &n= bsp;           &nbs= p;Gunter Van De Velde
Filename =        : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Pages =           : 8
= Date =            : = 2017-07-31

Abstract:
=   In some IPv6 environments, the need has arisen for hosts to = be able
  to utilize a unique IPv6 prefix, even = though the link or media may be
  shared. =  Typically hosts (subscribers) on a shared network, either
  wired or wireless, such as Ethernet, WiFi, etc., = will acquire unique
  IPv6 addresses from a = common IPv6 prefix that is allocated or
=   assigned for use on a specific link.

  In most deployments today, IPv6 address = assignment from a single IPv6
  prefix on a = shared network is done by either using IPv6 stateless
=   address auto-configuration (SLAAC) and/or stateful DHCPv6. =  While
  this is still viable and operates = as designed, there are some large
  scale = environments where this concept introduces significant
=   performance challenges and implications, specifically = related to IPv6
  router and neighbor = discovery.

  This document = outlines an approach utilising existing IPv6 protocols
=   to allow hosts to be assigned a unique IPv6 prefix (instead = of a
  unique IPv6 address from a shared IPv6 = prefix).  Benefits of unique
  IPv6 prefix = over a unique IPv6 address from the service provider
=   include improved subscriber isolation and enhanced = subscriber
  management.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-p= refix-per-host/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-07
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-i= pv6-prefix-per-host-07

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv= 6-prefix-per-host-07


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

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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_A373228E-2754-49AE-979F-337F0AE696A1-- From nobody Thu Aug 3 18:53:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B239128BC8 for ; Thu, 3 Aug 2017 18:53:24 -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, 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 AOHTfKdnkImv for ; Thu, 3 Aug 2017 18:53:22 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFF512EB9B for ; Thu, 3 Aug 2017 18:53:22 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id d67so1878274pfc.0 for ; Thu, 03 Aug 2017 18:53:22 -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=2plBcxgLMT/YoZmlwwogiqlIPcsFWSNQCi4wFJnP/LQ=; b=gldH9FDiSTtQfZfkJcD32CsUfPvsySzyUTlyzdGatRzrGUWoF6ZctfejIKY6eRIYqA nHoqfCwicRO2wKDnpdNDQnGTBFxYsfmLj/8bS+OJegdpnDM4tN4R+4/u8c0C8roMqSVN GJPnuTK9JXHR2svj5sFg1kEsmB/ur12bbPhUWVT5p3cpDjkJkX7025x+Q4gd+ltn/Iay eIgJx2Lc9wZeL/nEWOsjx5leZnMYqfSotLtm2MlzG5PWHnd1RxIf5PIwR7Yvr6rgnoa0 z18uQI7aP4Kt2oivAr+hKl8zFQVLyMwVE5YF5PbT+ktm4uNO1/6ir7p54M2hDsneDub1 jkWw== 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=2plBcxgLMT/YoZmlwwogiqlIPcsFWSNQCi4wFJnP/LQ=; b=E29Dnh9E0M3xz58vHR8sZjGlmJScfzFVxpKYbd/mdtdP7HpnD+nnm7cStCEZK1S0cz tpOoSYxhz86uEZ3G1EQESanQ3RQdRxy+wJwsrwC9XlPR/Wi18Xo6E73BE/MaHQqYVYUy fruN5yz2/Tipm3eBFY9bPRxmFgSyqzvH7J0OGHlIlQ57GRsEQK9LKH222gSOgrN8ey2g f1NChIwUTtJM7Vdry/6MHlRqpXiVEiAH0pZUsHOjn8wEDwemPS+yKg3QggSHbmWRnnw1 WPdUOgf7EnFB4MxRYCuTly4j5NP7fFJmPXiTfdBzTlupiHc2K6qYq1by1TetD2gveg0O F3Aw== X-Gm-Message-State: AIVw112xdCv2y0TtDK7JWaltrmD24G16Hj4tNtJ1lNF7cWyGLXEduZQ+ jhipa5tF7rC7P7TSl+0= X-Received: by 10.101.77.72 with SMTP id j8mr682792pgt.133.1501811601405; Thu, 03 Aug 2017 18:53:21 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id s4sm371829pfk.71.2017.08.03.18.53.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 18:53:20 -0700 (PDT) From: DY Kim Content-Type: multipart/alternative; boundary="Apple-Mail=_A66E30EE-D9AD-4919-8599-E7411BAAB5A3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> To: v6ops@ietf.org Date: Fri, 4 Aug 2017 10:53:18 +0900 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 01:53:24 -0000 --Apple-Mail=_A66E30EE-D9AD-4919-8599-E7411BAAB5A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the 2nd para of Sec. 4, it reads: =E2=80=9C=E2=80=A6 a Unique IPv6 prefix (currently a /64 = prefix)=E2=80=A6=E2=80=9D Assuming that there=E2=80=99d be at some place upwards where a /48 = prefix would be present, which prefix length is up to a common practice = for ISPs in assigning a prefix to a site, does the above spec means: o the maximum number of devices that the proposed scenario can = accommodate is 64K (2**16; 64 - 48 =3D 16)? --- DY > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [v6ops] I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Date: 31 July 2017 at 16:00:57 GMT+9 > To: > Cc: v6ops@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Pages : 8 > Date : 2017-07-31 >=20 > Abstract: > In some IPv6 environments, the need has arisen for hosts to be able > to utilize a unique IPv6 prefix, even though the link or media may = be > shared. Typically hosts (subscribers) on a shared network, either > wired or wireless, such as Ethernet, WiFi, etc., will acquire unique > IPv6 addresses from a common IPv6 prefix that is allocated or > assigned for use on a specific link. >=20 > In most deployments today, IPv6 address assignment from a single = IPv6 > prefix on a shared network is done by either using IPv6 stateless > address auto-configuration (SLAAC) and/or stateful DHCPv6. While > this is still viable and operates as designed, there are some large > scale environments where this concept introduces significant > performance challenges and implications, specifically related to = IPv6 > router and neighbor discovery. >=20 > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A66E30EE-D9AD-4919-8599-E7411BAAB5A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the 2nd para of Sec. 4, it reads:

=E2=80=9C=E2=80=A6 a Unique = IPv6 prefix (currently a /64 prefix)=E2=80=A6=E2=80=9D

Assuming that there=E2=80=99= d be at some place upwards where a /48 prefix would be present, which = prefix length is up to a common practice for ISPs in assigning a prefix = to a site, does the above spec means:

o the maximum number of devices = that the proposed scenario can accommodate is 64K (2**16; 64 - 48 =3D = 16)?


---
DY






Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = [v6ops] I-D = Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Date: = 31 July 2017 at 16:00:57 = GMT+9
To: = <i-d-announce@ietf.org>
Cc: v6ops@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IPv6 = Operations WG of the IETF.

=        Title =           : Unique = IPv6 Prefix Per Host
=        Authors =         : John Jason = Brzozowski
=             &n= bsp;           &nbs= p;Gunter Van De Velde
Filename =        : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Pages =           : 8
= Date =            : = 2017-07-31

Abstract:
=   In some IPv6 environments, the need has arisen for hosts to = be able
  to utilize a unique IPv6 prefix, even = though the link or media may be
  shared. =  Typically hosts (subscribers) on a shared network, either
  wired or wireless, such as Ethernet, WiFi, etc., = will acquire unique
  IPv6 addresses from a = common IPv6 prefix that is allocated or
=   assigned for use on a specific link.

  In most deployments today, IPv6 address = assignment from a single IPv6
  prefix on a = shared network is done by either using IPv6 stateless
=   address auto-configuration (SLAAC) and/or stateful DHCPv6. =  While
  this is still viable and operates = as designed, there are some large
  scale = environments where this concept introduces significant
=   performance challenges and implications, specifically = related to IPv6
  router and neighbor = discovery.

  This document = outlines an approach utilising existing IPv6 protocols
=   to allow hosts to be assigned a unique IPv6 prefix (instead = of a
  unique IPv6 address from a shared IPv6 = prefix).  Benefits of unique
  IPv6 prefix = over a unique IPv6 address from the service provider
=   include improved subscriber isolation and enhanced = subscriber
  management.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-p= refix-per-host/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-07
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-i= pv6-prefix-per-host-07

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv= 6-prefix-per-host-07


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

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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_A66E30EE-D9AD-4919-8599-E7411BAAB5A3-- From nobody Thu Aug 3 19:04:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B326F129ADD for ; Thu, 3 Aug 2017 19:04:27 -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, 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 oMv3qaanm94Y for ; Thu, 3 Aug 2017 19:04:26 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFEF1277BB for ; Thu, 3 Aug 2017 19:04:26 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id t86so1930525pfe.2 for ; Thu, 03 Aug 2017 19:04:26 -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=409bR96q4KO0bkZM9etBM2rLoVQveYEtcPR5cM5r7gI=; b=sRcjYBIlqls33IOOf9ilh1/ZuaWXImhA0NuZmbO+Dojh4JzrT950swwA+lfQv7NbTw ATTsl18LCDcGGnRLGSEnBYpBsFJYey9p60qpkfyT9sKKmczyDA1hQFzCsTrzNwnSIdG5 OtaHieNj+qCW2AyZsGL657CNgywpBOpHjwEic2gPvwre/PlfClg0fYTERYpAJLlHlsCK nhb/d+HDJxZIrsmssR/y6cDlLhOD1TLC+YpQFBP9tl5FFucVFDvBZ7g5VQFUNwcKjYDq Iy6rqYdqRAF4gvy7aFsKhOuCJ84o/3zVzN/cmx8dcBa4MOwhI7xKlje/KzJGXHQxaVgP Vqcg== 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=409bR96q4KO0bkZM9etBM2rLoVQveYEtcPR5cM5r7gI=; b=Uvw9A4162R3HG6got8j0szicv7Zy4uFAxhaAnQ7x0EZFGcHc4RLtApfxpDR7GgZgvt L1CTs+P6VGW7Rekqb+4AUnFvLYQxw4EVtDrm2nr9AvNUd9vaON6XdzV0NaPFg51zEiZF hrvGFaFvWv9eV89ngxYXi912NZdVlgEaKg19ZZx4KaAqmBHQN94bCEYjWWzQ/b6VymUu qqGP6RrgaQjBQs9cepNk8E0x7m/jDPpbJqxYKr/BOm2ek/ebyR/5kwq41CBAwiTtHcQC fnWs3wqVyOeBpTXzK5KOGiEEoCFA7+S/nZZZgl6NygisqwKDiA+Il8WBaGBy6BcbPhVP gXeQ== X-Gm-Message-State: AIVw113TeIo/r0JoQK+MYbuJHQiS4FW1xXzaHWyE9uIatC2tNqRUGGdr cakRb3LpQyGGp5xHkrI= X-Received: by 10.84.232.135 with SMTP id i7mr843914plk.193.1501812265315; Thu, 03 Aug 2017 19:04:25 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id n129sm391635pfn.27.2017.08.03.19.04.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 19:04:24 -0700 (PDT) From: DY Kim Content-Type: multipart/alternative; boundary="Apple-Mail=_D813C194-FAA3-446A-9B69-9C008B8BFABB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <148E758F-1B18-4E8F-95AB-0E713F711684@gmail.com> References: To: v6ops@ietf.org Date: Fri, 4 Aug 2017 11:04:22 +0900 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:04:28 -0000 --Apple-Mail=_D813C194-FAA3-446A-9B69-9C008B8BFABB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In regards to the wording "provider managed shared network=E2=80=9D. Does =E2=80=98provider=E2=80=99 here mean exclusively any commercial = ISPs or the kind? Can it also be interpreted as =E2=80=98site managed = shared network=E2=80=99 where site could be any AS? --- DY > Begin forwarded message: >=20 > Subject: [v6ops] I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Date: 4 August 2017 at 10:20:53 GMT+9 > To: v6ops@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > Pages : 8 > Date : 2017-07-31 >=20 > Abstract: > In some IPv6 environments, the need has arisen for hosts to be able > to utilize a unique IPv6 prefix, even though the link or media may = be > shared. Typically hosts (subscribers) on a shared network, either > wired or wireless, such as Ethernet, WiFi, etc., will acquire unique > IPv6 addresses from a common IPv6 prefix that is allocated or > assigned for use on a specific link. >=20 > In most deployments today, IPv6 address assignment from a single = IPv6 > prefix on a shared network is done by either using IPv6 stateless > address auto-configuration (SLAAC) and/or stateful DHCPv6. While > this is still viable and operates as designed, there are some large > scale environments where this concept introduces significant > performance challenges and implications, specifically related to = IPv6 > router and neighbor discovery. >=20 > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_D813C194-FAA3-446A-9B69-9C008B8BFABB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In regards to the wording "provider= managed shared network=E2=80=9D.

Does =E2=80=98provider=E2=80=99 here mean exclusively = any commercial ISPs or the kind? Can it also be interpreted = as =E2=80=98site managed shared network=E2=80=99 where site could = be any AS?

---
DY






Begin forwarded message:

Subject: = [v6ops] I-D = Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Date: = 4 August 2017 at 10:20:53 = GMT+9
To: = v6ops@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IPv6 = Operations WG of the IETF.

=        Title =           : Unique = IPv6 Prefix Per Host
=        Authors =         : John Jason = Brzozowski
=             &n= bsp;           &nbs= p;Gunter Van De Velde
Filename =        : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Pages =           : 8
= Date =            : = 2017-07-31

Abstract:
=   In some IPv6 environments, the need has arisen for hosts to = be able
  to utilize a unique IPv6 prefix, even = though the link or media may be
  shared. =  Typically hosts (subscribers) on a shared network, either
  wired or wireless, such as Ethernet, WiFi, etc., = will acquire unique
  IPv6 addresses from a = common IPv6 prefix that is allocated or
=   assigned for use on a specific link.

  In most deployments today, IPv6 address = assignment from a single IPv6
  prefix on a = shared network is done by either using IPv6 stateless
=   address auto-configuration (SLAAC) and/or stateful DHCPv6. =  While
  this is still viable and operates = as designed, there are some large
  scale = environments where this concept introduces significant
=   performance challenges and implications, specifically = related to IPv6
  router and neighbor = discovery.

  This document = outlines an approach utilising existing IPv6 protocols
=   to allow hosts to be assigned a unique IPv6 prefix (instead = of a
  unique IPv6 address from a shared IPv6 = prefix).  Benefits of unique
  IPv6 prefix = over a unique IPv6 address from the service provider
=   include improved subscriber isolation and enhanced = subscriber
  management.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-p= refix-per-host/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-07
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-i= pv6-prefix-per-host-07

A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv= 6-prefix-per-host-07


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

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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_D813C194-FAA3-446A-9B69-9C008B8BFABB-- From nobody Thu Aug 3 19:40:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D04129B2A for ; Thu, 3 Aug 2017 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJcElbV_9v1l for ; Thu, 3 Aug 2017 19:40:12 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B47313146C for ; Thu, 3 Aug 2017 19:40:12 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id u133so1489610vke.3 for ; Thu, 03 Aug 2017 19:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dDygyrh+O1cZn7XyQm2EhJtvCKX7JvS4uwkstunzzVE=; b=OD++KQAeL3GSiE45xf2A9RALpUFmdFyluoVB+MydQlB9Ycek3kiRcNbxQOsop22hJ8 t1fG7glUs+SPW50wKm7QOVYjZL/B5dq/bZXNz5C8Rx9zFl8UqqVrHyIpkgUQkXtDsGBL ZwCwy802/lxOPZGSZYPFx37g+s7e5XwY9lPjvlASZcrpLiwlFdlr4Hhbo2Fhr+I9nU7T lTkamg8RIp7wgqtH/XGO9GWe3t7n3RqFqecHVk0moRjHz4wcGxgOnMrMjKk6awZUZWsN tSTnHvQXgZYUxq5gG5d5pxk9wrhtzXtjUtLt5jlwS9pt2xb/oQXIb4YRZqF2Ty5d6Uji OaWw== 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=dDygyrh+O1cZn7XyQm2EhJtvCKX7JvS4uwkstunzzVE=; b=BfSxTBNtJsApFwk3Xcuqe6WcfKRdZQdWRyGuDfQIRIS5ltdIEs549FWJiwewFV8Ibc DQGmA/p4ODxOpTq7UxF3NpbNeuh7TRrzLJZaNtU3FxVbTCT9qV70DAoWY8qSBX3yM/41 ykej8uF001pzhhekt4erqg46/uT0QwWSqVZ+B7DeAu/s4/62rxIq9B68CW6V+srfIYKV uqmilAWxV8vZBdZyGYxqo40uMoTMb4ZvoM1FTd3joxjAUzCv4DhnaP4F3XTri6X3wCeQ h6Gz4MS0R2duT9qU9g9U3tTj0OmEBy+Kpezz0ryzVkjYeKE9MXN0htv7Bed3OcOTG0T9 BWeg== X-Gm-Message-State: AHYfb5iZh0OFwK8BnNMPb8lHz/Z01DDGhjxC9T8RLBdUhOitsAdxp9Iu s0itXNYYk3To0bi9dAcQoUvBnQ3HpQ== X-Received: by 10.31.59.69 with SMTP id i66mr464027vka.105.1501814411133; Thu, 03 Aug 2017 19:40:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 19:39:40 -0700 (PDT) In-Reply-To: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> From: Mark Smith Date: Fri, 4 Aug 2017 12:39:40 +1000 Message-ID: To: DY Kim Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:40:13 -0000 On 4 August 2017 at 11:53, DY Kim wrote: > In the 2nd para of Sec. 4, it reads: > > =E2=80=9C=E2=80=A6 a Unique IPv6 prefix (currently a /64 prefix)=E2=80=A6= =E2=80=9D > > Assuming that there=E2=80=99d be at some place upwards where a /48 prefix= would be > present, which prefix length is up to a common practice for ISPs in > assigning a prefix to a site, does the above spec means: > > o the maximum number of devices that the proposed scenario can accommodat= e > is 64K (2**16; 64 - 48 =3D 16)? > (Not speaking on the authors behalf) If you only received a /48 for your site, then yes, that would be the upper limit on how many devices this method supported. However, the scenario being described is one of a service provider, and they will get at least a /32 from their RIR, meaning in theory the maximum number of hosts they can support is 4 billion (!). They could get larger than /32 if they needed to if it became too small. In this scenario a "site" is really the individual host, rather than a boundary of a group of subnets at a site. /48 or /56 are common aggregation boundaries for a multi-subnet site, so they don't really apply here. The service provider could internally aggregate the /64s at any where they need to between e.g. /32 and /63 to suit their routing protocol scaling. So in short, /48 is not constraining this solution because /48 doesn't appl= y. Regards, Mark. From nobody Thu Aug 3 19:47:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9D132014 for ; Thu, 3 Aug 2017 19:47:13 -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 m3KdTcAzd9O4 for ; Thu, 3 Aug 2017 19:47:13 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CF613146C for ; Thu, 3 Aug 2017 19:47:13 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id o86so2307600pfj.1 for ; Thu, 03 Aug 2017 19:47:12 -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=yrWrfL3RW2eOaGptM276ov6uieymzGNJEwUacPoJRCg=; b=W3iQd2vPBxJcJukPIO875csfQ87KiQ/KBar84xgUPdT/HXmYiwOsuzLvLeK6B5NXDm o2kaxRSCTTtYi6Vx8HdM5bRY7vYcsM6He545Mi/KjQgNiwZPuAgQWjwUvnYwQrWJzVn0 INDbYczS4CypAaWwOYPqFeC9vwTcDFgNKvJAe7SCtiTJdW2v+JgEFDMmFTTcP7NQY13z 3k0T3un3dIxrg/J/hkrpjnseOiY6MFXHZJ/RG2kHV5lJZX+PmQGJiHQw864okyI3QzX5 lzmbNKndgEUYaocyG0hHTXPsYjmidinDkALX+q2ZqwjBP8z7sJxlDlsJqyMDpm2roSfo F3QA== 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=yrWrfL3RW2eOaGptM276ov6uieymzGNJEwUacPoJRCg=; b=nhNFjwLNgVpkgQLqipQ+SgIWsAS0GtXxHLRldcMyZgO2c2+STv6BSA0/WJz1/+vPp8 sN2A0gaHHEz6ts2TUEMvBKkDOqEw2gC6CcKlatOeMfeMBBJWSJRgATLouCxIF6fqiyUx dVjzzIEu5fD4UPbSN7hX0t3dfhSBjEZsqlYT3UdIvvkgxGGnh6+AfVtITgAwfnfJbH6n jIhSSoPR+POdIjT0VnSlUEjaB0+dtxTdtwqZI6fSH7oBebQyATZe/OGEdXIqzGfugDOp 4APy/D4qas3TrRbLGSnlcNaprCS3DmtEpvquF5Hf9BaCyUwJIO4YiaYB94nFdcThZnjD eWBQ== X-Gm-Message-State: AIVw110XLFFY7LHmCK0KJPFI35jCXjf64a47SvXlpZJeB3lUcDmGPEyf ogdVlbZQMn9V7A== X-Received: by 10.84.236.5 with SMTP id q5mr968060plk.233.1501814832527; Thu, 03 Aug 2017 19:47:12 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id z66sm468204pfi.137.2017.08.03.19.47.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 19:47:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 11:47:09 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:47:14 -0000 Taken.=20 A follow-on question: Assume the site under my management purview is assigned a /48 prefix = from an upstream provider. Can I apply this BCP to the devices in my = site? I think that=E2=80=99s at least technically possible. And I don=E2=80=99t = see a text in the doc which prevents me from doing that on my own = autonomous decision and responsibility. Right? --- DY > On 4 Aug 2017, at 11:39, Mark Smith wrote: >=20 > On 4 August 2017 at 11:53, DY Kim wrote: >> In the 2nd para of Sec. 4, it reads: >>=20 >> =E2=80=9C=E2=80=A6 a Unique IPv6 prefix (currently a /64 = prefix)=E2=80=A6=E2=80=9D >>=20 >> Assuming that there=E2=80=99d be at some place upwards where a /48 = prefix would be >> present, which prefix length is up to a common practice for ISPs in >> assigning a prefix to a site, does the above spec means: >>=20 >> o the maximum number of devices that the proposed scenario can = accommodate >> is 64K (2**16; 64 - 48 =3D 16)? >>=20 >=20 > (Not speaking on the authors behalf) >=20 > If you only received a /48 for your site, then yes, that would be the > upper limit on how many devices this method supported. >=20 > However, the scenario being described is one of a service provider, > and they will get at least a /32 from their RIR, meaning in theory the > maximum number of hosts they can support is 4 billion (!). They could > get larger than /32 if they needed to if it became too small. >=20 > In this scenario a "site" is really the individual host, rather than a > boundary of a group of subnets at a site. /48 or /56 are common > aggregation boundaries for a multi-subnet site, so they don't really > apply here. The service provider could internally aggregate the /64s > at any where they need to between e.g. /32 and /63 to suit their > routing protocol scaling. >=20 > So in short, /48 is not constraining this solution because /48 doesn't = apply. >=20 > Regards, > Mark. From nobody Thu Aug 3 19:55:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9E7131C2F for ; Thu, 3 Aug 2017 19:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 brWGpAQhBEAU for ; Thu, 3 Aug 2017 19:55:34 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA657132014 for ; Thu, 3 Aug 2017 19:55:34 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id u185so2343156pgb.1 for ; Thu, 03 Aug 2017 19:55:34 -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=g9Y//wWOEAS/Q6KdoOMUyra/3/fILlOuzLdR/e3dvIM=; b=dXzy6XS0tqXCSFsCrW+c5IJVikhbnuyQS8Pv1BnuEVeGHZs9AtS/U/Lnn893IXFwm7 sFYJaRJjA2taQYtJYPUXVAzXLIpvya+wWpX2cv+dbD3WOGjswol4v8NVDs1XjZaPu597 hn5WWtY8o3OWaYHAVICp/uWtCmLlx3UboqgAe4TH/aTpA/R+aWdqP2YWRuQttW1RBDlq 0aZD8mpwQXq1UNeSV3m7PWR7ji67orusDDHfRtOsYK+rcFM51gAatH01ODVD6HYsesqO 9XQQVA32+ZeC+iL9bHvKX47neDf1jDFygpM8kJGXBd0m+P0W2v3bZDgG7jbZe07WRcVj kkgw== 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=g9Y//wWOEAS/Q6KdoOMUyra/3/fILlOuzLdR/e3dvIM=; b=qkHXLgcMVpAooTBXEkM7RFTpeNlUGAql+5c8D7w0jdX5ukgby6i15gQlg9D3ncIv2v 4Fd1vwdgZRAcGKLPyEr/ES709mypJ2PIi9pm3G5HRgniWxWP0Xm8Um8w88LWwmFiZw8D osXDDPwC51PcrY/j8IRXGW2Tc8PGYA8KnRzMz4HrpNTU9pxDLUAby95qSdoS4pFEhvZC FzxyRRkxv77EOvXvUd33i6ObcZ2Ddkc88PdOzs7W0RKT/KX+nP9CcjjQpfbEWyTdGiOe H72EyMmmLWstB8wLpVdkXuoFkAcxkHvR5An8jeSycFDcwv++5+GyqktkWz7g7WOXINpI NERA== X-Gm-Message-State: AIVw112jUEr6hE4FVzFMqTUv/bONP+UPm/js8SX/mq5hHmZwFZ/ZcqcT KWfr1tEaw+kDeQ== X-Received: by 10.98.59.82 with SMTP id i79mr885116pfa.37.1501815334357; Thu, 03 Aug 2017 19:55:34 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:5135:fedc:4856:1744? ([2600:8801:d004:600:5135:fedc:4856:1744]) by smtp.gmail.com with ESMTPSA id r84sm481970pfa.57.2017.08.03.19.55.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 19:55:33 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C6669A5B-2EAE-4779-984D-8FAA9A7888C0 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (14G60) In-Reply-To: <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> Date: Thu, 3 Aug 2017 19:55:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:55:36 -0000 --Apple-Mail-C6669A5B-2EAE-4779-984D-8FAA9A7888C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable As discussed in Prague, this opens a two week WGLC on this draft. This will e= nd on 18 August. Please read the draft now and comment on it. The chairs are= interested to know about experiments using the old and modified behaviors, a= nd a quantification of the improvement (or lack thereof) if such exists. We a= re also interested in the clarity and utility of the proposal. Sent using a machine that autocorrects in interesting ways... > On Aug 3, 2017, at 7:50 PM, Fred Baker wrote: >=20 > Thanks >=20 > Sent using a machine that autocorrects in interesting ways... >=20 >> On Aug 2, 2017, at 7:41 PM, David Schinazi wrote: >>=20 >> Hi v6ops chairs, >>=20 >> As discussed in Prague, we have published a minor revision to RFC655bis: >> https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-03 >>=20 >> I think the document is ready to start Working Group Last Call. >>=20 >> Thanks, >> David Schinazi --Apple-Mail-C6669A5B-2EAE-4779-984D-8FAA9A7888C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As discussed in Prague, this opens a t= wo week WGLC on this draft. This will end on 18 August. Please read the draf= t now and comment on it. The chairs are interested to know about experiments= using the old and modified behaviors, and a quantification of the improveme= nt (or lack thereof) if such exists. We are also interested in the clarity a= nd utility of the proposal.

Sent using a machine that autocorrects in= interesting ways...

On Aug 3, 2017, at 7:50 PM, Fred Baker &l= t;fredbaker.ietf@gmail.com&g= t; wrote:

Thanks

Sent u= sing a machine that autocorrects in interesting ways...

On Aug= 2, 2017, at 7:41 PM, David Schinazi <dschinazi@apple.com> wrote:

Hi v6ops chairs,

A= s discussed in Prague, we have published a minor revision to RFC655bis:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555b= is-03

I think t= he document is ready to start Working Group Last Call.
=
Thanks,
David Schi= nazi
= --Apple-Mail-C6669A5B-2EAE-4779-984D-8FAA9A7888C0-- From nobody Thu Aug 3 20:11:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B97127058 for ; Thu, 3 Aug 2017 20:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT23CeWfIQLv for ; Thu, 3 Aug 2017 20:11:53 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F9A126D46 for ; Thu, 3 Aug 2017 20:11:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8FCA2A6; Fri, 4 Aug 2017 05:11:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501816309; bh=874kW+972sHCZCxxBnpkn+qa8ykUlRqPlfpPWaqdJ3Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kVONfOo9uVCMO08yfTBPiWUaLQvBKccsf8X+RNL6UJMy+voJPOC6qkBbsbtpIpiJP A3hEXisxoboEL4IG2RsaYRKgUFUH1hXxOTHwjssJ/oOBPnMKvE7J8hx2PdyRzkbDN+ KUcOGx7gDehK38jPUbP+TfIPlTu9B4tcJXadKRVs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 785DEA3; Fri, 4 Aug 2017 05:11:49 +0200 (CEST) Date: Fri, 4 Aug 2017 05:11:49 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon cc: "Bernie Volz (volz)" , "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: <8276B3B2-EABB-4212-B327-8A076AC61EC1@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 03:11:55 -0000 On Thu, 3 Aug 2017, Ted Lemon wrote: > On Aug 3, 2017, at 9:06 PM, Mikael Abrahamsson wrote: >> If we could send zero-lifetime RA before reconfiguring, the RA controlled part of this could be up and running again in a few seconds. > > Why can't you? We can. But it won't help much, I won't invalidate the PD because of that. So the RG will have WAN connectivity, but the computers on its LAN will still have the old, non-functioning PD based addresses. If is our gateway, we could modify it to do "/etc/init.d/network restart" (or just invalidate everything DHCP and restart that part) as soon as it sees a zero-lifetime RA (or when the WAN prefix RA changes). I tried this manually, and it works, it brings down the transition time a lot. I would like to support customer-purchased gateways, that's why I'm bringing it here so DHCP documents can be updated with this kind of recommendation (and next time we rev RFC7084, that could be updated as well). That however requires that we reach consensus on how it should be done. Just invalidating everything DHCP from WAN because we see other RA ruins the MIF use-case. Btw, does DHCP even support the MIF use-case without modifications? Can DHCP and RA information be tied together without PVD identifier? Heuristically perhaps, by seeing the MAC address used for DHCP and RA packets, if they match, then they belong together? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 3 20:13:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECBD132049 for ; Thu, 3 Aug 2017 20:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyXVPbNGt3_8 for ; Thu, 3 Aug 2017 20:13:01 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186C7126D46 for ; Thu, 3 Aug 2017 20:13:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 862FAA6; Fri, 4 Aug 2017 05:12:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501816379; bh=5qoiyEsNY9KF0iSJN9Nsx9Nj066eMSO20J666QIj4QE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XDcf5he3V/wIFaEB8v1hzxSGB8VAYv1AvC5fhFP1ki7hkUWU1g1M2zsPute/rgHqR oQ0PUSDo7rgrTan6R4t7J7nyUciNG2oRqtH6O+niEx+kHVdPWaBeAk+Bb8ujNdwqNU +0fI8DqgGMZv7FAkCC63B1JENrP8rHpcM1AEvXl0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 83EC9A3; Fri, 4 Aug 2017 05:12:59 +0200 (CEST) Date: Fri, 4 Aug 2017 05:12:59 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: v6ops@ietf.org In-Reply-To: <2E470571-1620-4527-9489-D4D953000040@gmail.com> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-990229035-1501816379=:2261" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 03:13:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-990229035-1501816379=:2261 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 4 Aug 2017, DY Kim wrote: > At the end of Sec. 4, it reads: > > "After the UE/subscriber received the RA, and the associated flags, it > will assign itself a 128 bit IPv6 address using SLAAC. Since the > address is composed by the UE/subscriber device itself, it will need > to verify that the address is unique on the shared network. The UE/ > subscriber will for that purpose, perform Duplicate Address Detection > algorithm. This will occur for each address the UE attempts to > utilize on the shared provider managed network.” > > Now the each device has a unique prefix, there’d be no chance that 128 bit addresses generated by different devices should collide. Do we need DAD here? No, we don't. That is what https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 is about. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-990229035-1501816379=:2261-- From nobody Thu Aug 3 20:48:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C981315FF for ; Thu, 3 Aug 2017 20:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehOBy1lin3Oy for ; Thu, 3 Aug 2017 20:48:54 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7AB12EC32 for ; Thu, 3 Aug 2017 20:48:54 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q25so2341201uah.1 for ; Thu, 03 Aug 2017 20:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fMWAFAUtiL0vdd6p/Pst4AsanM5et76xm/jaydTIHk4=; b=uPl0cCKfBnTeBgKAtQfWRfBdHw2KFS29VCuPjTZVgoUm/PKWNRPwImmQOs7612uCqu OGtdlaXTA2kMFdYyWjvvkkzQ+1OAt8I2BHroyjWRca1SgaCj7hIwMBaFSRWthVZOq0/8 wTQMn2lXHKDMCbdDrEJ3d0ov9Uh0USHbYB5eDaAs4nqr/vAoZ9RhZjjcAKjgM9GTlG1w F2F21dJwaGwgwyktewuTM/CFjG0ujQYxMGqSygE6VMee25TEi8kNDvhf64TRKU1pyLcx sEaHGOCXFTn1FkI+mdkj+rQ3Emxh6Ebgi2WSIYppfaWfejULe2hIQV0Wzdnioq7/+X5T 30IA== 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=fMWAFAUtiL0vdd6p/Pst4AsanM5et76xm/jaydTIHk4=; b=r1I4odWrvysj3dwgdL4vADvCgc6Ulf6IRyvi6Yma6itsCqW3h1sW1ZqfkUw0i3VPEE IWj9hDoBgpveuobVxbyLAde8SVVwmJsRINVE8OXfMhZtIEdtk1CVHQ/HU0TKekD5aT5C r0YbDJnixJO6L2MIPzh8vy9wVYJJ0lJY9UYfUJrdXXKy+uhPK/gw0+wZay4vBDvujcS/ wZiclKRb6oeaQjFU3ZcZKVVDmlB3ZrDq5B8okq467FkG7n+Nb8UhFe20XUhTJcYzuW1S yNOfRwOEjv43VxuqJzkitaVvAawBLXq8xWHf1O5G9KOr4sSBtsuF175SR4YePkfU2Uti UoNA== X-Gm-Message-State: AHYfb5h0N2x/FLxpGmS1AaigZ3/eQlQ6DqZVz59oyOOZpVWcn3RSRED4 7tZM246d8VrPZYpc7OTZVik7+oDK5Q== X-Received: by 10.176.8.81 with SMTP id b17mr793027uaf.82.1501818533315; Thu, 03 Aug 2017 20:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 20:48:22 -0700 (PDT) In-Reply-To: <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> From: Mark Smith Date: Fri, 4 Aug 2017 13:48:22 +1000 Message-ID: To: DY Kim Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 03:48:55 -0000 On 4 Aug 2017 12:47, "DY Kim" wrote: > Taken. > A follow-on question: > Assume the site under my management purview is assigned a /48 prefix from= an upstream provider. Can I apply this BCP to the devices in my site? No reason you couldn't, how you use those 64k /64s is up you and would be hidden from the provider. I can imagine some sites might have a mix of per-host /64s as well as a number of /64s with multiple hosts (that is, today's model), perhaps where some of the devices are unlikely to benefit from having their own /64 e.g., low powered IoT/sensor devices perhaps. A residential network might have a mix. > I think that=E2=80=99s at least technically possible. And I don=E2=80=99t= see a text in the doc which prevents me from doing that on my own autonomo= us decision and responsibility. Right? Even if there was text in the document that stated it was prohibited, I don't see how it could be policed, or be worth paying the cost of developing a system to try to police it. Regards, Mark. > On 4 Aug 2017, at 11:39, Mark Smith wrote: > > On 4 August 2017 at 11:53, DY Kim wrote: >> In the 2nd para of Sec. 4, it reads: >> >> =E2=80=9C=E2=80=A6 a Unique IPv6 prefix (currently a /64 prefix)=E2=80= =A6=E2=80=9D >> >> Assuming that there=E2=80=99d be at some place upwards where a /48 prefi= x would be >> present, which prefix length is up to a common practice for ISPs in >> assigning a prefix to a site, does the above spec means: >> >> o the maximum number of devices that the proposed scenario can accommoda= te >> is 64K (2**16; 64 - 48 =3D 16)? >> > > (Not speaking on the authors behalf) > > If you only received a /48 for your site, then yes, that would be the > upper limit on how many devices this method supported. > > However, the scenario being described is one of a service provider, > and they will get at least a /32 from their RIR, meaning in theory the > maximum number of hosts they can support is 4 billion (!). They could > get larger than /32 if they needed to if it became too small. > > In this scenario a "site" is really the individual host, rather than a > boundary of a group of subnets at a site. /48 or /56 are common > aggregation boundaries for a multi-subnet site, so they don't really > apply here. The service provider could internally aggregate the /64s > at any where they need to between e.g. /32 and /63 to suit their > routing protocol scaling. > > So in short, /48 is not constraining this solution because /48 doesn't ap= ply. > > Regards, > Mark. From nobody Thu Aug 3 22:40:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D4E127337 for ; Thu, 3 Aug 2017 22:40:24 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmPMmFIP5S8u for ; Thu, 3 Aug 2017 22:40:22 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF6B126DD9 for ; Thu, 3 Aug 2017 22:40:21 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4580F42A01 for ; Fri, 4 Aug 2017 07:40:20 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 33AE4429E9; Fri, 4 Aug 2017 07:40:20 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 30DEF3467D; Fri, 4 Aug 2017 07:40:20 +0200 (CEST) Date: Fri, 4 Aug 2017 07:40:20 +0200 From: Gert Doering To: Lorenzo Colitti Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Message-ID: <20170804054020.GE45648@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 05:40:24 -0000 Hi, On Fri, Aug 04, 2017 at 01:07:39AM +0200, Lorenzo Colitti wrote: > This sort of thing is precisely why DHCPv6 is not a good protocol to > configure dynamic networks such as home networks. When did you start opposing DHCPv6-PD as well (which is what this is about)? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Aug 3 22:56:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C971243F3 for ; Thu, 3 Aug 2017 22:56: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-bHFthVZKXg for ; Thu, 3 Aug 2017 22:56:35 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDD1131897 for ; Thu, 3 Aug 2017 22:56:34 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g35so2469253ioi.3 for ; Thu, 03 Aug 2017 22:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CdKnGzF4J58RhPfJjd7qV7rP3CSw/QLBwW100CvAk4I=; b=UeO+zHRK5KN33x0G0zBlXhhFqUS6Szqv/Y7vngoDY4PEMKirU82r+OY2HtZto59Fcs p7+Zs68p9r/vXPN4razRmW6V92+xvrtHjQRILdcixBuIOv59lRS/UhB1TyQofrFc+71n aGumFL3rgpivzI0CxWCIJDmgjkDktnh06BjbaTXe61qWqhfKVm94bm0Hx7YGeBsmaUKm Iodxkici1KQz2ygyYCMfH+TWk4xE3yjYcEjo04SRlbtXcEC52cS4R0NhonWevOI8hDoN PXmpUTO/zZhE2H2HS8aOqiQlem+LgpnFiiccY9cd9AG3bF6K6xeIMeNs3sqyjQTByUnH WyEw== 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=CdKnGzF4J58RhPfJjd7qV7rP3CSw/QLBwW100CvAk4I=; b=RZni7lGFJXjXSTYvzCbCCJ16+lrCZTN1UTtfDCspSmhvAFtaEfQiziBpkjMrDu+GIy L4+yshgsidrw9ewDDd2k8nSzd5LYaTOcly4d3iMF+Czekj/OAidy1dToDOhNX1ZgBZXa FpVlNKqqC+vTBomF8cZpd9NMKKZbGVyj9cr0BhW1uvuw9lvPMGSPJcAUlzg38p56n/B0 XPnhPTHXY1em1gSu51486JACVU84RCX4m3FUYcbVUthk1yOSlC5PIei60A5oIz/vQUe4 V7EuClEvHNRVfMbDD7oqPmm2J40ujbHmXWAzKV3CfZ4KKb9TgLDpNaB105+wql4Zwd80 NgFg== X-Gm-Message-State: AHYfb5gKz5cVlBs9A3uaFqdM9FgJQ+ytLauEQ+tTnJwkhuJWmxb+SwIo 34a+GlXxqJkdRZ8XJdvevZFnN2dx+Vd5 X-Received: by 10.107.4.18 with SMTP id 18mr1221004ioe.185.1501826194001; Thu, 03 Aug 2017 22:56:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 3 Aug 2017 22:56:13 -0700 (PDT) In-Reply-To: <20170804054020.GE45648@Space.Net> References: <20170804054020.GE45648@Space.Net> From: Lorenzo Colitti Date: Fri, 4 Aug 2017 14:56:13 +0900 Message-ID: To: Gert Doering Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113ee06acf4afd0555e72859" Archived-At: Subject: Re: [v6ops] clarification regarding RFC7084 G-5 requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 05:56:37 -0000 --001a113ee06acf4afd0555e72859 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 4, 2017 at 2:40 PM, Gert Doering wrote: > > This sort of thing is precisely why DHCPv6 is not a good protocol to > > configure dynamic networks such as home networks. > > When did you start opposing DHCPv6-PD as well (which is what this is > about)? > I don't think it's useful for anyone to oppose DHCPv6 PD since we don't really have an alternative. :-) However, I do think we should be mindful of the limitations of the protocols we use. And at least to me it's pretty clear, as a general rule that when using DHCPv6 it's very hard to change things. I think it would be good if we could find consensus on an operational guidance document that explained this limitation. One way to do this might be to have a document to explain the strengths and weaknesses of RA and DHCPv6 for layer 3 configuration parameters. I'm not particularly hopeful that we could gain consensus on any actual recommendations (except maybe a vague "if you want property X and protocol Y is not good at property X, then we recommend you don't use protocol Y"), but perhaps we can gain consensus on the facts. --001a113ee06acf4afd0555e72859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 4, 2017 at 2:40 PM, Gert Doering <gert@space.net> wrote= :
> This sort of thin= g is precisely why DHCPv6 is not a good protocol to
> configure dynamic networks such as home networks.

When did you start opposing DHCPv6-PD as well (which is what this is= about)?

I don't think it's use= ful for anyone to oppose DHCPv6 PD since we don't really have an altern= ative. :-)

However, I do think we should be mindfu= l of the limitations of the protocols we use. And at least to me it's p= retty clear, as a general rule that when using DHCPv6 it's very hard to= change things. I think it would be good if we could find consensus on an o= perational guidance document that explained this limitation.

=
One way to do this might be to have a document to explain the st= rengths and weaknesses of RA and DHCPv6 for layer 3 configuration parameter= s. I'm not particularly hopeful that we could gain consensus on any act= ual recommendations (except maybe a vague "if you want property X and = protocol Y is not good at property X, then we recommend you don't use p= rotocol Y"), but perhaps we can gain consensus on the facts.
--001a113ee06acf4afd0555e72859-- From nobody Thu Aug 3 23:58:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6219A1317A4 for ; Thu, 3 Aug 2017 23:57:58 -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 td5ixOiniDgj for ; Thu, 3 Aug 2017 23:57:57 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7845131C20 for ; Thu, 3 Aug 2017 23:57:56 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id u5so4537059pgn.0 for ; Thu, 03 Aug 2017 23:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rCaeXeGeDquhsHq6GeLAEi8e4vJczO42QUNzFrz7eqs=; b=dJI857mLFoDuOXTb8XtCZyDsIgZXYgU5EVNdgEDR/SWuBlEDNTo8e8oSCenn5oG9Wz dduUwYvYqgsxYiT1QUnS2hSa/3+UUvyzK2etOujW5RmJQR89mNZ4/+zIqaOpblIt7yfX BtbM7MiLNPfyROzZVdJgrVznpbm24jXNl9CuIR59ed+QpbYfIH0mIA891H7hvGxhdH35 CpeXhcI2Iluf2arN5PFhF/pz/SvwoqnIHJFItTL3leTdp7xLLolZzoV5pq5GVW3oGdfQ IEZQOfwyTBzMlm8etXsfLQp7JvCDr2oJyp4s1hSJkarg4HrOUOLKkYo8rdoxVDgnpIRd IvtQ== 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=rCaeXeGeDquhsHq6GeLAEi8e4vJczO42QUNzFrz7eqs=; b=rgYXJ+EYJaJ1in1A2ishg0mqabrBDpu2XUsLaVV4iXySmgEJGPPR575EOqyZhIuFT9 fuiz9422qBjIWcrhal2VFDuR/6SKyp38MWO6N1+DDi4EhZZ7nXBiCF0Z42p2O/nJhSHw RMgGoImtJ33CNIvHdopAsVbSqekT3b+Qd2QG+LNUxjBav5+6LINWpg4D+gGlfQnn/v3k JY2by4jpPNooG7L6+mT+7or8GIoG343Mgu09Bc1VkN5pK8ZmO7DWaNfqbGz1kOCXeNam +QiBAM7nR7iZ8j2nzhnfsotX4UpTj6/QxqKKUw3OL8crv6NrbNb0tMPonglCzvlV5hx2 F7ew== X-Gm-Message-State: AIVw1137FpPIBAljf8O80Xd1bCYgFFwICXJ9Isn47kqgyrkyjuiuK+Mj p7heWJPYD+YHIjfP4RY= X-Received: by 10.84.215.210 with SMTP id g18mr1626920plj.210.1501829876437; Thu, 03 Aug 2017 23:57:56 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id z64sm948299pgz.40.2017.08.03.23.57.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 23:57:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 15:57:52 +0900 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4E2E0371-EA83-4A47-AD4D-CA48220EED2B@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 06:57:58 -0000 Thanks. Regards, DY > On 4 Aug 2017, at 12:12, Mikael Abrahamsson wrote: >=20 > On Fri, 4 Aug 2017, DY Kim wrote: >=20 >> At the end of Sec. 4, it reads: >>=20 >> "After the UE/subscriber received the RA, and the associated flags, = it >> will assign itself a 128 bit IPv6 address using SLAAC. Since the >> address is composed by the UE/subscriber device itself, it will need >> to verify that the address is unique on the shared network. The UE/ >> subscriber will for that purpose, perform Duplicate Address = Detection >> algorithm. This will occur for each address the UE attempts to >> utilize on the shared provider managed network.=E2=80=9D >>=20 >> Now the each device has a unique prefix, there=E2=80=99d be no chance = that 128 bit addresses generated by different devices should collide. Do = we need DAD here? >=20 > No, we don't. >=20 > That is what = https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 is = about. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 4 00:01:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A651F131C8C for ; Fri, 4 Aug 2017 00:01:28 -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 VHlgqBH_CT8C for ; Fri, 4 Aug 2017 00:01:27 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF44F131C20 for ; Fri, 4 Aug 2017 00:01:24 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id d67so4550939pfc.0 for ; Fri, 04 Aug 2017 00:01:24 -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=Kfjltpy3nvj/zKi12G7VHPSaNrQ8+1BlxbtyNZ4LPWQ=; b=iGo0+gnbY60DdIUOiGtYmjVxCi5flHQls7SDXlwlhS6WY4z/ziEGkobICcpRrvQ3UY DduNmzRJHP2LlGCh8k3R3U9F4k7ncm7GEcCjHF+UdgfqyhujM2ctDf3U9corXeYa+wYJ wEUHX0ojJd5udSs4r4LdHe0B016AzY00A4uOOR7UGgDlcGEBqZh4HcV8AVLxkO2AJeZY HNocHWvdxzPEkpXrxx6ToalI6kTs9OdU6KJZdCuSHvfKMnFEywf1JkbsPLcpAnSlI1yw BmY3cdI/KrwUlGgPTv9UyQAz4Ul+Bck5sMXFnoK5A6khhO0whdwL+6O9g+BXxu8okxeL VG9A== 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=Kfjltpy3nvj/zKi12G7VHPSaNrQ8+1BlxbtyNZ4LPWQ=; b=e4b9UpZtbeXqmQLYF4CR17w9QwgMhL4Q0AeIRSXmasuuGUf8wKwVoXLAPXkOPymQS0 NCcgbmC9no3wHi3Ytgs3e8oNZVlSgWOzamygynI2LcuofHVtncxI0thBJUQ93Hdlx5KR JXO1OtEwyeErW7EgF1x/Ve+UebK782ZQNFwaSl8Nh7xn9KCOn81KqeWImZyesC8vzPm4 pzlJzBO/L+WPSmZeTSMTGVSdhi0yD7BV7M8kbWdK1qnNoxi1+aKLENf29ZQBf3A86Ujb NxWnYrE2k9xKXMqVD0QjV2EBgPxwdxgsPE6oWsZPS8nI4XjelNv4RfhRtUrPXbg4JKk6 D9rg== X-Gm-Message-State: AIVw110rPM0FKmyBFkiCKN5n7RHBPy9NdLvWzlSNAOPJ6K+d+tVDSvWZ khqq2k5ns6IgNA== X-Received: by 10.84.209.175 with SMTP id y44mr1542073plh.383.1501830084084; Fri, 04 Aug 2017 00:01:24 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id r86sm1568228pfi.138.2017.08.04.00.01.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 00:01:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 16:01:19 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:01:29 -0000 Thanks. Then=E2=80=A6 is the number =E2=80=98/64=E2=80=99 of this document a = MUST or MAY? For example, I might like to assign to each nodes in my site /96 prefix = instead of /64. Is this prohibited by this document? Or is =E2=80=98/64=E2=80=99 = mentioned in the document only an example? Regards, DY > On 4 Aug 2017, at 12:48, Mark Smith wrote: >=20 > On 4 Aug 2017 12:47, "DY Kim" wrote: >=20 >> Taken. >=20 >> A follow-on question: >=20 >> Assume the site under my management purview is assigned a /48 prefix = from an upstream provider. Can I apply this BCP to the devices in my = site? >=20 >=20 > No reason you couldn't, how you use those 64k /64s is up you and would > be hidden from the provider. >=20 > I can imagine some sites might have a mix of per-host /64s as well as > a number of /64s with multiple hosts (that is, today's model), perhaps > where some of the devices are unlikely to benefit from having their > own /64 e.g., low powered IoT/sensor devices perhaps. A residential > network might have a mix. >=20 >=20 >> I think that=E2=80=99s at least technically possible. And I don=E2=80=99= t see a text in the doc which prevents me from doing that on my own = autonomous decision and responsibility. Right? >=20 > Even if there was text in the document that stated it was prohibited, > I don't see how it could be policed, or be worth paying the cost of > developing a system to try to police it. >=20 >=20 > Regards, > Mark. >=20 >=20 >=20 >=20 >> On 4 Aug 2017, at 11:39, Mark Smith wrote: >>=20 >> On 4 August 2017 at 11:53, DY Kim wrote: >>> In the 2nd para of Sec. 4, it reads: >>>=20 >>> =E2=80=9C=E2=80=A6 a Unique IPv6 prefix (currently a /64 = prefix)=E2=80=A6=E2=80=9D >>>=20 >>> Assuming that there=E2=80=99d be at some place upwards where a /48 = prefix would be >>> present, which prefix length is up to a common practice for ISPs in >>> assigning a prefix to a site, does the above spec means: >>>=20 >>> o the maximum number of devices that the proposed scenario can = accommodate >>> is 64K (2**16; 64 - 48 =3D 16)? >>>=20 >>=20 >> (Not speaking on the authors behalf) >>=20 >> If you only received a /48 for your site, then yes, that would be the >> upper limit on how many devices this method supported. >>=20 >> However, the scenario being described is one of a service provider, >> and they will get at least a /32 from their RIR, meaning in theory = the >> maximum number of hosts they can support is 4 billion (!). They could >> get larger than /32 if they needed to if it became too small. >>=20 >> In this scenario a "site" is really the individual host, rather than = a >> boundary of a group of subnets at a site. /48 or /56 are common >> aggregation boundaries for a multi-subnet site, so they don't really >> apply here. The service provider could internally aggregate the /64s >> at any where they need to between e.g. /32 and /63 to suit their >> routing protocol scaling. >>=20 >> So in short, /48 is not constraining this solution because /48 = doesn't apply. >>=20 >> Regards, >> Mark. From nobody Fri Aug 4 00:08:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C001320CA for ; Fri, 4 Aug 2017 00:08:34 -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 UU1JIhLtGIJP for ; Fri, 4 Aug 2017 00:08:33 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2BD1320C6 for ; Fri, 4 Aug 2017 00:08:33 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y129so1002346pgy.3 for ; Fri, 04 Aug 2017 00:08:33 -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=PytVcf5QPyJDSGAeG8VlItU3LKLNCEdswDKVt1gxhfo=; b=spsihcnkO5oddX0UdtcJAegq3refWEjfKWgYg1GKCrxsRi9wu7ohYigkuZNoBmF04A J+0z0R23o1Bjhoep4XmVTX/iYrQrIELbY31GL0FK/Hk0v1VCk16bQNRAN1X/I2PUSgpU Nqxc3rfRWxVBT5Shh02f6KiS37uUwVJncfyBR0c7k3mPdgwvGE2nbaSHsX8lYNBVAjZS PhwhexFXOT+QonmBwY9J7EMsq+Ha3TyLyyCFR9ur9voDbPfH7b+f4hIO8/CyXv4NjaU8 +x02PSOWZAzoo4GhLI6ai+ZAiXc9q/kpoHflCpe+sTdAUrOCbGkK0MgcqNFPdrAhTNJ4 Rv1Q== 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=PytVcf5QPyJDSGAeG8VlItU3LKLNCEdswDKVt1gxhfo=; b=q3xao09+RMGavgE7a8La2Y3NmuyX+qN5LTaNg+ZoPsLM2knivQ68R8tDxe+xF2icBZ 7wKsHf/2C/cx8yyh0Yf40ujkAYKwVFN5Ali9KLMlK+lctq9ql61FcngM0MWKcuTPJg8N ykcQNJUSzGCOrS2RMDluZJ03aBxcJmqeZO6ra6qLGBE1q34ZQDmAq/iccXnV7CDuKnLG OiSfKbn4Z/vpnO4sfT3ZmfCqteANdpbhNy9idgUlAQhmUZumn9F9KzRTb1XVFiMjBCEB 1VJH3LMK1Z77xv4wpK6B4EiBWCpTj8W6GZ98eZg3UX2vjM86xinRqNt7awJtGJ/HraAM 5WQA== X-Gm-Message-State: AIVw113HdYhOdPscYoF0jUqvJU8WgImFzCRsrWqJq9httRa4BtohIvEX YM6aK0UZnaVsoRtpREw= X-Received: by 10.84.209.205 with SMTP id y71mr1583538plh.85.1501830512738; Fri, 04 Aug 2017 00:08:32 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id s11sm1689416pfi.24.2017.08.04.00.08.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 00:08:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 16:08:28 +0900 Cc: john_brzozowski@cable.comcast.com, gunter.van_de_velde@nokia.com Content-Transfer-Encoding: quoted-printable Message-Id: <03DD166B-D3A9-4789-AD57-EAAF1E1F017D@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> To: v6ops list X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:08:34 -0000 Is this I-D compliant with RFC 4291bis stating..?: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | = +-------------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94---------+ The prefix under discussion in the I-D should be a node prefix, whereas = all RFC 4291 comments on is the subnet prefix. Or.. is it that the subnet prefix mentioned in RFC 4291bis is just an = example, and you can assign prefixes to any network entities including = node, subnet, or whatever? =20 Regards, DY From nobody Fri Aug 4 00:15:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5D132145 for ; Fri, 4 Aug 2017 00:15:20 -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 ve7RQYoJlqq2 for ; Fri, 4 Aug 2017 00:15:19 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 B4465132143 for ; Fri, 4 Aug 2017 00:15:19 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id 123so1003975pga.5 for ; Fri, 04 Aug 2017 00:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tu0JcX8XfzlFafUcCu5NVAVwkv/EJvgKpWMKN6Xj/lw=; b=ZCWTteMge0rzZ+NqmCs0MHVu6uo/Sasxoqisrq7Vy210CJBC4KbioEreGN4FYOY95v b27psEHQuZagKhPJNgu4GpU0dZ2RXtNb3IeKy1/lTmZWg4poJyjtzaJCD88AeQ/Ql8m/ jdOpFOxQ/WRQKq1eZyx9SgkQAKmR3wsiq+tV5KYLsVSivyGp51vllzSdN8swHYs6RrNO st4MU66WH4TNmIOVf2SrPmxMAqflU7/a05UKxLUyK8z3GKG9IJ1WL5xs/P/NscJbfzP0 wmUhT+ZcYiRjWl2PCEByOoSRoO4MOb6fZxMJBBoLMAW2AQsCik0/KWHZReCMpl7zKcdz MaBQ== 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=tu0JcX8XfzlFafUcCu5NVAVwkv/EJvgKpWMKN6Xj/lw=; b=uDwqwOG08vGuIAl+d/VhPnG3530tzCXYieHJGkdZfs9zpPdvw0QII0a/VRMyjaL3MB g3tp6wWc+L6Fnp2L0P8UinLtioS8FXHSD9f2+M3sqyiISFC260q/svUbuKuJvnU/D6Jw NeT36a+RPZFPmhsm1CP6uqQgdXNTuKOahgUxzM4fIs0/vGUpwgKMI1McZnqtLovQZrJV ZM3aLMwtN1I+w9t9CyiVLCZzGzOaNLy1GVDbtZxrDYebqDYQkC93Sz0XvKgzHrxXLGf6 6mgjWUuYPmwZ2QRSEaIOpDS8+EyViBIOmmFpBub0FeZLXJFHYzykAOqg2wxItBVgakpS C8AQ== X-Gm-Message-State: AIVw112JkyQ3/maitRmdagvKBUzu26Ava/yilkaPVVr9dF/MEFk6yGMz Vj77EvNn7oCGDw== X-Received: by 10.84.142.133 with SMTP id 5mr1664387plx.148.1501830919279; Fri, 04 Aug 2017 00:15:19 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id t12sm1796768pfg.12.2017.08.04.00.15.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 00:15:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 16:15:15 +0900 Cc: v6ops list , john_brzozowski@cable.comcast.com, gunter.van_de_velde@nokia.com Content-Transfer-Encoding: quoted-printable Message-Id: <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:15:21 -0000 So, you need neither ND nor DAD with the proposed BCP=E2=80=A6? -------- Regards, DY > On 4 Aug 2017, at 12:12, Mikael Abrahamsson wrote: >=20 > On Fri, 4 Aug 2017, DY Kim wrote: >=20 >> At the end of Sec. 4, it reads: >>=20 >> "After the UE/subscriber received the RA, and the associated flags, = it >> will assign itself a 128 bit IPv6 address using SLAAC. Since the >> address is composed by the UE/subscriber device itself, it will need >> to verify that the address is unique on the shared network. The UE/ >> subscriber will for that purpose, perform Duplicate Address = Detection >> algorithm. This will occur for each address the UE attempts to >> utilize on the shared provider managed network.=E2=80=9D >>=20 >> Now the each device has a unique prefix, there=E2=80=99d be no chance = that 128 bit addresses generated by different devices should collide. Do = we need DAD here? >=20 > No, we don't. >=20 > That is what = https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 is = about. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 4 00:28:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3254D13213F for ; Fri, 4 Aug 2017 00:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y4OIjC6OQJj for ; Fri, 4 Aug 2017 00:28:32 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3BD131891 for ; Fri, 4 Aug 2017 00:28:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 149D5A6; Fri, 4 Aug 2017 09:28:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501831710; bh=h2ZOIccf4blrWzdB9Wy5Cb2/y1kejdUuKBTA7I6s9pY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=PtX6xCZxqKk2IYKL3oYCFKCsQraxA5l7KC8zXKCpTMBC/jQKwDh+jIZIuc+xyEODp 8kDn51DtqU1EtSVadVPH21aCLadTqOKIce2Pal6OsNPG0CBLD6bt3ztKVPR3MYl8px V5F7rwPQ3XLKwKF3kvGr908bPxWzDxZEgc9rHUCM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F1688A3; Fri, 4 Aug 2017 09:28:29 +0200 (CEST) Date: Fri, 4 Aug 2017 09:28:29 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: v6ops list In-Reply-To: <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1868819988-1501831666=:2261" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:28:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1868819988-1501831666=:2261 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT On Fri, 4 Aug 2017, DY Kim wrote: > So, you need neither ND nor DAD with the proposed BCP…? If you're talking about PIO-X, then correct. It's not BCP, it's currently intended to be experimental. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1868819988-1501831666=:2261-- From nobody Fri Aug 4 00:33:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA4513214A for ; Fri, 4 Aug 2017 00:33:05 -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 P_uAtoJ5QR4N for ; Fri, 4 Aug 2017 00:33:03 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 C9231131891 for ; Fri, 4 Aug 2017 00:33:03 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id 123so1040011pga.5 for ; Fri, 04 Aug 2017 00:33: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=ClEA2ukFbCm3pq8gwufB9c/fhfDigqr+KoHeom1cG40=; b=jr6vFMWLE1t80boTjhAkDtjR9URKdXJu3K23BL6eKbMCaixVic7qoEN8LZVQzhdQyw terEVbPa/8VAzSqyciwOQSR0LW5dZN6N7Ek6NT9Je62Uh3m4eYTmkwY+WNqW5Wxh+6aj DNggwXkrLZ0oVrDa9zuUAatsWhZ117OiN0/G619RbOkHVZG2beepflNOD+9RXyWdzcqc BN3KoqNxmY1db2ws70JD2/pbWuL8vGMYKvgeHHg3OKmdYSLt+eaXh7tKnzyCsqUp+Kvj GDV3FK+sYQcxxnCVPpazWGgMaVvda6+uEmGt7CjJYpUaES7Egj8YE4Oton14zTrSM+7l LeoA== 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=ClEA2ukFbCm3pq8gwufB9c/fhfDigqr+KoHeom1cG40=; b=nO5qE+vcqfUPB22bhgaVMAcuBSgM/v21xBFSXUFeuZZJ1BjRFKKyU4jleFpnD1vTgp ehiRc/kGjn/fvHcm8Imw+EPAIvDE/4Sa9WH54fBy1OOdI06VKKNyvWrk2eAyoi5kQcUq 0s2sPZGNHqY0kphbG6f8SsE527BPUfm8VxsJ2QsEgZzwIPl4vUzTkcx4YxEhEUC9Qe1Y Eov7x/xUB9Gccpa/R1u3thSxQCGU37Z30E1XGgOStDGesJUhU1B38rhX0+GjCxVcZw/l WrlrFwk2eo74Fr642YiAlnKGZ17iHxxpC1B13viySvPl7PlsXaSZVK5/WTnxWMFJqSSH AqLA== X-Gm-Message-State: AIVw112zBlaB5gpUHJajR5tiViuQXd+0rJgqbmrBN39mB4ULPhLjBzlT dqTA98PJo4JamMmvIMU= X-Received: by 10.99.56.5 with SMTP id f5mr1384996pga.162.1501831983075; Fri, 04 Aug 2017 00:33:03 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id 78sm1552909pft.123.2017.08.04.00.33.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 00:33:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <03DD166B-D3A9-4789-AD57-EAAF1E1F017D@gmail.com> Date: Fri, 4 Aug 2017 16:32:59 +0900 Cc: john_brzozowski@cable.comcast.com, gunter.van_de_velde@nokia.com Content-Transfer-Encoding: quoted-printable Message-Id: <84572649-27D9-4781-8162-F01C969624EB@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <03DD166B-D3A9-4789-AD57-EAAF1E1F017D@gmail.com> To: v6ops list X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:33:05 -0000 4291bis further states: > Except for the knowledge of the subnet boundary discussed in the > previous paragraphs, nodes should not make any assumptions about = the > structure of an IPv6 address. This sounds to me =E2=80=9Cno structure other than subnet should be = assumed.=E2=80=9D =E2=80=A6 which could mean (local, not global) = prefixes may not be assigned to network entities other than subnets. Isn=E2=80=99t the I-D in conflict with this parent (to-be-)standard RFC = 4291bis? ---------- Regards, DY > On 4 Aug 2017, at 16:08, DY Kim wrote: >=20 > Is this I-D compliant with RFC 4291bis stating..?: >=20 > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > = +-------------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94---------+ >=20 > The prefix under discussion in the I-D should be a node prefix, = whereas all RFC 4291 comments on is the subnet prefix. >=20 > Or.. is it that the subnet prefix mentioned in RFC 4291bis is just an = example, and you can assign prefixes to any network entities including = node, subnet, or whatever? >=20 >=20 > Regards, > DY From nobody Fri Aug 4 00:35:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1D132144 for ; Fri, 4 Aug 2017 00:35:03 -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 byFT3LBYNp7t for ; Fri, 4 Aug 2017 00:35:02 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BFF132145 for ; Fri, 4 Aug 2017 00:35:02 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id u5so4871667pgn.0 for ; Fri, 04 Aug 2017 00:35:02 -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=wWKLVvz631YYZWLb4bDo+4h1eSwdnd63w2VeLDzKVGY=; b=nUKJvgfvpNjULVO5FBmyMfaRDV6bK73sGCBHBRrn/thCuVqMN/VSaGeGChoG2kC45h J2bJWm6vEZM7/fZGOxD6xrcqvG/ABiuW8tFVC33+AWxm0GPVU1nKnSNvQoEthayxagyi C40KVYqgn+4CSIlyFbSTsEmTIFogPwrs7AYk8JxDVWEKnKMN6DQVOOeAncrfqIICY2mf eQcu1tfkOUvk8Nlocz0kpS5YVUnVBK9OSulzBU0cJYLH8Jm4eGtDMY/ZdYid3VstuzwC rk0kSH50BpooKMw4iQl/2bFSM1wZssmA7ATK1Tq2/LJn6dW5e9qGHAtydF3R3XfUnLYt 3CaA== 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=wWKLVvz631YYZWLb4bDo+4h1eSwdnd63w2VeLDzKVGY=; b=qIAStDTmjAR7G8CUG/EyVJdk73x3mcQ+IXKMP95026xFuvWYfnq9cm8kQD/kRPmTT9 IbCKVYa5F1ZR1h2ADUjwNvveAgqgulom4PGaw1oQvSnjaL2XHnM+F/a9oZ+PafqjoWxT 9rJ79Bns2ivzy9oy7B+oxkeeu459mR5YAO5V1o6d0pZLXKcaipayEfLl3pYgh6tX/pyV 0S6UV27m8ojGXItfbhaMCaENp7kkKZ+4/YS6NBdHqRv1jijHHLiWzbkBale/2DYCXBfU 2+READOcAy2m5ZCEkgSKp16B9siW11/bXDA5by5DzcZ8TsWtYXxId9nlBKPY5qUu38lf LMgw== X-Gm-Message-State: AIVw110yVIjJoiAR2MpYA9QmeijNupsd/xzuqt5+9XhifWhrPynV9zn2 2b/cA3aeWCOYFQ== X-Received: by 10.84.214.137 with SMTP id j9mr1620400pli.457.1501832102272; Fri, 04 Aug 2017 00:35:02 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id v86sm2253673pfa.6.2017.08.04.00.35.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 00:35:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 16:34:59 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:35:04 -0000 Oh=E2=80=A6 I meant the I-D in cited in the subject field of this = thread; unique-ipv6-prefix-per-host. The I-D says it=E2=80=99s intended status is BCP. ---------- Regards, DY > On 4 Aug 2017, at 16:28, Mikael Abrahamsson wrote: >=20 > On Fri, 4 Aug 2017, DY Kim wrote: >=20 >> So, you need neither ND nor DAD with the proposed BCP=E2=80=A6? >=20 > If you're talking about PIO-X, then correct. >=20 > It's not BCP, it's currently intended to be experimental. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 4 01:15:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E024128A32 for ; Fri, 4 Aug 2017 01:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdhU7yKIrtH6 for ; Fri, 4 Aug 2017 01:15:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E38126B6D for ; Fri, 4 Aug 2017 01:15:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8717BA6; Fri, 4 Aug 2017 10:15:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501834533; bh=OlsC3t/2PHxPY9nMGS0+qI4qnk1FHdFFlCvgD3ZiS7A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fOoAKGc1NMXLAH5cCeTl7waYXAgMim+S8c0YuzkDSvdMCsWVrn+Cb/rXOmemEtd4G H0UNkE2ER1HNpqD5u7p27j2SofzTQSYEsEybCr6RLF+RQlpFUO+qQ6inp6VmbJ7Ahr W+fLV71oeeYadQRn3ppeiAJYjc9gXJg72kiHnoF0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 83FACA3; Fri, 4 Aug 2017 10:15:33 +0200 (CEST) Date: Fri, 4 Aug 2017 10:15:33 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: v6ops list In-Reply-To: <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1001801202-1501834533=:2261" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:15:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1001801202-1501834533=:2261 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 4 Aug 2017, DY Kim wrote: > Oh… I meant the I-D in cited in the subject field of this thread; unique-ipv6-prefix-per-host. > > The I-D says it’s intended status is BCP. As far as I know, unique-ipv6-prefix-per-host doesn't suggest any changes to the host ipv6 stack. That's why it's a v6ops document and not a 6man document. So it doesn't change any standards, it tries to describe a deployment scenario, working within currently deployed standards. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1001801202-1501834533=:2261-- From nobody Fri Aug 4 01:18:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A4D128A32 for ; Fri, 4 Aug 2017 01:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIQlqgU8AfJk for ; Fri, 4 Aug 2017 01:18:45 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4977126B6D for ; Fri, 4 Aug 2017 01:18:44 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id x10so3477195vkd.0 for ; Fri, 04 Aug 2017 01:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kZH5F/lpr2iEFkWH5qKaysE0QTvcztdR29VKTINyeCk=; b=TwDFalEkK1kE6efuRhOHQlU5T7pU7IftGBUAf0iPIDCf+K/D7K7NbWe0AHNY12yxL1 IEYkTkQrYLiSrHAEYC17F/341zzER28GELuFQvh8QcquVdhI6GbfIkX31J8jggmyMYbo arV+yQAXJMuPHL2ePQTJlTgNEiq0oykqJtkmUGlxcbu8VbOht2AzBbeB+4uNlnEqZ0ym ISsjksk/zeZcIajch7hzgLF5UU0GMcMNPYKDSSw7fnho5fFUaNgMpMDOKOtMFHofn7Ar ZQsVxLQJ3X7Ta4iS2f0Lme7QHLhbeiFVz0j+OhpDAsiUqNnsM043dIBae86fQxLQIT5L o3yg== 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=kZH5F/lpr2iEFkWH5qKaysE0QTvcztdR29VKTINyeCk=; b=IzUWlapx2vzpw9zECUSnam6dL60fmBXN9TZ6Mfa9Dc/qgPDjbijwOIOFYwYaXypJSD zxR3pXsvooFh4/DqBu7YQws8Cruq9NcNXQy3sk7gV1Zf7xW3XC944o9vh1+LhJLSSQFo U0sd8wm/GAqfiU7tS7h1whVK9TmP5oCHQ2oB7MtGIGILFTTNJb6fzBj7Y1yQkMAEaPAU K3pmVJqbFjLdRCrsRcw9bPflQAxJJk9GbYmob42mWPh/wmG+UXZ/ykjjc/41ciVaEPIs 4vUdAQi19IHD6EAaKSMJDQcCffALMDWkEhrWTpda3acFLgBKEDrolSGVNvBTm5TnA/Ey v3yw== X-Gm-Message-State: AHYfb5ih8DzgtsOhM93kIBtXfkYB7G4kN3+wgAhoi9slPHln2fOA1X6T g7TkBzpSuvUxSj9xPkzWyXzVNtaiFw== X-Received: by 10.31.84.130 with SMTP id i124mr921622vkb.41.1501834724059; Fri, 04 Aug 2017 01:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 01:18:13 -0700 (PDT) In-Reply-To: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> From: Mark Smith Date: Fri, 4 Aug 2017 18:18:13 +1000 Message-ID: To: DY Kim Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:18:46 -0000 On 4 August 2017 at 17:01, DY Kim wrote: > Thanks. > > Then=E2=80=A6 is the number =E2=80=98/64=E2=80=99 of this document a MUST= or MAY? > > For example, I might like to assign to each nodes in my site /96 prefix i= nstead of /64. > Why specifically might you like to assign /96s? What benefit do you get? If you don't have enough /64s for one for each host, then somebody upstream is being unnecessarily miserly with IPv6 address space. > Is this prohibited by this document? Or is =E2=80=98/64=E2=80=99 mentione= d in the document only an example? > No. /64s as the subnet size as been the common edge subnet/IID boundary for almost 20 years since RFC2373. Variable length subnetmasking and CIDR in IPv4 was a work around to not having enough addressing bits (as were address classes and subnets) for how the Internet Protocols ended up being used - initially it was a research project protocol that became an unmitigated success. Analysis of the 64-bit Boundary in IPv6 Addressing https://tools.ietf.org/rfc/rfc7421.txt Regards, Mark. From nobody Fri Aug 4 01:42:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BB4126B6D for ; Fri, 4 Aug 2017 01:42:11 -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 k4B7_sMmQ8rW for ; Fri, 4 Aug 2017 01:42:10 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8252E131CB5 for ; Fri, 4 Aug 2017 01:42:10 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v77so5407046pgb.3 for ; Fri, 04 Aug 2017 01:42:10 -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=U8GLttcXNBxwu7voQRX5EMIkT85dhl/0jvUVgQKgOXw=; b=I7oTDe0sSoFGCUDPW54yncfbb46qmKb7c4DgXewUOcNYu9GrghJQVjN8beVm00Uv0B qAxiRddvx+cRPNIb8fHOnJ/khTLTi2z5W559hsEosJCkwQUutYO2UV2xBWpu5/CGYw+C nhCWpyHsNbK5xfZ/xftlRGn6RrNZOs4hG5gqdNE5/NASdsXOQ/aV9kWG4IeM7EOrcKV2 PjvjUynhnPa5Ugd29Vy6LI7CyUnpQDM1N6bu45XSoC1QSZyxpfvMCcl4S5+iBukQ1fuD jxmeQu6SNCfa5ZVF0jfdJorWoUrbVEfBxgKuCHCTXCqE7LX5nan0O7xShVGd5+EwznQR mYZg== 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=U8GLttcXNBxwu7voQRX5EMIkT85dhl/0jvUVgQKgOXw=; b=WlGu6YehKZ4DiF5Bw2yREObckasA3GsqcOyh3OoPPykoU8P5xmmKXwElE26Ow8wSzz XHJ7r4WFUm2qwas+2DLJN3F+nvEFnkc3EjjaqsGhEX0wbkHJdDAGFuqiT1RwxJNG9ILa k9dUTVLoKZQYS0f8bqkvuiVPq17JWiwHWJ4hjGVMIRawu2WOJjZcyoKaZUSgS97iTgYP ZerV+wqPVV1ZlCaj0cjHSPLnjkmAJeMuS5kHf+RzHhARtA0NMRClpHS6lr8j6b1e4Mo4 hKsR0C67cm+Im+5cBOjk72UwS1WPPaWDM1Hjj+UOoKctU3PdjOis73s7oeQjvA4lnXBa W6Vg== X-Gm-Message-State: AIVw110znjyihnwgrQ5fQUJTnKkdMcG8RgS3l/Krq0YZTdkAv0FFa63x H25F0G9Km4uQRA== X-Received: by 10.99.100.134 with SMTP id y128mr1503318pgb.365.1501836129849; Fri, 04 Aug 2017 01:42:09 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id s18sm1974878pfg.166.2017.08.04.01.42.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 01:42:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 17:42:04 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <6950ACA0-CAB9-4890-ABE3-0ECA84C58251@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:42:12 -0000 in line... -------- Regards, DY > On 4 Aug 2017, at 17:18, Mark Smith wrote: >=20 > Why specifically might you like to assign /96s? What benefit do you = get? Now that a device (can I say =E2=80=98node=E2=80=99?) trackable by its = (/64) unique prefix, the privacy of the node might be compromised. To combat this, you might want to regularly randomize/refresh the prefix = for a given node to secure privacy from eavesdroppers, except that the = privacy is not secured to the entity distributing the prefixes. For enough randomization in that case, I might like to have enough (say = 48) additional bits for the node prefix, rendering 48+48=3D96; 48 is = shorter than 64, but should be large enough for randomization for = privacy. > No. /64s as the subnet size as been the common edge subnet/IID > boundary for almost 20 years since RFC2373. In this I-D, /64s are not assigned to =E2=80=98subnets' but to =E2=80=98no= des' in a shared network. Or do you mean what RFC 4291bis really wanted say was the boundary for = 'any prefix'/IID is at 64th bit? From nobody Fri Aug 4 01:43:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B03124234 for ; Fri, 4 Aug 2017 01:43:34 -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 tdL_1-j_vQZm for ; Fri, 4 Aug 2017 01:43:33 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93FF131C6C for ; Fri, 4 Aug 2017 01:43:33 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v189so5437506pgd.2 for ; Fri, 04 Aug 2017 01:43:33 -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=3XJ5y7gTytMuQ7lKa8gB4XnuIuu/l334i74Q7JeXFxY=; b=d4HeVlmAA9GeNIX1Uq+EbuQVcWdaP+CRiNSgmhzG9eINM+AlSlV+XQEIctHviwfR0S ZSTNbvaGrrpMuDjwFfvEF0GVLWdlOBFepKUZdT8cqdQpiAqUcrqh8Fw2b0+YaiGsQWW5 8A283xPlBne7rhlzdWpwb6mWXr+V0316yFNrOwF/qZmyWxBt2LvQbRl4S8l/zXGHjedi sD99B/6R9FGNpBk7LkgN3ybf3UKSsrxLqeMW4/fvBRPwPb5m921wROwo50utYEnVIe+l lBvO0HyVwnCXAgv9T34QxVYUb6xXqDZUZkPUxHCQTLMMnvWTUDWygVLv3dciHbEB1vFn 3N6Q== 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=3XJ5y7gTytMuQ7lKa8gB4XnuIuu/l334i74Q7JeXFxY=; b=QIjeW6Z6AXkaBqcwZlpr3Qyyfm2jENuAlIJHINV6F3Fp/VIwjsS5fr6WTa4N56fBsV zkO4CZ33OhWGo+frJwm/MAVHJ+n+l/hvbF3OkkxVptQYQhy7ZA5CL1h5YHhNjP3ZMh5f 3+q4yvNJCY2kXNpXgW788Z6QhniweC2SvDwL9Y4iMlGy7tC/xI/0VPn740SSTd1TVT86 vk3e0wLh+2U1C9AYWXH+c666RoKTmZqzL08ZazcQKBFsU950VBTfsgkIpFbT1fjBSlXW 8P0VJR5XXuq5ivzgQOXRoqceHDFriZkeUcK3Pt2tN8Zmm7tRmZsoOG2Y6rTnLCFTJu2x yVOw== X-Gm-Message-State: AIVw113KsP1KtxG9iODoku/IWdW5LWMLUx3wfKD9yNX/fwgZwMFE/2Qu z59Uod/DcuLCeCzp1G8= X-Received: by 10.101.87.205 with SMTP id q13mr1566968pgr.359.1501836213329; Fri, 04 Aug 2017 01:43:33 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id t11sm2024925pfa.143.2017.08.04.01.43.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 01:43:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 17:43:30 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:43:35 -0000 All mentioned in 4291bis is the subnet prefix, not the node prefix. -------- Regards, DY > On 4 Aug 2017, at 17:15, Mikael Abrahamsson wrote: >=20 > So it doesn't change any standards, it tries to describe a deployment = scenario, working within currently deployed standards. From nobody Fri Aug 4 01:53:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC58131C6C for ; Fri, 4 Aug 2017 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvAqLXQZxqzI for ; Fri, 4 Aug 2017 01:52:57 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC74124234 for ; Fri, 4 Aug 2017 01:52:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E566A6; Fri, 4 Aug 2017 10:52:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1501836775; bh=eawy9bkkJQuSSeDTvh+ZW+ly/bcKh/mhTakY3RLNkZA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WObLP4/vSevQu6OiE3EyEBZJ6Imez2mR5UDpkmDu5N5mkAODcZmaR+dihwIQco+3D TZv52cyquBPouj4By7jlOspMW8Yy536ZJZJhgCBeYcYZT4c6OYuskaARU26BYoY4Jh cfFEBmgyHWnwWDr/J5btsMfbjt1v6OiVJVCFx8fg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 66864A3; Fri, 4 Aug 2017 10:52:55 +0200 (CEST) Date: Fri, 4 Aug 2017 10:52:55 +0200 (CEST) From: Mikael Abrahamsson To: DY Kim cc: v6ops list In-Reply-To: <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:52:59 -0000 On Fri, 4 Aug 2017, DY Kim wrote: > All mentioned in 4291bis is the subnet prefix, not the node prefix. It's impossible for me to follow your comments when you're changing what document you're talking about all the time. draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose any change in standards. Agreed? So your above comment, what is that about? How does it relate to draft-ietf-v6ops-unique-ipv6-prefix-per-host ? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 4 01:56:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA92131CB5 for ; Fri, 4 Aug 2017 01:56:53 -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 AJh1BMZGmiqz for ; Fri, 4 Aug 2017 01:56:52 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E941124234 for ; Fri, 4 Aug 2017 01:56:52 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id t86so5506878pfe.2 for ; Fri, 04 Aug 2017 01:56: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=QVNBigKU0pMeYfPvHBqdzNXuNR/cKnt2Y2yZzTQtFxQ=; b=FLZKzBsmt9QQrDaEflpH6yiyFvkseQB4U54b0W/M3GSfQDhWEGZCmc/pOLaA25q258 lrqOoFuMz8vwjHt5bsFsSVum0p3KZ3ehsmguKERwC3LvLh0PDv15r2G5EPVIqCVNXdA+ fA0EjpKckYPiDroAQms/bAz9srB1KvCNAer+O6q2qhEZev4ZVr2ce9tnBb2isjvOQLEr XNdrEKlhTqmrTk+j6sXLWA58nmclTvahDITFaCi9of5BINrNH60Of/mILz7kBx4HD2zj T2FX9oY1eovBcAfHmExIo8WlHKuYl7YSrHFEhQjkWicS7YjiMdUgI1nIb0ZgcnfgqSqn uOoA== 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=QVNBigKU0pMeYfPvHBqdzNXuNR/cKnt2Y2yZzTQtFxQ=; b=Fgg9/MRdfg49b2qeEJdtYuPzfthcaBukUXVfpobVGhRu0IXQTC24Ly2gpw6F6MbRnl ZBVfXtOC+wtNWtZE1DexcdnMg7d+qap252lpS3EyW9lmyymroT9Akje+VRUo/160tWF/ wOTu9uUGa9FnnVNuAD/EvwCJHXNtGY+S97cQCdGBZdjymaoA1iatCCQfHSuFzcw0iqw3 UWuOmhqTcQk0Sya0rKuXAmzAUTeprtMjW83Oo9qHeY4B0I2PblpR+pZwN95TfUXiYr96 mFG6pNFhBMv5cULQcoP1Ej+0PJf2dCaPRbuF2SHsnWKefWXgWagfDJOTV5hWUF9pcq4C jCiQ== X-Gm-Message-State: AIVw112J2ynJsY2fSHXe2up78sNXmgSbZpGqfb5yQ1gr65HhDWl3LJVQ n4SSLcKOXiAeXr4ggcg= X-Received: by 10.99.114.84 with SMTP id c20mr1539679pgn.13.1501837011679; Fri, 04 Aug 2017 01:56:51 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id s67sm1738730pfb.100.2017.08.04.01.56.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 01:56:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 17:56:48 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:56:53 -0000 OK, I=E2=80=99ll try again. o No concept of =E2=80=98node prefix=E2=80=99 is mentioned in 4291bis. o 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 talks about = =E2=80=98node prefix=E2=80=99. Although 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 is not = meant to change the standard 4291bis, isn=E2=80=99t that in conflict = with 4291bis in that the draft uses a notion not defined in the parent = standard. -------- Regards, DY > On 4 Aug 2017, at 17:52, Mikael Abrahamsson wrote: >=20 > On Fri, 4 Aug 2017, DY Kim wrote: >=20 >> All mentioned in 4291bis is the subnet prefix, not the node prefix. >=20 > It's impossible for me to follow your comments when you're changing = what document you're talking about all the time. >=20 > draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose any = change in standards. Agreed? >=20 > So your above comment, what is that about? How does it relate to = draft-ietf-v6ops-unique-ipv6-prefix-per-host ? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 4 03:03:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6F131771 for ; Fri, 4 Aug 2017 03:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TURPZdH2qD3G for ; Fri, 4 Aug 2017 03:03:51 -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 89346124234 for ; Fri, 4 Aug 2017 03:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501841027; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=aYrm2PiRAjza0g6UmMUkKAPHW/TbNeJ8YLkou9v5cd8=; b=QxW6LBNKoAgt24TkFPV7wac4l/ABo3+MilI7Wz1WP6poDt267zW3ozXa6vSD1LY92KTnfin0UyvGxSaF1DO6iy1f16kPo83khH0Zb4Qs+q4tMrJIWKj4JgyOdTzvL/UszApwcodqMmZ5si4o/MuNFlhITTUsl1yCwl4VPHkNPgk= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-136-SCqC7SH9M2eIzfFtGAd7DQ-1; Fri, 04 Aug 2017 11:03:44 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB435.eurprd07.prod.outlook.com (10.242.112.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Fri, 4 Aug 2017 10:03:42 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.012; Fri, 4 Aug 2017 10:03:42 +0000 From: Tim Chown To: DY Kim CC: Mark Smith , v6ops list Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDQjzcPLOvEGNgkuXOXbQbYoHAg== Date: Fri, 4 Aug 2017 10:03:42 +0000 Message-ID: <801ACC98-2A54-40CF-B6F5-7B36CEC99CDA@jisc.ac.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <6950ACA0-CAB9-4890-ABE3-0ECA84C58251@gmail.com> In-Reply-To: <6950ACA0-CAB9-4890-ABE3-0ECA84C58251@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:2c19:c7da:71cb:5b8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB435; 20:bqdN2+P6PQ5RjvqQW+3nxJ8WgfdxqEzqBbgL2YsNjpYnxORbIW6mQ5FaLElve7isrpTQZOuMBSpfJVTlrBRiFcN4vWPHwtU/1vq1ZEnw7Nd4FeTFpTvp2h7SsNtXsyZk74OnvrtzaHwtuNIe9xRj3LCzS0rb5Fpz9lBON+sVya0= x-ms-office365-filtering-correlation-id: 99af8bb2-292b-4b27-a9cf-08d4db201618 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB435; x-ms-traffictypediagnostic: AM3PR07MB435: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB435; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB435; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(199003)(24454002)(189002)(86362001)(4326008)(50986999)(189998001)(54906002)(99286003)(14454004)(50226002)(93886004)(39060400002)(72206003)(74482002)(76176999)(81156014)(966005)(3280700002)(82746002)(6506006)(229853002)(6306002)(81166006)(105586002)(6486002)(6512007)(33656002)(8676002)(83716003)(2906002)(68736007)(5660300001)(106356001)(6116002)(2950100002)(6916009)(42882006)(53936002)(6246003)(7736002)(305945005)(25786009)(230783001)(6436002)(8936002)(57306001)(110136004)(53546010)(5250100002)(38730400002)(478600001)(2900100001)(1411001)(97736004)(101416001)(36756003)(3660700001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB435; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 10:03:42.1609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB435 X-MC-Unique: SCqC7SH9M2eIzfFtGAd7DQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:03:54 -0000 PiBPbiA0IEF1ZyAyMDE3LCBhdCAwOTo0MiwgRFkgS2ltIDxkeWtpbTZAZ21haWwuY29tPiB3cm90 ZToNCj4gDQo+PiBPbiA0IEF1ZyAyMDE3LCBhdCAxNzoxOCwgTWFyayBTbWl0aCA8bWFya3p6enNt aXRoQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IFdoeSBzcGVjaWZpY2FsbHkgbWlnaHQgeW91 IGxpa2UgdG8gYXNzaWduIC85NnM/IFdoYXQgYmVuZWZpdCBkbyB5b3UgZ2V0Pw0KPiANCj4gTm93 IHRoYXQgYSBkZXZpY2UgKGNhbiBJIHNheSDigJhub2Rl4oCZPykgdHJhY2thYmxlIGJ5IGl0cyAo LzY0KSB1bmlxdWUgcHJlZml4LCB0aGUgcHJpdmFjeSBvZiB0aGUgbm9kZSBtaWdodCBiZSBjb21w cm9taXNlZC4NCj4gDQo+IFRvIGNvbWJhdCB0aGlzLCB5b3UgbWlnaHQgd2FudCB0byByZWd1bGFy bHkgcmFuZG9taXplL3JlZnJlc2ggdGhlIHByZWZpeCBmb3IgYSBnaXZlbiBub2RlIHRvIHNlY3Vy ZSBwcml2YWN5IGZyb20gZWF2ZXNkcm9wcGVycywgZXhjZXB0IHRoYXQgdGhlIHByaXZhY3kgaXMg bm90IHNlY3VyZWQgdG8gdGhlIGVudGl0eSBkaXN0cmlidXRpbmcgdGhlIHByZWZpeGVzLg0KDQpU aGF0IHdvdWxkIGJlIGEgcmVhc29uYWJsZSBpc3N1ZSB0byBkaXNjdXNzIGluIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBvZiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC4NCg0KPiBGb3IgZW5vdWdoIHJhbmRvbWl6YXRpb24gaW4gdGhhdCBjYXNlLCBJIG1p Z2h0IGxpa2UgdG8gaGF2ZSBlbm91Z2ggKHNheSA0OCkgYWRkaXRpb25hbCBiaXRzIGZvciB0aGUg bm9kZSBwcmVmaXgsIHJlbmRlcmluZyA0OCs0OD05NjsgNDggaXMgc2hvcnRlciB0aGFuIDY0LCBi dXQgc2hvdWxkIGJlIGxhcmdlIGVub3VnaCBmb3IgcmFuZG9taXphdGlvbiBmb3IgcHJpdmFjeS4N Cg0KVGhhdOKAmXMgb2ZmIHBpc3RlIGZvciB0aGlzIGRyYWZ0LiBBbmQgYSBkaXNjdXNzaW9uIGFs cmVhZHkgdGhyYXNoZWQgb3V0IGluIG90aGVyIHRocmVhZHMsIGFuZCBhbHNvIGRpc2N1c3NlZCBp biBSRkM3NDIxLg0KDQpUaW0NCg0KPj4gTm8uIC82NHMgYXMgdGhlIHN1Ym5ldCBzaXplIGFzIGJl ZW4gdGhlIGNvbW1vbiBlZGdlIHN1Ym5ldC9JSUQNCj4+IGJvdW5kYXJ5IGZvciBhbG1vc3QgMjAg eWVhcnMgc2luY2UgUkZDMjM3My4NCj4gDQo+IEluIHRoaXMgSS1ELCAvNjRzIGFyZSBub3QgYXNz aWduZWQgdG8g4oCYc3VibmV0cycgYnV0IHRvIOKAmG5vZGVzJyBpbiBhIHNoYXJlZCBuZXR3b3Jr Lg0KPiANCj4gT3IgZG8geW91IG1lYW4gd2hhdCBSRkMgNDI5MWJpcyByZWFsbHkgd2FudGVkIHNh eSB3YXMgdGhlIGJvdW5kYXJ5IGZvciAnYW55IHByZWZpeCcvSUlEIGlzIGF0IDY0dGggYml0Pw0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From nobody Fri Aug 4 03:26:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F98131C3A for ; Fri, 4 Aug 2017 03:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv3IOP9I2mWh for ; Fri, 4 Aug 2017 03:26:01 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 C4BA312EACD for ; Fri, 4 Aug 2017 03:26:00 -0700 (PDT) X-AuditID: 60721c4b-733ff70000000a8e-a0-59844bb51974 Received: from VAADCEX13.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 62.16.02702.5BB44895; Fri, 4 Aug 2017 06:25:59 -0400 (EDT) Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 4 Aug 2017 06:25:56 -0400 Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1293.002; Fri, 4 Aug 2017 06:25:56 -0400 From: "Brzozowski, John" To: DY Kim , "v6ops@ietf.org" Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDMKJTXxVkDdJF0OLwYWVfJmrNaJz/pgA Date: Fri, 4 Aug 2017 10:25:56 +0000 Message-ID: <216C3622-A9B5-40BC-814A-2575EDC58B1E@cable.comcast.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <8737A9C8-F798-4503-99C7-ADBD5B220759@gmail.com> In-Reply-To: <8737A9C8-F798-4503-99C7-ADBD5B220759@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: multipart/alternative; boundary="_000_216C3622A9B540BC814A2575EDC58B1Ecablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11UfWwTZRzOe73Sa9k7bzfavjvGZBcVmTrGgmQizsVJ+JgJSzSaAgm7tWfb 7NbOu3YfkkkHMy4jKKIBbUoGy1gyBpgMCGD4iGVM2Fymf+jU6uZCzXSaOF10NuD03rvruPrP e889z+/j+f3ey1Em5rCNpfyBkCAFeJFbYiNr5K1lT1ysaneV3JwrLHvrbK+lbGToqqmC2HI5 +r1lS09Piqgmdtg2egTR3yhIa8prbL7JO6hhJgaaD6XGyAj44gPQCawUoteh2Dv9CrZRDH2R QN2JQYv2ch2gyRMjZu3lFkDdbf0WnLKEXo/Of5JQ8TK6Ai283UlgnEvvRGOpUULjd6HbyaiO S1HssxsqJumH0GTPKRVD+nkU+2FKtcHQTejk7Jckxlb6GfT36SMqBrQDzQ+fVuNNtBN9m+wi NNs06rkyZtKwHf18Z8GMsZ0uRl/N9pEa/zgaHU/qY5agCyev6XwBOvbLBKnV9KLhn0ZJzU8O uv1hUo9xohuDl8yHAIoaWkcNKVFDShRQCr8affTxGi2kEL1/YMqi4UfRm7FjOt6AInf7zcaY 44A6BQoaed7jrvcFw6GStcVuvlYUit3Bejcvh/BzAOArl/KrLoGzqc1xQFOAy4Kgot3FmPlG uaU+DuoogrPDPUP7XEx2bdDT4uNl324pLAoytwxO/7vfxcBFujYs1nEstG5W8nMX2YDQJItC SPnGuAL4Ei7kXNTksNzgd/uDYXl3WBLjAFEmpWz+NqUA9PAtrwtSUGsWB8spknPC1seUjrSX Dwl1gtAgSGm1iaI4BF/EiTmS4BWaX/WLobSs5D1pVhTaqKhmV8BsXNBhFAx+C2GkSMljjfL/ LROUNQ68VJbiO6b6lhv4etnv1Vvnwn/wkrLSrNo2D1bjUCZNGlqugP5PlRU50lJmu2HwLqDO 3701T1Bx9RzCJ0MGggGBdcLtW/GUONUXDiyOzzrgypxmF/OAQcA22Hx4OLXXxdgN/H0n7Eo4 SytZeQY100z6fzED3Mp3kwsH8UxZyt/k/vQMbMXkUp1Uh0dwl3pNOmeYPV+b3a4rmd1mlCUT ypLvvdGGlxziQ8Yln9jbhpess/qSj2KSSZMZS45iyZGWMjuxEXD14JmHv9tm5X97gZnr8Iwf Offe1LqJ0gvLDz5S+dzoj5uul5ezr7y8acKy4/OBomJx7mb2U6mqpZWt+7r6Or458FfyzNdV 1dktr0X2/M4NJDYknq24VnpuYVVN6fqEr33nn70jTwe7Fqbv9T5YDRt/peY7C/44XslvHE92 7O896s/rnu7bzpGyj19bZJJk/j9u/4wVpQUAAA== Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:26:03 -0000 --_000_216C3622A9B540BC814A2575EDC58B1Ecablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgbG9uZyBhcyB0aGUgcm91dGVyIGZhY2luZyB0aGUgZW5kIHBvaW50cyBpcyBhYmxlIHRvIHRy YW5zbWl0IGEgdW5pcXVlIHByZWZpeCBwZXIgaG9zdCBpbiB0aGUgUkEgdGhlbiBib3RoIG9mIHRo ZSBjYXNlcyBiZWxvdyB3aWxsIHdvcmsuDQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQpGcm9t OiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERZIEtpbSA8ZHlr aW02QGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBBdWd1c3QgMywgMjAxNyBhdCAyMTozOQ0K VG86IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFt2Nm9wc10gRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNy50eHQN Cg0KSW4gdGhlIDJuZCBwYXJhIG9mIFNlYy4gNCwgaXQgcmVhZHM6DQoNCiJUaGUgVW5pcXVlIElQ djYgcHJlZml4IGNhbiBiZSBkZXJpdmVkIGZyb20gYSBsb2NhbGx5IG1hbmFnZWQNCiAgIHBvb2wg b3IgYWdncmVnYXRlIElQdjYgYmxvY2sgYXNzaWduZWQgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRl cg0KICAgUm91dGVyIG9yIGZyb20gYSBjZW50cmFsbHkgYWxsb2NhdGVkIHBvb2wu4oCdDQoNCklu IHRoZSBjYXNlIHRoZSBwcmVmaXggaXMgYXNzaWduZWQgZnJvbSBhIGNlbnRyYWxseSBhbGxvY2F0 ZWQgcG9vbCwgZG9lcyB0aGlzIHNjZW5hcmlvIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjYXNlcz86 DQoNCm8gYWxsIHByZWZpeGVzIGFzc2lnbmVkIHRvIGRldmljZXMgb24gdGhlIHNhbWUgc2hhcmVk IG5ldHdvcmsgbWF5IG5vdCBiZSBhZ2dyZWdhdGFibGUgaW50byBhIHNpbmdsZSBzaG9ydGVyIHBy ZWZpeC4NCm8gLzY0IHByZWZpeGVzIG1heSBiZSBhc3NpZ25lZCByYW5kb21seSB0byBkaWZmZXJl bnQgZGV2aWNlcyBvbiBkaWZmZXJlbnQgc2hhcmUgbmV0d29yay4NCg0KLS0tDQpEWQ0KDQoNCg0K DQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dC0wNy50eHQNCkRhdGU6IDMxIEp1bHkgMjAxNyBhdCAxNjowMDo1NyBHTVQrOQ0KVG86IDxpLWQt YW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQoNCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBX RyBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFBy ZWZpeCBQZXIgSG9zdA0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4gSmFzb24gQnJ6b3pv d3NraQ0KICAgICAgICAgICAgICAgICAgICAgICAgIEd1bnRlciBWYW4gRGUgVmVsZGUNCkZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTA3LnR4dA0KUGFnZXMgICAgICAgICAgIDogOA0KRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNy0z MQ0KDQpBYnN0cmFjdDoNCiAgSW4gc29tZSBJUHY2IGVudmlyb25tZW50cywgdGhlIG5lZWQgaGFz IGFyaXNlbiBmb3IgaG9zdHMgdG8gYmUgYWJsZQ0KICB0byB1dGlsaXplIGEgdW5pcXVlIElQdjYg cHJlZml4LCBldmVuIHRob3VnaCB0aGUgbGluayBvciBtZWRpYSBtYXkgYmUNCiAgc2hhcmVkLiAg VHlwaWNhbGx5IGhvc3RzIChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29yaywgZWl0aGVy DQogIHdpcmVkIG9yIHdpcmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBXaUZpLCBldGMuLCB3aWxs IGFjcXVpcmUgdW5pcXVlDQogIElQdjYgYWRkcmVzc2VzIGZyb20gYSBjb21tb24gSVB2NiBwcmVm aXggdGhhdCBpcyBhbGxvY2F0ZWQgb3INCiAgYXNzaWduZWQgZm9yIHVzZSBvbiBhIHNwZWNpZmlj IGxpbmsuDQoNCiAgSW4gbW9zdCBkZXBsb3ltZW50cyB0b2RheSwgSVB2NiBhZGRyZXNzIGFzc2ln bm1lbnQgZnJvbSBhIHNpbmdsZSBJUHY2DQogIHByZWZpeCBvbiBhIHNoYXJlZCBuZXR3b3JrIGlz IGRvbmUgYnkgZWl0aGVyIHVzaW5nIElQdjYgc3RhdGVsZXNzDQogIGFkZHJlc3MgYXV0by1jb25m aWd1cmF0aW9uIChTTEFBQykgYW5kL29yIHN0YXRlZnVsIERIQ1B2Ni4gIFdoaWxlDQogIHRoaXMg aXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCwgdGhlcmUgYXJlIHNvbWUg bGFyZ2UNCiAgc2NhbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29uY2VwdCBpbnRyb2R1Y2Vz IHNpZ25pZmljYW50DQogIHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywg c3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2Ng0KICByb3V0ZXIgYW5kIG5laWdoYm9yIGRpc2Nv dmVyeS4NCg0KICBUaGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBl eGlzdGluZyBJUHY2IHByb3RvY29scw0KICB0byBhbGxvdyBob3N0cyB0byBiZSBhc3NpZ25lZCBh IHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhDQogIHVuaXF1ZSBJUHY2IGFkZHJlc3Mg ZnJvbSBhIHNoYXJlZCBJUHY2IHByZWZpeCkuICBCZW5lZml0cyBvZiB1bmlxdWUNCiAgSVB2NiBw cmVmaXggb3ZlciBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgc2VydmljZSBwcm92aWRl cg0KICBpbmNsdWRlIGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9uIGFuZCBlbmhhbmNlZCBz dWJzY3JpYmVyDQogIG1hbmFnZW1lbnQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC8NCg0KVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTA3DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNw0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== --_000_216C3622A9B540BC814A2575EDC58B1Ecablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5jaG8i Ow0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAg MCAwIDIgMCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93 dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5BcyBsb25nIGFzIHRoZSByb3V0ZXIg ZmFjaW5nIHRoZSBlbmQgcG9pbnRzIGlzIGFibGUgdG8gdHJhbnNtaXQgYSB1bmlxdWUgcHJlZml4 IHBlciBob3N0IGluIHRoZSBSQSB0aGVuIGJvdGggb2YgdGhlIGNhc2VzIGJlbG93IHdpbGwgd29y ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzsxLTQ4NC05NjItMDA2MDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayI+djZvcHMgJmx0O3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJl aGFsZiBvZiBEWSBLaW0gJmx0O2R5a2ltNkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlRodXJzZGF5LCBBdWd1c3QgMywgMjAxNyBhdCAyMTozOTxicj4NCjxiPlRvOiA8L2I+djZvcHMg Jmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bdjZvcHNdIEZ3ZDog SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qt MDcudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SW4g dGhlIDJuZCBwYXJhIG9mIFNlYy4gNCwgaXQgcmVhZHM6DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+JnF1b3Q7VGhlIFVuaXF1ZSBJUHY2IHByZWZpeCBjYW4gYmUgZGVy aXZlZCBmcm9tIGEgbG9jYWxseSBtYW5hZ2VkDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwO3Bv b2wgb3IgYWdncmVnYXRlIElQdjYgYmxvY2sgYXNzaWduZWQgdG8gdGhlIEZpcnN0IEhvcCBQcm92 aWRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDtSb3V0ZXIgb3IgZnJvbSBhIGNl bnRyYWxseSBhbGxvY2F0ZWQgcG9vbC7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5JbiB0aGUgY2FzZSB0aGUgcHJlZml4IGlzIGFzc2lnbmVkIGZyb20g YSBjZW50cmFsbHkgYWxsb2NhdGVkIHBvb2wsIGRvZXMgdGhpcyBzY2VuYXJpbyBpbmNsdWRlIHRo ZSBmb2xsb3dpbmcgY2FzZXM/OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPm8gYWxsIHByZWZpeGVzIGFzc2lnbmVkIHRvIGRldmljZXMgb24gdGhlIHNhbWUg c2hhcmVkIG5ldHdvcmsgbWF5IG5vdCBiZSBhZ2dyZWdhdGFibGUgaW50byBhIHNpbmdsZSBzaG9y dGVyIHByZWZpeC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5vIC82NCBwcmVmaXhlcyBtYXkgYmUgYXNz aWduZWQgcmFuZG9tbHkgdG8gZGlmZmVyZW50IGRldmljZXMgb24gZGlmZmVyZW50IHNoYXJlIG5l dHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+LS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPkRZ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1s ZWZ0Oi41aW4iPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7Ij5TdWJqZWN0OiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA3LnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 Ij5EYXRlOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDsiPjMxIEp1bHkgMjAxNyBhdCAxNjowMDo1NyBHTVQmIzQzOzk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7Ij5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmktZC1h bm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7Ij5DYzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5v cmciPnY2b3BzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi48YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaXRsZSAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvcnMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBKb2huIEphc29uIEJyem96b3dza2k8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtHdW50ZXIgVmFuIERlIFZlbGRlPGJyPg0KRmls ZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1p ZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNy50eHQ8YnI+DQpQYWdlcyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs6IDg8YnI+DQpEYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxNy0wNy0zMTxicj4NCjxicj4NCkFic3RyYWN0 Ojxicj4NCiZuYnNwOyZuYnNwO0luIHNvbWUgSVB2NiBlbnZpcm9ubWVudHMsIHRoZSBuZWVkIGhh cyBhcmlzZW4gZm9yIGhvc3RzIHRvIGJlIGFibGU8YnI+DQombmJzcDsmbmJzcDt0byB1dGlsaXpl IGEgdW5pcXVlIElQdjYgcHJlZml4LCBldmVuIHRob3VnaCB0aGUgbGluayBvciBtZWRpYSBtYXkg YmU8YnI+DQombmJzcDsmbmJzcDtzaGFyZWQuICZuYnNwO1R5cGljYWxseSBob3N0cyAoc3Vic2Ny aWJlcnMpIG9uIGEgc2hhcmVkIG5ldHdvcmssIGVpdGhlcjxicj4NCiZuYnNwOyZuYnNwO3dpcmVk IG9yIHdpcmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBXaUZpLCBldGMuLCB3aWxsIGFjcXVpcmUg dW5pcXVlPGJyPg0KJm5ic3A7Jm5ic3A7SVB2NiBhZGRyZXNzZXMgZnJvbSBhIGNvbW1vbiBJUHY2 IHByZWZpeCB0aGF0IGlzIGFsbG9jYXRlZCBvcjxicj4NCiZuYnNwOyZuYnNwO2Fzc2lnbmVkIGZv ciB1c2Ugb24gYSBzcGVjaWZpYyBsaW5rLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO0luIG1vc3Qg ZGVwbG95bWVudHMgdG9kYXksIElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IGZyb20gYSBzaW5nbGUg SVB2Njxicj4NCiZuYnNwOyZuYnNwO3ByZWZpeCBvbiBhIHNoYXJlZCBuZXR3b3JrIGlzIGRvbmUg YnkgZWl0aGVyIHVzaW5nIElQdjYgc3RhdGVsZXNzPGJyPg0KJm5ic3A7Jm5ic3A7YWRkcmVzcyBh dXRvLWNvbmZpZ3VyYXRpb24gKFNMQUFDKSBhbmQvb3Igc3RhdGVmdWwgREhDUHY2LiAmbmJzcDtX aGlsZTxicj4NCiZuYnNwOyZuYnNwO3RoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBh cyBkZXNpZ25lZCwgdGhlcmUgYXJlIHNvbWUgbGFyZ2U8YnI+DQombmJzcDsmbmJzcDtzY2FsZSBl bnZpcm9ubWVudHMgd2hlcmUgdGhpcyBjb25jZXB0IGludHJvZHVjZXMgc2lnbmlmaWNhbnQ8YnI+ DQombmJzcDsmbmJzcDtwZXJmb3JtYW5jZSBjaGFsbGVuZ2VzIGFuZCBpbXBsaWNhdGlvbnMsIHNw ZWNpZmljYWxseSByZWxhdGVkIHRvIElQdjY8YnI+DQombmJzcDsmbmJzcDtyb3V0ZXIgYW5kIG5l aWdoYm9yIGRpc2NvdmVyeS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IG91 dGxpbmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29sczxicj4N CiZuYnNwOyZuYnNwO3RvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQdjYg cHJlZml4IChpbnN0ZWFkIG9mIGE8YnI+DQombmJzcDsmbmJzcDt1bmlxdWUgSVB2NiBhZGRyZXNz IGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAmbmJzcDtCZW5lZml0cyBvZiB1bmlxdWU8YnI+ DQombmJzcDsmbmJzcDtJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9t IHRoZSBzZXJ2aWNlIHByb3ZpZGVyPGJyPg0KJm5ic3A7Jm5ic3A7aW5jbHVkZSBpbXByb3ZlZCBz dWJzY3JpYmVyIGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlcjxicj4NCiZuYnNwOyZu YnNwO21hbmFnZW1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3Bz LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC88L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0w Nzxicj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc8YnI+DQo8YnI+DQpBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4 LXBlci1ob3N0LTA3PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQp2Nm9wc0BpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_216C3622A9B540BC814A2575EDC58B1Ecablecomcastcom_-- From nobody Fri Aug 4 03:35:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD61318A0 for ; Fri, 4 Aug 2017 03:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KIi_Z6Itve_u for ; Fri, 4 Aug 2017 03:35:53 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 D8463131C6C for ; Fri, 4 Aug 2017 03:27:27 -0700 (PDT) X-AuditID: 60721c4b-719ff70000000a8e-df-59844c0eae91 Received: from VAADCEX12.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id F3.16.02702.E0C44895; Fri, 4 Aug 2017 06:27:26 -0400 (EDT) Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX12.cable.comcast.com (147.191.102.79) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 4 Aug 2017 06:27:26 -0400 Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1293.002; Fri, 4 Aug 2017 06:27:25 -0400 From: "Brzozowski, John" To: DY Kim , "v6ops@ietf.org" Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDMYKS5aM47U/l0elH2W6kOwwzKJz/vwA Date: Fri, 4 Aug 2017 10:27:25 +0000 Message-ID: <2765EBE6-EC1B-4CDE-8C56-4403807710E8@cable.comcast.com> References: <148E758F-1B18-4E8F-95AB-0E713F711684@gmail.com> In-Reply-To: <148E758F-1B18-4E8F-95AB-0E713F711684@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: multipart/alternative; boundary="_000_2765EBE6EC1B4CDE8C564403807710E8cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf0wTZxjOd9faa+XDj4O2HxWZXHRxzAGaaYjZkC1LUFwiAZKlm0s52lvb cf2RXosw5wqbBsIckummVMzYUjWTRY1jUdkPsmJAXAhbtrBkRhTsRqbJZMmCNhts9/VavO6f u/ee532f97nnLh9Dsx8YLIzbGxQCXl7kVhg0DdLO8qeyXzxgLYueKCvvOHdaV/7d6Nd0JbXj SuSmbkc0mqBqqJcNzzgE0d0sBEorGgyu+e4Bjf/CIdByafww1QYmOkEX0DMYPY1vXTyj6wIG hkWXKHy17xCtPAwDHJ+9D5SHawDfuPAlRUZWoK148NsbOlLnoUq81N2VxHPRK3gyMUEp+B48 Ho+k6s2449cOWZVhNGgdXnxoJCVEL+CHs1WkZJEP3/+tgTTr0bN46siSltQAmfCD658lRWhk xr/EP6IUzwhHv5qkldqIf7+j9BtRCZ6a/1Sj4BvxxM/x1DuW4S9OfZPCC/HJe9MaRdOJPz8d Tc5ClIPHe+OpHjMeuXpZ2wNwRLU6ohqJqEYi8hvQ6Al8fqhUaSnCR9+d0Sn1Bnyw76ROadmG R/5ap27pB8xZUNjM8w67x+ULBcs2ldj5RlEosfs8dl4KkvtFQL53oGDXZXAuURUDiAFcFgSV B6yslm+WWj0x0MRQnBHuG33bymY3+hytLl5y2QIhUZC4PDj37ztWFi7DjSGxibNAfZU8n7uM eoW9kigE5R+MK4T1RMi8zEkhye+2u30hyRYKiDGAGVqWPbhLFoAOvvUNIeBTlsXAakbDmeH+ J+WNyMkHhSZB8AuBNLuXYTgMh6vlwZyA4BRaXnOLwTQtz23RygxSM0mza2A2ETSpCZXfIthW LM9Z1PT/LVOMPgacTJbsOy/pW/LzHsntTK3OhYskpKw0mlybD2uIUzYNqlauge4xOSJTmspc dx0cA0zn8cQCxQz+fe0BxcSS11FyZTVen1ewmGEn0UZEwBXyLodgMcG1OS1WdpWKIGYsBfD9 RNjKGlX4Iz+WtXAeyVP5KjbTUvrIuAvs8t+TC7eTELLkA+VRBizcTyytTIHJCDDck/xYKUyV QIGSgDHFZG67K0dNyVH/81Y7iTrIB9VRfxxuJ1Gn0FTUxwjIpsGMqCOEMqWpzE2WNmB7/bGl fT2D9TvdR+7VrC+qzd9SP1M3ra3dXDr1alOd/vYfFQ66t2JJNzQzfMe++8ONV/roDduqh2yr xp67fXbhfO1Wx63tn8zN7J7kVoN2f133tKfRJL43ONDfG576EeWL1dT34ecXbWH9D+vf/POn 0NzYSydGZr3H+3sGim8+fnjlAqeRXPymYjog8f8BmsFAUKgFAAA= Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:35:55 -0000 --_000_2765EBE6EC1B4CDE8C564403807710E8cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbmNlcHQgaW4gdGhlIEktRCBhcHBsaWVzIHRvIGFueSBhbmQgYWxsIHR5cGVzIG9mIGxh eWVyIDMgbmV0d29ya3Mgd2hlcmUgSVB2NiBpcyBzdXBwb3J0ZWQuICBXZSBoYXZlIGRpc2N1c3Nl ZCBlbnRlcnByaXNlIGFuZCBtb2JpbGUgdXNlIGNhc2VzIHdpdGggb3RoZXIgcG90ZW50aWFsIGFk b3B0ZXJzLiAgVGhpcyBpcyBub3QgZXhjbHVzaXZlIHRvIFNQIFdpLUZpIG5ldHdvcmtzIHRoYXQg YXJlIG9wZW4gb3IgY2xvc2VkLg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KRnJvbTogdjZv cHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEWSBLaW0gPGR5a2ltNkBn bWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgQXVndXN0IDMsIDIwMTcgYXQgMjI6MDQNClRvOiB2 Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdjZvcHNdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcudHh0DQoNCklu IHJlZ2FyZHMgdG8gdGhlIHdvcmRpbmcgInByb3ZpZGVyIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmvi gJ0uDQoNCkRvZXMg4oCYcHJvdmlkZXLigJkgaGVyZSBtZWFuIGV4Y2x1c2l2ZWx5IGFueSBjb21t ZXJjaWFsIElTUHMgb3IgdGhlIGtpbmQ/IENhbiBpdCBhbHNvIGJlIGludGVycHJldGVkIGFzIOKA mHNpdGUgbWFuYWdlZCBzaGFyZWQgbmV0d29ya+KAmSB3aGVyZSBzaXRlIGNvdWxkIGJlIGFueSBB Uz8NCg0KLS0tDQpEWQ0KDQoNCg0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNClN1 YmplY3Q6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDcudHh0DQpEYXRlOiA0IEF1Z3VzdCAyMDE3IGF0IDEwOjIwOjUzIEdN VCs5DQpUbzogdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQoNCkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYg T3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IFVu aXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdA0KICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4g SmFzb24gQnJ6b3pvd3NraQ0KICAgICAgICAgICAgICAgICAgICAgICAgIEd1bnRlciBWYW4gRGUg VmVsZGUNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LTA3LnR4dA0KUGFnZXMgICAgICAgICAgIDogOA0KRGF0ZSAgICAgICAgICAg IDogMjAxNy0wNy0zMQ0KDQpBYnN0cmFjdDoNCiAgSW4gc29tZSBJUHY2IGVudmlyb25tZW50cywg dGhlIG5lZWQgaGFzIGFyaXNlbiBmb3IgaG9zdHMgdG8gYmUgYWJsZQ0KICB0byB1dGlsaXplIGEg dW5pcXVlIElQdjYgcHJlZml4LCBldmVuIHRob3VnaCB0aGUgbGluayBvciBtZWRpYSBtYXkgYmUN CiAgc2hhcmVkLiAgVHlwaWNhbGx5IGhvc3RzIChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0 d29yaywgZWl0aGVyDQogIHdpcmVkIG9yIHdpcmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBXaUZp LCBldGMuLCB3aWxsIGFjcXVpcmUgdW5pcXVlDQogIElQdjYgYWRkcmVzc2VzIGZyb20gYSBjb21t b24gSVB2NiBwcmVmaXggdGhhdCBpcyBhbGxvY2F0ZWQgb3INCiAgYXNzaWduZWQgZm9yIHVzZSBv biBhIHNwZWNpZmljIGxpbmsuDQoNCiAgSW4gbW9zdCBkZXBsb3ltZW50cyB0b2RheSwgSVB2NiBh ZGRyZXNzIGFzc2lnbm1lbnQgZnJvbSBhIHNpbmdsZSBJUHY2DQogIHByZWZpeCBvbiBhIHNoYXJl ZCBuZXR3b3JrIGlzIGRvbmUgYnkgZWl0aGVyIHVzaW5nIElQdjYgc3RhdGVsZXNzDQogIGFkZHJl c3MgYXV0by1jb25maWd1cmF0aW9uIChTTEFBQykgYW5kL29yIHN0YXRlZnVsIERIQ1B2Ni4gIFdo aWxlDQogIHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCwgdGhl cmUgYXJlIHNvbWUgbGFyZ2UNCiAgc2NhbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29uY2Vw dCBpbnRyb2R1Y2VzIHNpZ25pZmljYW50DQogIHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMgYW5kIGlt cGxpY2F0aW9ucywgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2Ng0KICByb3V0ZXIgYW5kIG5l aWdoYm9yIGRpc2NvdmVyeS4NCg0KICBUaGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNo IHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scw0KICB0byBhbGxvdyBob3N0cyB0byBi ZSBhc3NpZ25lZCBhIHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhDQogIHVuaXF1ZSBJ UHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZCBJUHY2IHByZWZpeCkuICBCZW5lZml0cyBvZiB1bmlx dWUNCiAgSVB2NiBwcmVmaXggb3ZlciBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgc2Vy dmljZSBwcm92aWRlcg0KICBpbmNsdWRlIGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9uIGFu ZCBlbmhhbmNlZCBzdWJzY3JpYmVyDQogIG1hbmFnZW1lbnQuDQoNCg0KVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dC8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LTA3DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3DQoNCkEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC0wNw0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== --_000_2765EBE6EC1B4CDE8C564403807710E8cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4F7DBCE927D22B45ABB0AA82B8F6F161@comcast.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5jaG8i Ow0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAg MCAwIDIgMCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93 dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5UaGUgY29uY2VwdCBpbiB0aGUgSS1E IGFwcGxpZXMgdG8gYW55IGFuZCBhbGwgdHlwZXMgb2YgbGF5ZXIgMyBuZXR3b3JrcyB3aGVyZSBJ UHY2IGlzIHN1cHBvcnRlZC4mbmJzcDsgV2UgaGF2ZSBkaXNjdXNzZWQgZW50ZXJwcmlzZSBhbmQg bW9iaWxlIHVzZSBjYXNlcyB3aXRoIG90aGVyIHBvdGVudGlhbCBhZG9wdGVycy4mbmJzcDsgVGhp cyBpcyBub3QgZXhjbHVzaXZlIHRvDQogU1AgV2ktRmkgbmV0d29ya3MgdGhhdCBhcmUgb3BlbiBv ciBjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MS00ODQtOTYyLTAwNjA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPnY2b3BzICZsdDt2Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgRFkgS2ltICZsdDtkeWtpbTZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5UaHVyc2RheSwgQXVndXN0IDMsIDIwMTcgYXQgMjI6MDQ8YnI+DQo8Yj5UbzogPC9i PnY2b3BzICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3Y2b3Bz XSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0LTA3LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkluIHJlZ2FyZHMgdG8gdGhlIHdvcmRpbmcgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQiPnByb3ZpZGVyIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmvigJ0uPC9zcGFuPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0Ij5Eb2VzJm5ic3A74oCYcHJvdmlkZXLigJkgaGVyZSBtZWFuIGV4Y2x1c2l2ZWx5 IGFueSBjb21tZXJjaWFsIElTUHMgb3IgdGhlIGtpbmQ/IENhbiBpdCBhbHNvIGJlIGludGVycHJl dGVkIGFzJm5ic3A74oCYc2l0ZSBtYW5hZ2VkIHNoYXJlZCBuZXR3b3Jr4oCZIHdoZXJlIHNpdGUg Y291bGQgYmUgYW55IEFTPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+LS0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6 YmxhY2siPkRZPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0Oi41aW4iPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5TdWJqZWN0OiBbdjZvcHNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3LnR4dDwv c3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EYXRlOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjQgQXVndXN0IDIwMTcg YXQgMTA6MjA6NTMgR01UJiM0Mzs5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+VG86DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 OyI+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogVW5pcXVlIElQdjYgUHJl Zml4IFBlciBIb3N0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QXV0aG9ycyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs6IEpvaG4gSmFzb24gQnJ6b3pvd3NraTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0d1bnRlciBWYW4gRGUgVmVsZGU8YnI+DQpGaWxlbmFtZSAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0LTA3LnR4dDxicj4NClBhZ2VzICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogODxicj4NCkRhdGUgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiAyMDE3LTA3LTMxPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7 SW4gc29tZSBJUHY2IGVudmlyb25tZW50cywgdGhlIG5lZWQgaGFzIGFyaXNlbiBmb3IgaG9zdHMg dG8gYmUgYWJsZTxicj4NCiZuYnNwOyZuYnNwO3RvIHV0aWxpemUgYSB1bmlxdWUgSVB2NiBwcmVm aXgsIGV2ZW4gdGhvdWdoIHRoZSBsaW5rIG9yIG1lZGlhIG1heSBiZTxicj4NCiZuYnNwOyZuYnNw O3NoYXJlZC4gJm5ic3A7VHlwaWNhbGx5IGhvc3RzIChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQg bmV0d29yaywgZWl0aGVyPGJyPg0KJm5ic3A7Jm5ic3A7d2lyZWQgb3Igd2lyZWxlc3MsIHN1Y2gg YXMgRXRoZXJuZXQsIFdpRmksIGV0Yy4sIHdpbGwgYWNxdWlyZSB1bmlxdWU8YnI+DQombmJzcDsm bmJzcDtJUHY2IGFkZHJlc3NlcyBmcm9tIGEgY29tbW9uIElQdjYgcHJlZml4IHRoYXQgaXMgYWxs b2NhdGVkIG9yPGJyPg0KJm5ic3A7Jm5ic3A7YXNzaWduZWQgZm9yIHVzZSBvbiBhIHNwZWNpZmlj IGxpbmsuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7SW4gbW9zdCBkZXBsb3ltZW50cyB0b2RheSwg SVB2NiBhZGRyZXNzIGFzc2lnbm1lbnQgZnJvbSBhIHNpbmdsZSBJUHY2PGJyPg0KJm5ic3A7Jm5i c3A7cHJlZml4IG9uIGEgc2hhcmVkIG5ldHdvcmsgaXMgZG9uZSBieSBlaXRoZXIgdXNpbmcgSVB2 NiBzdGF0ZWxlc3M8YnI+DQombmJzcDsmbmJzcDthZGRyZXNzIGF1dG8tY29uZmlndXJhdGlvbiAo U0xBQUMpIGFuZC9vciBzdGF0ZWZ1bCBESENQdjYuICZuYnNwO1doaWxlPGJyPg0KJm5ic3A7Jm5i c3A7dGhpcyBpcyBzdGlsbCB2aWFibGUgYW5kIG9wZXJhdGVzIGFzIGRlc2lnbmVkLCB0aGVyZSBh cmUgc29tZSBsYXJnZTxicj4NCiZuYnNwOyZuYnNwO3NjYWxlIGVudmlyb25tZW50cyB3aGVyZSB0 aGlzIGNvbmNlcHQgaW50cm9kdWNlcyBzaWduaWZpY2FudDxicj4NCiZuYnNwOyZuYnNwO3BlcmZv cm1hbmNlIGNoYWxsZW5nZXMgYW5kIGltcGxpY2F0aW9ucywgc3BlY2lmaWNhbGx5IHJlbGF0ZWQg dG8gSVB2Njxicj4NCiZuYnNwOyZuYnNwO3JvdXRlciBhbmQgbmVpZ2hib3IgZGlzY292ZXJ5Ljxi cj4NCjxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2gg dXRpbGlzaW5nIGV4aXN0aW5nIElQdjYgcHJvdG9jb2xzPGJyPg0KJm5ic3A7Jm5ic3A7dG8gYWxs b3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXggKGluc3RlYWQgb2Yg YTxicj4NCiZuYnNwOyZuYnNwO3VuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSBhIHNoYXJlZCBJUHY2 IHByZWZpeCkuICZuYnNwO0JlbmVmaXRzIG9mIHVuaXF1ZTxicj4NCiZuYnNwOyZuYnNwO0lQdjYg cHJlZml4IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlk ZXI8YnI+DQombmJzcDsmbmJzcDtpbmNsdWRlIGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9u IGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyPGJyPg0KJm5ic3A7Jm5ic3A7bWFuYWdlbWVudC48YnI+ DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4 LXBlci1ob3N0LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6PGJyPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3PGJyPg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdC0wNzxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc8YnI+DQo8 YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+ DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1h aWxpbmcgbGlzdDxicj4NCnY2b3BzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_2765EBE6EC1B4CDE8C564403807710E8cablecomcastcom_-- From nobody Fri Aug 4 03:45:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB40132014 for ; Fri, 4 Aug 2017 03:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8JtwYinW80h for ; Fri, 4 Aug 2017 03:45:23 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E341D131D0E for ; Fri, 4 Aug 2017 03:45:22 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k43so5431192uaf.3 for ; Fri, 04 Aug 2017 03:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sf8Walj0cf8Z2nzHGN3R5iPnEdQ3ASvnhn7q8V7cRUA=; b=rd6G/qoyOeZ0rVeRHpRyJubvGvp4uhuLvY7AjS0T+UB9+czi0LOu1eIPWYsm/4lhgq 7dKjBU0EdQhS4YbDm1fdzbzCmx1P0f7cspeck/mKOkw8MyTR5ukb+W9yLW2eIlJZkh9E zzZ2Ro8M+G1sM/CAckNwo6PHiHrHT6zSQX7Suo4xmOpxNx1fHTDvIp1bStTwJienb3x/ 3lkNwHmMBI8YnEQHYiMV/0X9QNJMcFrp5cj/nzEgSrjl97IBFobg4+BbuLpj6/bL+s/S WnctXhkX9KXTvMiO6mAHAi5OBKofAA/SftAbHsUKqmX8lDHBo8kW3YyhPU/LkmGZNavF fiRA== 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=sf8Walj0cf8Z2nzHGN3R5iPnEdQ3ASvnhn7q8V7cRUA=; b=FjFzLQ48kD3ZIO9hi9+AHrTn8RbkaJf/s0r/RAceoEAp3WK0TQYzvMVwi7V+7BjgVS 8xiCvrHrdBXER9fm8Jd2Ggr0ceGRcgF+B9e/qfPfYw/imaFuKUNdy5lXuKU6hcizu6uk auucjTdq9i0Ce8x9758+Y2moMN8Cv52dzh00qhOr9xvnZ1ww5va0VRdVbDfzcDE3dLJL tvcwSftwvTj+moW7wXBEvFZUyd6pQ8WY9Nv0i+TlC0/2T7P/lePn3i5MGK7bIXJ78N9q 5yBegWzspzoVmPhpdLxpn9+TK/BcrstQ/sLdEJqLXWeaX37b2jSKuD8zstlKoHqGqwqN g2EQ== X-Gm-Message-State: AHYfb5iIaJ0EMhABi3faWkF2EsvytFhHBQhmfKw50kJwAVBKSrxVFKil FLd0vKLsCTgmt83mE1xOShWLYXs54w== X-Received: by 10.176.86.87 with SMTP id z23mr1356035uaa.170.1501843522029; Fri, 04 Aug 2017 03:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 03:45:21 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 03:45:21 -0700 (PDT) In-Reply-To: <801ACC98-2A54-40CF-B6F5-7B36CEC99CDA@jisc.ac.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <6950ACA0-CAB9-4890-ABE3-0ECA84C58251@gmail.com> <801ACC98-2A54-40CF-B6F5-7B36CEC99CDA@jisc.ac.uk> From: Mark Smith Date: Fri, 4 Aug 2017 20:45:21 +1000 Message-ID: To: Tim Chown Cc: DY Kim , v6ops list Content-Type: multipart/alternative; boundary="f403045df280a38bf10555eb3165" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:45:24 -0000 --f403045df280a38bf10555eb3165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 4 Aug. 2017 8:03 pm, "Tim Chown" wrote: > On 4 Aug 2017, at 09:42, DY Kim wrote: > >> On 4 Aug 2017, at 17:18, Mark Smith wrote: >> >> Why specifically might you like to assign /96s? What benefit do you get? > > Now that a device (can I say =E2=80=98node=E2=80=99?) trackable by its (/= 64) unique prefix, the privacy of the node might be compromised. > > To combat this, you might want to regularly randomize/refresh the prefix for a given node to secure privacy from eavesdroppers, except that the privacy is not secured to the entity distributing the prefixes. That would be a reasonable issue to discuss in the security considerations of draft-ietf-v6ops-unique-ipv6-prefix-per-host. I think Fred Baker wrote a draft a while back that suggested randomising subnets with a site level /48 to mitigate that, so a reference to that could be useful. Relatedly, I've thought that those using /127s should be randomising some or all of the bits between /127 and the likely single /64 they're assigning the /127s out of. Regards, Mark. > For enough randomization in that case, I might like to have enough (say 48) additional bits for the node prefix, rendering 48+48=3D96; 48 is shorte= r than 64, but should be large enough for randomization for privacy. That=E2=80=99s off piste for this draft. And a discussion already thrashed = out in other threads, and also discussed in RFC7421. Tim >> No. /64s as the subnet size as been the common edge subnet/IID >> boundary for almost 20 years since RFC2373. > > In this I-D, /64s are not assigned to =E2=80=98subnets' but to =E2=80=98n= odes' in a shared network. > > Or do you mean what RFC 4291bis really wanted say was the boundary for 'any prefix'/IID is at 64th bit? > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --f403045df280a38bf10555eb3165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 4 Aug. 2017 8:03 pm, "Tim Chown" <Tim.Chown@jisc.ac.uk> wrote:
> On 4 Aug= 2017, at 09:42, DY Kim <dykim6@gmai= l.com> wrote:
>
>> On 4 Aug 2017, at 17:18, Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>> Why specifically might you like to assign /96s? What benefit do yo= u get?
>
> Now that a device (can I say =E2=80=98node=E2=80=99?) trackable by its= (/64) unique prefix, the privacy of the node might be compromised.
>
> To combat this, you might want to regularly randomize/refresh the pref= ix for a given node to secure privacy from eavesdroppers, except that the p= rivacy is not secured to the entity distributing the prefixes.

That would be a reasonable issue to discuss in the security considera= tions of draft-ietf-v6ops-unique-ipv6-prefix-per-host.

I think Fr= ed Baker wrote a draft a while back =C2=A0that suggested randomising subnet= s with a site level /48 to mitigate that, so a reference to that could be u= seful.

Relatedly, I'= ve thought that those using /127s should be randomising some or all of the = bits between /127 and the likely single /64 they're assigning the /127s= out of.

Regards,
<= div dir=3D"auto">Mark.

<= br>

> For enough randomization in that case, I might like to have enough (sa= y 48) additional bits for the node prefix, rendering 48+48=3D96; 48 is shor= ter than 64, but should be large enough for randomization for privacy.

That=E2=80=99s off piste for this draft. And a discussion already thr= ashed out in other threads, and also discussed in RFC7421.

Tim

>> No. /64s as the subnet size as been the common edge subnet/IID
>> boundary for almost 20 years since RFC2373.
>
> In this I-D, /64s are not assigned to =E2=80=98subnets' but to =E2= =80=98nodes' in a shared network.
>
> Or do you mean what RFC 4291bis really wanted say was the boundary for= 'any prefix'/IID is at 64th bit?
>
>
> ________________________________= _______________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops=


--f403045df280a38bf10555eb3165-- From nobody Fri Aug 4 03:49:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B38131FC6 for ; Fri, 4 Aug 2017 03:49:36 -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 SRjJFR6X1gQV for ; Fri, 4 Aug 2017 03:49:36 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1403131CFE for ; Fri, 4 Aug 2017 03:49:35 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so1484074pgd.1 for ; Fri, 04 Aug 2017 03:49:35 -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=kSbaC3FclqMBEXwCfiuRn55HACdTlAoclqiPgfUAeLE=; b=JVZhzE/WW8FidMJquHUqgIZfawQPGpZbuopcpFR9aquq0roPp5A8pI05v5wisWdnpA a+hQEqZ6sJbtki72VNrrB2xRnb4gREB2s8Ofs1p2ES8cWuGo3/YzmDLkfbLFDuYKCebJ tXnLPLHXvMYdGdq7JqSub+N4/cg61vd/rHZYSRpD4ZTW4NAuJWF5yF39EQg4nIBEsTaG 0FVJIsjxBtuMLZIGO9rUFF2YC3U3ot/rJDRPpCuMO0gGnQh51tjzT+pdFsC10eeUMB+n dQU6R9qr5BmXi7mjc1oiOOqmvCoPyt0OsAv/IC1hW/Uju/RKRcR5oEg4mbOwAY97pR4+ EFww== 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=kSbaC3FclqMBEXwCfiuRn55HACdTlAoclqiPgfUAeLE=; b=JlX9pRKpi+4x29dfOsEtYYhIEmL6wvX2xd74KaS3U1Pg69drNXKs8Mf9YatJNnU/RI MDpIffUz7Vm+FyzWmv9W/uHcfHpfxooackwLUz/43z7rcmwNMA7Pan0T8/hMPlfP5VSJ l5HYJA6ufQn3vtXXpjaaixY5Pc87nrCWDSF7IkVaND1P9voScrHQJnlVDYAH7x5vCiPi PwmUiKze7NptovaATJWpfkaP4mNkaeiLkeTfi6Iq2aSN3w2jgv1uyzo1sgRJi09v3tnK dxv6IH29SOWKEVX4708obzeTotM/Iswrgye039WmWhrxV/1+BzXFHalhiHHMtI9tQuz0 4Efw== X-Gm-Message-State: AIVw113zbANmhlbBIDlz4u9M5nJ65Y2SIUQDffj6fp6UtGuSsq9W+qZt FObpobvPPoZrPQ== X-Received: by 10.84.217.78 with SMTP id e14mr2276525plj.394.1501843775423; Fri, 04 Aug 2017 03:49:35 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id d86sm2588999pfk.43.2017.08.04.03.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 03:49:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <801ACC98-2A54-40CF-B6F5-7B36CEC99CDA@jisc.ac.uk> Date: Fri, 4 Aug 2017 19:49:32 +0900 Cc: Mark Smith , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <7FA8C6A0-9410-408F-9AC9-B3FB9C3D6B38@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <6950ACA0-CAB9-4890-ABE3-0ECA84C58251@gmail.com> <801ACC98-2A54-40CF-B6F5-7B36CEC99CDA@jisc.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:49:37 -0000 OK. -------- Regards, DY > On 4 Aug 2017, at 19:03, Tim Chown wrote: >=20 >>=20 >> For enough randomization in that case, I might like to have enough = (say 48) additional bits for the node prefix, rendering 48+48=3D96; 48 = is shorter than 64, but should be large enough for randomization for = privacy. >=20 > That=E2=80=99s off piste for this draft. And a discussion already = thrashed out in other threads, and also discussed in RFC7421. From nobody Fri Aug 4 03:51:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298B5131B3F for ; Fri, 4 Aug 2017 03:51:42 -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 nklycKz1daZZ for ; Fri, 4 Aug 2017 03:51:41 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EA3131CE8 for ; Fri, 4 Aug 2017 03:51:41 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v189so6608521pgd.2 for ; Fri, 04 Aug 2017 03:51:40 -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=UKk+CfTiIgoMDoXghTQmm2luUFZwsnvBJSOwGEu1K90=; b=Ka+WptaK0B1zqbzdvDWd5IWotjzfl/iakWkJkfZKO0c0rQMssrjpqBtzacbtHDsdfK vAAOFvnLHs+GGGey3BNsSm/dItOV1FoUizNT3w1hwVXQegZWX1D/MDAiPR9OO++W63ul WJAgdOgBmxoOuKQAEdl2LzdgA0MuXdd2leZL8u9cFw8ixBLXTAYMTF74eMJXGJvGsAab GR3lPFcqbDd+xojFQPA4C4TFpEC4Kkkkx9Xi5Bsm2h6wQhhmWaKSFuaxzXfDUvF6gRKF G3lQISnahdxfk12xYW4mDgiYu+dAMM+MpP1Nd0HoKmIvEEIvpcw1X8zh2UDME3bNJGl1 UnUQ== 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=UKk+CfTiIgoMDoXghTQmm2luUFZwsnvBJSOwGEu1K90=; b=Q2+Uo5camaxuQH39MyleVL2aYL65uKTA9q95BtxtbIftt8Qj7X+7IApx6Y9/9DEslS x+qy4aWHBuNCv3dUTw9Fv2EcHZFGVSLS+zjpSalQl3k/y9EMU2qdiFzA435xPnuz6b2H XLn/Tuv1yydZRivoK85hh3/zs6U5mJEqSyxtGmnKRi+uX84dW69ptwOiLxqC1ea8UXEk L9d1apVdPJ3zvpFmuT89pIW6d1PJEQ+Qa1lfYs8rEm8v+spJApJVsWS1x8WmaHpfsM4z 8Ojw63m/rres+Aqts/JMBZYmdg8cQubJm8qo20xbLnmTr+Yiws/yD+Xah9WBKzWLWLMV JADA== X-Gm-Message-State: AIVw113SjVxwT4hT6jwv38nHeYzbZ05dcgtAN/pu5L2MvZoAhp8ikqyF cyEPtWGBdIyVmHcopM8= X-Received: by 10.84.232.7 with SMTP id h7mr2231718plk.360.1501843900565; Fri, 04 Aug 2017 03:51:40 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id d86sm2604871pfk.43.2017.08.04.03.51.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 03:51:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <216C3622-A9B5-40BC-814A-2575EDC58B1E@cable.comcast.com> Date: Fri, 4 Aug 2017 19:51:37 +0900 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <169B45EE-358F-4875-8953-F7EF7BA86DF7@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <8737A9C8-F798-4503-99C7-ADBD5B220759@gmail.com> <216C3622-A9B5-40BC-814A-2575EDC58B1E@cable.comcast.com> To: "Brzozowski, John" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:51:42 -0000 Thanks. -------- Regards, DY > On 4 Aug 2017, at 19:25, Brzozowski, John = wrote: >=20 > As long as the router facing the end points is able to transmit a = unique prefix per host in the RA then both of the cases below will work. > =20 > John > +1-484-962-0060 > =20 > From: v6ops on behalf of DY Kim = > Date: Thursday, August 3, 2017 at 21:39 > To: v6ops > Subject: [v6ops] Fwd: I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt > =20 > In the 2nd para of Sec. 4, it reads: > =20 > "The Unique IPv6 prefix can be derived from a locally managed > pool or aggregate IPv6 block assigned to the First Hop Provider > Router or from a centrally allocated pool.=E2=80=9D > =20 > In the case the prefix is assigned from a centrally allocated pool, = does this scenario include the following cases?: > =20 > o all prefixes assigned to devices on the same shared network may not = be aggregatable into a single shorter prefix. > o /64 prefixes may be assigned randomly to different devices on = different share network. > =20 > --- > DY From nobody Fri Aug 4 04:30:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7463A126CC4 for ; Fri, 4 Aug 2017 04:30:47 -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 O4Aw9L1aE3cQ for ; Fri, 4 Aug 2017 04:30:46 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4218513206D for ; Fri, 4 Aug 2017 04:30:46 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id v189so6967127pgd.2 for ; Fri, 04 Aug 2017 04:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=OAMQWMBPBp30fVpsH78CU1Q1aoKs382EpS2DVTw2GsM=; b=ssDdKQrFy52loTHCpo4WMP9x0ZXCmTpxoLftcQv4mYbqXBMHrowluUwSq/gRY8IhZ6 gs1m8Tdlaqz3eh6meq/fwgAMptgfenBvYNlOMk2cbKygMOMU7Ni/09LH8bSdB8sLTCF5 0h5JuSYLjyz3fjXhb6VzgOx5MQxx3UHPRYUxlCOnsaeMtGdq+T66S1clFCawN73OrmRR QgMhUE6ap+TkvrpmmxxRpUi07Ok1yPd0efq+adN0im2CmPP4yvXIsOwdbIPEoMt0pq1b CXq/dmCMY2ifcEX3d4ZNqjU14gb7FVCZsjbVko+uvoDnwcwpCIC96cQnNcSbgNHi57NT SJuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=OAMQWMBPBp30fVpsH78CU1Q1aoKs382EpS2DVTw2GsM=; b=G/Oef3HW8fpECiqSkRBURrqghubBrMi0ZpEWTbecvuVZN2F2Eer74rSR3UQW8jfFr8 yTUsY74VdyxjzSW6OnyMTh0lb+p+cKxe91r3ESCxJHZrTjegDTmb654KdGdXDayppdq1 XZPQ3A3fRFe+L5V071Dm7t+Gt5ZuMT29WZmcwFKqFIwJC4Wp/xO1FYZwUoagJmd6/k00 ukP3qmt6ss7vQVo7eqDvCPWAdFGlbpCCAcw9zfT/O0pbXCjt8VraBhceyxKJQnJplzqf 7lj+yXlEfTO7QBKfgPDQLx9jSOyxbkT5Cs/Zh5l88jG84RE9HfQIl975pWK14PZpohDQ ef6Q== X-Gm-Message-State: AIVw112BFCCc9yH8za9eTuGwmnSvyKIGvzPwxgQF6FcmALgQEqD0WKs9 OU/XwUXO/YZ2Ul6xUM0= X-Received: by 10.98.149.132 with SMTP id c4mr2119321pfk.134.1501846245409; Fri, 04 Aug 2017 04:30:45 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id y3sm2804852pff.47.2017.08.04.04.30.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 04:30:43 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 Aug 2017 20:30:41 +0900 References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> To: v6ops list In-Reply-To: Message-Id: <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 11:30:47 -0000 Based on a conversation with John Brzozowski in the thread on =E2=80=98uni= que ipv6 prefix per host=E2=80=99, I=E2=80=99d say most of SID6 is = pursuing could be achieved by appropriate application of that draft to a = site of interest: o Every intra-site node would be assigned a /64 prefix from a central = prefix pool installed somewhere (preferably at the site border router) = in the site. o With the use of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07=E2=80= =99, there=E2=80=99d be no need for ND and DAD, and hence no changes to = previous protocols are necessary. o All that remains is that the IGP now deals with host prefix routes = throughout. o In that fashion, intra-site node mobility is provided inherently by = the IGP. o Behaviors of the site exposed to DFZ remain the same as with usual = legacy sites, so such a site can be deployed incrementally, not = disturbing the DFZ. I=E2=80=99m happy with = 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07=E2=80=99. -------- Regards, DY < quote begins > On 4 Aug 2017, at 19:25, Brzozowski, John = wrote: As long as the router facing the end points is able to transmit a unique = prefix per host in the RA then both of the cases below will work. John +1-484-962-0060 From: v6ops on behalf of DY Kim = Date: Thursday, August 3, 2017 at 21:39 To: v6ops Subject: [v6ops] Fwd: I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt In the 2nd para of Sec. 4, it reads: "The Unique IPv6 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the First Hop Provider Router or from a centrally allocated pool.=E2=80=9D In the case the prefix is assigned from a centrally allocated pool, does = this scenario include the following cases?: o all prefixes assigned to devices on the same shared network may not be = aggregatable into a single shorter prefix. o /64 prefixes may be assigned randomly to different devices on = different share network. =E2=80=94 DY < quote ends > From nobody Fri Aug 4 06:04:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37A131EA0 for ; Fri, 4 Aug 2017 06:04:31 -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 Qkx0lzTOvQCr for ; Fri, 4 Aug 2017 06:04:30 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303E4131EBB for ; Fri, 4 Aug 2017 06:04:30 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id l64so7806725pge.5 for ; Fri, 04 Aug 2017 06:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=WGzt2yfqZN74VaVPQClQNXrl1WJf+TdsfBuhqOCscuc=; b=P53B09BaxDrgM8sk3s/QLJwnw3qcJtELaxcliHrIS2iL8kx3rHrE7qT8oDXLXqxpl1 w1/tC+1jAKPv5olG6zcGv3+GnmP4vgkqiyPbe2kI332wBZY5kbRaPMmNvFftktzskFWK Z3Nzafir2qtdzc8he537mq2HCOoMjiCzgSOb5Oa5K4AZHBBeqjcAEqSkt0T4Bjl4e8s+ vMSth3ejCgOhXWvFSY7kPyE+EJq4Y1pGqTDmPFxdXFpST1D7tkZbM4bwpxGSbWXRkJxV PEJTPvPXXvvN8JFp52U7hsw22K6zlueyGRmZvIcs7q7Rgl3rbxQCmRhBMqD2Uxx2yE3q 1bEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=WGzt2yfqZN74VaVPQClQNXrl1WJf+TdsfBuhqOCscuc=; b=Jyz0agZrKd7nrozAECoMsV580nU3gp2ytEKRWcAlo5PTn1mssr1xs+t++uZIG07pfa fAnWgeIqFG3WTDBR9RuyR49hBpoPcIaGiEKtEnPspI2KIOZltQbjO06mnLRLLbZpw+nh G2t/wS82+FM/z32ia1z1bFlRRzn3ySk/StsmNKS29vkWj/qK2AGldUQHYlYe5UmxjeTp Wxrw/Gppko7dw8Dd6DPvDWaNzB12hDIxm2kSrACeS5p8kvhXwW4N2GryyB4QGi7SfYzH U7DIfeHEerM88nPnGKfdF5USeCvTehGPuM38JP2Z8T61oF5oFoWQ0U6UJ6a15OroKiUO Ll2Q== X-Gm-Message-State: AIVw111DYVOF5XQNaAkHEYNhSIZL2ouRRwZUViyTLxXMfX3dSibF8D6Q ZmTtlI4FiX8tzex4OJs= X-Received: by 10.99.178.72 with SMTP id t8mr2332145pgo.34.1501851869238; Fri, 04 Aug 2017 06:04:29 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id d86sm3164386pfk.43.2017.08.04.06.04.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 06:04:28 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 4 Aug 2017 22:04:26 +0900 References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> To: v6ops list In-Reply-To: <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:04:31 -0000 The unique prefix per host is /64. Hence, when a site is assigned a /48 = prefix as usual, as many as 64K (2**16) nodes can be accommodated, which = number being not terribly huge but large enough for most application = cases, I=E2=80=99d think. -------- Regards, DY > On 4 Aug 2017, at 20:30, DY Kim wrote: >=20 > Based on a conversation with John Brzozowski in the thread on = =E2=80=98unique ipv6 prefix per host=E2=80=99, I=E2=80=99d say most of = SID6 is pursuing could be achieved by appropriate application of that = draft to a site of interest: >=20 > o Every intra-site node would be assigned a /64 prefix from a central = prefix pool installed somewhere (preferably at the site border router) = in the site. >=20 > o With the use of = 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07=E2=80=99, there=E2=80=99d= be no need for ND and DAD, and hence no changes to previous protocols = are necessary. >=20 > o All that remains is that the IGP now deals with host prefix routes = throughout. >=20 > o In that fashion, intra-site node mobility is provided inherently by = the IGP. >=20 > o Behaviors of the site exposed to DFZ remain the same as with usual = legacy sites, so such a site can be deployed incrementally, not = disturbing the DFZ. >=20 > I=E2=80=99m happy with = 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07=E2=80=99. >=20 > -------- > Regards, > DY >=20 > < quote begins > >=20 > On 4 Aug 2017, at 19:25, Brzozowski, John = wrote: >=20 > As long as the router facing the end points is able to transmit a = unique prefix per host in the RA then both of the cases below will work. >=20 > John > +1-484-962-0060 >=20 > From: v6ops on behalf of DY Kim = > Date: Thursday, August 3, 2017 at 21:39 > To: v6ops > Subject: [v6ops] Fwd: I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt >=20 > In the 2nd para of Sec. 4, it reads: >=20 > "The Unique IPv6 prefix can be derived from a locally managed > pool or aggregate IPv6 block assigned to the First Hop Provider > Router or from a centrally allocated pool.=E2=80=9D >=20 > In the case the prefix is assigned from a centrally allocated pool, = does this scenario include the following cases?: >=20 > o all prefixes assigned to devices on the same shared network may not = be aggregatable into a single shorter prefix. > o /64 prefixes may be assigned randomly to different devices on = different share network. >=20 > =E2=80=94 > DY >=20 > < quote ends > >=20 From nobody Fri Aug 4 06:58:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397F131FD3 for ; Fri, 4 Aug 2017 06:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIkBavrD0MWD for ; Fri, 4 Aug 2017 06:58:50 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA42131F6A for ; Fri, 4 Aug 2017 06:58:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id E23FC92E for ; Fri, 4 Aug 2017 13:58:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS1LofxwGtKs for ; Fri, 4 Aug 2017 08:58:48 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id ACF5BB73 for ; Fri, 4 Aug 2017 08:58:48 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id a123so6666485vkc.11 for ; Fri, 04 Aug 2017 06:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w+PNU1OT/eWxvsOzbQXK4XnOzYTi3ly4Nzk4IkceWWc=; b=IppebFPoy432tKqEP15mFNyToyMqdA/gc5h3DoJt8W01Qqzaz2zQbykl1rw1FMKGPq ENljvx+HQbb/k24BpKr7rBLer64zjmz6gD3XFjlIk2wWHyKNe2JxlGUNaaM+qPX3tXru dpMUpClQXkxjMHqLSVEkBNl75qWmCvpAZOs0FKjuV7235SBbCUuiFbdzOY6gi1bo6s5+ EUo4iXpYNRgzFrZyaTNl5/QmNaA0FLxWYL3Ui05928luNt8jLAJxOIbjGjIDI6gPYXr/ YLMzYmVqN7z8vY2XMDpAOlrDUZ8plfclOQzAwZLo3h47Yw2gpAgZozFSJwICEqRTDidn 1xqg== 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=w+PNU1OT/eWxvsOzbQXK4XnOzYTi3ly4Nzk4IkceWWc=; b=JkNsMN9qBFjUsHWnnxdnmER/gVASYzuf/1lLHOkLUdBB5WZpuHqb645ATTMQ1DUxQ4 KimAoMAxeoSEZGNiUnNu+tGWN3b/12IVpeR41MDe08hdFGHgNwua5NjARu61OfhgxE8f pZSDAV9djXOeftsQa+Obqzu+ucgrZMTJ1Y5VwFjeVhFHqqBMuCVf4aw3VzSiApokmFJi jg9J8ZvAO3F8YoNGA7NOr/Mu6vq75VeC6D9G4Im6lZypBElYwdJ35osrBJMLhqd2D3im 7dky/7zplwlnwwCp7whSqoFEMZ2KeYMIqjguQud7fd91ep6aDyNJRMdOZwyAHQpcZxxH gOuw== X-Gm-Message-State: AHYfb5jXtYPzayweUROfDaqc/M5wiqsVqeJHJOiViAyLpaHyMwxeRXDc scUoenX7yjRCZM+S12wxBwIaZ95yrvwmohyzjrVI7XhRo77X4tkjd+UKA+w+1G9ht1o5zgjUoDJ /wZ9ZyZkH1M8VxH/Y X-Received: by 10.159.33.211 with SMTP id 77mr1476871uac.218.1501855128168; Fri, 04 Aug 2017 06:58:48 -0700 (PDT) X-Received: by 10.159.33.211 with SMTP id 77mr1476860uac.218.1501855127979; Fri, 04 Aug 2017 06:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Fri, 4 Aug 2017 06:58:47 -0700 (PDT) In-Reply-To: <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> From: David Farmer Date: Fri, 4 Aug 2017 08:58:47 -0500 Message-ID: To: DY Kim Cc: Mikael Abrahamsson , v6ops list Content-Type: multipart/alternative; boundary="001a1135526068689a0555ede52a" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:58:53 -0000 --001a1135526068689a0555ede52a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't see how whole subnet or prefix assigned to just a single host is incompatible with with RFC4291 or RFC4291bis in any way. That said there was some discussion of adding a reference to RFC7934 - Host Address Availability Recommendations, which introduces the concept of assigning a whole /64 to an individual host. I think its still think that is a good idea, and maybe adding a reference to this would be a good idea too. It does represent a bit of an evolution in the subnet model. But, again I don't see how it is incompatible with ether RFC4291 or RFC4291bis On Fri, Aug 4, 2017 at 3:56 AM, DY Kim wrote: > OK, I=E2=80=99ll try again. > > o No concept of =E2=80=98node prefix=E2=80=99 is mentioned in 4291bis. > > o 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 talks about = =E2=80=98node > prefix=E2=80=99. > > Although 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 is not me= ant to > change the standard 4291bis, isn=E2=80=99t that in conflict with 4291bis = in that > the draft uses a notion not defined in the parent standard. > > -------- > Regards, > DY > > > > > > > > > > On 4 Aug 2017, at 17:52, Mikael Abrahamsson wrote: > > > > On Fri, 4 Aug 2017, DY Kim wrote: > > > >> All mentioned in 4291bis is the subnet prefix, not the node prefix. > > > > It's impossible for me to follow your comments when you're changing wha= t > document you're talking about all the time. > > > > draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose any change > in standards. Agreed? > > > > So your above comment, what is that about? How does it relate to > draft-ietf-v6ops-unique-ipv6-prefix-per-host ? > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=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 --001a1135526068689a0555ede52a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see how whole subnet or prefix assigned to jus= t a single host is incompatible with with RFC4291 or RFC4291bis in any way.=

That said there was some discussion of adding a referen= ce to RFC7934 -=C2=A0Host Address Availability Recommendations, which intro= duces the concept of assigning a whole /64 to an individual host.=C2=A0 I t= hink its still think that is a good idea, and maybe adding a reference to t= his would be a good idea too. It does represent a bit of an evolution in th= e subnet model.

But, again I don't see how it = is incompatible with ether RFC4291 or RFC4291bis

On Fri, Aug 4, 2017 at 3:56 AM, DY Kim= <dykim6@gmail.com> wrote:
= OK, I=E2=80=99ll try again.

=C2=A0 o No concept of =E2=80=98node prefix=E2=80=99 is mentioned in 4291bi= s.

=C2=A0 o 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 ta= lks about =E2=80=98node prefix=E2=80=99.

Although 'draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 is= not meant to change the standard 4291bis, isn=E2=80=99t that in conflict w= ith 4291bis in that the draft uses a notion not defined in the parent stand= ard.

--------
Regards,
DY








> On 4 Aug 2017, at 17:52, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> On Fri, 4 Aug 2017, DY Kim wrote:
>
>> All mentioned in 4291bis is the subnet prefix, not the node prefix= .
>
> It's impossible for me to follow your comments when you're cha= nging what document you're talking about all the time.
>
> draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose = any change in standards. Agreed?
>
> So your above comment, what is that about? How does it relate to draft= -ietf-v6ops-unique-ipv6-prefix-per-host ?
>
> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
--001a1135526068689a0555ede52a-- From nobody Fri Aug 4 07:01:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B03131F5C for ; Fri, 4 Aug 2017 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=truman-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 0TWdxAkgcpaO for ; Fri, 4 Aug 2017 07:01:53 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99978131EF8 for ; Fri, 4 Aug 2017 07:01:53 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l82so10362971ywc.2 for ; Fri, 04 Aug 2017 07:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=truman-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kow4tJ7ey6YP7GNHaGklwYw6PsO4QRVapsya+kJWB7Q=; b=IOGLu48J0IVq/CDjGab7NIorwbgqs2SrNrLbmh3PFOVlLOJIvk7odUj7GgruvA3RHy gE24178gPiY4aZiyfdX0nzHfX3cDvxxKGa2ZnSf3uR5FsnHvuexKgUzZCYq7mQuroV/t 5DyJWcEmSRaMiQ3JjEDOSlh1vsRRP89NTRztzLblb/z7AhUlLge9qm5vakQKvDz/wOeC 2Lb6eyJW3qC8JDyJ0xNeUBmrLqWk7eyDB3vC1kpo5vZO7gEs944gtYSOIqOgiNkJh5gt 3nN+xBrWDClvqOZgYe0HYHDjuSeuxbtFv1fg/Z3f+fklLPMLl0zARRkkKvYMtCY1is7+ s9dg== 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=kow4tJ7ey6YP7GNHaGklwYw6PsO4QRVapsya+kJWB7Q=; b=oe8Bt4fgvNNquyCYSoAA+K5Tzf8i3QqH0cyYQTdPSN6q63pKSbuGPsAEl172cmxczj OaSXR4Oxag7qiwdnmCQ0P0YYVmbGmApcPoe0biznK293+4zNJ7a0rZwFhYpZd846dNx4 hIMzRrSM+dPOK4s9paBw23OtF18maOkut7d3IUGY+YLd0HJHjw0B1mnExLOwI2Wb6kyY /a3p6bHjTsQUSV6Zsfi22T/6NR49y9/h0rMu1K72goPJ2rNRT6slD6GjFAhPI4xUbT27 nQa6qatElZFWW5z5nrn9aKqMmZrWIP2jata80DpS3kqXYIu8gJK81UcfSopdZP4hOqeW Xe4g== X-Gm-Message-State: AIVw110uqVy7PZz7lJgULuhfLCYVK8VX30VugqrqTmYiNoPmlwzvwES+ zOkeb/siZojMgic08cSjN6WFxLmU71B/ X-Received: by 10.129.153.144 with SMTP id q138mr1852009ywg.236.1501855312645; Fri, 04 Aug 2017 07:01:52 -0700 (PDT) MIME-Version: 1.0 References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <017901d30b85$14cf4440$3e6dccc0$@gmail.com> <0AD35C89-7C6C-4F82-8B8A-A9D397767C7F@gmail.com> In-Reply-To: <0AD35C89-7C6C-4F82-8B8A-A9D397767C7F@gmail.com> From: Truman Boyes Date: Fri, 04 Aug 2017 14:01:42 +0000 Message-ID: To: DY Kim , Russ White <7riw77@gmail.com> Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0bb3dc6a77550555edf049" Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 14:01:56 -0000 --94eb2c0bb3dc6a77550555edf049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am happy to see creative proposals such as this draft. But I do question the environment where this technology would ideally live. I see very little interest within the DC to support address mobility from the network. There are plenty of ways to solve mobility of a service if we do care about the significance of the address. Truman On Wed, Aug 2, 2017, 08:07 DY Kim wrote: > Hi Russ, > > Thanks for your comments. > > Two things: > > [Russ] =E2=80=9CJust eliminate the SID, rather than setting it to 0. Push= those > bits into some other part of the address where they will work for both > possible deployment models.=E2=80=9D > > [DY] I agree. I started with nullifying it to be consistent with the > current IPv6 addressing model. But, just killing it and assign the bits t= o > either eastwards or westwards would be better. The idea of node prefix as > Mikael suggested would be an idea, too. > > [Russ] "a lot more work than it looks like, a lot of uphill battles, > probably ultimately useful in at least some environments, but we need to = be > careful to consider environments where this would not be useful.=E2=80=9D > > [DY] I fully agree. After all, I=E2=80=99m not such an expert in IPv6 net= working > realities, so, in every pushing the idea forwards, it is essential that > real experts chip (jump) in to come up with neat solutions. My trial in t= he > draft should be too clumsy. As long as the core message (on which I > commented in a response to Fred) of mine would be taken, I would be wholl= y > open to expertise contributions or takeover. > > Thanks. > > --- > DY > > > > > > > > On 2 Aug 2017, at 20:47, Russ White <7riw77@gmail.com> wrote: > > > > > >> I have just read it. I would agree; it updates RFC 4291, and by > extension > >> 4291bis, and should be discussed in the same context. We will need to > point > >> 6man at it. > >> > >> That said, I'd suggest we collect operational viewpoints before we do > that. > >> Erik has given his. Other comments on the draft? > > > > I've just read this, and several (possibly incorrect) thoughts... So > take them with a grain of salt. > > > > Essentially, this seems to entail host routing at the site level, unles= s > you do something like the original IS-IS level 2 with attached bit to lev= el > 1's. This is actually okay/a good thing in many environments at the site > level. I think we way overblow the problems or running a lot of prefixes = in > an IGP -- we've moved from 10-15 views of 100k routes being "big" in 1996 > to 200-250 views of 1.5 million routes being "big" today (though I think > there might be speakers with more). And yet, we still have a minor heart > attack when someone suggests we should be able to carry 250k routes in > EIGRP or IS-IS -- in fact, I've seen both done quite well, and the open > fabric work is specifically targeted at 250-300k routes across 5k'ish nod= es > in a single flooding domain in a variant of IS-IS. We seem to have upped > our impression of BGP incrementally without noticing, and not thought > through the implications on the IGP side. In fact, doing something like > this could get rid of much of the "let's stretch layer 2 for the one > millionth time in yet another creative (and probably harmful) way" we see= m > to be experiencing right now. Good riddance, I would say -- stretched lay= er > 2 is an abomination that has been much more harmful than port NAT ever wa= s. > > > > On the other hand, there are some places where you don't want to host > route, I think. Per link aggregation is still a good thing in many cases. > There are a range of solutions you could probably deploy to solve this so= rt > of problem -- for instance, you could solve this by treating such > situations as a single level 1 flooding domain from the link state's > perspective, a strange land where all the hosts expect addresses with the > same prefix to be on the same broadcast domain, because the hosts don't > support the requisite protocols. This would be useful in a lot of > situations, so this is something that would definitely need to be looked = in > to and solved. For instance, no-one is (probably) going to develop and > deploy a host routing stack like ES-IS for mobile devices (mobile phones, > tablets, etc.). > > > > There are some quibbles with this, however. The first is that we don't > need to set the SID to 0 to do any of this -- in fact, it seems like a > waste of good address space to do so. I know it feels like the IPv6 addre= ss > space is infinite right now, but it's really not. We need to be careful > here. IS-IS can provide a good analog here, as well. There are two parts = to > the upper bits of the address, the HO-DSP and the area. These are treated > as one "thing" by every IS-IS deployment I know of, and have been for > years. Just eliminate the SID, rather than setting it to 0. Push those bi= ts > into some other part of the address where they will work for both possibl= e > deployment models. > > > > The second is this -- > > > > =3D=3D > > When a site is multihomed on multiple upstream networks, it would be > associated with multiple site prefixes and hence every intra-site node > would be associated with multiple addresses. For seamless site-multihomi= ng > in such an instance, a node should be able to receive inbound packets > destined to any of its multiple addresses, and also be able to source > outbound packets with one of such multiple addresses as appropriate > [DASv6]. > > =3D=3D > > > > This is not a bad thing per se, but there is a configuration issue here > that needs to be addressed. Specifically, you cannot have partitions with= in > any upper bits of address space if you play this game. The results are ve= ry > bad. So this would need to be thought through, etc. > > > > On the routing side, I'm perfectly willing to work on a draft of a > protocol to solve the routing parts of this problem... Building a small, > lightweight protocol to gather local routing information for a host, is > very close to the MANET space; I can think of some folks who would be > really interested in working on such a thing from a research perspective. > If you combined such a thing with dynamic DNS (think ILNP), you get lots > more host mobility out of this sort of thing, as well, so there is some > thought that needs to be put in, in that direction. > > > > I would argue against doing anything with a tunneled overlay or overlay > routing protocol here -- I would rule that out from the first day of work= . > Tunneled solutions are possible, but different; we're addicted to overlay= s > right now, it would be good to solve something without a tunneled header > for once. =F0=9F=98=8A > > > > So my initial thoughts are -- interesting, a lot more work than it look= s > like, a lot of uphill battles, probably ultimately useful in at least som= e > environments, but we need to be careful to consider environments where th= is > would not be useful. > > > > =F0=9F=98=8A > > > > Russ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0bb3dc6a77550555edf049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am happy to see creative proposals such as this draft. B= ut I do question the environment where this technology would ideally live. = I see very little interest within the DC to support address mobility from t= he network. There are plenty of ways to solve mobility of a service if we d= o care about the significance of the address.

Truman


On Wed, Aug 2, 2017,= 08:07 DY Kim <dyk= im6@gmail.com> wrote:
Hi Rus= s,

Thanks for your comments.

Two things:

[Russ] =E2=80=9CJust eliminate the SID, rather than setting it to 0. Push t= hose bits into some other part of the address where they will work for both= possible deployment models.=E2=80=9D

[DY] I agree. I started with nullifying it to be consistent with the curren= t IPv6 addressing model. But, just killing it and assign the bits to either= eastwards or westwards would be better. The idea of node prefix as Mikael = suggested would be an idea, too.

[Russ] "a lot more work than it looks like, a lot of uphill battles, p= robably ultimately useful in at least some environments, but we need to be = careful to consider environments where this would not be useful.=E2=80=9D
[DY] I fully agree. After all, I=E2=80=99m not such an expert in IPv6 netwo= rking realities, so, in every pushing the idea forwards, it is essential th= at real experts chip (jump) in to come up with neat solutions. My trial in = the draft should be too clumsy. As long as the core message (on which I com= mented in a response to Fred) of mine would be taken, I would be wholly ope= n to expertise contributions or takeover.

Thanks.

---
DY






> On 2 Aug 2017, at 20:47, Russ White <7riw77@gmail.com> wrote:
>
>
>> I have just read it. I would agree; it updates RFC 4291, and by ex= tension
>> 4291bis, and should be discussed in the same context. We will need= to point
>> 6man at it.
>>
>> That said, I'd suggest we collect operational viewpoints befor= e we do that.
>> Erik has given his. Other comments on the draft?
>
> I've just read this, and several (possibly incorrect) thoughts... = So take them with a grain of salt.
>
> Essentially, this seems to entail host routing at the site level, unle= ss you do something like the original IS-IS level 2 with attached bit to le= vel 1's. This is actually okay/a good thing in many environments at the= site level. I think we way overblow the problems or running a lot of prefi= xes in an IGP -- we've moved from 10-15 views of 100k routes being &quo= t;big" in 1996 to 200-250 views of 1.5 million routes being "big&= quot; today (though I think there might be speakers with more). And yet, we= still have a minor heart attack when someone suggests we should be able to= carry 250k routes in EIGRP or IS-IS -- in fact, I've seen both done qu= ite well, and the open fabric work is specifically targeted at 250-300k rou= tes across 5k'ish nodes in a single flooding domain in a variant of IS-= IS. We seem to have upped our impression of BGP incrementally without notic= ing, and not thought through the implications on the IGP side. In fact, doi= ng something like this could get rid of much of the "let's stretch= layer 2 for the one millionth time in yet another creative (and probably h= armful) way" we seem to be experiencing right now. Good riddance, I wo= uld say -- stretched layer 2 is an abomination that has been much more harm= ful than port NAT ever was.
>
> On the other hand, there are some places where you don't want to h= ost route, I think. Per link aggregation is still a good thing in many case= s. There are a range of solutions you could probably deploy to solve this s= ort of problem -- for instance, you could solve this by treating such situa= tions as a single level 1 flooding domain from the link state's perspec= tive, a strange land where all the hosts expect addresses with the same pre= fix to be on the same broadcast domain, because the hosts don't support= the requisite protocols. This would be useful in a lot of situations, so t= his is something that would definitely need to be looked in to and solved. = For instance, no-one is (probably) going to develop and deploy a host routi= ng stack like ES-IS for mobile devices (mobile phones, tablets, etc.).
>
> There are some quibbles with this, however. The first is that we don&#= 39;t need to set the SID to 0 to do any of this -- in fact, it seems like a= waste of good address space to do so. I know it feels like the IPv6 addres= s space is infinite right now, but it's really not. We need to be caref= ul here. IS-IS can provide a good analog here, as well. There are two parts= to the upper bits of the address, the HO-DSP and the area. These are treat= ed as one "thing" by every IS-IS deployment I know of, and have b= een for years. Just eliminate the SID, rather than setting it to 0. Push th= ose bits into some other part of the address where they will work for both = possible deployment models.
>
> The second is this --
>
> =3D=3D
> When a site is multihomed on multiple upstream networks, it would be a= ssociated with multiple site prefixes and hence every intra-site node would= be associated with multiple addresses.=C2=A0 For seamless site-multihoming= in such an instance, a node should be able to receive inbound packets dest= ined to any of its multiple addresses, and also be able to source outbound = packets with one of such multiple=C2=A0 =C2=A0addresses as appropriate [DAS= v6].
> =3D=3D
>
> This is not a bad thing per se, but there is a configuration issue her= e that needs to be addressed. Specifically, you cannot have partitions with= in any upper bits of address space if you play this game. The results are v= ery bad. So this would need to be thought through, etc.
>
> On the routing side, I'm perfectly willing to work on a draft of a= protocol to solve the routing parts of this problem... Building a small, l= ightweight protocol to gather local routing information for a host, is very= close to the MANET space; I can think of some folks who would be really in= terested in working on such a thing from a research perspective. If you com= bined such a thing with dynamic DNS (think ILNP), you get lots more host mo= bility out of this sort of thing, as well, so there is some thought that ne= eds to be put in, in that direction.
>
> I would argue against doing anything with a tunneled overlay or overla= y routing protocol here -- I would rule that out from the first day of work= . Tunneled solutions are possible, but different; we're addicted to ove= rlays right now, it would be good to solve something without a tunneled hea= der for once. =F0=9F=98=8A
>
> So my initial thoughts are -- interesting, a lot more work than it loo= ks like, a lot of uphill battles, probably ultimately useful in at least so= me environments, but we need to be careful to consider environments where t= his would not be useful.
>
> =F0=9F=98=8A
>
> Russ
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--94eb2c0bb3dc6a77550555edf049-- From nobody Fri Aug 4 07:20:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C584E132256 for ; Fri, 4 Aug 2017 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aGvmsl1hvNq6 for ; Fri, 4 Aug 2017 07:20:44 -0700 (PDT) Received: from atl4mhob01.registeredsite.com (atl4mhob01.registeredsite.com [209.17.115.39]) (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 50ECE1321E7 for ; Fri, 4 Aug 2017 07:20:44 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob01.registeredsite.com (8.14.4/8.14.4) with ESMTP id v74EKehW007233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 4 Aug 2017 10:20:40 -0400 Received: (qmail 31704 invoked by uid 0); 4 Aug 2017 14:20:40 -0000 X-TCPREMOTEIP: 73.133.18.55 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.16?) (lee@asgard.org@73.133.18.55) by 0 with ESMTPA; 4 Aug 2017 14:20:38 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 04 Aug 2017 10:20:35 -0400 From: Lee Howard To: , Message-ID: Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 14:20:47 -0000 Top posting review (as individual, not co-chair): I=E2=80=99m skipping grammar edits; we=E2=80=99ll get to that later. "we MUST NOT talk about a whole network having a "single and uniform" status regarding IPv6,=E2=80=9D I don=E2=80=99t think you mean rfc2119 MUST NOT. I think you mean =E2=80=9Cwe are unabl= e to=E2=80=9D or =E2=80=9Ccan not.=E2=80=9D I would suggest removing rfc2119 language from the document; it=E2=80=99s a terminology doc, not a specification. I also disagree with the point: a network may be as small as two hosts, and could well have a uniform state. I=E2=80=99d cut most of the context; I don=E2=80=99t think it=E2=80=99s necessary to understa= nd the definitions, and I it=E2=80=99s redundant with statements elsewhere. I=E2=80=99m confused by the reference to forwarding IP at layer 2. Rather, I woul= d say: IPv6-only There is no connectivity to IPv4 through any transition technology. IPv6-only host IPv4 is unconfigured and/or disabled on all interfaces on the host. IPv6-only router IPv4 is disabled and/or unconfigured and not forwarded on any interface. IPv6-only LAN IPv4 is disabled and/or unconfigured on all hosts on the LAN. IPv6-only WAN There is no transition mechanism available anywhere on the WAN. Thus, and IPv6-only host may exist on a WAN that is not IPv6-only. An IPv6-only host might exist on an IPv6-only LAN that is part of a WAN that is not IPv6-only. In addition, I propose: Native dual-stack Both IPv4 and IPv6 are natively configured. Transitional dual-stack IPv6 is natively configured, but IPv4 works only via a transition mechanism. Dual-stack Both IPv4 and IPv6 are reachable; method is not specified. I=E2=80=99m not sure we need terms for native IPv6+NATted IPv4 (most common case today), or for native IPv4 plus transitional IPv6 (6rd, DS-Lite). They could be subsumed under =E2=80=9Ctransitional dual-stack.=E2=80=9D Lee On 8/3/17, 4:31 AM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: >Hi, > >I=E2=80=99ve posted a new version of this document. > >https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > >Comments welcome! > >Regards, >Jordi >=20 > >-----Mensaje original----- >De: >Responder a: >Fecha: jueves, 3 de agosto de 2017, 10:28 >Para: Jordi Palet , Jordi Palet Martinez > >Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt > > =20 > A new version of I-D, draft-palet-v6ops-ipv6-only-01.txt > has been successfully submitted by Jordi Palet Martinez and posted to >the > IETF repository. > =20 > Name: draft-palet-v6ops-ipv6-only > Revision: 01 > Title: IPv6-only Terminology Definition > Document date: 2017-08-03 > Group: Individual Submission > Pages: 5 > URL: =20 >https://www.ietf.org/internet-drafts/draft-palet-v6ops-ipv6-only-01.txt > Status: =20 >https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > Htmlized: =20 >https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-01 > Htmlized: =20 >https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only-01 > Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-ipv6-only-01 > =20 > Abstract: > This document clarify the terminology regarding the usage of > expressions such as "IPv6-only", in order to avoid confusions when > using them in IETF and other documents, in reference to what is the > actual functionalities being used (not the actual protocol >support). > =20 > =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 > > > >********************************************** >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 >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aware >that any disclosure, copying, distribution or use of the contents of this >information, including attached files, is prohibited. > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 4 07:29:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1290913235C for ; Fri, 4 Aug 2017 07:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiizR7XHEsjf for ; Fri, 4 Aug 2017 07:29:48 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11A4132356 for ; Fri, 4 Aug 2017 07:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501856986; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=rM0hj3gzMU4Xkg1toh4szXkN1HIrhHQcfuHqgcNZx+4=; b=K1iw2x6QTso0XO014GybJuCqnoSNsfBHPa5gPJjsfOZsv7wmU1THqdQOBXXWAgfZOQAwhG5bdRs0QCBpjbsHMStw30n3307CtJoXB0ZSeoS1x+7DyoQ3Ug7a6+f2ptHNwsutcsJ083CxWzNqptHu5Er4tqGm6JQnlyTxlAhI1tE= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0149.outbound.protection.outlook.com [213.199.180.149]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-56-0wwPdq2OMBWRQueIYcZPww-1; Fri, 04 Aug 2017 15:29:42 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0584.eurprd07.prod.outlook.com (10.255.248.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Fri, 4 Aug 2017 14:29:41 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.012; Fri, 4 Aug 2017 14:29:41 +0000 From: Tim Chown To: Lee Howard CC: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt Thread-Index: AQHTDSzW7xkCaiH0dkKYEdIWB35TqKJ0QdwA Date: Fri, 4 Aug 2017 14:29:41 +0000 Message-ID: <0765B706-F687-4926-B2F9-A53D3B2B62F6@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:2c19:c7da:71cb:5b8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0584; 20:miMZMie4QFsNRCY3pBu2+PNane3vqXuS/t4oE7eaxx+Tsq/gZaPNRAnbmjaqkzBHnNjCHHTY8bdybK/VjnvJSGdf57IhWXMLrDJxl6S2Dcjv2GRH4JtIs/ZDoCbls+P4IYvSmSQZe8lJONvAXfbmNpDdylmwDTQXnansI7AUzyM= x-ms-office365-filtering-correlation-id: b3e8b7f6-8bec-4a80-a42a-08d4db453e5c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603120)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0584; x-ms-traffictypediagnostic: AM3PR07MB0584: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0584; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0584; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39850400002)(39400400002)(24454002)(377424004)(59124004)(199003)(377454003)(189002)(6306002)(50986999)(6512007)(81156014)(50226002)(5250100002)(101416001)(2900100001)(81166006)(74482002)(5660300001)(5890100001)(305945005)(76176999)(8676002)(38730400002)(97736004)(8936002)(189998001)(6246003)(15650500001)(53386004)(110136004)(33656002)(82746002)(53936002)(7110500001)(25786009)(99286003)(6116002)(3280700002)(3660700001)(102836003)(230783001)(6436002)(2420400007)(36756003)(106356001)(7736002)(54906002)(105586002)(68736007)(4326008)(2906002)(57306001)(42882006)(2950100002)(6486002)(83716003)(6916009)(86362001)(72206003)(14454004)(966005)(10710500007)(6506006)(229853002)(478600001)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0584; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 14:29:41.0317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0584 X-MC-Unique: 0wwPdq2OMBWRQueIYcZPww-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 14:29:51 -0000 SGkgSm9yZGksDQoNCkFsc28gc2xhY2tpbmcgd2l0aCB0b3AtcG9zdOKApg0KDQpJdCBvY2N1cnMg dG8gbWUgcmVhZGluZyBMZWXigJlzIGNvbW1lbnRzIHlvdSBtaWdodCB3YW50IHRvIGxvb2sgYXQg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ4NTINCg0KQW5kIHRoZSB0ZXJtaW5vbG9n eSBzZWN0aW9uIHRoZXJlLCBhbmQgVGFibGUgMSwgZm9yIHNvbWUgaW5zcGlyYXRpb24uDQoNCkkg cmVhbGx5IG1pc3MgSmltIDovDQoNClRpbSANCg0KPiBPbiA0IEF1ZyAyMDE3LCBhdCAxNToyMCwg TGVlIEhvd2FyZCA8bGVlQGFzZ2FyZC5vcmc+IHdyb3RlOg0KPiANCj4gVG9wIHBvc3RpbmcgcmV2 aWV3IChhcyBpbmRpdmlkdWFsLCBub3QgY28tY2hhaXIpOg0KPiBJ4oCZbSBza2lwcGluZyBncmFt bWFyIGVkaXRzOyB3ZeKAmWxsIGdldCB0byB0aGF0IGxhdGVyLg0KPiANCj4gIndlIE1VU1QgTk9U IHRhbGsgYWJvdXQgYSB3aG9sZSBuZXR3b3JrIGhhdmluZyBhICJzaW5nbGUgYW5kIHVuaWZvcm0i DQo+IHN0YXR1cyByZWdhcmRpbmcgSVB2NizigJ0NCj4gSSBkb27igJl0IHRoaW5rIHlvdSBtZWFu IHJmYzIxMTkgTVVTVCBOT1QuIEkgdGhpbmsgeW91IG1lYW4g4oCcd2UgYXJlIHVuYWJsZQ0KPiB0 b+KAnSBvciDigJxjYW4gbm90LuKAnSBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgcmZjMjExOSBs YW5ndWFnZSBmcm9tIHRoZQ0KPiBkb2N1bWVudDsgaXTigJlzIGEgdGVybWlub2xvZ3kgZG9jLCBu b3QgYSBzcGVjaWZpY2F0aW9uLg0KPiBJIGFsc28gZGlzYWdyZWUgd2l0aCB0aGUgcG9pbnQ6IGEg bmV0d29yayBtYXkgYmUgYXMgc21hbGwgYXMgdHdvIGhvc3RzLA0KPiBhbmQgY291bGQgd2VsbCBo YXZlIGEgdW5pZm9ybSBzdGF0ZS4NCj4gDQo+IEnigJlkIGN1dCBtb3N0IG9mIHRoZSBjb250ZXh0 OyBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIG5lY2Vzc2FyeSB0byB1bmRlcnN0YW5kDQo+IHRoZSBk ZWZpbml0aW9ucywgYW5kIEkgaXTigJlzIHJlZHVuZGFudCB3aXRoIHN0YXRlbWVudHMgZWxzZXdo ZXJlLg0KPiANCj4gSeKAmW0gY29uZnVzZWQgYnkgdGhlIHJlZmVyZW5jZSB0byBmb3J3YXJkaW5n IElQIGF0IGxheWVyIDIuIFJhdGhlciwgSSB3b3VsZA0KPiBzYXk6DQo+IElQdjYtb25seQlUaGVy ZSBpcyBubyBjb25uZWN0aXZpdHkgdG8gSVB2NCB0aHJvdWdoIGFueSB0cmFuc2l0aW9uDQo+IHRl Y2hub2xvZ3kuDQo+IElQdjYtb25seSBob3N0CUlQdjQgaXMgdW5jb25maWd1cmVkIGFuZC9vciBk aXNhYmxlZCBvbiBhbGwgaW50ZXJmYWNlcyBvbg0KPiB0aGUgaG9zdC4NCj4gSVB2Ni1vbmx5IHJv dXRlciBJUHY0IGlzIGRpc2FibGVkIGFuZC9vciB1bmNvbmZpZ3VyZWQgYW5kIG5vdCBmb3J3YXJk ZWQgb24NCj4gYW55IGludGVyZmFjZS4NCj4gSVB2Ni1vbmx5IExBTglJUHY0IGlzIGRpc2FibGVk IGFuZC9vciB1bmNvbmZpZ3VyZWQgb24gYWxsIGhvc3RzIG9uIHRoZSBMQU4uDQo+IElQdjYtb25s eSBXQU4JVGhlcmUgaXMgbm8gdHJhbnNpdGlvbiBtZWNoYW5pc20gYXZhaWxhYmxlIGFueXdoZXJl IG9uIHRoZQ0KPiBXQU4uDQo+IA0KPiBUaHVzLCBhbmQgSVB2Ni1vbmx5IGhvc3QgbWF5IGV4aXN0 IG9uIGEgV0FOIHRoYXQgaXMgbm90IElQdjYtb25seS4gQW4NCj4gSVB2Ni1vbmx5IGhvc3QgbWln aHQgZXhpc3Qgb24gYW4gSVB2Ni1vbmx5IExBTiB0aGF0IGlzIHBhcnQgb2YgYSBXQU4gdGhhdA0K PiBpcyBub3QgSVB2Ni1vbmx5Lg0KPiANCj4gSW4gYWRkaXRpb24sIEkgcHJvcG9zZToNCj4gTmF0 aXZlIGR1YWwtc3RhY2sJQm90aCBJUHY0IGFuZCBJUHY2IGFyZSBuYXRpdmVseSBjb25maWd1cmVk Lg0KPiBUcmFuc2l0aW9uYWwgZHVhbC1zdGFjawlJUHY2IGlzIG5hdGl2ZWx5IGNvbmZpZ3VyZWQs IGJ1dCBJUHY0IHdvcmtzIG9ubHkNCj4gdmlhIGEgdHJhbnNpdGlvbiBtZWNoYW5pc20uDQo+IER1 YWwtc3RhY2sJCUJvdGggSVB2NCBhbmQgSVB2NiBhcmUgcmVhY2hhYmxlOyBtZXRob2QgaXMgbm90 IHNwZWNpZmllZC4NCj4gDQo+IEnigJltIG5vdCBzdXJlIHdlIG5lZWQgdGVybXMgZm9yIG5hdGl2 ZSBJUHY2K05BVHRlZCBJUHY0IChtb3N0IGNvbW1vbiBjYXNlDQo+IHRvZGF5KSwgb3IgZm9yIG5h dGl2ZSBJUHY0IHBsdXMgdHJhbnNpdGlvbmFsIElQdjYgKDZyZCwgRFMtTGl0ZSkuIFRoZXkNCj4g Y291bGQgYmUgc3Vic3VtZWQgdW5kZXIg4oCcdHJhbnNpdGlvbmFsIGR1YWwtc3RhY2su4oCdDQo+ IA0KPiBMZWUNCj4gDQo+IA0KPiANCj4gT24gOC8zLzE3LCA0OjMxIEFNLCAidjZvcHMgb24gYmVo YWxmIG9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaIg0KPiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2Ygam9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+IHdyb3RlOg0KPiANCj4+IEhp LA0KPj4gDQo+PiBJ4oCZdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudC4N Cj4+IA0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsZXQtdjZv cHMtaXB2Ni1vbmx5Lw0KPj4gDQo+PiBDb21tZW50cyB3ZWxjb21lIQ0KPj4gDQo+PiBSZWdhcmRz LA0KPj4gSm9yZGkNCj4+IA0KPj4gDQo+PiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPj4g RGU6IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+PiBSZXNwb25kZXIgYTogPGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4NCj4+IEZlY2hhOiBqdWV2ZXMsIDMgZGUgYWdvc3RvIGRlIDIwMTcs IDEwOjI4DQo+PiBQYXJhOiBKb3JkaSBQYWxldCA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+ LCBKb3JkaSBQYWxldCBNYXJ0aW5leg0KPj4gPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPg0K Pj4gQXN1bnRvOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBhbGV0LXY2b3Bz LWlwdjYtb25seS0wMS50eHQNCj4+IA0KPj4gDQo+PiAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1wYWxldC12Nm9wcy1pcHY2LW9ubHktMDEudHh0DQo+PiAgIGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSm9yZGkgUGFsZXQgTWFydGluZXogYW5kIHBvc3RlZCB0bw0KPj4g dGhlDQo+PiAgIElFVEYgcmVwb3NpdG9yeS4NCj4+IA0KPj4gICBOYW1lOgkJZHJhZnQtcGFsZXQt djZvcHMtaXB2Ni1vbmx5DQo+PiAgIFJldmlzaW9uOgkwMQ0KPj4gICBUaXRsZToJCUlQdjYtb25s eSBUZXJtaW5vbG9neSBEZWZpbml0aW9uDQo+PiAgIERvY3VtZW50IGRhdGU6CTIwMTctMDgtMDMN Cj4+ICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+ICAgUGFnZXM6CQk1DQo+PiAg IFVSTDogICAgICAgICAgDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtcGFsZXQtdjZvcHMtaXB2Ni1vbmx5LTAxLnR4dA0KPj4gICBTdGF0dXM6ICAgICAgIA0K Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsZXQtdjZvcHMtaXB2 Ni1vbmx5Lw0KPj4gICBIdG1saXplZDogICAgIA0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXBhbGV0LXY2b3BzLWlwdjYtb25seS0wMQ0KPj4gICBIdG1saXplZDogICAgIA0K Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1wYWxldC12Nm9w cy1pcHY2LW9ubHktMDENCj4+ICAgRGlmZjogICAgICAgICANCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wYWxldC12Nm9wcy1pcHY2LW9ubHktMDENCj4+IA0KPj4g ICBBYnN0cmFjdDoNCj4+ICAgICAgVGhpcyBkb2N1bWVudCBjbGFyaWZ5IHRoZSB0ZXJtaW5vbG9n eSByZWdhcmRpbmcgdGhlIHVzYWdlIG9mDQo+PiAgICAgIGV4cHJlc3Npb25zIHN1Y2ggYXMgIklQ djYtb25seSIsIGluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbnMgd2hlbg0KPj4gICAgICB1c2lu ZyB0aGVtIGluIElFVEYgYW5kIG90aGVyIGRvY3VtZW50cywgaW4gcmVmZXJlbmNlIHRvIHdoYXQg aXMgdGhlDQo+PiAgICAgIGFjdHVhbCBmdW5jdGlvbmFsaXRpZXMgYmVpbmcgdXNlZCAobm90IHRo ZSBhY3R1YWwgcHJvdG9jb2wNCj4+IHN1cHBvcnQpLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAN Cj4+ICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj4+IHN1Ym1pc3Npb24NCj4+ICAgdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+IA0KPj4g ICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+ICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IElQdjQgaXMgb3Zl cg0KPj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+PiBodHRwOi8vd3d3 LmNvbnN1bGludGVsLmVzDQo+PiBUaGUgSVB2NiBDb21wYW55DQo+PiANCj4+IFRoaXMgZWxlY3Ry b25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2Vk IG9yDQo+PiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBm b3IgdGhlIHVzZSBvZiB0aGUNCj4+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4+IHRoYXQgYW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMNCj4+IGluZm9ybWF0aW9uLCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0 ZWQuDQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3Bz IG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg== From nobody Fri Aug 4 08:34:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60368132335 for ; Fri, 4 Aug 2017 08:33: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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRpLARXI9Kzm for ; Fri, 4 Aug 2017 08:33:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB01132396 for ; Fri, 4 Aug 2017 08:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1501860834; x=1502465634; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=HcCaUgtnc5gqAhR4FeZ3RKl5n I454Z5/O21eOV9eoBc=; b=chi1Xb5rJCwvt1MYD0pPItbZyfNTzzdQPWMhr/HBd wcX3C+IoLhJKFuLBeqNR+eFDEeA/os+LTqrk7eW9dJZTVJe9QR5hN2Q1o7rq/YMy IzTbpix3wR/1nLw7vAQ159isIRej99w3SBnH2M8W9gKa5vGRI0VundKZFGG11fQH EI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=NJfC/l6UlVdxBZkI+MTzS5baElRZGo3Do+JYjcTiKYiRxJIZMZ7EGVa8dtBC 7lK2tJbKBIvXpLZzzCg00Lkl5WuvlzrVyRuwltUiFiTJvtG2oUcMsrnYb uBQASYaH5O/mozrOGxt0tLicm+3UinwqElsW4rESmd9XzrtLr6izxc=; X-MDAV-Processed: mail.consulintel.es, Fri, 04 Aug 2017 17:33:53 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 04 Aug 2017 17:33:52 +0200 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005494868.msg for ; Fri, 04 Aug 2017 17:33:52 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170804:md50005494868::S/NGT3obFxUQy6OB:00006/46 X-Return-Path: prvs=1389a0e90e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Fri, 04 Aug 2017 17:33:49 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <29494B82-78BB-426E-865B-2FCBDD001B74@consulintel.es> Thread-Topic: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6-only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 15:33:59 -0000 Hi Lee, Thousands thanks for the comments! Below in-line Regards, Jordi =20 -----Mensaje original----- De: Lee Howard Responder a: Fecha: viernes, 4 de agosto de 2017, 16:20 Para: , Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-ipv6= -only-01.txt Top posting review (as individual, not co-chair): I=E2=80=99m skipping grammar edits; we=E2=80=99ll get to that later. =20 "we MUST NOT talk about a whole network having a "single and uniform" status regarding IPv6,=E2=80=9D I don=E2=80=99t think you mean rfc2119 MUST NOT. I think you mean =E2= =80=9Cwe are unable to=E2=80=9D or =E2=80=9Ccan not.=E2=80=9D I would suggest removing rfc2= 119 language from the document; it=E2=80=99s a terminology doc, not a specification. [Jordi] Agreed, will do a new version in a couple of days or so (hoping the= re are new inputs by then) and can change that across all the document. I also disagree with the point: a network may be as small as two hosts, and could well have a uniform state. [Jordi] I was thinking that the =E2=80=9Cin general=E2=80=9D before that se= ntence setup that context, but will find out something to make it not contr= adicting your point, which obviously I agree. Maybe: =E2=80=9C=E2=80=A6 in = most of the cases, except maybe some very simple networks, it is difficult = to find whole networks which have a "single and uniform" status regarding I= Pv6, at least not in the early deployment stages.=E2=80=9C =20 I=E2=80=99d cut most of the context; I don=E2=80=99t think it=E2=80=99s= necessary to understand the definitions, and I it=E2=80=99s redundant with statements elsewhere= . [Jordi] While I see your point, I=E2=80=99m trying to make sure that folks = reading the document from scratch, don=E2=80=99t get the appropriate contex= t. I think many of us, which have already done *real* deployment in several= networks, worked with different technologies, etc., have this context clea= r, but I=E2=80=99m not really sure about =E2=80=9Cforeigners=E2=80=9D. I ne= ed to think about this, maybe having most of this text in an annex =E2=80= =A6 =20 I=E2=80=99m confused by the reference to forwarding IP at layer 2. Rath= er, I would say: [Jordi] I got this comment already yesterday. Initially I responded that ma= ybe =E2=80=9Cforwarding=E2=80=9D is not the right term, and then I was thin= king myself about networks using MPLS or other =E2=80=9Caccess=E2=80=9D tec= hnologies, which are instead of layer 2, layer 3, or can be both, etc,, =E2= =80=A6 so instead considering something like =E2=80=9Cnetwork transporting = natively IPv6-only=E2=80=9D. IPv6-only There is no connectivity to IPv4 through any transition technology. IPv6-only host IPv4 is unconfigured and/or disabled on all interfaces o= n the host. IPv6-only router IPv4 is disabled and/or unconfigured and not forwarded= on any interface. IPv6-only LAN IPv4 is disabled and/or unconfigured on all hosts on the = LAN. IPv6-only WAN There is no transition mechanism available anywhere on th= e WAN. [Jordi] I think we don=E2=80=99t agree here with some of the definitions. F= or example, IPv6-only you basically say =E2=80=9Cno IPv4 at all=E2=80=9D, b= ut actually what I=E2=80=99m trying to say is that, in that part of the net= work, let=E2=80=99s take the example of the access network, in a cellular o= perator that only provides single stack IPv6 PDP context, but is providing = a NAT64 and the smartphones have CLAT. So for me, if I say =E2=80=9CIPv6-on= ly-WAN=E2=80=9D, I=E2=80=99m meaning that the WAN link is only =E2=80=9Ctra= nsporting natively IPv6 traffic=E2=80=9D, but that doesn't preclude the ope= rator have a NAT64 so the user device apps can access to end-IPv6-only-site= s. It may even happen that the NAT64 is an external service, not in this op= erator itself. So taking your definitions, =E2=80=9Cno transition=E2=80=9D = means that you =E2=80=9Cdisable=E2=80=9D the possibility of having some IPv= 4 =E2=80=9Ctransported somehow as IPv6=E2=80=9D. Note that what you=E2=80=99re suggesting could end-up meaning that the oper= ator of an IPv6-only network =E2=80=9Cdisables=E2=80=9D (or somehow filters= ), the capability of transporting IPv4 on top of the IPv6 infrastructure. So will you agree that what we mean with IPv6-only is that there is ONLY IP= v6 *native* support, but other protocols (IPv4) can be transported using th= e IPv6 network?. =20 Thus, and IPv6-only host may exist on a WAN that is not IPv6-only. An IPv6-only host might exist on an IPv6-only LAN that is part of a WAN th= at is not IPv6-only. [Jordi] I think that works as well with my previous definition of native su= pport. An IPv6-only host has not IPv4 configured (even if the stack is dual= -stack, this is irrelevant here), and it may be connected to a non-IPv6-onl= y WAN, etc..=20 =20 In addition, I propose: Native dual-stack Both IPv4 and IPv6 are natively configured. Transitional dual-stack IPv6 is natively configured, but IPv4 works onl= y via a transition mechanism. Dual-stack Both IPv4 and IPv6 are reachable; method is not specified. [Jordi] native dual-stack and dual-stack are fine. However transitional dua= l-stack we may want to say if the =E2=80=9Ctransport=E2=80=9D is native IPv= 4 or native IPv6 =E2=80=93 furthermore, I think if we agree in my previous = point about the definition of IPv6-only, we don=E2=80=99t need this, becaus= e becomes irrelevant. =20 I=E2=80=99m not sure we need terms for native IPv6+NATted IPv4 (most co= mmon case today), or for native IPv4 plus transitional IPv6 (6rd, DS-Lite). They could be subsumed under =E2=80=9Ctransitional dual-stack.=E2=80=9D [Jordi] Agree on this. =20 Lee =20 =20 =20 On 8/3/17, 4:31 AM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: =20 >Hi, > >I=E2=80=99ve posted a new version of this document. > >https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > >Comments welcome! > >Regards, >Jordi >=20 > >-----Mensaje original----- >De: >Responder a: >Fecha: jueves, 3 de agosto de 2017, 10:28 >Para: Jordi Palet , Jordi Palet Martinez > >Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-01.tx= t > > =20 > A new version of I-D, draft-palet-v6ops-ipv6-only-01.txt > has been successfully submitted by Jordi Palet Martinez and posted= to >the > IETF repository. > =20 > Name: draft-palet-v6ops-ipv6-only > Revision: 01 > Title: IPv6-only Terminology Definition > Document date: 2017-08-03 > Group: Individual Submission > Pages: 5 > URL: =20 >https://www.ietf.org/internet-drafts/draft-palet-v6ops-ipv6-only-01.tx= t > Status: =20 >https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > Htmlized: =20 >https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-01 > Htmlized: =20 >https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only-01 > Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-ipv6-only-01 > =20 > Abstract: > This document clarify the terminology regarding the usage of > expressions such as "IPv6-only", in order to avoid confusions w= hen > using them in IETF and other documents, in reference to what is= the > actual functionalities being used (not the actual protocol >support). > =20 > =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.or= g. > =20 > The IETF Secretariat > =20 > =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 o= r >confidential. The information is intended to be for the use of the >individual(s) named above. If you are not the intended recipient be aw= are >that any disclosure, copying, distribution or use of the contents of t= his >information, including attached files, is prohibited. > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Fri Aug 4 10:36:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B3D13238A for ; Fri, 4 Aug 2017 10:36:39 -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 1fSP1TF7tWYA for ; Fri, 4 Aug 2017 10:36:38 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7DE131F5C for ; Fri, 4 Aug 2017 10:36:38 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so2384288pgd.1 for ; Fri, 04 Aug 2017 10:36:38 -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=endI2FggdJD77vPY4KMithfjVYNBRa9hXY3sj4+E6S0=; b=a5b9cA5i5CHWnDw9qA1teQwnE45UW8RAPCz/STguoz76h/uR7tr6mjPhRb9PMBM3Hu u6qkyrpWdWnLVnKEF3eOG3WkKQet8ErMbPKUCXXWBwyV+O4eYYwlAbS+JXXDmX/KEv6T l9RHELELAWbDEDmTbXnzmJ0EjcyTrMJGoauVc0gXMC2vXh0yTIX95o8C1IWl1/A/FSvs 9QvgL0m23GbvR4VKwzuGDM4aJiAt9pd3UYHmSn0AFIu83jtVIpglpA6jXR2uKQt8M/nM ShYSk1biYKK1rVL3NnbIFOD33J4QREnVZz1cnYNipAR5481ift/wHce5+qdvV6J709Zc m8GQ== 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=endI2FggdJD77vPY4KMithfjVYNBRa9hXY3sj4+E6S0=; b=MWqI1bbV0S9btGUdBA69ZsHSvPj8R/AcElJ3mIdKUtRJI9nHC/7omjZ3wkq5HqTltZ AwTxjyCZH6Imlk6DKzTqZhE7ix1r3cJisNG2iVCs6Z4KR24fdcLOhOkBGcs3lk4U4YPU Ettmcs6uXKdp8IVAZJjR3MNkyYztwKSGfjPaYk8M5wRuKc6bUw1kGN9JFoSQz4PixPFS FQOKv/SOtaIzH/3Ef3rXeSUJaiGXTCb8bn6nExy1NeETYGvzcNvpSygukQpIoBFsVfhB T4/aQPgb6sYXvDDTFMXbG9iZ2taMs+agL4X99zkcTBrD8JfdHTfyUNeEjEWFzK0vxcyY fWQA== X-Gm-Message-State: AIVw1138PeGYRoEwC2WgvMdehi/eCnZWlwq3X08IBrB+JRxgkX5UD1kH 8JVYWGuDNCZl9A== X-Received: by 10.84.129.193 with SMTP id b59mr3632892plb.299.1501868198064; Fri, 04 Aug 2017 10:36:38 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id d135sm5032689pga.6.2017.08.04.10.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 10:36:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 02:36:33 +0900 Cc: Russ White <7riw77@gmail.com>, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <076A9469-B8BE-410C-ACA8-EED1A127698F@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <017901d30b85$14cf4440$3e6dccc0$@gmail.com> <0AD35C89-7C6C-4F82-8B8A-A9D397767C7F@gmail.com> To: Truman Boyes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:36:40 -0000 Yes, there are plenty of ways to solve intra-site mobility. With SID6, - Intra-site mobility can be provided without extra = infrastructure installed due to like MIPv6 and/or any LISs. - Inter-site mobility would be provided by MIPv6 as usual. - No need to resort to LISs; no id/loc mapping servers and the = like. - IPv6 networking remains as native (simple) as possible, with = no significant extra infrastructure like LISs. - =E2=80=98Simple is the best.' -------- Regards, DY > On 4 Aug 2017, at 23:01, Truman Boyes wrote: >=20 > I am happy to see creative proposals such as this draft. But I do = question the environment where this technology would ideally live. I see = very little interest within the DC to support address mobility from the = network. There are plenty of ways to solve mobility of a service if we = do care about the significance of the address. >=20 > Truman From nobody Fri Aug 4 10:49:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9E131EB6 for ; Fri, 4 Aug 2017 10:49:27 -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 3V6TfIwuIN72 for ; Fri, 4 Aug 2017 10:49:26 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::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 EAFC5132334 for ; Fri, 4 Aug 2017 10:49:25 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id t83so2471618pfj.3 for ; Fri, 04 Aug 2017 10:49:25 -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=CxtvkfSYf9D874c+N5mkuAr6U2KjTKYThW58kYDFTYg=; b=hnj3pqd3TQVunQITvN3fZZDKjwZTD15D1/owUM16J9LEqF243ZF0GpX14I8lFip4Bu PbfkMq2gn4KrKoPI/qGZsWnrD+E38JDcGqR1mMg1TjucTN6gEhuOTt0Zpnz8UfSDVIjQ f4XrXT9W0kXPBSY9BXCsiGPyQupYWcNSN1mfQycg7V8QZ8KhC1SCJxP8cREa4St961cy hatduVP9l30pBEV7KlhiS02feOoeqdI5NKcVxGY3sOLjKpmbUpMsfqt/2lOsQkGVRm65 +9yQL4bszuFAhEvv6uGSKIhR1Ljm/RQ/DUbSPDFdJmHQduW5/av8ZmZznPh+/w/EKY6W iCdQ== 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=CxtvkfSYf9D874c+N5mkuAr6U2KjTKYThW58kYDFTYg=; b=XaROd/sMvd4iZ++plimU4qJPLrONelPvYxe70B5O6gy3+JxtDLjQp82OpygYSHVg8W J6XhZOXD8o73v04ZON3c6XhBwsGHnWyyxEVb3BJrgFug0akDC+dvFVXoXQY1Xx0Ww5hJ F+DayGF4T0qIGPSXcXzGcY6VRiklUkGVQVPhg+vvMqIwikSTVJ6Q2ntzGGex0JirLHCO MHsd5pSYpDtFaIjs4RcN/0uex1nakbP2PeCS5NKFb3Ub1WhE/X2vlCzn+4jkRtnmT2PX qeV+v/hgxg2+EwAabRmtEhh6cGKrryj0IfuE3XAuWUC0BQgCUMKaItr8NC+ovZw31PoG 3Jpw== X-Gm-Message-State: AIVw1115zUCJ6uqp2XbjZogHjuMbSkW1vhZAay1FeNApR5wxHHDUsDbM gOWXV2O2ZnbWB/xYJiU= X-Received: by 10.84.214.23 with SMTP id h23mr3782327pli.321.1501868965388; Fri, 04 Aug 2017 10:49:25 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id p80sm4505819pfa.19.2017.08.04.10.49.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 10:49:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 02:49:21 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:49:27 -0000 in line... =E2=80=94- DY > On 4 Aug 2017, at 22:58, David Farmer wrote: >=20 > I don't see how whole subnet or prefix assigned to just a single host = is incompatible with with RFC4291 or RFC4291bis in any way. Subnet, to my understanding, is a shared network comprising of a = collection of hosts managed (bordered) by one or more routers. A subnet = prefix is one assigned to the whole subnet wherein all hosts share the = same prefix. When each host in such a share network (subnet) is assigned a unique = prefix (and hosts don=E2=80=99t share the same prefix), that prefix is = not a subnet prefix and should be name differently, say, =E2=80=98host = prefix=E2=80=99 or =E2=80=98node prefix=E2=80=99. RFC4291bis defines (comments) only the subnet prefix. The draft of this = thread title deals with a prefix type not defined (commented) in the = RFC4291bis (to-be-)standard. In that, the draft under discussion in this = thread could be said =E2=80=98not in compliance with=E2=80=99 the = RFC4291bis. This is my logic. Odd yet? > That said there was some discussion of adding a reference to RFC7934 - = Host Address Availability Recommendations, which introduces the concept = of assigning a whole /64 to an individual host. I think its still think = that is a good idea, and maybe adding a reference to this would be a = good idea too. It does represent a bit of an evolution in the subnet = model. From nobody Fri Aug 4 10:57:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257A7132224 for ; Fri, 4 Aug 2017 10:57:54 -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 CVF6SV42wAZA for ; Fri, 4 Aug 2017 10:57:53 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 AE64313238A for ; Fri, 4 Aug 2017 10:57:49 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id j68so2492058pfc.2 for ; Fri, 04 Aug 2017 10:57:49 -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=gZqSVTpAFV1rwkjqJyrssUCVXgqr5OxXpeaIx3ve6ZQ=; b=Wb/GE2xlI719Wy7t4v3Dee7AWRnsWKKMuMgGWNmrlNu2vEh/NwXvyX5XR7A8gFPEI9 v5YBjuD3c8IV58PZoGtJkmiDqLnkZXbe2nhRkmvl7utZh5PgW4brz5fRUAMyKHX+/8GA +bnS2P64ZL6uZPSW6Y9Mzjp73aHxGRUa+80IP1fIyUTFSNDHP/Rf/WpJmefXjMEggKva 1EtSxzwJiC3Xpcps8sL4IcWS6YT8WxE7AwRxAoQDV+ks20Pbjgi9tz3IXYMVYE6w1sJU LjEhopL3E5Fpk2/oHtWlcccfp7gaCg8FQa3DTwmd3lY3ALFiBdvT/Pl9Kh57nwtIOx+8 qs/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gZqSVTpAFV1rwkjqJyrssUCVXgqr5OxXpeaIx3ve6ZQ=; b=fCB3CmZjV4twgWoIpb+DUDUjSi+kmY1TlxS/u66izEVLIRFzNDl5LKmgnYFJTwp//K QP8iQkqEQp0jnkGtKIxFAZdCawaHSCPBnlh1+DnLE5mVT+Q2kCGoqmaVYxGOKHos7wvk FRgNVIg/PiKxTOQ7SjX2SGfsQfTpfSQCjYP1K6Cz2xsLKgDr1IsMSFqKkyWRDRmqBHRD xceAc0NX1/5CNUmGzE2In/UaksfOJZR/pf7dxeKi278OrMR0WNxhN+SXJoW7Wx+1fPAd X0RxkicFeWHsY5wegiaDjqxUDKC3qjrHczbboSiodW4ukUqthBSamriVsDNzT7fvH+On Xw5w== X-Gm-Message-State: AIVw111eLXSMEi7rRaiO9OfOnbvYZ4YYL6zOf6QwnTROp0s4p9Yd9Ezi abZ63IgLPG8a3g== X-Received: by 10.84.241.13 with SMTP id a13mr3659439pll.307.1501869469211; Fri, 04 Aug 2017 10:57:49 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id h29sm4019180pfd.145.2017.08.04.10.57.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 10:57:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 02:57:46 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <21F4EF48-A2E5-4A6F-86E8-BC19D45B9C11@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:57:54 -0000 Konglish=E2=80=A6 >> consisting of --- DY > On 5 Aug 2017, at 02:49, DY Kim wrote: >=20 > comprising of From nobody Fri Aug 4 11:15:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E160D126C23 for ; Fri, 4 Aug 2017 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nx2GOIm6ts7 for ; Fri, 4 Aug 2017 11:15:14 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B698131EB2 for ; Fri, 4 Aug 2017 11:15:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 1C828B26 for ; Fri, 4 Aug 2017 18:15:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aO1XsX9mdo0 for ; Fri, 4 Aug 2017 13:15:13 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id D7E18757 for ; Fri, 4 Aug 2017 13:15:13 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id k43so8949915uaf.6 for ; Fri, 04 Aug 2017 11:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/C05pARNhfk5dBMxyq0cEpj8GB6B+KQhorg5JuBDGI=; b=QeCuEcpBWZnEaqTjaUxMjkk1Dk8Y3/H9gp0owZg2RbRrwGVBQzO9UJ/a6a2LsdRFjl e60NcO5lmN4JakTGgor4YZm91GBkTxS+47HsTt5Xrym1gpxm3HBlI+vkH6i1ut0UtyD/ i5BK7ktwdjVRvVtDlS619+0Rb9tXy0n+FZs58zeITncqhQ7Jr3cjxnaVi39VdceO0Pkb T/ejXXaiuOfc7YmJyvcf2KMCJ3veozvQK3M8/nj+1axrtdTvEuym+QhBzp3AfpwCH5Xt FnOCUCKl6PNfpR4R40I93LySbTKlmuXBaE8ksPPJZfTb0W6mNYiHQKxl6KEppCQCOIvt PyfQ== 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=+/C05pARNhfk5dBMxyq0cEpj8GB6B+KQhorg5JuBDGI=; b=aJlT3zK1+dLg+pmO7kPgRii0bzUK00iPVcmIwqO1bAGOcGJPfKXOktGwTYgAD7/60e Eo32CVrA8RCJK8tPKPWjPHDMwJFEow7UHyvC7t+yL57Us38DggxcLPlLzoRzlP1AhUvj /T9RRD+QixEQHH1GwsjLpnx9hJ15xAWKZpq7RjA7wFbJGwldYZkJpaXfNO4zThazdewe nEx9Dlh8LV6xTZaCawXc6oRgg/qOJt2ZeHSinwk469E4HiaPPgiI+p7kNiCDH0mY2G0+ yL+ssZsNyZAVJqphIh8lKcQRZAGfSou8uMYBIavW3kVQh08OeCQ8VLOFT8Z8eoXsG2+t qo5w== X-Gm-Message-State: AHYfb5iNzRqBmC81Qk3WsQJVCsIeawa9ZVrL3Nc8qTJcAV7Kb6HyGY8I y/7f2YY6j3nRxkR7+xnIHpNi2f2hi+Slj+oTPZ+FI/POB82/zmLXCEMj8mqqQoJYLV13267tvpU vD0ovdmuNjy3cWB41 X-Received: by 10.31.178.87 with SMTP id b84mr1995225vkf.4.1501870513329; Fri, 04 Aug 2017 11:15:13 -0700 (PDT) X-Received: by 10.31.178.87 with SMTP id b84mr1995214vkf.4.1501870513138; Fri, 04 Aug 2017 11:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Fri, 4 Aug 2017 11:15:12 -0700 (PDT) In-Reply-To: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> From: David Farmer Date: Fri, 4 Aug 2017 13:15:12 -0500 Message-ID: To: DY Kim Cc: Mikael Abrahamsson , v6ops list Content-Type: multipart/alternative; boundary="001a1143f0666f492c0555f17adb" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 18:15:19 -0000 --001a1143f0666f492c0555f17adb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 4, 2017 at 12:49 PM, DY Kim wrote: > in line... > > =E2=80=94- > DY > > > > On 4 Aug 2017, at 22:58, David Farmer wrote: > > > > I don't see how whole subnet or prefix assigned to just a single host i= s > incompatible with with RFC4291 or RFC4291bis in any way. > > Subnet, to my understanding, is a shared network comprising of a > collection of hosts managed (bordered) by one or more routers. A subnet > prefix is one assigned to the whole subnet wherein all hosts share the sa= me > prefix. > > When each host in such a share network (subnet) is assigned a unique > prefix (and hosts don=E2=80=99t share the same prefix), that prefix is no= t a subnet > prefix and should be name differently, say, =E2=80=98host prefix=E2=80=99= or =E2=80=98node prefix=E2=80=99. > > RFC4291bis defines (comments) only the subnet prefix. The draft of this > thread title deals with a prefix type not defined (commented) in the > RFC4291bis (to-be-)standard. In that, the draft under discussion in this > thread could be said =E2=80=98not in compliance with=E2=80=99 the RFC4291= bis. > > This is my logic. Odd yet? > Well, RFC4291 is quite clear there can be more than one subnet per link, there might be practical limits on how may subnet you can have on a link but there is no theoretical limit that I'm aware of. Furthermore, Wifi or other link technology will probably reach congestion collapse before you reach such limits on a modern router. While it is common for a router to have an address in the subnet this is not required, the host can just use the router's link-local address, and if the router is learned form RAs using the link-local address is the normal mode of operation anyway. Also, it's common for subnets to have more than one host again nothing requires this either. So, this isn't what most people will think of when they read RFC4291, but your only running afoul of people's assumptions not the specification itself. Therefore, bring this up might be a good idea for RFC4291bis, principle of least astonishment and all, but not absolutely necessary. --=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 --001a1143f0666f492c0555f17adb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 4, 2017 at 12:49 PM, DY Kim <dykim6@gmail.com> wrote:
in line...<= br>
=E2=80=94-
DY


> On 4 Aug 2017, at 22:58, David Farmer <farmer@umn.edu> wrote:
>
> I don't see how whole subnet or prefix assigned to just a single h= ost is incompatible with with RFC4291 or RFC4291bis in any way.

Subnet, to my understanding, is a shared network comprising of a collection= of hosts managed (bordered) by one or more routers. A subnet prefix is one= assigned to the whole subnet wherein all hosts share the same prefix.

When each host in such a share network (subnet) is assigned a unique prefix= (and hosts don=E2=80=99t share the same prefix), that prefix is not a subn= et prefix and should be name differently, say, =E2=80=98host prefix=E2=80= =99 or =E2=80=98node prefix=E2=80=99.

RFC4291bis defines (comments) only the subnet prefix. The draft of this thr= ead title deals with a prefix type not defined (commented) in the RFC4291bi= s (to-be-)standard. In that, the draft under discussion in this thread coul= d be said =E2=80=98not in compliance with=E2=80=99 the RFC4291bis.

This is my logic. Odd yet?

Well, RFC429= 1 is quite clear there can be more than one subnet per link, there might be= practical limits on how may subnet you can have on a link but there is no = theoretical limit that I'm aware of.=C2=A0 Furthermore, Wifi or other l= ink technology will probably reach congestion collapse before you reach suc= h limits on a modern router.=C2=A0 While it is common for a router to have = an address in the subnet this is not required, the host can just use the ro= uter's link-local address, and if the router is learned form RAs using = the link-local address is the normal mode of operation anyway. Also, it'= ;s common for subnets to have more than one host again nothing requires thi= s either.

So, this isn'= t what most people will think of when they read RFC4291, but your only runn= ing afoul of people's assumptions not the specification itself. Therefo= re, bring this up might be a good idea for RFC4291bis, principle of least a= stonishment and all, but not absolutely necessary.=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
--001a1143f0666f492c0555f17adb-- From nobody Fri Aug 4 13:38:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61898131D28 for ; Fri, 4 Aug 2017 13:38:26 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZXUtea_3PZ5 for ; Fri, 4 Aug 2017 13:38:24 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807A2131C34 for ; Fri, 4 Aug 2017 13:38:23 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3D57E42990 for ; Fri, 4 Aug 2017 22:38:21 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2F0D24291C; Fri, 4 Aug 2017 22:38:21 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 2BE4B2479D; Fri, 4 Aug 2017 22:38:21 +0200 (CEST) Date: Fri, 4 Aug 2017 22:38:21 +0200 From: Gert Doering To: Mark Smith Cc: DY Kim , v6ops list Message-ID: <20170804203821.GN45648@Space.Net> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:38:26 -0000 Hi, On Fri, Aug 04, 2017 at 06:18:13PM +1000, Mark Smith wrote: > No. /64s as the subnet size as been the common edge subnet/IID > boundary for almost 20 years since RFC2373. Is "a host having many IPv6 addresses" a *subnet* in the usual sense here? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Aug 4 13:43:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91E131537 for ; Fri, 4 Aug 2017 13:43:39 -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 qB766dNBwngF for ; Fri, 4 Aug 2017 13:43:37 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B1F12EBF4 for ; Fri, 4 Aug 2017 13:43:37 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u5so12113380pgn.0 for ; Fri, 04 Aug 2017 13:43:37 -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=SZfgw5MVXiV2Xl4mmIIANLzN/eqyye96dy6a86h6Ro0=; b=IketC96bs9KGkB2Zu/aQ8ZEvtOh1hciyvDVcjVtA/AB9bCSxa7ZLyYj7K8AQe4GZB6 d6ywImwIBokPpqCRf8n7c/EkD2LqO8X4d1n99M7lOmaiZyUQY1MHVToJzKzim5/uagt7 II+h8F77sYqT9kE74UHQ+7JawVukuLv0ACWKcVWycUIxztXAg0axu7/oDvr2QQn60aEd 7Ge+y1Zqwn6fqptkgDn3QwQo1AQ+RLpIULYrs6tBNT2VsNWK4HY53CT9UM3pZlWlSpvI diAiL4qTHZDMuyCoiMFBRbK0pCWnPsOfuhKtSKLxr/9qQetoPj8cK4+nKJwQLL0SHx1W /LYA== 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=SZfgw5MVXiV2Xl4mmIIANLzN/eqyye96dy6a86h6Ro0=; b=T//3BHYGIIgCINCBJGi4G0k4Q911GrczlsGSkS3w4ADNlS9NgxQrNe35hcWUZmeY1h oCD5H+Iopo5Sk658yRifoyzZyMJCTp13O5dyyhYkHnbl3fb1vP1VD5YARoP3cyaHV0JP TEUZXuLHzXCT2I+JP4Hsd/iwFBfIsKtU/m3CVLjVL3XnlMZ7g/Tqt/Q/iYjZLh9+bMIQ d06D7ga8KkNjSXdfYfboya7r/Iz8Y4Ni0kab/0NIxXLvocG0+OqSd/3rpGZXWyOsZWFZ +X2rhbRMrOz/Pro2SjvA9iVRIPfl4feAdx6fcKzVprsa3tQBeZBuiyeuIzHZyXuFuqdx w0EA== X-Gm-Message-State: AIVw110ActiMDPqCh+EyQG8GMnWyPZmJWXW35U1dsJbHOYDXdO5UX4Eq 4DFemNZVl3y6oDHDLsE= X-Received: by 10.84.130.47 with SMTP id 44mr4224249plc.305.1501879417181; Fri, 04 Aug 2017 13:43:37 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id b3sm4067030pga.32.2017.08.04.13.43.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 13:43:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 05:43:33 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:43:39 -0000 inline... --- DY > On 5 Aug 2017, at 03:15, David Farmer wrote: >=20 > Well, RFC4291 is quite clear there can be more than one subnet per = link Clear? Where? Let=E2=80=99s assume what you say is correct and hence =E2=80=98link=E2=80= =99 and =E2=80=98subnet=E2=80=99 are totally different things. Hosts on a subnet acquire the subnet prefix from RA. All hosts on the = same subnet gets the same common prefix; well eligible to be called = =E2=80=99subnet prefix=E2=80=99. Hosts generate interface addresses = through SLAAC, by generating IID independently. That=E2=80=99s why we = need DAD for no collision of the interface addresses, or equivalently, = of the IIDs on the same subnet. With the draft under discussion, however, each host gets a unique = prefix, different from those of others. And hence, there=E2=80=99s no = worry of address collision, so that DAD is not necessary in this case. = What do we call then the prefix unique to each host in this case? Should = we continue call that 'subnet prefix', with the consequence that we = should then be dealing with multiple subnet prefixes for the same = subnet? I=E2=80=99d think that=E2=80=99s an odd naming, and the prefix unique to = each host should best be called =E2=80=98host prefix=E2=80=99 or =E2=80=98= node prefix=E2=80=99. Now that neither =E2=80=98host prefix=E2=80=99 nor =E2=80=98node = prefix=E2=80=99 is defined in rfc4291bis, wherein only the subnet prefix = is defined, the current draft is using an address-related terminology = not defined in the address architecture standard. In this sense, the current draft could be said not to be compliant with = the address architecture standard. I=E2=80=99m not sure of the IETF culture, but terminology/nomenclature = is ultimately important in dealing with standards. I=E2=80=99m not at all against the draft under discussion. On the = contrary, I like this draft very much. To resolve the conflict, if any change has to take place, I=E2=80=99d = think it should be with rfc 4291bis, very unfortunately. That is, this = text in rfc4291bis | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ might better be changed to | n bits | 128-n bits | +-------------------------------+---------------------------------+ | prefix | interface ID | = +-------------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94-----------------+ > , there might be practical limits on how may subnet you can have on a = link but there is no theoretical limit that I'm aware of. Furthermore, = Wifi or other link technology will probably reach congestion collapse = before you reach such limits on a modern router. While it is common for = a router to have an address in the subnet this is not required, the host = can just use the router's link-local address, and if the router is = learned form RAs using the link-local address is the normal mode of = operation anyway. Also, it's common for subnets to have more than one = host again nothing requires this either. >=20 > So, this isn't what most people will think of when they read RFC4291, = but your only running afoul of people's assumptions not the = specification itself. Therefore, bring this up might be a good idea for = RFC4291bis, principle of least astonishment and all, but not absolutely = necessary.=20 From nobody Fri Aug 4 14:02:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2708F126CD6 for ; Fri, 4 Aug 2017 14:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkDOhb1UnU5u for ; Fri, 4 Aug 2017 14:02:46 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF70126C2F for ; Fri, 4 Aug 2017 14:02:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 271E3C6C for ; Fri, 4 Aug 2017 21:02:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fwoV3N3YPzV for ; Fri, 4 Aug 2017 16:02:45 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id D3D3BC5C for ; Fri, 4 Aug 2017 16:02:45 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id d29so10329446uai.14 for ; Fri, 04 Aug 2017 14:02:45 -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=39jxm1Ov2uvn/j3lch2FsXfbl0bcoIF3fdm0iNguLSU=; b=Fw7SDbNWwx1uO+oylBrj1PVluMRrtYfl6CvBjTxCWuuPAfEsku5Ev7c2Z7I0leGJ4X Qf5QQsYnJqSAZJYYo8HsbFmEtxH8H4BX84meezU0APuGK3eSSARQCciySTYPKU45mr6L HrSariRdMZ2Hu8ePCQFUZ+dxd8iPrIIiJxvy9Aks/9u3Nk7CkGtEj4hbSQWArpTljjHE eDpp05lR3pilV8KvxoHHOHUkuwb9eT3eZHauKIZmJzRRnsei6VOWbRxqZUTIelS/6Vw5 9U0dC3ce8tk29/q5rn8FR+se74nCvOnqOszg0amtbbcGb8mJnklipuDXX0XpiK7AUCqo yRhw== 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=39jxm1Ov2uvn/j3lch2FsXfbl0bcoIF3fdm0iNguLSU=; b=Jq8cDAztLlSZu6cIcUSj4hR6+kMj0ulF6kMnCKf/bi40h2qkKgwgBtKdqzWjBDl9gQ NFQ6EXt13RQc59blUM32t4eCmd6AXq7mMMCHe8fJYiMlC3+WKjFOSnPB/izjeRa875ec NA14MmFHpk7kX6ocXY3/gow592p0ozkP/vnJFFC5QmHCIs6ZU6WYT6EZ2cEtFJRGPOtJ 6pphBjZdpuPiAXtPEcRML/xnqGJ2n7uj+cxTNXScrpEFi4CUWjar27K7DfGRPy5NRg2j 7DPgsTU8/PZmuG8NWW1FMwPkFJwKBJt8933vnXX4Lzx1Fjq/Lvns5gFZHYKnT0E9bIBA kW/w== X-Gm-Message-State: AHYfb5ivPxAdL1kW/9Dax3/S/GQgxRwXgGVND2jy143nceKO9rRuEEIy vsQvYSFtsOaX+RfITWzTZ1v1J35k7pbbtsxZY7NwCGEVBbry0jSudraUsHW5Hqo8WyfkfCGaiwV wJAWljjKA4OScLDAq X-Received: by 10.159.33.211 with SMTP id 77mr2248147uac.218.1501880565017; Fri, 04 Aug 2017 14:02:45 -0700 (PDT) X-Received: by 10.159.33.211 with SMTP id 77mr2248141uac.218.1501880564811; Fri, 04 Aug 2017 14:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Fri, 4 Aug 2017 14:02:44 -0700 (PDT) In-Reply-To: <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> From: David Farmer Date: Fri, 4 Aug 2017 16:02:44 -0500 Message-ID: To: DY Kim Cc: Mikael Abrahamsson , v6ops list Content-Type: multipart/alternative; boundary="001a113552608fc61d0555f3d1ad" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:02:49 -0000 --001a113552608fc61d0555f3d1ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 4, 2017 at 3:43 PM, DY Kim wrote: > inline... > > --- > DY > > > > On 5 Aug 2017, at 03:15, David Farmer wrote: > > > > Well, RFC4291 is quite clear there can be more than one subnet per link > > Clear? Where? > Read Section 2.1 of RFC4291, multiple subnets per link in in the last paragraph of that section. > Let=E2=80=99s assume what you say is correct and hence =E2=80=98link=E2= =80=99 and =E2=80=98subnet=E2=80=99 are > totally different things. > > Hosts on a subnet acquire the subnet prefix from RA. All hosts on the sam= e > subnet gets the same common prefix; well eligible to be called =E2=80=99s= ubnet > prefix=E2=80=99. Hosts generate interface addresses through SLAAC, by gen= erating > IID independently. That=E2=80=99s why we need DAD for no collision of the= interface > addresses, or equivalently, of the IIDs on the same subnet. > > With the draft under discussion, however, each host gets a unique prefix, > different from those of others. And hence, there=E2=80=99s no worry of ad= dress > collision, so that DAD is not necessary in this case. What do we call the= n > the prefix unique to each host in this case? Should we continue call that > 'subnet prefix', with the consequence that we should then be dealing with > multiple subnet prefixes for the same subnet? > > I=E2=80=99d think that=E2=80=99s an odd naming, and the prefix unique to = each host should > best be called =E2=80=98host prefix=E2=80=99 or =E2=80=98node prefix=E2= =80=99. > There are lots of links with only one hosts, at least at some point in its life cycle, are you saying that a subnet prefix isn't a subnet until the second host shows up? Now that neither =E2=80=98host prefix=E2=80=99 nor =E2=80=98node prefix=E2= =80=99 is defined in rfc4291bis, > wherein only the subnet prefix is defined, the current draft is using an > address-related terminology not defined in the address architecture > standard. > > In this sense, the current draft could be said not to be compliant with > the address architecture standard. > > I=E2=80=99m not sure of the IETF culture, but terminology/nomenclature is > ultimately important in dealing with standards. > > I=E2=80=99m not at all against the draft under discussion. On the contrar= y, I like > this draft very much. > > To resolve the conflict, if any change has to take place, I=E2=80=99d thi= nk it > should be with rfc 4291bis, very unfortunately. That is, this text in > rfc4291bis > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ > > might better be changed to > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | prefix | interface ID | > +-------------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94-----------------+ > For a whole bunch of other reasons I'd be just fine with that suggestion, I think the term subnet brings a who bunch of IPv4 baggage that is really complicating other part of the RFC4291bis conversations. I'm all for banishing the term subnet from RFC4291bis, except when comparing to an IPv4 subnet. > > , there might be practical limits on how may subnet you can have on a > link but there is no theoretical limit that I'm aware of. Furthermore, > Wifi or other link technology will probably reach congestion collapse > before you reach such limits on a modern router. While it is common for = a > router to have an address in the subnet this is not required, the host ca= n > just use the router's link-local address, and if the router is learned fo= rm > RAs using the link-local address is the normal mode of operation anyway. > Also, it's common for subnets to have more than one host again nothing > requires this either. > > > > So, this isn't what most people will think of when they read RFC4291, > but your only running afoul of people's assumptions not the specification > itself. Therefore, bring this up might be a good idea for RFC4291bis, > principle of least astonishment and all, but not absolutely necessary. > --=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 --001a113552608fc61d0555f3d1ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 4, 2017 at 3:43 PM, DY Kim <dykim6@gmail.com>= wrote:
inline...

---
DY


> On 5 Aug 2017, at 03:15, David Farmer <farmer@umn.edu> wrote:
>
> Well, RFC4291 is quite clear there can be more than one subnet per lin= k

Clear? Where?

Read Section 2.1 of RFC42= 91, multiple subnets per link in in the last paragraph of that section.
=C2=A0
Let=E2=80=99s assume what you say is correct and hence =E2=80=98link=E2=80= =99 and =E2=80=98subnet=E2=80=99 are totally different things.

Hosts on a subnet acquire the subnet prefix from RA. All hosts on the same = subnet gets the same common prefix; well eligible to be called =E2=80=99sub= net prefix=E2=80=99. Hosts generate interface addresses through SLAAC, by g= enerating IID independently. That=E2=80=99s why we need DAD for no collisio= n of the interface addresses, or equivalently, of the IIDs on the same subn= et.

With the draft under discussion, however, each host gets a unique prefix, d= ifferent from those of others. And hence, there=E2=80=99s no worry of addre= ss collision, so that DAD is not necessary in this case. What do we call th= en the prefix unique to each host in this case? Should we continue call tha= t 'subnet prefix', with the consequence that we should then be deal= ing with multiple subnet prefixes for the same subnet?

I=E2=80=99d think that=E2=80=99s an odd naming, and the prefix unique to ea= ch host should best be called =E2=80=98host prefix=E2=80=99 or =E2=80=98nod= e prefix=E2=80=99.

There are lots of li= nks with only one hosts, at least at some point in its life cycle, are you = saying that a subnet prefix isn't a subnet until the second host shows = up?

Now that neither =E2=80=98host prefix=E2=80=99 nor =E2=80=98node prefix=E2= =80=99 is defined in rfc4291bis, wherein only the subnet prefix is defined,= the current draft is using an address-related terminology not defined in t= he address architecture standard.

In this sense, the current draft could be said not to be compliant with the= address architecture standard.

I=E2=80=99m not sure of the IETF culture, but terminology/nomenclature is u= ltimately important in dealing with standards.

I=E2=80=99m not at all against the draft under discussion. On the contrary,= I like this draft very much.

To resolve the conflict, if any change has to take place, I=E2=80=99d think= it should be with rfc 4291bis, very unfortunately. That is, this text in r= fc4291bis

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

might better be changed to

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0128-n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------------------------------+------------------------= ---------+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix=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= =A0interface ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------------------------------+=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94-----------------+

For a whole bunch of other reasons I'd be= just fine with that suggestion, I think the term subnet brings a who bunch= of IPv4 baggage that is really complicating other part of the RFC4291bis c= onversations. I'm all for banishing the term subnet from RFC4291bis, ex= cept when comparing to an IPv4 subnet. =C2=A0
=C2=A0
> , there might be practical limits on how may subnet you can have on a = link but there is no theoretical limit that I'm aware of.=C2=A0 Further= more, Wifi or other link technology will probably reach congestion collapse= before you reach such limits on a modern router.=C2=A0 While it is common = for a router to have an address in the subnet this is not required, the hos= t can just use the router's link-local address, and if the router is le= arned form RAs using the link-local address is the normal mode of operation= anyway. Also, it's common for subnets to have more than one host again= nothing requires this either.
>
> So, this isn't what most people will think of when they read RFC42= 91, but your only running afoul of people's assumptions not the specifi= cation itself. Therefore, bring this up might be a good idea for RFC4291bis= , principle of least astonishment and all, but not absolutely necessary.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Service= s
Office of Information Technology
University of Minnesota=C2=A0=C2= =A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-08= 15
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
--001a113552608fc61d0555f3d1ad-- From nobody Fri Aug 4 14:08:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA20120727 for ; Fri, 4 Aug 2017 14:08:25 -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 ZyJ-zEZL2Q8T for ; Fri, 4 Aug 2017 14:08:23 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5934120713 for ; Fri, 4 Aug 2017 14:08:23 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id y129so12249709pgy.4 for ; Fri, 04 Aug 2017 14:08:23 -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=NCmtQytObfN5Hmq47tx4PpVo8Wg8r2dZGt/qP+RfwRI=; b=qAwqSEY/qz6CeBNvh2akWGuvLhYRobjEpJZACUlIdpgVsNcidrhSZyg/F02PQ0peXe bVc/rmbo+X3FMkMZS7GDMmW91LubWM+YMQyoqti56Z1N9wLDNW1zwv/xdf1QinwdAaQ9 G8zF91xhxfgVassziYcqHEDaK3uOXyzZUQGSGCPyv4l9Gso0kwHmpVVWNaqXSAo2Cd3A tZwvvQWSsk2z+HOt8Suysno4eeKTxUWt2DFLCQnJEaXAK1fspho4XNIkAW7A432ULo+Y EtxsrUdjBk9NFIBaTp3u2d2Kkys+mJGLP3I64FRlKajZOvQs4yCjSddIYyNFC6RJGPT4 VyyA== 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=NCmtQytObfN5Hmq47tx4PpVo8Wg8r2dZGt/qP+RfwRI=; b=f37ASF116CGLUwRr3fZ3DNZAUYUiwnlLoq2JASpehyH0AOqssInoysDWu7sdB3WXvk /dYPiyso9dQS9qlDQ6OhAcUsudbRVVheRj1/35icGPM+/HjHll8aX4YBslLW7z68DjaL qjCx93k4gO83NEVhFR4ogUNUwen/jIEyEFDr//twUu+7cK5N4+Vjcq26lkGm8cDx0DW1 NXhkG950ZLOxgUqnTYkntQKEga13moG/KXntp/QV84XjTRWVBd6Dp0Oc3tvNIvssmPla J3Xwnwne3sGnzpwZKWQo/cQ6wyVows+PqIucjG4jPiePdSy3F7Am/wErZFWvRP1HJ0gi 5Uow== X-Gm-Message-State: AIVw112s5pzAPMi7XuQXM2ujr2d+udvnQyBXDZddEIRLa+hZP2FbQ7Y9 +aKwT+55kJMoiQ== X-Received: by 10.84.224.134 with SMTP id s6mr4452056plj.4.1501880903381; Fri, 04 Aug 2017 14:08:23 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id s3sm2912448pgn.70.2017.08.04.14.08.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:08:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 06:08:19 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <4E8547E5-14A7-4BDD-9D13-EE734C955193@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:08:25 -0000 It=E2=80=99s not =E2=80=98multiple subnets per link=E2=80=99, but = =E2=80=98multiple subnet prefixes per link=E2=80=99. "Multiple subnet prefixes may be assigned to the same link.=E2=80=9D --- DY > On 5 Aug 2017, at 06:02, David Farmer wrote: >=20 > Read Section 2.1 of RFC4291, multiple subnets per link in in the last = paragraph of that section. From nobody Fri Aug 4 14:09:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8F126E64 for ; Fri, 4 Aug 2017 14:09:56 -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 SE1KNVQDp1rG for ; Fri, 4 Aug 2017 14:09:55 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2CC126CD6 for ; Fri, 4 Aug 2017 14:09:55 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id t86so12181602pfe.2 for ; Fri, 04 Aug 2017 14:09:55 -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=P8fFJfkh/zSa2xobM4Zu9VitIlBC7jx6NQfIvHMJb/A=; b=ao4qv5Ms4IbYrxqq35R0d1QnfXx92VNVPwbYJtw/ThmEiw5SiRaODdEYDVfuf7HsNB tLbDBbX74yl3bkzF1K2Ck6tTEd5KXNK31so7Z+8jQDSAqtzlJ6sm1IMpqCqV2jlQNt0T 46TJuvT8CCdMIvdMlos2+20/qYHecgFVgcTwoKkQNMtxirvDoJyllc9hpOdlEGBnQDW6 xWpD8f2TOdCFtlhwG2VmtsPEtMgAroIKs++kHtHNbVMsUBLt6PqklMPXYOtzt9tNx77s fx1khv4hszT7i51cfJ9VTQ5ro6qwWHsLOYicYQoenT3kO41fVdNS/4kYBBDrKoeHIgk1 iJwg== 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=P8fFJfkh/zSa2xobM4Zu9VitIlBC7jx6NQfIvHMJb/A=; b=ifpIomK58MJsxZLBuYLKwtFooE7/9PA29aJVzojL2rrgOmVBPJxc/kx1rF2eEsfqsz Y4Ghx7FqBwWo/rPWPemwHqqyyhG8W81bZknbXRvsl4MabYg3NchJN6jO1XU1k/bYlMBB nhIEtna3tfuVoR92j1rQkCu9WWJ/kRzzzsXvrev/6y4fPcCdfFxUcd2qskUrfwlU/+5T UUJqIH8hoAl3thYSFqlyctKR8FZvjkIhnBbdqAb5de7jZOhafqGQ47j/iuPtELwfKyv8 E0EqKQ2IfoKgQ1Q6ANa4kRsRhVIgtr1UorfcpDlv4jVNImnrgldy7nZrURBbI0p3KOjY otWw== X-Gm-Message-State: AIVw110JlvujT+XHJw+PiEdLJfleFe+MAzH7CeuhCBMSc2hYw/oN+6MS krfmqe4Vnm5x1g== X-Received: by 10.84.217.93 with SMTP id e29mr4330501plj.472.1501880995135; Fri, 04 Aug 2017 14:09:55 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id v1sm5789716pfi.52.2017.08.04.14.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:09:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 06:09:51 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <5B26B848-6900-4D90-BBFF-B6E9E6DA54C9@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:09:56 -0000 You seem to be mixed up between subnet and subnet prefix. --- DY > On 5 Aug 2017, at 06:02, David Farmer wrote: >=20 > There are lots of links with only one hosts, at least at some point in = its life cycle, are you saying that a subnet prefix isn't a subnet until = the second host shows up? From nobody Fri Aug 4 14:10:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F814126B6D for ; Fri, 4 Aug 2017 14:10:56 -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 sUxaXNG8qkEN for ; Fri, 4 Aug 2017 14:10:55 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936641252BA for ; Fri, 4 Aug 2017 14:10:55 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v189so12299271pgd.2 for ; Fri, 04 Aug 2017 14:10:55 -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=KOL/mqm3bnbizNHrrXZetTNF/WjaLQyXp4S5/rujIaw=; b=DCXZsaY0lWR25Cp5dgpaWALwKFISGvsQrulcrTQW0crkCRfaMem1STIBJS/tgiOuRK AKVeoCw6/V87qlt/a/SoZmGleX3xD1IJ9OnrT2WQ1QR3zZ+OrCo2bf6/amWGe09AhuUm DbTSTvdgpCpJpOlPoxE/oOBh4xpHa9WajLYleFf3AnbcY+B9xIiFXh22ZQX1j/c52IE4 Pxn4OvYa6/DF/kj6nL6BCkj2cVumIdsP0Q0xXcMr1myRJ0kJsvAD1xhGsm0MZYsVQ7Hm 1LrWwYQ/asCnFYM8jJBKCAWSzR5Kc04NXlXEQ6wKV+1RJlByoIwF0cZlT0Is1t5mDQxk D1hQ== 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=KOL/mqm3bnbizNHrrXZetTNF/WjaLQyXp4S5/rujIaw=; b=JwPjvABBy8TGo1JcE+uO3tOhT4Qe/Lm4KXMemExxSZOLGlIXBx3dDmikB/AN0zNob1 /JpqyyD3n97bBHqnK/N8F5ONxUdaslMTdj04EimJvYKlQXLAbj+vK/6YZiMr2skFfBiV RZeqqjqJCPKB/Gsp0hddNhH+R2uv8hJKnULToB5I+G7eliavGClfOmrF9CmrW9MXGjup CGwhV0DHRgKIa9vr9evpDbp112wdtg78n/hTNuDVVFTYyXEJ11qLobmyyY3REBcFokOL soh+nvNFbsfkdNYeKECvg5eB1BnN/xOhPemmWgwnIPb3aTsdFPeXWcQ5pIbDw8Kyh45X NANQ== X-Gm-Message-State: AIVw112VAKH67lmvO0qWEVw+VAHYUW/8p9edUHpnioEncVnZ9Qho46/L zWtMuM3bKhLJ8s99kGM= X-Received: by 10.84.233.132 with SMTP id l4mr4313983plk.298.1501881055169; Fri, 04 Aug 2017 14:10:55 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id v1sm5789716pfi.52.2017.08.04.14.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:10:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 06:10:53 +0900 Cc: Mikael Abrahamsson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <66829B36-5514-4911-9930-9715A387E68B@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:10:56 -0000 We agree at least on one point.. :-). --- DY > On 5 Aug 2017, at 06:02, David Farmer wrote: >=20 > I think the term subnet brings a who bunch of IPv4 baggage that is = really complicating other part of the RFC4291bis conversations. I'm all = for banishing the term subnet from RFC4291bis, except when comparing to = an IPv4 subnet. =20 From nobody Fri Aug 4 14:14:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902AB124B18 for ; Fri, 4 Aug 2017 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oaf0GWh8pWi9 for ; Fri, 4 Aug 2017 14:14:28 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BE9126CB6 for ; Fri, 4 Aug 2017 14:14:28 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 5D37FC73 for ; Fri, 4 Aug 2017 21:14:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm97PXPtm9J8 for ; Fri, 4 Aug 2017 16:14:28 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 25377C59 for ; Fri, 4 Aug 2017 16:14:28 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id b3so11043772vkh.7 for ; Fri, 04 Aug 2017 14:14:28 -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=05sIAp83X0MjUXwUUNIJXHTWSVxcoVdIfppeZy/47AA=; b=IoOHPGQci6I9h50F+cYj3imOu8YNcGjxJMNbdkgYOMizokEYC9I/IrzSIN7AxI3krN ZrmKf9imf7SIYgz7tz7Ef9xLfqns5pLpTzhN0RmWMjAc7roDlVZwO+UIr87wwns9ldkg 1Xcc1yCk9ZfdeaFjGU/jBZ1husBGPuHqvGEqn0EcXUZugwdNoydM7+W2qujbazYQ/DBH 6y7yftcWFlsPs3S4K29wquB6WlSuR2jP/SKtZQS9rZvJSUbSeFhrW87FxacpPGkzIDUB a5VkSTvQ1xFM8Lh9CgNu1dl22Bx+JGwPjmqGryrhHpiihx/w7bRM2ENqB7G4rmxPIA8c PlKg== 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=05sIAp83X0MjUXwUUNIJXHTWSVxcoVdIfppeZy/47AA=; b=NT1nKc4BgxBSiH8xLGruw4FUhnyAER1BI0pqWFA0f7TIznOz2iIT/M+SpY7YMHbTpF aNzyqnbgkjjKKFoiA3hldRHkyjeMrt8+YzwLOkJpr4JtJ3jeB1UwYHZxSNTXWcFzhwqQ oGY8y/3xDw+d0/3uuDn7T2GOrseGXt1y1Sqz0dwFVe5ZiYJ38zl7Z1JIGrnrZu4tmOjz cVwtjo/m8yRTYrClcI+l13XTzDvHSzlvX31HcmX4kBYzBvbAwdaqOENEgXE2mAvufjkA CBVkrIPIiyAXRIDP54dQh6O2lrEoYPq92WhjHGlTKVHgi6OxwW6GptNqmUgukWZHpFT6 eTaA== X-Gm-Message-State: AHYfb5ijKjK2sFs88jxI6kiFEzWTVYcbrtd783oNnmuITALx/i8QE2Rd jc2Qzgqlgwg/wfPpp8rvVUYHoZdfNx6FFJhVhrPnRQSzvfDHWDozGZAM01Vk1E3qyTmWLD12zM7 7Jc03dMVc5nd5EeD8 X-Received: by 10.31.2.67 with SMTP id 64mr2306328vkc.7.1501881267718; Fri, 04 Aug 2017 14:14:27 -0700 (PDT) X-Received: by 10.31.2.67 with SMTP id 64mr2306318vkc.7.1501881267555; Fri, 04 Aug 2017 14:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Fri, 4 Aug 2017 14:14:26 -0700 (PDT) In-Reply-To: <5B26B848-6900-4D90-BBFF-B6E9E6DA54C9@gmail.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <2E470571-1620-4527-9489-D4D953000040@gmail.com> <336987B8-56B0-4C59-A9B1-8B91D4D09BD1@gmail.com> <3D12AB07-7CE4-4625-ADDF-5F7CEC8CB115@gmail.com> <0E577FCD-857E-4F2D-947B-D4AA201DE346@gmail.com> <8DA09B07-00EE-4132-9125-8FED16582F66@gmail.com> <7938F668-7CA2-4C21-8674-4073221E088E@gmail.com> <5B26B848-6900-4D90-BBFF-B6E9E6DA54C9@gmail.com> From: David Farmer Date: Fri, 4 Aug 2017 16:14:26 -0500 Message-ID: To: DY Kim Cc: Mikael Abrahamsson , v6ops list Content-Type: multipart/alternative; boundary="001a113dc5f472a89e0555f3fb0c" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:14:30 -0000 --001a113dc5f472a89e0555f3fb0c Content-Type: text/plain; charset="UTF-8" I might have be talking a little loosely, but you seem to see more significance in the difference than I do. On Fri, Aug 4, 2017 at 4:09 PM, DY Kim wrote: > You seem to be mixed up between subnet and subnet prefix. > > --- > DY > > > > On 5 Aug 2017, at 06:02, David Farmer wrote: > > > > There are lots of links with only one hosts, at least at some point in > its life cycle, are you saying that a subnet prefix isn't a subnet until > the second host shows up? > > -- =============================================== 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 =============================================== --001a113dc5f472a89e0555f3fb0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I might have be talking a little loosely, but you seem to = see more significance in the difference than I do.

=C2= =A0

On= Fri, Aug 4, 2017 at 4:09 PM, DY Kim <dykim6@gmail.com> wrote= :
You seem to be mixed up between subnet = and subnet prefix.

---
DY


> On 5 Aug 2017, at 06:02, David Farmer <farmer@umn.edu> wrote:
>
> There are lots of links with only one hosts, at least at some point in= its life cycle, are you saying that a subnet prefix isn't a subnet unt= il the second host shows up?




--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
--001a113dc5f472a89e0555f3fb0c-- From nobody Fri Aug 4 18:48:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1E4126B6D for ; Fri, 4 Aug 2017 18:48:35 -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 iSlglciKzk-S for ; Fri, 4 Aug 2017 18:48:34 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E06129A9F for ; Fri, 4 Aug 2017 18:48:34 -0700 (PDT) X-AuditID: 60721c4c-001ff70000004e62-d5-598523ef9239 Received: from VAADCEX15.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id AF.76.20066.FE325895; Fri, 4 Aug 2017 21:48:33 -0400 (EDT) Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX15.cable.comcast.com (147.191.102.82) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 4 Aug 2017 21:48:31 -0400 Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1293.002; Fri, 4 Aug 2017 21:48:30 -0400 From: "Brzozowski, John" To: Gert Doering , Mark Smith CC: v6ops list Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDWGcS5aM47U/l0elH2W6kOwwzKJ0/x0A Date: Sat, 5 Aug 2017 01:48:30 +0000 Message-ID: <8EABC877-12F1-4191-B7E2-2D00C9609DD1@cable.comcast.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <20170804203821.GN45648@Space.Net> In-Reply-To: <20170804203821.GN45648@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="utf-8" Content-ID: <469DC2BC0E4DE945B974D297FB8716ED@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Ub2wTZRzOe9c/17oX397W9qXbkB180Cnt3JBUM1GMmiqK+2BMKkS4dUfb rWvLXbs//mM492WYqUOmlCAQS4jTRJ1MmBkDCs5uZsE4ZDIUMlmcTJOhRHFsQe/tXbern+53 z/P+nuf3e+7NMTTbYXYwwXBMEMN8iDOYdVukJ9yr/ljR5i0b72DcvW9eN7r7znxldH8zeJx+ mPb0JX4yepLJWcrzxUeXdFX08+bKGiEUbBBE19ot5sDOPWkqegs2zZ2YAC3gW9gOTAxGq/GB 6cN0OzAzLDpK4Za5Swbl5QTA47/+QikvaYCH+i7TpMWA1uAjpy4a2wHDFKDHceeuhwhMozvw VFfCSOp8tBGfnR2hSF2ANuGhyYRal+Pf0lcyZ3RoJe7sOp2pIXoUz5wb1CteYzTun/9ATwgT cuGDh+YzNUA2fGP4Y0oxs+Pxyf2UsgLCyf6ztFJb8dUrtzLnrciJz1/7UKfg9+CRsUmg1GW4 99CAipfgm++fM5BdaHQX/uRLlyL/AL7QPWBQ6hL8zs4JdU4LHtozqbba8ekzx/RvgcKEZqLE olJCo5TQKCU0SgeAvhssa+D5Gl99IBKPlZU7fXx1SHD6IvU+XoqRZw8gn14seuoY+LPLkwKI AVwevGxq87J6vkFqrk+BOobirPClwde87JLqSE1zgJcCm8V4SJC4Ajj1xuteFi7A1fFQHeeA n3Nyf/4CGhYapZAQk+8atww+S4TsC5wUl6JBXzASlzbHxVAKYIaWZRtoWQDW8M0vCmJEMUuB QkbH2eHLd7d6WeTnY0KdIEQFMcs2MgyHIZAvMGsRBb/QtDUYimVpue8+vTwp0jKZYYvhEiJo 0xKaeUtgS6nc59DS/x+ZYkwp4Gfy5LnDxB5KUb5eCvpV63xYUSCjeVk0Y7sUFpOM2CyosSyG wa/liGxZKtduGLQB5shc+gbF6sKRsOCwwzXEFJHjgXh4YWWHDS63NHnZ2zUEsXYUwc7Z7V7W qsEX3R3L4TUkdy3VsLkDZP8V08An35V8uI/skSf/SRY3ZuHTBLxNBTMLY+gimEXFNPsWKfta VSbXbVoOlpKDnX91Bwk2xse0wR7cvoMEq6JqsO8SkM2COcEmCGXLUrlOjhaAy2caq5oGLBWt q5OeJztgZa1Y+P17615YW+vs3vv2xk7Pg21M5ejRicbH+jftH1u/wX9yL2uK/u2k525ObT31 TAnuSY/qKh7Ztru1P3j4leQK28re0h9+/vfHC3fqDPf3PLd73dTw8e9WDf9eXTt6/VNv1chf M/+cd4dO0le3feYqd2+4yOmkAH9vKS1K/H92sFG/oQUAAA== Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 01:48:36 -0000 SSBob3N0IG9uIGEgVkxBTiBjYW4gaGF2ZSBtdWx0aXBsZSBhZGRyZXNzZXMgd2hpY2ggZG9lcyBu b3QgaW5kaWNhdGUgdGhhdCB0aGUgaG9zdCBoYXMgdGhlIGVudGlyZSBzdWJuZXQgb3IgcHJlZml4 Lg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgR2VydCBE b2VyaW5nIDxnZXJ0QHNwYWNlLm5ldD4NCkRhdGU6IEZyaWRheSwgQXVndXN0IDQsIDIwMTcgYXQg MTY6MzgNClRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KQ2M6IHY2b3Bz IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcudHh0DQoNCiAg ICBIaSwNCiAgICANCiAgICBPbiBGcmksIEF1ZyAwNCwgMjAxNyBhdCAwNjoxODoxM1BNICsxMDAw LCBNYXJrIFNtaXRoIHdyb3RlOg0KICAgID4gTm8uIC82NHMgYXMgdGhlIHN1Ym5ldCBzaXplIGFz IGJlZW4gdGhlIGNvbW1vbiBlZGdlIHN1Ym5ldC9JSUQNCiAgICA+IGJvdW5kYXJ5IGZvciBhbG1v c3QgMjAgeWVhcnMgc2luY2UgUkZDMjM3My4NCiAgICANCiAgICBJcyAiYSBob3N0IGhhdmluZyBt YW55IElQdjYgYWRkcmVzc2VzIiBhICpzdWJuZXQqIGluIHRoZSB1c3VhbCBzZW5zZQ0KICAgIGhl cmU/DQogICAgDQogICAgR2VydCBEb2VyaW5nDQogICAgICAgICAgICAtLSBOZXRNYXN0ZXINCiAg ICAtLSANCiAgICBoYXZlIHlvdSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0K ICAgIA0KICAgIFNwYWNlTmV0IEFHICAgICAgICAgICAgICAgICAgICAgICAgVm9yc3RhbmQ6IFNl YmFzdGlhbiB2LiBCb21oYXJkDQogICAgSm9zZXBoLURvbGxpbmdlci1Cb2dlbiAxNCAgICAgICAg ICBBdWZzaWNodHNyYXRzdm9ycy46IEEuIEdydW5kbmVyLUN1bGVtYW5uDQogICAgRC04MDgwNyBN dWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQogICAg VGVsOiArNDkgKDApODkvMzIzNTYtNDQ0ICAgICAgICAgICBVU3QtSWROci46IERFODEzMTg1Mjc5 DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCiAgICB2Nm9wc0BpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICANCiAgICANCg0K From nobody Fri Aug 4 18:49:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E8126B6D for ; Fri, 4 Aug 2017 18:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_SPAM=0.5, 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 o5JiwAcxHcwv for ; Fri, 4 Aug 2017 18:49:46 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 5ED2E129B5E for ; Fri, 4 Aug 2017 18:49:46 -0700 (PDT) X-AuditID: 60721c4b-719ff70000000a8e-8d-5985243609ed Received: from VAADCEX11.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 6C.A8.02702.63425895; Fri, 4 Aug 2017 21:49:44 -0400 (EDT) Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 4 Aug 2017 21:49:41 -0400 Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1293.002; Fri, 4 Aug 2017 21:49:41 -0400 From: "Brzozowski, John" To: "Brzozowski, John" , "Gert Doering" , "Mark Smith" CC: v6ops list Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDWGcS5aM47U/l0elH2W6kOwwzKJ0/x0AgAAAVIA= Date: Sat, 5 Aug 2017 01:49:41 +0000 Message-ID: <22284889-4CCB-485E-A969-CD29E1BB4858@cable.comcast.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <20170804203821.GN45648@Space.Net> <8EABC877-12F1-4191-B7E2-2D00C9609DD1@cable.comcast.com> In-Reply-To: <8EABC877-12F1-4191-B7E2-2D00C9609DD1@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="utf-8" Content-ID: <31C32376A13B834484EF9250EEB3C59D@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf0wbZRjOd3el19pvXg/afusA4cQsq7OA4tIQNP6hE2Oy7I9lptiEHeVG G4623rUMXBTmbFTUzGGZ2SU6HV0yB1FhP4S5aew2HFNCTObmNrvEDcURNGQkLkyzeF/vClf/ uvee53uf53nf73I0yb5rddPhSFyQIrzIFVmpbfJzvkd8VUl/zcFJ1nd8z6LZN372nNn3/cRp 8imycVzJmhvT6SWi8cTQdWoz2WRtaBXEcKcgVT+5zRrKvn+ais07uvoW/6Z6QdrRByw0YurQ yMRhog9YaZb5kkDnUvNm7eUbgAZGj+rMeYCS91IAtxQxG9Cxb6+ZcV3C9KDhbNqEa5J5AM3u U3J4MfMiml6aIrQzATQ5o6g1rdb16MAJEcMUU4Xm797IHYfM0+jnqdGcPMv0U2h0rgHXFuYZ lP1jMIcDxonuXBgmNCsXujpzgNAmYFD61DSp1Q506+a9XBwH40WXFj6lNHw9mro8A7S6Bh0/ 9LWOV6K7H10swtFIZh36/GS1Jl+Pvli4rU9ViVJv/6rHtKPJ/TN6qwudOTtmeg+sUQyJlBUl xaCkGJQUg9LHwHQElHfyfGuwIxRNxGtqvUG+RRS8wWhHkJfj+DkK8M1Lpc+Pgc+Wns0Ahgac Df5mSfpZE98pd3dkQDtNcA64c+I1P7uqJdraHeLlULOUEAWZK4Gz77zuZ+Ey3JIQ2zk3fKtS 7S9eRiPCDlkU4uqnxpXDLVjItczJCTkWDoajCbk5IYkZgGhSle0kVQHYyne/LEhRzSwD1tAU 54KvPLzbzzJtfFxoF4SYIOXZHTTNIQgeVBvtktAmdG0Pi/E8rfY9blKTMkYmF7YMrsKCTiNh yFsJez1qn9tI/z8yQVsyoI22qbkj2B7KMb5DDrfp1sXwsRIVteXRnO1qWMapIJsHDZZlMPyd uiJnniq0uwCSgD72z/k7BEtFohHB7YIbsCmDj4cSkeWR3U5YYe/ys/cbCGztLoX9Sz1+1mHA V9zdFXCBUbtWG9jCAPlfxRwIqt9KMdyL3W3qj2RlYhZ2YfA+HcwNjGAgdzU6Zpi3VJvXoTOF bnPqYgl1sf++ugsvNs7HjYv9pGcXXqyO6ov9AINsHixYrIIpZ54qdHL3AiUqVW+vylo9p95o 3BkYvPbh7r17/prdV3fzhaa1G0cubXo00C82m8bGD96uHTry0vqhVMzckv3zIt3w06atwuCA Z13T+JXk9Yp64rLX4ghImZGmLV8dLXee+fEGZ0N1AfubP2z0DA8wwi8PXdn6xK2106WZoUP2 8OLVk66K6pRX+p2j5BBf6yElmf8P5ZuDo6AFAAA= Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 01:49:47 -0000 QSBob3N0LCBub3QgSSBob3N0LCBvbiBhIFZMQU7igKYNCg0KSm9obg0KKzEtNDg0LTk2Mi0wMDYw DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJCcnpvem93c2tpLCBKb2huIiA8Sm9obl9Ccnpvem93 c2tpQGNvbWNhc3QuY29tPg0KRGF0ZTogRnJpZGF5LCBBdWd1c3QgNCwgMjAxNyBhdCAyMTo0OA0K VG86IEdlcnQgRG9lcmluZyA8Z2VydEBzcGFjZS5uZXQ+LCBNYXJrIFNtaXRoIDxtYXJrenp6c21p dGhAZ21haWwuY29tPg0KQ2M6IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb djZvcHNdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QtMDcudHh0DQoNCiAgICBJIGhvc3Qgb24gYSBWTEFOIGNhbiBoYXZlIG11bHRp cGxlIGFkZHJlc3NlcyB3aGljaCBkb2VzIG5vdCBpbmRpY2F0ZSB0aGF0IHRoZSBob3N0IGhhcyB0 aGUgZW50aXJlIHN1Ym5ldCBvciBwcmVmaXguDQogICAgDQogICAgSm9obg0KICAgICsxLTQ4NC05 NjItMDA2MA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTog djZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBHZXJ0IERvZXJpbmcg PGdlcnRAc3BhY2UubmV0Pg0KICAgIERhdGU6IEZyaWRheSwgQXVndXN0IDQsIDIwMTcgYXQgMTY6 MzgNCiAgICBUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4NCiAgICBDYzog djZvcHMgPHY2b3BzQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZ3ZDogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcu dHh0DQogICAgDQogICAgICAgIEhpLA0KICAgICAgICANCiAgICAgICAgT24gRnJpLCBBdWcgMDQs IDIwMTcgYXQgMDY6MTg6MTNQTSArMTAwMCwgTWFyayBTbWl0aCB3cm90ZToNCiAgICAgICAgPiBO by4gLzY0cyBhcyB0aGUgc3VibmV0IHNpemUgYXMgYmVlbiB0aGUgY29tbW9uIGVkZ2Ugc3VibmV0 L0lJRA0KICAgICAgICA+IGJvdW5kYXJ5IGZvciBhbG1vc3QgMjAgeWVhcnMgc2luY2UgUkZDMjM3 My4NCiAgICAgICAgDQogICAgICAgIElzICJhIGhvc3QgaGF2aW5nIG1hbnkgSVB2NiBhZGRyZXNz ZXMiIGEgKnN1Ym5ldCogaW4gdGhlIHVzdWFsIHNlbnNlDQogICAgICAgIGhlcmU/DQogICAgICAg IA0KICAgICAgICBHZXJ0IERvZXJpbmcNCiAgICAgICAgICAgICAgICAtLSBOZXRNYXN0ZXINCiAg ICAgICAgLS0gDQogICAgICAgIGhhdmUgeW91IGVuYWJsZWQgSVB2NiBvbiBzb21ldGhpbmcgdG9k YXkuLi4/DQogICAgICAgIA0KICAgICAgICBTcGFjZU5ldCBBRyAgICAgICAgICAgICAgICAgICAg ICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZA0KICAgICAgICBKb3NlcGgtRG9sbGlu Z2VyLUJvZ2VuIDE0ICAgICAgICAgIEF1ZnNpY2h0c3JhdHN2b3JzLjogQS4gR3J1bmRuZXItQ3Vs ZW1hbm4NCiAgICAgICAgRC04MDgwNyBNdWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEz NjA1NSAoQUcgTXVlbmNoZW4pDQogICAgICAgIFRlbDogKzQ5ICgwKTg5LzMyMzU2LTQ0NCAgICAg ICAgICAgVVN0LUlkTnIuOiBERTgxMzE4NTI3OQ0KICAgICAgICANCiAgICAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgdjZvcHMgbWFp bGluZyBsaXN0DQogICAgICAgIHY2b3BzQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiAgICAgICAgDQogICAgICAgIA0KICAgIA0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg djZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgDQogICAgDQoNCg== From nobody Sat Aug 5 00:20:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670E3131C96 for ; Sat, 5 Aug 2017 00:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR7FJYrqGriu for ; Sat, 5 Aug 2017 00:20:43 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58459131C95 for ; Sat, 5 Aug 2017 00:20:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C910242988 for ; Sat, 5 Aug 2017 09:20:40 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id BA06F42987; Sat, 5 Aug 2017 09:20:40 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id B6E4B6E811; Sat, 5 Aug 2017 09:20:40 +0200 (CEST) Date: Sat, 5 Aug 2017 09:20:40 +0200 From: Gert Doering To: "Brzozowski, John" Cc: Gert Doering , Mark Smith , v6ops list Message-ID: <20170805072040.GP45648@Space.Net> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <20170804203821.GN45648@Space.Net> <8EABC877-12F1-4191-B7E2-2D00C9609DD1@cable.comcast.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+o5wj1QLBP9PGQM0" Content-Disposition: inline In-Reply-To: <8EABC877-12F1-4191-B7E2-2D00C9609DD1@cable.comcast.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 07:20:45 -0000 --+o5wj1QLBP9PGQM0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Aug 05, 2017 at 01:48:30AM +0000, Brzozowski, John wrote: > I host on a VLAN can have multiple addresses which does not indicate that= the host has the entire subnet or prefix. I was talking about "we route a full /96 to a host, and the host can make use of all of the addresses in that subnet" case, where Mark argued that "a subnet must be a /64!". Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --+o5wj1QLBP9PGQM0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmFcccACgkQ31bAZeTO f8UNKA/+PBbf8MnfJDURvXoPQovp9gHlqkl818jaU1bZUp2yTC2NLF/DUexmGe4q 4IZO6TkV+Cwt3BQQQmgBNaVHa2tqmKUZIPZeBTj1GkGuYGJNFmVhMALToun8tOeV JsKN7XBILPw69VBAid5WeEVwEqVz0e8KFg9emJVFDmZ9/XdAvFRguygk+VRuxgv8 66AGdZI5sdnZug3zyIjBMTVSIiUidVjJ6SUD3I6y0qUIiI8ce8zwbt5A5OpUPJf8 jIk6cm3rSfSdXdQTWnPwI7c9/SeCHQQaGBNGb/jtNqkvnPC67KEi2e8sgu9RVuiR u4JUXvJXgaWDOtuDaGGE53OiURT5HC7hoCyW9b2EMRos9Q8to8IyEVRJWxe2fUm9 ocaiUjU5l74q9Qxip5Bl5+gzk8yJqNSZzCHPDRJo0eLVE8oc/zSU7ro2JSdTpwwK 8liYOvfrnFYvMFCPRHZJgDujuKySlodhf/xDJ3cnqzWcd6NEV3iM/aLHWf6PF9aL m18BtYwtktgSmkZKPI3HBI1a82L1I/NNFfyr1qKcFU4PIbGV9BGH+8cThsQNp5jr Y9GnDLO/Mlamxa+e1q/ClPGw3O/zud69BiCPle7a7Y5jr2LWtYFkMgBLcQlDk7Hq VhryX71s/pdD1hRpu2SuK+B1SmFYP4E9SQ4XIijk4G36+dSf398= =a2ZV -----END PGP SIGNATURE----- --+o5wj1QLBP9PGQM0-- From nobody Sat Aug 5 02:58:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1184812741D for ; Sat, 5 Aug 2017 02:58:52 -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 sEMAhSzr1OwM for ; Sat, 5 Aug 2017 02:58:50 -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 EA42F127B73 for ; Sat, 5 Aug 2017 02:58:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id AEF3C1BC37 for ; Sat, 5 Aug 2017 09:58:37 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Sat, 5 Aug 2017 10:58:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 09:58:52 -0000 Mark Smith wrote: >> Is this prohibited by this document? Or is =91/64=92 mentioned in the = document only an example? >=20 > No. /64s as the subnet size as been the common edge subnet/IID > boundary for almost 20 years since RFC2373. > Analysis of the 64-bit Boundary in IPv6 Addressing > https://tools.ietf.org/rfc/rfc7421.txt I'll make an observation that one of the primary reasons given is the = now deprecated EUI64 addressing model for SLAAC. Also there is mention of "but there sooooo many addresses, we can't = possibly run out". I don't have a crystal ball, in much the same way = that all those decades ago, those designing IPv4 didn't have a crystal = ball. So it appears to me that the basis of a fixed /64 comes down to : 1) A now deprecated addressing method requires it 2) Based on what we know now we can't see things ever running out 3) If any but /64 is used, then some things (implementations) may break. So isn't the logical route to say that all implementations must support = arbitrary prefix lengths - that avoids breakage when (and I suspect in = the real world it will be when, rather than if) they meet something = other than /64 ? Something that handles arbitrary prefix lengths can handle 64+64, the = reverse isn't true if it expects 64+64 and is thrown something else. That and removing references to fixed 64 bit boundaries where they = aren't necessary. Noting that allowing plenty of space for randomisation = for security by obscurity isn't a technical limitation as such - it's = merely a best practice. And finally. There has been mention in here in the past about not = preventing flexibility in the future with things no-one has yet thought = of. Yes the numbers are huge, but as I said, I don't have a crystal = ball. And the argument about not having to work out prefixes/masks/etc is only = partly true - and assumes that no-one would ever have to work with = anything but /64. It could well lead to people who CANNOT work with = anything else, in the same way that many people cannot work with = anything but /24 in the IPv4 world. From nobody Sat Aug 5 03:07:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A3131CDF for ; Sat, 5 Aug 2017 03:06:59 -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 Z87UMHkGfteK for ; Sat, 5 Aug 2017 03:06:57 -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 828B9131CCB for ; Sat, 5 Aug 2017 03:06:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id F3F101BC37 for ; Sat, 5 Aug 2017 10:06:40 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Sat, 5 Aug 2017 11:06:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20B17E44-50AA-4D31-812A-BCB3382BD30A@thehobsons.co.uk> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 10:06:59 -0000 On 4 Aug 2017, at 14:04, DY Kim wrote: > The unique prefix per host is /64. Hence, when a site is assigned a = /48 prefix as usual, as many as 64K (2**16) nodes can be accommodated, = which number being not terribly huge but large enough for most = application cases, I=92d think. That's assuming the entire /48 is allocated to the one network segment. Suppose the business customer has several sites - that would take = several bits off that. And each site might have multiple networks - eg = "secure" systems (servers), staff, visitors, IoTs, ... which will need = several bits. You could now be down to a fairly small pool or prefixes for a given = network - and given previous comments would make tacking of individual = systems a lot easier if an attacker knows that this is the system in = use. Ie, an attacker could just ignore the last 64 bits of the address, = and then the last (say) 8 bits of the address is now the identifier for = the individual host. So suddenly, you (IIRC) previous suggestion that allocating a (say) /96 = to leave more bits for the host identifier, thus making a larger pool = for it to be randomised into, would make sense. And there we were (or I = was), only moments ago reading about how 64 bits made such an enormous = range that we could not possibly run out even with idea not yet thought = of - yet here we are, already discussing how restrictive it could be ! From nobody Sat Aug 5 06:10:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB87131D0E for ; Sat, 5 Aug 2017 06:10:11 -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 jK1PprrphAb4 for ; Sat, 5 Aug 2017 06:10:10 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738B7131F19 for ; Sat, 5 Aug 2017 06:06:35 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id v189so17900134pgd.2 for ; Sat, 05 Aug 2017 06:06:35 -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=ZrlIWQUeUPkFP5Ucl41Pqi/ddhr5o/lxUd4MpsxTdkk=; b=GHHnu2hBjc2BvaTt4BSCEIP0RVLC/vJVdYHUtYHGne7ez0OPT1dFpiUdz2wNQCqdYp COtXTydEnoaFFdtXwH1CNxULtcPl1lRpjj+gXFg4+NOGG/at3ygJPsb104WtgThvYB91 YTJ3O2L1sM4mp4SFiERYpELBJJ1JY+oFzHMy+gsk++2NJwky/AzaGqJDUsH7ST6kScX/ T4hRuK7Y7qjpCXZvDJlvOGfkSyg7vtaUpf5GHws2/Tk6Xbc5sHp4ChZXP5X5d/cKzBqi OdWpq/aXlVKvyQSuhmkbPQ7SkYnNt+/YYGN0Iizw5zlkzkes6kHxKTJ5XNuG06N67gzi RR1Q== 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=ZrlIWQUeUPkFP5Ucl41Pqi/ddhr5o/lxUd4MpsxTdkk=; b=slYA+hcn92IqQc4csMDK6FevCPB+HEl+xnt06LTAoEdsOGvNasECuzBInDtQUZ7Gxd xELayt/r7NtkNcnpe56kDsbLrO86cU005FVP9xL4VgDs8f2dxLLl/pGR65r1OfAFmfa3 hQq5dK+0x5p47LfhoUm2w2pEw500YNJIILIPH4j5+ZfrgC+9Fy+JogaipRSRoPiDW8zm 2H1CrEapsx5BIfoOuJupo9jVzhnSNKQieMrO4ZcmOolMBaR5IFRTmtqq7Qybbe1Lcuy2 uSgDayZIt2aqSjALfKSlpF5b5R1jce3/3MC9SQyhQ+B4EF0Q6KYPyYNmjHODRQh6eiO4 +9fQ== X-Gm-Message-State: AIVw1133gw8zWQE5QmZmk8G3bCX2gGFYwSaAUP7Ea7w0FnyblXAGQkvf 3iGbBtcZtZ69QXFuH8M= X-Received: by 10.99.98.71 with SMTP id w68mr5551773pgb.100.1501938395021; Sat, 05 Aug 2017 06:06:35 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id a67sm8136724pfl.167.2017.08.05.06.06.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 06:06:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <20B17E44-50AA-4D31-812A-BCB3382BD30A@thehobsons.co.uk> Date: Sat, 5 Aug 2017 22:06:29 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <8C0FF7DB-2B60-4A6B-8E4B-B287567C6F2F@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> <20B17E44-50AA-4D31-812A-BCB3382BD30A@thehobsons.co.uk> To: Simon Hobson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 13:10:12 -0000 I stepped back since it was argued that I cannot escape from the = operational practice of /64 prefix and an IID of 64 bits; that the = mentioning of /64 in =E2=80=98unique prefix per host=E2=80=99 doc is not = just an example but almost a MUST. Of course, I=E2=80=99d be happier if I=E2=80=99m given more freedom in = placing the boundary between prefix and IID. If allowed, my preference = would be /48 site prefix /96 host prefix 32-bit IID --- DY > On 5 Aug 2017, at 19:06, Simon Hobson wrote: >=20 > So suddenly, you (IIRC) previous suggestion that allocating a (say) = /96 to leave more bits for the host identifier, thus making a larger = pool for it to be randomised into, would make sense.=20 From nobody Sat Aug 5 06:14:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F63131F13 for ; Sat, 5 Aug 2017 06:13:59 -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 8wWXBGFo6bO8 for ; Sat, 5 Aug 2017 06:13:58 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B325E131D9F for ; Sat, 5 Aug 2017 06:10:35 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c28so17054069pfe.3 for ; Sat, 05 Aug 2017 06:10:35 -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=CDkhl7rntfpgNEY9T7dVrifMct/spYfWZ9K/uewGlUU=; b=NOz9tWwFQ+ZPLXVMmLEJyuxbGf8gfNav7ctgNU9n0n1JlH6sBejAzM5ISXXEZRvaF1 dkQyVtb+cK25wzE7qHX2M5Uno3jM/7is+52G6mu0hGuCwzQDiXhpyjWpQKtQlltUQYn3 SgyTUaJig9a7JGT5kR42kZk7hnvp0bChhHwst3NVUWaC4K5ChaqEh5zPAStRLrAw4sbL fROoKyCAAqhDM8ozZekhi7cjh/nfPkbDBV2Kg2v819b86Wahx/BMcnL0X7/w7nK2a4GU BAJfhD25fXI2g9Yb5lCDS0KUl8TjMdaIulwGnWkOjYZNjUG7eEwigwAdKRZAPc6802h8 7RoA== 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=CDkhl7rntfpgNEY9T7dVrifMct/spYfWZ9K/uewGlUU=; b=sh+rb2yuZ1Z0bOh/Ucihhy4s0TMc7GZhbuRQ08uIyvaSbdD6Ix+c1dNzp5hhfvfBdU kwgj+jHF/8zzxHIGH6U3VdYo4kY/XyG0a2t1SweG9tUNN8GE+o64jcYYRqaNrFtf69SD yeKorvDofuSg7nPMTbl6fSJtAHC1GUpvmdvVHCThP1QZ1m5O4xUa4ELQVB4GPCWTSgE5 g+FNIuPJAjQANkKseUlnZ78aDLq1y5OEqUUXmgv3AO0ulgGib5FJkYGnziyUcKvnMyx1 22eG4FayeeIyhuGZaAGM0DB4d6amxtgAI621QcD4jJy0yuJZ3oNVpeU6XDIwfkjmXVvN UpsQ== X-Gm-Message-State: AIVw1100oLnWbhaxYd4NDuc/hXa7aMQLqbs2tWMwtgHVrm6QJqxA2F6C h0Ajuu7mGhC0Mw1Y0AE= X-Received: by 10.84.175.3 with SMTP id s3mr6740910plb.161.1501938635155; Sat, 05 Aug 2017 06:10:35 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id x5sm6176382pgq.18.2017.08.05.06.10.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 06:10:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <8C0FF7DB-2B60-4A6B-8E4B-B287567C6F2F@gmail.com> Date: Sat, 5 Aug 2017 22:10:31 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <76B816D0-67D1-4879-911C-567C7EF685FC@gmail.com> References: <150157992497.9522.9954708038233523654.idtracker@ietfa.amsl.com> <4F94BEC1-6A68-456B-BD1E-8A0B27784A4C@gmail.com> <569CC00E-D26D-4478-B1CB-AD061573691F@gmail.com> <20B17E44-50AA-4D31-812A-BCB3382BD30A@thehobsons.co.uk> <8C0FF7DB-2B60-4A6B-8E4B-B287567C6F2F@gmail.com> To: Simon Hobson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-dykim-v6ops-sid6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 13:14:00 -0000 By now, I myself am lost in the air with my own reasoning=E2=80=A6. = Well, =E2=80=A6 In a while, I might sit down and give more thought in revising SID6 = based on the doc =E2=80=98unique prefix per host=E2=80=99. --- DY > On 5 Aug 2017, at 22:06, DY Kim wrote: >=20 > I stepped back since it was argued that I cannot escape from the = operational practice of /64 prefix and an IID of 64 bits; that the = mentioning of /64 in =E2=80=98unique prefix per host=E2=80=99 doc is not = just an example but almost a MUST. >=20 > Of course, I=E2=80=99d be happier if I=E2=80=99m given more freedom in = placing the boundary between prefix and IID. If allowed, my preference = would be >=20 > /48 site prefix > /96 host prefix > 32-bit IID >=20 > --- > DY >=20 >=20 >> On 5 Aug 2017, at 19:06, Simon Hobson wrote: >>=20 >> So suddenly, you (IIRC) previous suggestion that allocating a (say) = /96 to leave more bits for the host identifier, thus making a larger = pool for it to be randomised into, would make sense.=20 >=20 From nobody Sat Aug 5 13:16:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF247131F13 for ; Sat, 5 Aug 2017 13:16: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, 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 dGQfMNWREUDt for ; Sat, 5 Aug 2017 13:16:53 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD89131EC1 for ; Sat, 5 Aug 2017 13:16:49 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id h68so5945575pfk.0 for ; Sat, 05 Aug 2017 13:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VWOC1x6a/ThqzRoOO9Lxz/GEtSmddHnhXjdKEs7Igxo=; b=qmtVrb7eiTDv6g/uxITNv6M9DLMYIw02XPJgSo7JarfXJbmli542hkrsm+wefDSKV9 EpJx51+wxCgNmsXTnDrik7gmsie68zop+2QBct8rpHkWQtpf2EdlqEcl3hPnbu914T2J HvGonpbMFWlnuZMmxpGI5zbcfAqSsRUMN5MAsRLfdgqJe1HO/NHPWes6rlAnzpHYhrZB YPh2momTROzZz501cR5y1Kri6jUxNuwCOgHZPVsxyIldfNRtIKzSlkj6+KtZI66TeZHW nYvUss9MeltlFbvGgxF4YWx50j9F0ydqF/JA9yx+uNzLEqUW/ePQcXtqyAxs6aKRWAV4 mWcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VWOC1x6a/ThqzRoOO9Lxz/GEtSmddHnhXjdKEs7Igxo=; b=d4VXK9St3QUWBqAak8+OqoYC1mor8vFDb08gxNzLcmXAuGUxwsB6sin0WgHjnQoXnr GzIeZaXWPpO1sX2SRwSKnL7wkAdVcZZ+WIsk9sGR7c7olRxUDlZuGEb2I2Hs745Ul4kD +3YlFXkUpnvaEogZheXrJ0nVRyliLPKM8ROeX9DiqW4Ng+xx8ffYPvGn4Vda1EveuQpY o6VzmYazwn9gXQGDGXJcAEZfGm1U/Lkv/KxzcysfFQv/Ccu0SIKr04mlKUT8kxWEhLk7 PKDEQEEnaEt1ZwYvCMJDcsxng2DkMle/NztK6nV8ECpI+umYr9QsYaGxfVxGkShfX985 0/Rg== X-Gm-Message-State: AIVw110DiUfjVbG9vtU5HzEdwRv28aq75Gl6ZMEhsakWHof9CTl3T65H jSFTK+izwbdW7Lrw X-Received: by 10.99.180.78 with SMTP id n14mr6359747pgu.3.1501964208456; Sat, 05 Aug 2017 13:16:48 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y6sm7564978pgq.41.2017.08.05.13.16.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 13:16:47 -0700 (PDT) To: v6ops list References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <52f24bbd-8ac9-33d3-b291-2fdf5b25b95a@gmail.com> Date: Sun, 6 Aug 2017 08:16:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 20:16:58 -0000 On 05/08/2017 21:58, Simon Hobson wrote: > Mark Smith wrote: >=20 >>> Is this prohibited by this document? Or is =E2=80=98/64=E2=80=99 ment= ioned in the document only an example? >> >> No. /64s as the subnet size as been the common edge subnet/IID >> boundary for almost 20 years since RFC2373. >=20 >> Analysis of the 64-bit Boundary in IPv6 Addressing >> https://tools.ietf.org/rfc/rfc7421.txt Which says: "The first purpose of this document is to explain the advantages of the fixed IID length. Its second purpose is to analyze, in some detail, the effects of hypothetically varying the IID length." I suggest that everybody reads the whole RFC, which does indeed cover those points. The historical reasons why we chose 64 are somewhat irrelevant today. Brian =20 >=20 > I'll make an observation that one of the primary reasons given is the n= ow deprecated EUI64 addressing model for SLAAC. > Also there is mention of "but there sooooo many addresses, we can't pos= sibly run out". I don't have a crystal ball, in much the same way that al= l those decades ago, those designing IPv4 didn't have a crystal ball. >=20 > So it appears to me that the basis of a fixed /64 comes down to : >=20 > 1) A now deprecated addressing method requires it > 2) Based on what we know now we can't see things ever running out > 3) If any but /64 is used, then some things (implementations) may break= =2E >=20 > So isn't the logical route to say that all implementations must support= arbitrary prefix lengths - that avoids breakage when (and I suspect in t= he real world it will be when, rather than if) they meet something other = than /64 ? > Something that handles arbitrary prefix lengths can handle 64+64, the r= everse isn't true if it expects 64+64 and is thrown something else. >=20 > That and removing references to fixed 64 bit boundaries where they aren= 't necessary. Noting that allowing plenty of space for randomisation for = security by obscurity isn't a technical limitation as such - it's merely = a best practice. >=20 > And finally. There has been mention in here in the past about not preve= nting flexibility in the future with things no-one has yet thought of. Ye= s the numbers are huge, but as I said, I don't have a crystal ball. >=20 > And the argument about not having to work out prefixes/masks/etc is onl= y partly true - and assumes that no-one would ever have to work with anyt= hing but /64. It could well lead to people who CANNOT work with anything = else, in the same way that many people cannot work with anything but /24 = in the IPv4 world. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sat Aug 5 16:40:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EC2124207 for ; Sat, 5 Aug 2017 16:40:08 -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 dNiJuz7YrqVS for ; Sat, 5 Aug 2017 16:40:06 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81D1120721 for ; Sat, 5 Aug 2017 16:40:06 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id y129so20764836pgy.4 for ; Sat, 05 Aug 2017 16:40:06 -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=72G0xCgsXcDaSBLM/kHHHzr48onDu2rfaOpsPlvjars=; b=MArtrhNnX4q0oqxSGA1ZRr1NCThp6LoNUAsGypDfHiMT3Jh3dMNk5Uixs98WLFqwjD +Uz1cOU4kUkl2jDXQpA2bh+9eoGJ056F2qQlqe4uHGMBy23s5JiVBQjqV9nq15z/ef01 Z/sau/NPR8W0Y58u/xSo1G7bPztLPEeW36/PaHU/uPS0241MqV8sdtTJYNcjJrpfGLPb hy3Gqw9rF+9a2Je1qyFR+sBwWslAJ45qun9W2PNeWukKhoeAEG2SFcgOCihnacwa0tn4 WKAtdHxHCZNR0/3A/qZXJHHaPcK8PT84zRl7TImwk7J05dGLGtmzM6cN/5TajAJ/G9K8 Ix3w== 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=72G0xCgsXcDaSBLM/kHHHzr48onDu2rfaOpsPlvjars=; b=GOTXwxIuSbXdqy53zu/aJae0c+NVreN1jOtXnZ2xOBDfO+ZKonfY6HIHZAhZXM/hX9 44u0qZ7c62m+QW8bCQ560RNO8EiyddKiLzzsnb02/lJYwN7zEIYgJWS8b8/ex1chfWtS aHPxFuGBGndUUfX+f2rmo/tlKtjLHZTf20Sl6vv8nlL3P+/2fPjAAF4aXX8q6wT65AxB jDJfSE+KkdUPjgkZx8EReufADWfbhTv/ya2+WK1//7EKfXrwzht/ZOJa9qwOFycdwAY4 Lb8UgrgjAhaYBqUQ6h6X8RtjWs8gFkL/XY2rPoP+JVJ3aSt1mSKhF9o6UbSKRk/AKiJi ucYA== X-Gm-Message-State: AIVw113pnmwz5o5JPqKovjXI+wiU/I6ZSiI/hgPGnuu72TLbQff9cTw8 gBfShq2ZAdKD25EjDxo= X-Received: by 10.99.95.71 with SMTP id t68mr7061769pgb.353.1501976406293; Sat, 05 Aug 2017 16:40:06 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id 190sm8621691pfy.56.2017.08.05.16.40.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 16:40:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <52f24bbd-8ac9-33d3-b291-2fdf5b25b95a@gmail.com> Date: Sun, 6 Aug 2017 08:40:01 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <52f24bbd-8ac9-33d3-b291-2fdf5b25b95a@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 23:40:08 -0000 The firm reference pole RFC7421 along with a number of docs prescribing 64 bits for the IID length RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072 (thanks to Tatuya Jinmei for the list) would be enough to ensure that SLAAC will accept only 64-bit long prefixes and produce 64-bit long IIDs. not to disturb the wide deployment of SLAAC implementation as such. RFC4291bis doesn=E2=80=99t need (or even ought not to, for it's about = =E2=80=98architecture=E2=80=99) mention or mandate the length of IID, = leaving such implementation specific details to companion docs like = those listed above. --- DY > On 6 Aug 2017, at 05:16, Brian E Carpenter = wrote: >=20 >>> Analysis of the 64-bit Boundary in IPv6 Addressing >>> https://tools.ietf.org/rfc/rfc7421.txt >=20 > Which says: > "The first purpose of this document is to explain the > advantages of the fixed IID length. Its second purpose is to > analyze, in some detail, the effects of hypothetically varying the > IID length." >=20 > I suggest that everybody reads the whole RFC, which does indeed > cover those points. The historical reasons why we chose 64 are > somewhat irrelevant today. From nobody Sat Aug 5 19:19:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD0812783A for ; Sat, 5 Aug 2017 19:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7WTTxwpgTiM for ; Sat, 5 Aug 2017 19:19:35 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A6712706D for ; Sat, 5 Aug 2017 19:19:35 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id d29so19762834uai.2 for ; Sat, 05 Aug 2017 19:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MgC5rA+fofXNcg6mZxLjmO6MMgRNap7ViAckT4Y++yc=; b=EMmceGL8MvnbuAmDj00lkejsunhR0noZ4mSc2VpgupjOncbQKsU+M5r7SWDz9gj1Tw Vdi8hgTJMJNa/HSaMyshapEsdbged7xE+Hm67u/XCMfgx25nZk32LORK25/YbJJeHXYW 1iMBU7DnYY1hzoX4gNkhjXYcx8XOzcODWSYdZrdpOnB5kFoJSArp1CuxOjRSJfKKVze7 pu8JOLmUudVkVSHV1mrW0gpfit28ymkXWBxJF6L66LS2SAgmnjnbjrHU6bkEXAF+QlFl MCotSJWow/+uqZsL0eXeuaFGJ5j0tG7SS4CoV/+Jm/vmGcDLoPyYpUsD2dk0ug0kJbGx ckaw== 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=MgC5rA+fofXNcg6mZxLjmO6MMgRNap7ViAckT4Y++yc=; b=qgoFFRutu6gx/u/kESY0C9e3gsMnLIid2TD7s3D9sFdnYQVYOWt2p4RXQfiVXHVgx0 smNWWFbKW7t191orfDcPz0K28YuOmSG2D80jOh7iiT7f49AnNl5xV1omuNMAd6SBA4YB /gALwwgFg32kHVXclxow3TUkG2UYiSpg7nq2QCJbiAmVptXgPq7BKR0Ki2+zxQRZZ2bl NbJzumHsKOPIIyqkhr8Zq1PhtRsrtlEFXJmf5UnnKmzFafzCl3hHaczoqrRLvu2UYlBP kZbVbEQSjU1NIBwcGkUZ/FnWEhYRhDN1BXVpshjgibogpn7ZwdUVB9b0K0RbuGL+Y1wC H68g== X-Gm-Message-State: AHYfb5ilujATG4gakXGy7chGB0avuoZ2ocoMzeIg56oynrhWA3HTnbhL gMOqTGG8Os9ZS7jnxxkVMdpvfGZ1zw== X-Received: by 10.176.79.201 with SMTP id t9mr4936137uah.176.1501985974277; Sat, 05 Aug 2017 19:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Sat, 5 Aug 2017 19:19:03 -0700 (PDT) In-Reply-To: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> From: Mark Smith Date: Sun, 6 Aug 2017 12:19:03 +1000 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 02:19:37 -0000 I give up. Do what you like, treat sand like diamonds. On 5 August 2017 at 19:58, Simon Hobson wrote: > Mark Smith wrote: > >>> Is this prohibited by this document? Or is =E2=80=98/64=E2=80=99 mentio= ned in the document only an example? >> >> No. /64s as the subnet size as been the common edge subnet/IID >> boundary for almost 20 years since RFC2373. > >> Analysis of the 64-bit Boundary in IPv6 Addressing >> https://tools.ietf.org/rfc/rfc7421.txt > > I'll make an observation that one of the primary reasons given is the now= deprecated EUI64 addressing model for SLAAC. > Also there is mention of "but there sooooo many addresses, we can't possi= bly run out". I don't have a crystal ball, in much the same way that all th= ose decades ago, those designing IPv4 didn't have a crystal ball. > So it appears to me that the basis of a fixed /64 comes down to : > > 1) A now deprecated addressing method requires it > 2) Based on what we know now we can't see things ever running out > 3) If any but /64 is used, then some things (implementations) may break. > > So isn't the logical route to say that all implementations must support a= rbitrary prefix lengths - that avoids breakage when (and I suspect in the r= eal world it will be when, rather than if) they meet something other than /= 64 ? > Something that handles arbitrary prefix lengths can handle 64+64, the rev= erse isn't true if it expects 64+64 and is thrown something else. > > That and removing references to fixed 64 bit boundaries where they aren't= necessary. Noting that allowing plenty of space for randomisation for secu= rity by obscurity isn't a technical limitation as such - it's merely a best= practice. > > And finally. There has been mention in here in the past about not prevent= ing flexibility in the future with things no-one has yet thought of. Yes th= e numbers are huge, but as I said, I don't have a crystal ball. > > And the argument about not having to work out prefixes/masks/etc is only = partly true - and assumes that no-one would ever have to work with anything= but /64. It could well lead to people who CANNOT work with anything else, = in the same way that many people cannot work with anything but /24 in the I= Pv4 world. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Aug 5 20:22:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7E2129AA0 for ; Sat, 5 Aug 2017 20:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goYxbCw1dW_Z for ; Sat, 5 Aug 2017 20:21:58 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAA4129A96 for ; Sat, 5 Aug 2017 20:21:58 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id l64so21640053pge.5 for ; Sat, 05 Aug 2017 20:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hHga28cEVeLZcHZuzZMk6z64zu+3avTdlMsOWHYXlMg=; b=SN8b+U9dAiksIsKz9CV2jns9UvHzfIvE9LJB61Eo0bXoj5e7QO+hOajH32X8Rj/+QD oIF+G6xQkRPHno0tjmosT3QiCtvy9tV2c3w3NCC/D66+/jGLrrfBrevRv6L8LTNGuv/v RHtz7meFsad4Q+yvVnjQc/n9KewezzZ0pf4D73yzxS03moCTluDN/YsCYXHEbwfLdB5u SrqeLvppqe5h7yb2EBTsqE7DgFPy+UAACr50JR+7/qhXk6yLtc9bUaXD/7K4AFxNzBMR orkzvBsH+w40WCEVd06PYC+ep0CAY3aLmuUec0Lja2aw8wgAeHXI/g0O7jxQEoEYxQUV CGnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hHga28cEVeLZcHZuzZMk6z64zu+3avTdlMsOWHYXlMg=; b=P6oUjDWIYEDX7pRKCL7SiwuJY2FNAbbvylIkb3TwLbI9UBHNcR56bVCOrYHdgtn/7H HVTq6UM5aDKe3D5tNOixDiitphkX7Bg5bgA+I7jKlbHN0LZWIUHYmyStOPtZiR7/Ek5t z9deLSjKXmOjOW/0pOYRred9FM9KR19WMOa1xTR44hqD+fGrt5qrBYW+QUjtKMEA75A9 Og2abXolV10kfripOfmmclcNAEFws0xEez6Ri0TO+O2Rq+FqUJj4+h5S0Vk8fJT8L9Mx OiSJAItjUKnVymC2IEdttPaoqgafDrPwbEqkZYakAFgHJg1XvEopPkwYb3NGHLbshkjo r8tg== X-Gm-Message-State: AIVw1128LdwPEtchVmMgrQFZK1nWiZrcxeoYfmN2nG6LH2ixZhJbTHz1 NL44PptIuQw3/Ceb X-Received: by 10.99.56.68 with SMTP id h4mr7275537pgn.52.1501989717728; Sat, 05 Aug 2017 20:21:57 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v78sm10144565pfd.121.2017.08.05.20.21.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2017 20:21:56 -0700 (PDT) To: Mark Smith Cc: v6ops list References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> Date: Sun, 6 Aug 2017 15:21:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 03:22:01 -0000 On 06/08/2017 14:19, Mark Smith wrote: > I give up. Do what you like, treat sand like diamonds. I thought "Mark's exaggerating", but no, he isn't. There's a reasonable estimate of 5.6x10^21 grains of sand on the Earth's beaches: http://www.quickanddirtytips.com/education/math/how-many-grains-of-sand-a= re-on-earth%E2%80%99s-beaches In the address space already available to IANA, we have 35x10^12 /48s (in= 2000::/3)**. That allows for 2.3x10^18 /64s (in 2000::/3). To count the available /128s, multiply again by 18x10^18. Or to put it another way, with only about 2430 addresses per /64 subnet, and 2.3x10^18 subnets, we could address every grain of sand. With that degree of sparseness, DAD will hardly blink and the grains of sand can feel sure of their privacy, if they care to use RFC4941. If there's a problem, it's not in the area of a shortfall of /128s. If there's a shortfall of /64s, it's human error. Brian ** Powers of 2 are at https://en.wikipedia.org/wiki/Power_of_two#The_0th_= through_95th_powers_of_two >=20 > On 5 August 2017 at 19:58, Simon Hobson wrote:= >> Mark Smith wrote: >> >>>> Is this prohibited by this document? Or is =E2=80=98/64=E2=80=99 men= tioned in the document only an example? >>> >>> No. /64s as the subnet size as been the common edge subnet/IID >>> boundary for almost 20 years since RFC2373. >> >>> Analysis of the 64-bit Boundary in IPv6 Addressing >>> https://tools.ietf.org/rfc/rfc7421.txt >> >> I'll make an observation that one of the primary reasons given is the = now deprecated EUI64 addressing model for SLAAC. >> Also there is mention of "but there sooooo many addresses, we can't po= ssibly run out". I don't have a crystal ball, in much the same way that a= ll those decades ago, those designing IPv4 didn't have a crystal ball. >=20 >=20 >> So it appears to me that the basis of a fixed /64 comes down to : >> >> 1) A now deprecated addressing method requires it >> 2) Based on what we know now we can't see things ever running out >> 3) If any but /64 is used, then some things (implementations) may brea= k. >> >> So isn't the logical route to say that all implementations must suppor= t arbitrary prefix lengths - that avoids breakage when (and I suspect in = the real world it will be when, rather than if) they meet something other= than /64 ? >> Something that handles arbitrary prefix lengths can handle 64+64, the = reverse isn't true if it expects 64+64 and is thrown something else. >> >> That and removing references to fixed 64 bit boundaries where they are= n't necessary. Noting that allowing plenty of space for randomisation for= security by obscurity isn't a technical limitation as such - it's merely= a best practice. >> >> And finally. There has been mention in here in the past about not prev= enting flexibility in the future with things no-one has yet thought of. Y= es the numbers are huge, but as I said, I don't have a crystal ball. >> >> And the argument about not having to work out prefixes/masks/etc is on= ly partly true - and assumes that no-one would ever have to work with any= thing but /64. It could well lead to people who CANNOT work with anything= else, in the same way that many people cannot work with anything but /24= in the IPv4 world. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Aug 6 00:44:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AD1131C96 for ; Sun, 6 Aug 2017 00:44:47 -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 QUGlPs62h_J5 for ; Sun, 6 Aug 2017 00:44:47 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D74132011 for ; Sun, 6 Aug 2017 00:44:46 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 83so5835580pgb.4 for ; Sun, 06 Aug 2017 00:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=+c6Tc9roO+QVfWQjugOD3x/BfXSbRNhgWVCBN7H42sw=; b=RSOE/eK/UKU/FvpOiacH87wFKVfEn9TIcGoIMzSv/+xRrVhGG/npttmpx+Rt2L/6kV 8yjpdcGdV4jsfx8l8sgyuNiBKbgJ0xulHiiOzzMgDHb0JdVLTUvNWEoK03W5+7LiekRP I/4gEw2e3na6JXg82K0GSYM8zolA8jL6+lUgz9M3eL3RrCTEd+KDY5PbQJUJR9+yYHnO HLFaXWTej+6PDFk0Fhxp2i1xsBuYVo/dC9FrMrpisz5P+VddjwjrwbPybPGYSnj5/O28 pri4JAu4NEIA1DwZdO3tcug0a02qcuQOhS0xBO42oUBqOBVgmUphrJXESYfS386YeZc5 Oyxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=+c6Tc9roO+QVfWQjugOD3x/BfXSbRNhgWVCBN7H42sw=; b=BWzO+Au+ml6PAUcVb8E1TqwDu2etiH2VlLX5mD6fQdTCH80buf69alwGtjyEvl4laA dwYisrVGNsVdKuCv4jTe+WPn4oYMyFw3C/e4tr20VZrzpg1kV7qc7YtLNA///K76LjdC QSCO8S1vctN8nnmkQjuP7SOjFiuZKy5FIOO8fkkafdnY8qVfwZnK/u3YTx1jY6pDKz7J Oi5MHGtmPcOjMnZHVfDrhjEK5r8GRsG8KgpUMlw1EZ+M7VWpX52vuzYgvPQEKJmhGmqk tHojCyIA0C9/AihieAkow9uBdde5ZKqVrxIDU6n2tEXbPwoh+AzBo/EX0269pwFN3S9/ tx1A== X-Gm-Message-State: AIVw113l6MrT80H3mXWjKeOQ9IR1T7m+OnLn/hoiDnThFMwNGwXJDAkH 4QPlT4UZhcRa9w== X-Received: by 10.84.254.71 with SMTP id a7mr9294370pln.69.1502005486535; Sun, 06 Aug 2017 00:44:46 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id c12sm9454477pfe.154.2017.08.06.00.44.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2017 00:44:44 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> Date: Sun, 6 Aug 2017 16:44:41 +0900 Cc: v6ops list To: john_brzozowski@cable.comcast.com, gunter.van_de_velde@nokia.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 07:44:48 -0000 Hi authors, I had some questions on Sec. Security Considerations of the document. It = is said: The mechanics of IPv6 privacy extensions RFC4941 is compatible with assignment of an Unique IPv6 Prefix per Host. In the case of unique prefixes per host, the privacy of interest is in = regard to the host prefix, not the IID. Privacy of a host would be = compromised by use of its prefix, not of its IID anymore. That is, the = privacy extension mechanisms proposed in rfc4291 or elsewhere in similar = ways would become pointless for host prefixes. How would you access this situation? An alternative might be you apply a privacy extension mechanism to the = host prefixes. However, the pool of the available prefixes would = significantly be reduced from 2**64 for IID down to: o 2**16 if the controlled domain is a usual /48 site o 2**32, e.g., if the domain is a /32 network somewhere upstream = in an ISP Aren=E2=80=99t these numbers too small compared with 2**64 in order to = benefit from any such privacy mechanisms? --- DY From nobody Sun Aug 6 07:53:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD11132046 for ; Sun, 6 Aug 2017 07:53:32 -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 S033klKd_qlC for ; Sun, 6 Aug 2017 07:53:29 -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 C7F29132042 for ; Sun, 6 Aug 2017 07:53:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id B86981BC37 for ; Sun, 6 Aug 2017 14:53:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> Date: Sun, 6 Aug 2017 15:53:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 14:53:32 -0000 On 6 Aug 2017, at 04:21, Brian E Carpenter = wrote: > On 06/08/2017 14:19, Mark Smith wrote: >> I give up. Do what you like, treat sand like diamonds. >=20 > I thought "Mark's exaggerating", but no, he isn't. There's a = reasonable > estimate of 5.6x10^21 grains of sand on the Earth's beaches: Ah, that's what that's about. > In the address space already available to IANA, we have 35x10^12 /48s = (in 2000::/3)**. >=20 > That allows for 2.3x10^18 /64s (in 2000::/3). Which is all fascinating given that ISPs generally hand out /48 or = smaller - and we hear of some providing only a small number of /64s. By the same reasoning, there's trillions of money around - so I should = have no problem having a Ferrari on the drive ;-) It's not any help that = there are so many addresses around if they aren't available to me. In reality, if the ISP hands out a /48 then there are 2^80 addresses = there. Now we go and constrain that (by continued insistence on "there = shalt be no other allocation than /64") such that there are now only = 2^16 available prefixes - but that assumes the entire /48 is available = for such allocation. As I pointed out, by the time you have allowed for = multiple sites, multiple networks, you might only have 2^8 prefixes - = thus making the address space for tracking hosts quite small. Now if you can make a case for a single host to have 2^64 addresses = available to it then there's validity in not relaxing the /64 = requirement - but I can't help thinking that that would be a hard case = to make. > If there's a problem, it's not in the area of a shortfall of /128s. > If there's a shortfall of /64s, it's human error. In theory yes, but meanwhile, back in the real world ... From nobody Sun Aug 6 08:38:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988B7131D33 for ; Sun, 6 Aug 2017 08:38:38 -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 Sao2O1B9rc43 for ; Sun, 6 Aug 2017 08:38:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6854F131D1E for ; Sun, 6 Aug 2017 08:38:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1deNdP-0000H9C; Sun, 6 Aug 2017 17:38:31 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> In-reply-to: Your message of "Thu, 3 Aug 2017 19:55:32 -0700 ." Date: Sun, 06 Aug 2017 17:38:29 +0200 Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 15:38:39 -0000 I still disagree with Section 3. In particular the use of MUST and MUST NOT in that section. It is fine if an implementation want to go the extra mile and do asynch DNS. But happy eyeballs has a lot of benefits without asynch DNS. From nobody Sun Aug 6 11:24:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2982A131DA1 for ; Sun, 6 Aug 2017 11:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg3yRPAvYheI for ; Sun, 6 Aug 2017 11:24:43 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AEA131D6D for ; Sun, 6 Aug 2017 11:24:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A89CC49; Sun, 6 Aug 2017 20:24:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502043876; bh=5j6aV5zIZAMuns3nMzW jcJS0Vnu0YAkgjcA/uclDc84=; b=gOL5iqoizIOe9/cffYnE6E+h4bGq71jH0uy dKs8JO9dzWNG+YzMLlgpryoIoP5iJmoqqyslLTsmHuhkR7BmCSk2mOHjs1k+1ULq PzGgOMdJ6XgSWWy1KFZqSP3IK8dEJapwU0oNovN2/UTcX2Pt4SqJtJMYPDsWXVCr qLuYaMjI= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ktZy_306-qhx; Sun, 6 Aug 2017 20:24:36 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5] (unknown [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id AD6A33C; Sun, 6 Aug 2017 20:24:35 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_1DD4463E-E348-44AE-A924-5FBB4A30E687"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 6 Aug 2017 20:24:34 +0200 In-Reply-To: Cc: v6ops list To: Simon Hobson References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 18:24:45 -0000 --Apple-Mail=_1DD4463E-E348-44AE-A924-5FBB4A30E687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Simon, > In reality, if the ISP hands out a /48 then there are 2^80 addresses = there. Now we go and constrain that (by continued insistence on "there = shalt be no other allocation than /64") such that there are now only = 2^16 available prefixes - but that assumes the entire /48 is available = for such allocation. As I pointed out, by the time you have allowed for = multiple sites, multiple networks, you might only have 2^8 prefixes Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 = to a customer and then divide it over the connections ("sites") that = that customer has. It far more convenient for everybody to just give = each connection/site a separate /48. And business-ISP really shouldn't = give any customer any less. Cheers, Sander --Apple-Mail=_1DD4463E-E348-44AE-A924-5FBB4A30E687 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----- iQEcBAEBCAAGBQJZh17iAAoJEKAtA7D+JBO5lisH/R6nKvbp41TuEVPx9nJxdSDO 6Dq91j1rGnPVGdrZXe3b7PeFf/VrGpRxn7aR4oVQAOy2+B7VApQWwoTqFEAb5ucx HqFjZGwhkr6sZve3SlqyyZOZxVU9axVa24XOcxjIrgkYInfJj8leZRqGcfHC8NlN FYT5Y8unpw1Mn8KO3aBBb9jVY1fIFOSuIRHXxTpzmbV30e3/M/YNo2LvQTrG3OgN +CjRHIyTHj5nhlN59GkqVSOgot2RmtmsB73PBu/oqlsFh/mPtCcZ7tEsFL8sp2g0 j8D4qitcAO+mMoDAVKojrCTLu43+EMNPssrr2PD2Gku9fMUhG2dBU/sqqx8Gj7w= =sb34 -----END PGP SIGNATURE----- --Apple-Mail=_1DD4463E-E348-44AE-A924-5FBB4A30E687-- From nobody Sun Aug 6 13:42:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A913208C for ; Sun, 6 Aug 2017 13:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n3WXCvLWDMxe for ; Sun, 6 Aug 2017 13:42:37 -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 BC80113207A for ; Sun, 6 Aug 2017 13:42:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 0C1021BC37 for ; Sun, 6 Aug 2017 20:42:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> Date: Sun, 6 Aug 2017 21:42:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 20:42:45 -0000 Sander Steffann wrote: > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one = /48 to a customer and then divide it over the connections ("sites") that = that customer has. It far more convenient for everybody to just give = each connection/site a separate /48. And business-ISP really shouldn't = give any customer any less. What about businesses with multiple sites (or even, just multiple = buildings on a large site), connected by leased lines or whatever, and = one central internet connection ? It's not that uncommon. Some time ago = (different job) I managed a network with 45 sites and only one internet = connection - 40 of them were retail outlets, using dial on demand ISDN, = and the ONLY networking they had was back to head office for PoS = systems. OK, not typical, but as I say, not all that rare either. These days it would be mostly done with DSL lines and VPNs - but we'd = still not be allowing local use of the internet connection at each = store. As I've been pointing out - there are comments along the lines of "we = must not block future innovation". Yet at the same time there are = limitation being hardcoded in that do exactly that. Just think about it, = even if the entire /48 is used on one network, then that only gives 16 = bits for host selection - with 60+ bits "wasted". While at the same time = there are those saying that anything less than 64 bits to pick an = address from is inadequate. From nobody Sun Aug 6 23:08:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F72120227 for ; Sun, 6 Aug 2017 23:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 SjB0BEPZHOIi for ; Sun, 6 Aug 2017 23:08:44 -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 9C088128BC8 for ; Sun, 6 Aug 2017 23:08:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 25C9D6CD for ; Mon, 7 Aug 2017 06:08:44 +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 apKVqZ3EAhHQ for ; Mon, 7 Aug 2017 01:08:43 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id D2C0D64F for ; Mon, 7 Aug 2017 01:08:43 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id u200so32000368vkd.1 for ; Sun, 06 Aug 2017 23:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g7nuD7p0NMfUnmh2mx5coAWpE8AtvkeeOLT0kKX3X0Y=; b=C/N7SQknD/gJlUR6LjNYjiP448YnuxDWMNTBK4hRLWM9AaeFimBZG7spuSXb7ic12Q nMXs5+8chU8cSBEkRYbCnS+zHg9W1o/IJm6x8KefeG4FkWWVP5k4hqVk0GYMvMV77oQ3 xZ6CmbhLUlX0ZDeP3zlB0eTwIG1GDOIgQE5Q1g3bFFKWrOrIMsckXXc/7/o568JLpK2d URgj1HrGj1MfugkOzU/0fPsyph2lLSRpQInarOcWQmVmb5OzC/a5iuuKKd7VMb/prAwU T6Omh8ApuGfctGRXUyAAhd7RmESDEPGVTwUJndLKQHl2sbluKv9XzbbHkzeP2Iyiho9v kJOA== 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=g7nuD7p0NMfUnmh2mx5coAWpE8AtvkeeOLT0kKX3X0Y=; b=gToCd+6hpdyKNpLev3IMgFsDEW1GGof43By1kr/YZDOemIGb+tUZR7cnFNfsHg08DL YmlPCMnnxEaZAYXFYM7Z3JMZpxmV44KKUDvz9RYinu4nwq5mZVfGZc3YaFQ7zJ/OExWj 5RisnuKM2hccRHXM1uVNqXpHL+43qSjHrD0xi9Y5awPGKJM6Nv4X30qGebpCQtDF7432 PIBFjhoKNBpz1KqQ47w2Gxx/jPk15FlL3sa4DEYdE8lFdCJLFlZ+VVbvX7ca5m14WCsH cFk+7Rabq9C2ROy5UHRtNw6zs3mzXqju995kojIVIJnKXRm4TVZZlLpFV1svMuNz0DTE /tiQ== X-Gm-Message-State: AHYfb5jEBEE3xb2/gJ0GUlUWcZVU4frmmMPtZR2tjCSy6kHHvGqHkFxw BNF0XFwsIOO2QYBZcPkVDMgpjRgdKXpEB//y9xC/eiCaZ8k3SwW3QGXPdvLN1fyUFlG4rrvwNjd Cmtml04n1Ca/KZoo6 X-Received: by 10.31.178.87 with SMTP id b84mr6337758vkf.4.1502086122971; Sun, 06 Aug 2017 23:08:42 -0700 (PDT) X-Received: by 10.31.178.87 with SMTP id b84mr6337752vkf.4.1502086122735; Sun, 06 Aug 2017 23:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Sun, 6 Aug 2017 23:08:41 -0700 (PDT) In-Reply-To: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> From: David Farmer Date: Mon, 7 Aug 2017 01:08:41 -0500 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: multipart/alternative; boundary="001a1143f066c4ad72055623adf8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 06:08:47 -0000 --001a1143f066c4ad72055623adf8 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson wrote: > Sander Steffann wrote: > > > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 > to a customer and then divide it over the connections ("sites") that that > customer has. It far more convenient for everybody to just give each > connection/site a separate /48. And business-ISP really shouldn't give any > customer any less. > > What about businesses with multiple sites (or even, just multiple > buildings on a large site), connected by leased lines or whatever, and one > central internet connection ? It's not that uncommon. Some time ago > (different job) I managed a network with 45 sites and only one internet > connection - 40 of them were retail outlets, using dial on demand ISDN, and > the ONLY networking they had was back to head office for PoS systems. OK, > not typical, but as I say, not all that rare either. > These days it would be mostly done with DSL lines and VPNs - but we'd > still not be allowing local use of the internet connection at each store. > > As I've been pointing out - there are comments along the lines of "we must > not block future innovation". Yet at the same time there are limitation > being hardcoded in that do exactly that. Just think about it, even if the > entire /48 is used on one network, then that only gives 16 bits for host > selection - with 60+ bits "wasted". While at the same time there are those > saying that anything less than 64 bits to pick an address from is > inadequate. > This discussion seem to be rapidly spinning out of the IETF's preview, but it is still important. I think the RIR assignment and allocation policies aren't as stingy as some might think. Organizations with multiple sites should not be limited to only a /48, in fact /48 is really just the staring point, at least in the ARIN region /44s and /40s are not that difficult to justify for most organizations. ARIN's policy explicitly allows the assignment of a /48 for each site of a multi-site end-user, either by an ISP or directly by ARIN (if one of several qualifications is meet by the end-user), further additional /48s per site can be assigned if 16,384 /64 subnets are used in an single x-large site. However, the policy is really a ceiling for ISPs, and ISPs are free to assign less if they see fit. Also, it could very well be the case that if an end-user has multiple sites behind a single connection to an ISP, the ISP might not realize the end-user has multiple site unless the end-user requests a block larger than /48. It seems quit logical for an ISP to assume a connection is just one site, unless the customer informs them otherwise. ARIN's IPv6 end-user policy; https://www.arin.net/policy/nrpm.html#six58 The follow allow ISPs or LIRs to make IPv6 assignment based on the above end-user policy; https://www.arin.net/policy/nrpm.html#six54 On the other hand as I have been listening to this discussion, and I've become a little concerned that some may think this new model of a /64 per host should replace or obsolete the more traditional subnet model of multiple hosts within a subnet for any and all use cases. However, it should be noted that the primary use case for this model is public internet access, or public WiFi. There are several arguments that the traditional subnet model has always been a bad fit for this use case, in that you end up mixing totally unrelated users and hosts on the same subnet, there are several security and privacy issues with that. This isn't necessarily true of other use cases. So, the /64 prefix per host model solves some important problems for this, and maybe other use cases too. But, that doesn't mean it should be viewed as a universal replacement for the traditional multiple host per subnet model for all use cases we have. There are plenty of use cases left where traditional multiple host per subnet model still works just fine. 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 =============================================== --001a1143f066c4ad72055623adf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson <linux@thehobsons.co= .uk> wrote:
Sander Steffann <sander@steffa= nn.nl> wrote:

> Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give on= e /48 to a customer and then divide it over the connections ("sites&qu= ot;) that that customer has. It far more convenient for everybody to just g= ive each connection/site a separate /48. And business-ISP really shouldn= 9;t give any customer any less.

What about businesses with multiple sites (or even, just multiple buildings= on a large site), connected by leased lines or whatever, and one central i= nternet connection ? It's not that uncommon. Some time ago (different j= ob) I managed a network with 45 sites and only one internet connection - 40= of them were retail outlets, using dial on demand ISDN, and the ONLY netwo= rking they had was back to head office for PoS systems. OK, not typical, bu= t as I say, not all that rare either.
These days it would be mostly done with DSL lines and VPNs - but we'd s= till not be allowing local use of the internet connection at each store.
As I've been pointing out - there are comments along the lines of "= ;we must not block future innovation". Yet at the same time there are = limitation being hardcoded in that do exactly that. Just think about it, ev= en if the entire /48 is used on one network, then that only gives 16 bits f= or host selection - with 60+ bits "wasted". While at the same tim= e there are those saying that anything less than 64 bits to pick an address= from is inadequate.

This discussion seem to be rapidly spinning out of the IETF's = preview, but it is still important. I think the RIR assignment and allocati= on policies aren't as stingy as some might think.=C2=A0 Organizations w= ith multiple sites should not be limited to only a /48, in fact /48 is real= ly just the staring point, at least in the ARIN region /44s and /40s are no= t that difficult to justify for most organizations.=C2=A0

ARIN's policy explicitly allows the assignment of a /48 for eac= h site of a multi-site end-user, either by an ISP or directly by ARIN (if o= ne of several qualifications is meet by the end-user), further additional /= 48s per site can be assigned if 16,384 /64 subnets are used in an single x-= large site.=C2=A0 However, the policy is really a ceiling for ISPs, and ISP= s are free to assign less if they see fit. Also, it could very well be the = case that if an end-user has multiple sites behind a single connection to a= n ISP, the ISP might not realize the end-user has multiple site unless the = end-user requests a block larger than /48. It seems quit logical for an ISP= to assume a connection is just one site, unless the customer informs them = otherwise.

ARIN's IPv6 end-user polic= y;
<= div>
The follow allow ISPs or LIRs to make IPv6 assignment ba= sed on the above end-user policy;
=C2=A0
On the other = hand as I have been listening to this discussion, and I've become a lit= tle concerned that some may think this new model of a /64 per host should r= eplace or obsolete the more traditional subnet model of multiple hosts with= in a subnet for any and all use cases. However, it should be noted that the= primary use case for this model is public internet access, or public WiFi.= There are several arguments that the traditional subnet model=C2=A0has alw= ays been a bad fit for this use case, in that you end up mixing totally unr= elated users and hosts on the same subnet, there are several security and p= rivacy issues with that. This isn't necessarily true of other use cases= .

So, the /64 prefix per host model solves some im= portant problems for this, and maybe other use cases too. But, that doesn&#= 39;t mean it should be viewed as a universal replacement for the traditiona= l multiple host per subnet model for all use cases we have. There are plent= y of use cases left where traditional multiple host per subnet model still = works just fine.

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 Service= s
Office of Information Technology
University of Minnesota=C2=A0=C2= =A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-08= 15
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
--001a1143f066c4ad72055623adf8-- From nobody Mon Aug 7 03:05:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBEC132195 for ; Mon, 7 Aug 2017 03:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl1pcwRZBY2p for ; Mon, 7 Aug 2017 03:05:31 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D121E132018 for ; Mon, 7 Aug 2017 03:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502100328; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=L2i5UXcgq/TLGFZ8P7YkArxUoQnKKNapz6P6keGuUh0=; b=b9qnWWVL2r/yEnm4kBY5KGXDd2rizlHqgiGyNvzeHb+ymreUwNvCl1JLPptwo+jsHQkWxPcxAdYeIWX2BioYTsl0aDgEhqV9R9A5FBzH5Jj1cIPOAa5g+eCXrW0/KRrf+Z6lTMfKSxCkmbQQFR0oLEEyUs1FHjVtHPbViIuaVWk= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0241.outbound.protection.outlook.com [213.199.154.241]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-77-0lg_15maNTS1cDquOjT5xg-1; Mon, 07 Aug 2017 11:05:25 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB388.eurprd07.prod.outlook.com (10.242.111.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 7 Aug 2017 10:05:23 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 10:05:23 +0000 From: Tim Chown To: David Farmer CC: Simon Hobson , v6ops list Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDdGB+HQZzf+4OUiIy6ehixgf+KJ2mRuAgAARjoCAAME1AIAAOwAAgAAmjACAAJ4ugIAAQiEA Date: Mon, 7 Aug 2017 10:05:23 +0000 Message-ID: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [212.188.254.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB388; 20:rl178h/5dAqkGbvznAkf8r2Q+rsgI6YemeECBkrUPVI5WYpTMYlB9XFPDo0rOOW+ZPPBn8FoL1ACEMy0seqZbjlI67sKaKfntspCPE08CVJXfnV0VE1AhqxAAFeoeHUjfY6/Oh2g4zrj/5+foLFbwbhMp8ajC7w3z2FYZyQIPV4= x-ms-office365-filtering-correlation-id: a0edb353-909a-496d-b7fc-08d4dd7bd180 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB388; x-ms-traffictypediagnostic: AM3PR07MB388: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(8104003914727)(136301948869941); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB388; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB388; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(24454002)(199003)(377454003)(189002)(3280700002)(189998001)(97736004)(2171002)(230783001)(53936002)(14454004)(6246003)(68736007)(6306002)(6512007)(99286003)(8676002)(54906002)(57306001)(8936002)(2900100001)(36756003)(101416001)(4326008)(25786009)(2950100002)(74482002)(6916009)(2906002)(53546010)(110136004)(3660700001)(38730400002)(6436002)(5250100002)(50226002)(82746002)(83716003)(93886004)(86362001)(6486002)(76176999)(6506006)(42882006)(478600001)(106356001)(72206003)(6116002)(229853002)(305945005)(105586002)(102836003)(33656002)(966005)(50986999)(7736002)(81156014)(3846002)(81166006)(66066001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB388; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <1E3D83115C7FBE408A82062ADB732BDB@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 10:05:23.0578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB388 X-MC-Unique: 0lg_15maNTS1cDquOjT5xg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:05:34 -0000 SGksDQoNCj4gT24gNyBBdWcgMjAxNywgYXQgMDc6MDgsIERhdmlkIEZhcm1lciA8ZmFybWVyQHVt bi5lZHU+IHdyb3RlOg0KPiANCj4gT24gU3VuLCBBdWcgNiwgMjAxNyBhdCAzOjQyIFBNLCBTaW1v biBIb2Jzb24gPGxpbnV4QHRoZWhvYnNvbnMuY28udWs+IHdyb3RlOg0KPiBTYW5kZXIgU3RlZmZh bm4gPHNhbmRlckBzdGVmZmFubi5ubD4gd3JvdGU6DQo+IA0KPiA+IE1vc3QgKGFsbD8pIFJJUnMg YWxsb3cgYSAvNDggcGVyIHNpdGUuIEkgaGF2ZW4ndCBzZWVuIElTUHMgZ2l2ZSBvbmUgLzQ4IHRv IGEgY3VzdG9tZXIgYW5kIHRoZW4gZGl2aWRlIGl0IG92ZXIgdGhlIGNvbm5lY3Rpb25zICgic2l0 ZXMiKSB0aGF0IHRoYXQgY3VzdG9tZXIgaGFzLiBJdCBmYXIgbW9yZSBjb252ZW5pZW50IGZvciBl dmVyeWJvZHkgdG8ganVzdCBnaXZlIGVhY2ggY29ubmVjdGlvbi9zaXRlIGEgc2VwYXJhdGUgLzQ4 LiBBbmQgYnVzaW5lc3MtSVNQIHJlYWxseSBzaG91bGRuJ3QgZ2l2ZSBhbnkgY3VzdG9tZXIgYW55 IGxlc3MuDQo+IA0KPiBXaGF0IGFib3V0IGJ1c2luZXNzZXMgd2l0aCBtdWx0aXBsZSBzaXRlcyAo b3IgZXZlbiwganVzdCBtdWx0aXBsZSBidWlsZGluZ3Mgb24gYSBsYXJnZSBzaXRlKSwgY29ubmVj dGVkIGJ5IGxlYXNlZCBsaW5lcyBvciB3aGF0ZXZlciwgYW5kIG9uZSBjZW50cmFsIGludGVybmV0 IGNvbm5lY3Rpb24gPyBJdCdzIG5vdCB0aGF0IHVuY29tbW9uLiBTb21lIHRpbWUgYWdvIChkaWZm ZXJlbnQgam9iKSBJIG1hbmFnZWQgYSBuZXR3b3JrIHdpdGggNDUgc2l0ZXMgYW5kIG9ubHkgb25l IGludGVybmV0IGNvbm5lY3Rpb24gLSA0MCBvZiB0aGVtIHdlcmUgcmV0YWlsIG91dGxldHMsIHVz aW5nIGRpYWwgb24gZGVtYW5kIElTRE4sIGFuZCB0aGUgT05MWSBuZXR3b3JraW5nIHRoZXkgaGFk IHdhcyBiYWNrIHRvIGhlYWQgb2ZmaWNlIGZvciBQb1Mgc3lzdGVtcy4gT0ssIG5vdCB0eXBpY2Fs LCBidXQgYXMgSSBzYXksIG5vdCBhbGwgdGhhdCByYXJlIGVpdGhlci4NCj4gVGhlc2UgZGF5cyBp dCB3b3VsZCBiZSBtb3N0bHkgZG9uZSB3aXRoIERTTCBsaW5lcyBhbmQgVlBOcyAtIGJ1dCB3ZSdk IHN0aWxsIG5vdCBiZSBhbGxvd2luZyBsb2NhbCB1c2Ugb2YgdGhlIGludGVybmV0IGNvbm5lY3Rp b24gYXQgZWFjaCBzdG9yZS4NCj4gDQo+IEFzIEkndmUgYmVlbiBwb2ludGluZyBvdXQgLSB0aGVy ZSBhcmUgY29tbWVudHMgYWxvbmcgdGhlIGxpbmVzIG9mICJ3ZSBtdXN0IG5vdCBibG9jayBmdXR1 cmUgaW5ub3ZhdGlvbiIuIFlldCBhdCB0aGUgc2FtZSB0aW1lIHRoZXJlIGFyZSBsaW1pdGF0aW9u IGJlaW5nIGhhcmRjb2RlZCBpbiB0aGF0IGRvIGV4YWN0bHkgdGhhdC4gSnVzdCB0aGluayBhYm91 dCBpdCwgZXZlbiBpZiB0aGUgZW50aXJlIC80OCBpcyB1c2VkIG9uIG9uZSBuZXR3b3JrLCB0aGVu IHRoYXQgb25seSBnaXZlcyAxNiBiaXRzIGZvciBob3N0IHNlbGVjdGlvbiAtIHdpdGggNjArIGJp dHMgIndhc3RlZCIuIFdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgdGhlcmUgYXJlIHRob3NlIHNheWlu ZyB0aGF0IGFueXRoaW5nIGxlc3MgdGhhbiA2NCBiaXRzIHRvIHBpY2sgYW4gYWRkcmVzcyBmcm9t IGlzIGluYWRlcXVhdGUuDQo+IA0KPiBUaGlzIGRpc2N1c3Npb24gc2VlbSB0byBiZSByYXBpZGx5 IHNwaW5uaW5nIG91dCBvZiB0aGUgSUVURidzIHByZXZpZXcsIGJ1dCBpdCBpcyBzdGlsbCBpbXBv cnRhbnQuIEkgdGhpbmsgdGhlIFJJUiBhc3NpZ25tZW50IGFuZCBhbGxvY2F0aW9uIHBvbGljaWVz IGFyZW4ndCBhcyBzdGluZ3kgYXMgc29tZSBtaWdodCB0aGluay4gIE9yZ2FuaXphdGlvbnMgd2l0 aCBtdWx0aXBsZSBzaXRlcyBzaG91bGQgbm90IGJlIGxpbWl0ZWQgdG8gb25seSBhIC80OCwgaW4g ZmFjdCAvNDggaXMgcmVhbGx5IGp1c3QgdGhlIHN0YXJpbmcgcG9pbnQsIGF0IGxlYXN0IGluIHRo ZSBBUklOIHJlZ2lvbiAvNDRzIGFuZCAvNDBzIGFyZSBub3QgdGhhdCBkaWZmaWN1bHQgdG8ganVz dGlmeSBmb3IgbW9zdCBvcmdhbml6YXRpb25zLiANCg0KVHdvIFVLIHVuaXZlcnNpdGllcyBoYXZl IGEgLzQ0IGR1ZSB0byB0aGVpciBpbnRlcm5hbCBvcmdhbmlzYXRpb24uDQoNCj4gQVJJTidzIHBv bGljeSBleHBsaWNpdGx5IGFsbG93cyB0aGUgYXNzaWdubWVudCBvZiBhIC80OCBmb3IgZWFjaCBz aXRlIG9mIGEgbXVsdGktc2l0ZSBlbmQtdXNlciwgZWl0aGVyIGJ5IGFuIElTUCBvciBkaXJlY3Rs eSBieSBBUklOIChpZiBvbmUgb2Ygc2V2ZXJhbCBxdWFsaWZpY2F0aW9ucyBpcyBtZWV0IGJ5IHRo ZSBlbmQtdXNlciksIGZ1cnRoZXIgYWRkaXRpb25hbCAvNDhzIHBlciBzaXRlIGNhbiBiZSBhc3Np Z25lZCBpZiAxNiwzODQgLzY0IHN1Ym5ldHMgYXJlIHVzZWQgaW4gYW4gc2luZ2xlIHgtbGFyZ2Ug c2l0ZS4gIEhvd2V2ZXIsIHRoZSBwb2xpY3kgaXMgcmVhbGx5IGEgY2VpbGluZyBmb3IgSVNQcywg YW5kIElTUHMgYXJlIGZyZWUgdG8gYXNzaWduIGxlc3MgaWYgdGhleSBzZWUgZml0LiBBbHNvLCBp dCBjb3VsZCB2ZXJ5IHdlbGwgYmUgdGhlIGNhc2UgdGhhdCBpZiBhbiBlbmQtdXNlciBoYXMgbXVs dGlwbGUgc2l0ZXMgYmVoaW5kIGEgc2luZ2xlIGNvbm5lY3Rpb24gdG8gYW4gSVNQLCB0aGUgSVNQ IG1pZ2h0IG5vdCByZWFsaXplIHRoZSBlbmQtdXNlciBoYXMgbXVsdGlwbGUgc2l0ZSB1bmxlc3Mg dGhlIGVuZC11c2VyIHJlcXVlc3RzIGEgYmxvY2sgbGFyZ2VyIHRoYW4gLzQ4LiBJdCBzZWVtcyBx dWl0IGxvZ2ljYWwgZm9yIGFuIElTUCB0byBhc3N1bWUgYSBjb25uZWN0aW9uIGlzIGp1c3Qgb25l IHNpdGUsIHVubGVzcyB0aGUgY3VzdG9tZXIgaW5mb3JtcyB0aGVtIG90aGVyd2lzZS4NCj4gDQo+ IEFSSU4ncyBJUHY2IGVuZC11c2VyIHBvbGljeTsNCj4gaHR0cHM6Ly93d3cuYXJpbi5uZXQvcG9s aWN5L25ycG0uaHRtbCNzaXg1OA0KPiANCj4gVGhlIGZvbGxvdyBhbGxvdyBJU1BzIG9yIExJUnMg dG8gbWFrZSBJUHY2IGFzc2lnbm1lbnQgYmFzZWQgb24gdGhlIGFib3ZlIGVuZC11c2VyIHBvbGlj eTsNCj4gaHR0cHM6Ly93d3cuYXJpbi5uZXQvcG9saWN5L25ycG0uaHRtbCNzaXg1NA0KPiAgDQo+ IE9uIHRoZSBvdGhlciBoYW5kIGFzIEkgaGF2ZSBiZWVuIGxpc3RlbmluZyB0byB0aGlzIGRpc2N1 c3Npb24sIGFuZCBJJ3ZlIGJlY29tZSBhIGxpdHRsZSBjb25jZXJuZWQgdGhhdCBzb21lIG1heSB0 aGluayB0aGlzIG5ldyBtb2RlbCBvZiBhIC82NCBwZXIgaG9zdCBzaG91bGQgcmVwbGFjZSBvciBv YnNvbGV0ZSB0aGUgbW9yZSB0cmFkaXRpb25hbCBzdWJuZXQgbW9kZWwgb2YgbXVsdGlwbGUgaG9z dHMgd2l0aGluIGEgc3VibmV0IGZvciBhbnkgYW5kIGFsbCB1c2UgY2FzZXMuIEhvd2V2ZXIsIGl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSBwcmltYXJ5IHVzZSBjYXNlIGZvciB0aGlzIG1vZGVs IGlzIHB1YmxpYyBpbnRlcm5ldCBhY2Nlc3MsIG9yIHB1YmxpYyBXaUZpLiBUaGVyZSBhcmUgc2V2 ZXJhbCBhcmd1bWVudHMgdGhhdCB0aGUgdHJhZGl0aW9uYWwgc3VibmV0IG1vZGVsIGhhcyBhbHdh eXMgYmVlbiBhIGJhZCBmaXQgZm9yIHRoaXMgdXNlIGNhc2UsIGluIHRoYXQgeW91IGVuZCB1cCBt aXhpbmcgdG90YWxseSB1bnJlbGF0ZWQgdXNlcnMgYW5kIGhvc3RzIG9uIHRoZSBzYW1lIHN1Ym5l dCwgdGhlcmUgYXJlIHNldmVyYWwgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzIHdpdGggdGhh dC4gVGhpcyBpc24ndCBuZWNlc3NhcmlseSB0cnVlIG9mIG90aGVyIHVzZSBjYXNlcy4NCj4gDQo+ IFNvLCB0aGUgLzY0IHByZWZpeCBwZXIgaG9zdCBtb2RlbCBzb2x2ZXMgc29tZSBpbXBvcnRhbnQg cHJvYmxlbXMgZm9yIHRoaXMsIGFuZCBtYXliZSBvdGhlciB1c2UgY2FzZXMgdG9vLiBCdXQsIHRo YXQgZG9lc24ndCBtZWFuIGl0IHNob3VsZCBiZSB2aWV3ZWQgYXMgYSB1bml2ZXJzYWwgcmVwbGFj ZW1lbnQgZm9yIHRoZSB0cmFkaXRpb25hbCBtdWx0aXBsZSBob3N0IHBlciBzdWJuZXQgbW9kZWwg Zm9yIGFsbCB1c2UgY2FzZXMgd2UgaGF2ZS4gVGhlcmUgYXJlIHBsZW50eSBvZiB1c2UgY2FzZXMg bGVmdCB3aGVyZSB0cmFkaXRpb25hbCBtdWx0aXBsZSBob3N0IHBlciBzdWJuZXQgbW9kZWwgc3Rp bGwgd29ya3MganVzdCBmaW5lLg0KDQpUaGUgcXVlc3Rpb24gdGhvdWdoLCBhcyBhbmQgYXMgeW91 IHNheSBpdOKAmXMgbm90IG9uZSByZWFsbHkgaW4gdGhlIElFVEbigJlzIHNjb3BlLCBtb3JlIHRo ZSBSSVIgY29tbXVuaXRpZXMsIGlzIGlmIGEgc2l0ZSBoYXMgYSAvNDgsIGFuZCB1c2VzIGl0IHVw IChvciAxNiwzODQgLzY0cyBvZiBpdCB1cCkgaW1wbGVtZW50aW5nIGRyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LCB3aWxsIHRoYXQgYmUgZGVlbWVkIGFwcHJvcHJp YXRlIHVzZSB0byBhbGxvdyBhIGZ1cnRoZXIgYXNzaWdubWVudD8NCg0KQSBsYXJnZSB1bml2ZXJz aXR5IG1heSBjaG9vc2UgdG8gaW1wbGVtZW50IHRoaXMgb24gaXRzIHdpZmkvZWR1cm9hbSwgZm9y IGV4YW1wbGUuDQoNClRpbQ== From nobody Mon Aug 7 03:26:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADA113201A for ; Mon, 7 Aug 2017 03:26:28 -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 Ud_Zs4x9zSGU for ; Mon, 7 Aug 2017 03:26:26 -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 B3B6A124217 for ; Mon, 7 Aug 2017 03:26:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id A7AD11A071 for ; Mon, 7 Aug 2017 10:26:22 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> Date: Mon, 7 Aug 2017 11:26:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4511FB-5E38-46B9-870C-3882B55F852B@thehobsons.co.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:26:29 -0000 Tim Chown wrote: > The question though, as and as you say it=92s not one really in the = IETF=92s scope, more the RIR communities, is if a site has a /48, and = uses it up (or 16,384 /64s of it up) implementing = draft-ietf-v6ops-unique-ipv6-prefix-per-host, will that be deemed = appropriate use to allow a further assignment? >=20 > A large university may choose to implement this on its wifi/eduroam, = for example. Presumably that means another separate prefix. And when 2003:: is used, = 2004:: will get allocated and so on. At what point will people be suggesting that we could have avoided the = routing table bloat by allowing better use of the prefixes ? AFAICS the insistence that it must be /64 per host, rather than anything = else (eg /80/host or /96/host) seems to be more religion than technical = requirement. I can see the security (through obscurity) and privacy reasons why = individual addresses should come from a /64 (or at least, large) prefix = - but I fail to see much, if any, merit in allocating 2^64 addresses to = a single host "because we can". From nobody Mon Aug 7 03:34:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF70412708C for ; Mon, 7 Aug 2017 03:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5c3WEi_Hc5W for ; Mon, 7 Aug 2017 03:34:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1411201F2 for ; Mon, 7 Aug 2017 03:34:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6E170A2; Mon, 7 Aug 2017 12:34:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502102088; bh=/WDY/IG5pionVZa2iS/xgCAjcH+S3FjW/k11wlZ8m/E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eKBIf2lu/XF/VJZEWnjABLuyzjJIcpNdj6t5d8NPQMQs+scKEFvkswYeQ21vwCddo cbN5y1yLHNhu1HYqCyXCjyCJp804WBun4o1q9d6fdlKmNC+tGVOZ31DmOCrMdYnuhQ cXwFfBXhGZ+ZyezosUUA+Em26mCJh3yC0FQHosac= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6AF51A1; Mon, 7 Aug 2017 12:34:48 +0200 (CEST) Date: Mon, 7 Aug 2017 12:34:48 +0200 (CEST) From: Mikael Abrahamsson To: Tim Chown cc: v6ops list In-Reply-To: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-50746663-1502102088=:2261" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:34:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-50746663-1502102088=:2261 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 7 Aug 2017, Tim Chown wrote: > The question though, as and as you say it’s not one really in the IETF’s > scope, more the RIR communities, is if a site has a /48, and uses it up > (or 16,384 /64s of it up) implementing > draft-ietf-v6ops-unique-ipv6-prefix-per-host, will that be deemed > appropriate use to allow a further assignment? If a RIR deems this not appropriate use, I will personally engage the policy development groups of these RIRs, advocating change to the policy. I don't think I'll be alone. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-50746663-1502102088=:2261-- From nobody Mon Aug 7 03:35:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785FD1201F2 for ; Mon, 7 Aug 2017 03:35: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFI1tgQFe6PG for ; Mon, 7 Aug 2017 03:35:35 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8313D13201B for ; Mon, 7 Aug 2017 03:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502102132; x=1502706932; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=A/t7PVVW202RJSVJAIq43FWA+ jzjjjY5YwQRcbeA6ew=; b=pNIa1t3hqt7RsdrzOxWHDEVVZFmfcAeqdqrmbu7Vd T5UzNay5y1BQPtpGxDI4tozDB3dxyp5T5zN8mTmMtyoyB5GuxZ9lwGpc8P8AjKD0 ph7hspSZOmYaHCbjk9/P9rkQjTmhBGWeVWcjv24vVye2BRjzQ/sIJDsBsm6LNXKv zg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=bhs02PCnha4aDvOW+p1wdr3aPD91fBebj6bBJ1tHHGU4kndWtk9RMdlGirJl f9WNEfN99gNre6gweFMR5UKX13lssUfkIWSHV4fuvhj+jPMbzBbTj9rdd GjfERIIn0TZ1Sh8S6ZcvhinaOofTppsdR/7cBB5bcAE6+/1vejXn7Q=; X-MDAV-Processed: mail.consulintel.es, Mon, 07 Aug 2017 12:35:32 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 07 Aug 2017 12:35:31 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005498417.msg for ; Mon, 07 Aug 2017 12:35:31 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170807:md50005498417::eVhACxu3zIfBAFDG:00000tZy X-Return-Path: prvs=13920e8dc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 07 Aug 2017 12:35:25 +0200 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> In-Reply-To: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:35:38 -0000 My take on this. Most of the RIR policies allow a shorter prefix than /48 for a single site = if justified. As Tim said, there are already examples of /44 and I=E2=80=99= ve seen others (/47). If you are using a single /64 per host, and furthermore an IETF RFC documen= ts it, a RIR policy can=E2=80=99t block it. In the worst case, a RIR policy= can always be modified by the community, and I think this can happen in ge= neral in less than 4-6 months in most of the regions, looking at most of th= e PDP process overall length. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Tim Chown Responder a: Fecha: lunes, 7 de agosto de 2017, 12:05 Para: David Farmer CC: Simon Hobson , v6ops list Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-hos= t-07.txt Hi, =20 > On 7 Aug 2017, at 07:08, David Farmer wrote: >=20 > On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson = wrote: > Sander Steffann wrote: >=20 > > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one= /48 to a customer and then divide it over the connections ("sites") that t= hat customer has. It far more convenient for everybody to just give each co= nnection/site a separate /48. And business-ISP really shouldn't give any cu= stomer any less. >=20 > What about businesses with multiple sites (or even, just multiple bui= ldings on a large site), connected by leased lines or whatever, and one cen= tral internet connection ? It's not that uncommon. Some time ago (different= job) I managed a network with 45 sites and only one internet connection - = 40 of them were retail outlets, using dial on demand ISDN, and the ONLY net= working they had was back to head office for PoS systems. OK, not typical, = but as I say, not all that rare either. > These days it would be mostly done with DSL lines and VPNs - but we'd= still not be allowing local use of the internet connection at each store. >=20 > As I've been pointing out - there are comments along the lines of "we= must not block future innovation". Yet at the same time there are limitati= on being hardcoded in that do exactly that. Just think about it, even if th= e entire /48 is used on one network, then that only gives 16 bits for host = selection - with 60+ bits "wasted". While at the same time there are those = saying that anything less than 64 bits to pick an address from is inadequat= e. >=20 > This discussion seem to be rapidly spinning out of the IETF's preview= , but it is still important. I think the RIR assignment and allocation poli= cies aren't as stingy as some might think. Organizations with multiple sit= es should not be limited to only a /48, in fact /48 is really just the star= ing point, at least in the ARIN region /44s and /40s are not that difficult= to justify for most organizations.=20 =20 Two UK universities have a /44 due to their internal organisation. =20 > ARIN's policy explicitly allows the assignment of a /48 for each site= of a multi-site end-user, either by an ISP or directly by ARIN (if one of = several qualifications is meet by the end-user), further additional /48s pe= r site can be assigned if 16,384 /64 subnets are used in an single x-large = site. However, the policy is really a ceiling for ISPs, and ISPs are free = to assign less if they see fit. Also, it could very well be the case that i= f an end-user has multiple sites behind a single connection to an ISP, the = ISP might not realize the end-user has multiple site unless the end-user re= quests a block larger than /48. It seems quit logical for an ISP to assume = a connection is just one site, unless the customer informs them otherwise. >=20 > ARIN's IPv6 end-user policy; > https://www.arin.net/policy/nrpm.html#six58 >=20 > The follow allow ISPs or LIRs to make IPv6 assignment based on the ab= ove end-user policy; > https://www.arin.net/policy/nrpm.html#six54 > =20 > On the other hand as I have been listening to this discussion, and I'= ve become a little concerned that some may think this new model of a /64 pe= r host should replace or obsolete the more traditional subnet model of mult= iple hosts within a subnet for any and all use cases. However, it should be= noted that the primary use case for this model is public internet access, = or public WiFi. There are several arguments that the traditional subnet mod= el has always been a bad fit for this use case, in that you end up mixing t= otally unrelated users and hosts on the same subnet, there are several secu= rity and privacy issues with that. This isn't necessarily true of other use= cases. >=20 > So, the /64 prefix per host model solves some important problems for = this, and maybe other use cases too. But, that doesn't mean it should be vi= ewed as a universal replacement for the traditional multiple host per subne= t model for all use cases we have. There are plenty of use cases left where= traditional multiple host per subnet model still works just fine. =20 The question though, as and as you say it=E2=80=99s not one really in t= he IETF=E2=80=99s scope, more the RIR communities, is if a site has a /48, = and uses it up (or 16,384 /64s of it up) implementing draft-ietf-v6ops-uniq= ue-ipv6-prefix-per-host, will that be deemed appropriate use to allow a fur= ther assignment? =20 A large university may choose to implement this on its wifi/eduroam, fo= r example. =20 Tim _______________________________________________ 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 use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Aug 7 03:48:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614C7132194 for ; Mon, 7 Aug 2017 03:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gex8-zstnTl0 for ; Mon, 7 Aug 2017 03:48:40 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F651321A4 for ; Mon, 7 Aug 2017 03:48:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 64EF2A2; Mon, 7 Aug 2017 12:48:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502102918; bh=vY4jbXrE7GRlwwtnp2uXby5t2QDn3/ymR3JQ9MXtzXo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=czA80joviL9ytSsq7A/Augc8U0xIKOpHWcyaxDMhaK0exV7H18mDd2h1b4FTwDa+C zxTrzOb9VduES2SDq+UyLIBlMGH8XX8NKRwwZZTqDFhVKNDf6MTsdXlZDGA0WooOgD J0FjlFXdEXtnmYjumH7RtVIQPrHYYOJAMtHfcbn0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4B845A1; Mon, 7 Aug 2017 12:48:38 +0200 (CEST) Date: Mon, 7 Aug 2017 12:48:38 +0200 (CEST) From: Mikael Abrahamsson To: Simon Hobson cc: v6ops list In-Reply-To: <4B4511FB-5E38-46B9-870C-3882B55F852B@thehobsons.co.uk> Message-ID: References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <4B4511FB-5E38-46B9-870C-3882B55F852B@thehobsons.co.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:48:42 -0000 On Mon, 7 Aug 2017, Simon Hobson wrote: > Presumably that means another separate prefix. And when 2003:: is used, 2004:: will get allocated and so on. We have 2000::-3fff:: to get this right. If we deem that we're now wasting addresses, we'll have to come up with different policy for 4000::-5fff::: (the next /3. > At what point will people be suggesting that we could have avoided the > routing table bloat by allowing better use of the prefixes ? Routing table bloat happens because the allocated prefixes at the higher level are too small, not because they're too big. If someone spends their /29 then next time we should give them a significantly larger prefix to avoid routing table bloat. RIPE at least allocates a 8 times the size of your initial allocation off the bat, so anyone going to them saying "I have a million customers and I want to give each a /48" should receive a /28 or a /27, with a /25 reserved for growth for them (in case they did receive a /28). This is to avoid routing table bloat. > AFAICS the insistence that it must be /64 per host, rather than anything else (eg /80/host or /96/host) seems to be more religion than technical requirement. > I can see the security (through obscurity) and privacy reasons why > individual addresses should come from a /64 (or at least, large) prefix > - but I fail to see much, if any, merit in allocating 2^64 addresses to > a single host "because we can". It's /64 because we can't agree on a smaller size that makes sense to everybody, that at the same time isn't too small. I wouldn't call it religion, but I would call it "healthy sceptisism about what might happen otherwise". Today a non-trivial amount of ISPs hand out /64 to residential users, probably because they they reason that a site is a single subnet. If we allowed /80, what stops them handing out /80? Or /79, because, why not? I kind of like having this hard limit, it means there is reasonable expectation just by looking at the address that "this is a subnet", without having to know the remote end addressing policy. Sure there could be multiple customers within that /64, but we should drive towards having fewer customers sharing the same /64, as opposed to the other way around. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 7 04:07:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E796131CCF for ; Mon, 7 Aug 2017 04:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSkJNaSq8Xa8 for ; Mon, 7 Aug 2017 04:07:50 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12891132017 for ; Mon, 7 Aug 2017 04:07:49 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8388542928 for ; Mon, 7 Aug 2017 13:07:46 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 725B542919; Mon, 7 Aug 2017 13:07:46 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 6455824837; Mon, 7 Aug 2017 13:07:46 +0200 (CEST) Date: Mon, 7 Aug 2017 13:07:46 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Cc: v6ops list Message-ID: <20170807110746.GG45648@Space.Net> References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:07:52 -0000 Hi, On Mon, Aug 07, 2017 at 12:35:25PM +0200, JORDI PALET MARTINEZ wrote: > Most of the RIR policies allow a shorter prefix than /48 for a single site > if justified. "If justified" has traditionally been along the lines of "number of buildings, number of subnets, number of aggregation levels", so, number of *networks*. "Number of hosts" has not been a justification argument in (at least) RIPE IPv6 policy, so that would be a fairly significant change. Personally, I would be very careful here - permitting assignments of larger address blocks because we *waste* a /64 on a potentially very large number of hosts in a network might cause shortage further up. And yes, I think this is extremely wastive, well over the limits of what is normal "do not care about wasting addresses!" level of IPv6 normal. On a subnet, having a "it is big enough for everything, no matter how many hosts" is a desirable property because it makes network planning much easier - single size fits all, focus on more interesting work. A /64 is already excessive here, but given that the number of subnets is bound by factors like "how many different purposes can you come up with?", "router config", etc. I'm willing to accept a /64 here. A /64 per *host* is much less bound - while far beyond anything you can configure on that host, so the trade-off "waste vs. useful number of bits" is not reasonable for me. Should this topic come up in RIPE policy discussion, I'll chair the discussion and refrain from having an opinion, but will reserve the right for a "told you so" later. Gert Doering -- RIPE APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Aug 7 04:21:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0913219F for ; Mon, 7 Aug 2017 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRa7XMQU_V2E for ; Mon, 7 Aug 2017 04:21:42 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7FF13219E for ; Mon, 7 Aug 2017 04:21:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A51C149; Mon, 7 Aug 2017 13:21:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502104866; bh=sMwk6nvnFpj5D0vqNyj Jrclb4ToZhilojK0SJqj/x54=; b=LL2uAvHsSVOHrutZY5iJl0TpD+ckFFZmYj3 s9ba0ju982ZBFTIif56TtBNUTvfGN1CqXNyXmS9O+LY4gvGJrldZXKZWt7LdETnO XficukyXIAAqTFFwY0tpQicDNkXVJoKx75FuC/rsgG0yvaAICisjyYj4JRzvirp3 Ws3MmfGw= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6y0XPeOGhk7p; Mon, 7 Aug 2017 13:21:06 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5] (unknown [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id B2BC33C; Mon, 7 Aug 2017 13:21:05 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_46625299-14D6-43F3-B1D3-FAA39AE05CE8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 13:21:05 +0200 In-Reply-To: <20170807110746.GG45648@Space.Net> Cc: JORDI PALET MARTINEZ , v6ops list To: =?utf-8?Q?Gert_D=C3=B6ring?= References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:21:46 -0000 --Apple-Mail=_46625299-14D6-43F3-B1D3-FAA39AE05CE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > A /64 per *host* is much less bound - while far beyond anything you = can > configure on that host, so the trade-off "waste vs. useful number of = bits" > is not reasonable for me. I agree. Sticking to /64 for subnets is fine. Delegating prefixes to = hosts is also fine, but they don't have to (shouldn't) be /64. A /96 per = host sounds about right. When acting as a router (connection sharing, = running VMs etc) the need for separate subnets (=3D /64s) comes back, = but for individual host behaviour a /96 should be fine. > Should this topic come up in RIPE policy discussion, I'll chair the > discussion and refrain from having an opinion, but will reserve the = right > for a "told you so" later. :-) Sander --Apple-Mail=_46625299-14D6-43F3-B1D3-FAA39AE05CE8 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----- iQEcBAEBCAAGBQJZiE0hAAoJEKAtA7D+JBO5MJIH/0/rZwbbb01LYG1m+fsI/SVn M+Vo14pkR65rrRbm2B2oY19FAt8IGV1k15SK/yjaNEqYm8cwGjV45SGBAdA6TmqO P1d0VOx0pPcPfx/a/9WFst/GD+m265f267BHh2AZtVv96RIjkf0rOwo1N6gFnWQW lfgrONSHZHyUjQ6vUjRxeg0o0KoJvUZXmaqSvE8Toj5fBVfoxeEZkONmpWRbOS5L EBiv81otmx53pD/DeY8X3nPfH26Yp64395olHsSHpVDBqGPz9Al8UBdWeAmFuBpx 363kmsu9PBBxVRBiobZQpM/P+7/kve0o0DXgrsuzZod4OXWCu7rRUBGVvGAoWII= =jy7b -----END PGP SIGNATURE----- --Apple-Mail=_46625299-14D6-43F3-B1D3-FAA39AE05CE8-- From nobody Mon Aug 7 04:34:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FFE1321A7 for ; Mon, 7 Aug 2017 04:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq25lJ8QJBvH for ; Mon, 7 Aug 2017 04:34:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA8513201F for ; Mon, 7 Aug 2017 04:34:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3525DA3; Mon, 7 Aug 2017 13:34:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502105689; bh=iT/CFdxkKZcXYFCJ+KGxaGvy6FueC71DtoU5aazDVJA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ki6EaDKW5Qf8cF6D8m41vrRk5mS9TiXoLZuZIbRrExY9weQvr09l7WYPuTgDEbyiZ HUtZapOzjREvbf1AfYLs0yiz85+nIyXgTmBoWnd+z9S1fKLKHDlFOCU8v1at4eX8b8 meLpGkqSaIAIBE87tiNSX766HzPE75dtjJCI5kck= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 32DEDA2; Mon, 7 Aug 2017 13:34:49 +0200 (CEST) Date: Mon, 7 Aug 2017 13:34:49 +0200 (CEST) From: Mikael Abrahamsson To: Sander Steffann cc: =?ISO-8859-15?Q?Gert_D=F6ring?= , v6ops list In-Reply-To: Message-ID: References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:34:52 -0000 On Mon, 7 Aug 2017, Sander Steffann wrote: > I agree. Sticking to /64 for subnets is fine. Delegating prefixes to > hosts is also fine, but they don't have to (shouldn't) be /64. A /96 per > host sounds about right. When acting as a router (connection sharing, > running VMs etc) the need for separate subnets (= /64s) comes back, but > for individual host behaviour a /96 should be fine. Our problem is that we can't tell which is which. The laptop I show up at IETF meeting with normally has its own host stack, plus at least 2 other VMs running, sometimes more. How should the network differentiate me from "just a single host" when I connect to the IETF wifi? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 7 04:37:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2351321AB for ; Mon, 7 Aug 2017 04:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH-z2Inv1dWu for ; Mon, 7 Aug 2017 04:37:21 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DBDC128AA1 for ; Mon, 7 Aug 2017 04:37:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BF7464B; Mon, 7 Aug 2017 13:37:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502105831; bh=4d9LQUD4Bz/MATsMUH9 RD/8QYCWrHWbYeGOgGklTAJw=; b=Qwvwc0jgzdJOdo1WLEDKL5XxBUc733EdOR6 wsd+n4YDH+QSyaInqcmEZLPe9CkF13ogh3OBH9nkSCaDES4fbc/cqjnexpumsMAh hC+ziAGIZi1u8sLL6qUXUgIPE9JQvghZhctSQCYS23/4HWjkwRNfNouWpl/IB6Vu myPhkL0I= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hQgOKRaH5qlZ; Mon, 7 Aug 2017 13:37:11 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5] (unknown [IPv6:2a02:a213:a301:b480:757a:d3e8:3380:2cf5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 6D8C449; Mon, 7 Aug 2017 13:37:10 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <6DA66FF8-732F-4C15-8AB0-C7656514BD17@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_0164466D-95EA-41AB-BB80-C451FEB7A07C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 13:37:09 +0200 In-Reply-To: Cc: =?utf-8?Q?Gert_D=C3=B6ring?= , v6ops list To: Mikael Abrahamsson References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:37:22 -0000 --Apple-Mail=_0164466D-95EA-41AB-BB80-C451FEB7A07C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > How should the network differentiate me from "just a single host" when = I connect to the IETF wifi? Your laptop should know :-) It could ask for a /96 or a /64 with = DHCPv6-PD. Or the laptop can ask for a /96 for itself and your = virtualisation software can ask for its own /64. It even gives you a = nice separation of responsibilities. Cheers, Sander --Apple-Mail=_0164466D-95EA-41AB-BB80-C451FEB7A07C 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----- iQEcBAEBCAAGBQJZiFDlAAoJEKAtA7D+JBO5qVAH/jdRfeKaeyCe6IiFgnF/SHSA 4pP4pg2hWodrhezsjrPkC1M8Z640LMV6xRhNOcwjONVK2uvuLNcA23ic+0GQxn9d 4wud18TJBnG+THEmzNakQT05IBgstnvDc8yORfFRCF8oyic+Tvs1QTktCcFTD9R0 4/WnLFY9cWVUFaaQSQhEOOlEpWKYbfR54Ohi74zMi+mw1lhB/OpfGkqG0Xq34HmC CdyfOew+1ocN9nyUsJVHEJrIBNtz4hHEsviIuCuCcz57zwj++TGRcCAkhJe00Aqj sVtc54SN3R4CtI0qpBBAIQyqHmjCKc5ha7AvO2ZZYic91PnYneGKBJ1aUMncjRY= =jTgr -----END PGP SIGNATURE----- --Apple-Mail=_0164466D-95EA-41AB-BB80-C451FEB7A07C-- From nobody Mon Aug 7 04:40:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E8128AA1 for ; Mon, 7 Aug 2017 04:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eid8XI6YkvBq for ; Mon, 7 Aug 2017 04:40:07 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8789B127ABE for ; Mon, 7 Aug 2017 04:40:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9D86DA2; Mon, 7 Aug 2017 13:40:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502106005; bh=pr+is3X5D1WbEkwRfCjQ95tvgO21AEZZlv86uY2EaXI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Uq/f2nBFPk9SX/wu7TOnxAzqFefSBR4L4agcayun71IFaDXrdzLFD1nNMsna/Z3jc TjYG9pPYSX8cOGbXZYNBvCpqh5U7l3ZjxfCWgKkJ2yrf/xEysDBvKrkTfpdWi7662w AZDUTNDIvosNLH+ozM8Lhu0Ec0uifao5uRmtfAfc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9A51EA1; Mon, 7 Aug 2017 13:40:05 +0200 (CEST) Date: Mon, 7 Aug 2017 13:40:05 +0200 (CEST) From: Mikael Abrahamsson To: Sander Steffann cc: =?ISO-8859-15?Q?Gert_D=F6ring?= , v6ops list In-Reply-To: <6DA66FF8-732F-4C15-8AB0-C7656514BD17@steffann.nl> Message-ID: References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <6DA66FF8-732F-4C15-8AB0-C7656514BD17@steffann.nl> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:40:09 -0000 On Mon, 7 Aug 2017, Sander Steffann wrote: > Your laptop should know :-) It could ask for a /96 or a /64 with > DHCPv6-PD. Or the laptop can ask for a /96 for itself and your > virtualisation software can ask for its own /64. It even gives you a > nice separation of responsibilities. Please see me posts from thursday regarding G-5 requirement in 7084 where I describe why DHCPv6-PD is a bad fit for this use-case. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 7 04:53:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0673129ABE for ; Mon, 7 Aug 2017 04:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRT7hE0EFPaE for ; Mon, 7 Aug 2017 04:53:44 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510C9128AA1 for ; Mon, 7 Aug 2017 04:53:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2EE2142928 for ; Mon, 7 Aug 2017 13:53:42 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1EFAD42922; Mon, 7 Aug 2017 13:53:42 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1065024A23; Mon, 7 Aug 2017 13:53:42 +0200 (CEST) Date: Mon, 7 Aug 2017 13:53:41 +0200 From: Gert Doering To: Mikael Abrahamsson Cc: Sander Steffann , Gert =?iso-8859-1?Q?D=F6ring?= , v6ops list Message-ID: <20170807115341.GI45648@Space.Net> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VChLUJW13rC1nfm8" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:53:47 -0000 --VChLUJW13rC1nfm8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 07, 2017 at 01:34:49PM +0200, Mikael Abrahamsson wrote: > How should the network differentiate me from "just a single host" when I= =20 > connect to the IETF wifi? DHCPv6-PD comes to mind... as the next person to speak up will want a routed setup with many layers in their VM stack on their laptop,=20 "something with routed subnets" is (obviously) needed. Otherwise, you're back to "your VM stack needs to do bridging", which they notoriously cannot get right for the generic "bridging to wifi" case. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --VChLUJW13rC1nfm8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmIVMUACgkQ31bAZeTO f8UzoxAAsWN3QUQrl8+KYYZgX1DdY/+NKIpC2oy3d7Rk9ssCF6BctaQKK621R133 B8ABbcypFu/XQpYmCI5ClD9kT8FdlRB4v/H6jWstICoC0gKS9JniNCgBkZThHlBz qq8esWiKI9XIx3VH40+32ALOCDHSLFlDUrZ5vABiy7rDrOeRswIwPXbb51Qv5+oO RtCbs2WoPDmxcGfKBiPPch4L1zh5JatRpcblL3Di3kWWlFGSAInxiNmxHusDTuks 5u6PXeWwWN2xpvdKtRFjwRJovpqVUr8/M3mVLRTqVkHSwaZ+RQjtXDx5vaUG3lPE 8RyFoVE+I30GVphzVsfkqioKjHtjeaVA5LWXiSjGUitVv/BaI8zt58i4PINkrzp5 KXjw9ZzCJCbCgpLUZ/tMsuKB+Dtn/5vTuFzzhu8cPJb/uLWCLWjr6qBv3n94g3Py XLSqnByu9stikCG43K5v6Ek9j4OjzvDtvA+VVnuZizu/Fy6Cy7FbPxxMpaRttG96 16/5+QTrjIycHayZWIPoybnlsvdIev/7OdrggWO1IZxHRLF7cMaSjRmIhJszNovl FvZ6Oo4Zq0IbqHuF3TnKWM7pG+s55mqwbFw1rEZqCy1n6mxhYsMLOPfemV2Nh0K5 6v+LR6kz5aXcYr0Qb0sE/k9/5lrfPJkPpDILR6xOKIFy+7vHhVE= =sUXP -----END PGP SIGNATURE----- --VChLUJW13rC1nfm8-- From nobody Mon Aug 7 05:02:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E127213219D for ; Mon, 7 Aug 2017 05:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXF0Hk3othru for ; Mon, 7 Aug 2017 05:02:47 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85068127ABE for ; Mon, 7 Aug 2017 05:02:47 -0700 (PDT) X-AuditID: 60721c4c-001ff70000004e62-75-598856e5909d Received: from VAADCEX11.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id DD.AE.20066.5E658895; Mon, 7 Aug 2017 08:02:46 -0400 (EDT) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 7 Aug 2017 08:02:45 -0400 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.002; Mon, 7 Aug 2017 08:02:45 -0400 From: "Brzozowski, John" To: DY Kim , "gunter.van_de_velde@nokia.com" CC: v6ops list Thread-Topic: privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 Thread-Index: AQHTDofhlp++pL4g7kKII+B5KH8QfqJ4zRcA Date: Mon, 7 Aug 2017 12:02:45 +0000 Message-ID: <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> In-Reply-To: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf1AUZRju21tgOe7DZY+7+1zRZPWfsBAcS8aMzMyuoMbGcub6B5a7lbs4 7m529/hR4hjNFSNZjTSUa1POSA4VYz+ABMYSTofQYrJosCx1BJLxRmccs5QUpv1292Cvv/bd 53m/53ne99tZysK0WVkqEJIFMcQHuXQrWSk9VfLA5e0tnqK397lK3jhyOKPk2qHboOT74W8s Gy3ufuV8hrujY4Zwnz/3M7HV8qJ1g08IBuoEcXVppdXfNhcjI825DXtPHgG7waB9D8ikEL0W zXX2ZOCaoY8S6EZsxR5gVevjAP1w5nCG/jIC0NjIZwB3pdMPoZ6h37UTuXQlujTZQ+DaQt+L ptsVDbfTT6CbX3em6z1b0OSf7YRer0F913Qdkl6Jju8b1vohvRm1HOwm9RQbUHPXe1p/Jv0I mv3igqYDaCe6dbrL8HKhc1MfEfoENOo49qNFrx3oyuRcGq4ddCEav/4JqeP3o9GzU0Cvi1Dv x98aeD7698NfVH1K1bwPfT6wWpdfj4YGu0i9zkfvtl4yYuagU/unjKMudOJkX9o7YIliSqQs KCkmJcWkpJiUDoK0T8GyOp73eWv94ahctKbQy1cFhUJvuNbLSzJ+fgXwzYt55X3gRrs7DmgK cDY4sanFw6TxdVJjbRzUUATngBWdr3uY7Kqwr9HPS/4KMRoUJC4X+h5WO+E8XBUN1nAsHH5B Re3zaEiol4KCrH5q3DLYhIVc85wUlSIBbyAclSqiYjAOEGVRZZ+zYlkf3/iyIIZ1szhYQpGc C+5c9ZqHoat5WagRhIggJtl6iuIQ7MPOOaJQLTTsCATlJK2eo8+qvrSZ0cIuhdlY0GkmTHnz IbtFVWTN9P8jE1RmHFRTNjW3jO2hFOFrpUC1YW2HCbwkWxLVbBfDu8+rIJMETZZLYTNekTNJ pdqdBq2Aanl/5h+C6rkzcotgyFA4JLAuuAvr0fiQPxqaH5x1Qqk05mEWmQgcgM2DTRh3mPCF DOxyuBOzi01saozkDyMBvOoXY4ezeHCb+jtZmJuBf29TwSwD1MZGcIV2QQZmmjoPKnhqh8Gk uiXU9RLqeq/yMbxemZfN632mKobXa6DGessxyCTBlPW6MeVMUqlO7G6wKEYUd163bxq6bVt1 ILyjvv+79bs27+9/qfVU91t/rO1NlHk+kMvuRrJGY19eLCg7c+KVxx99U4gnYgNXm47uvdB2 cevT45F77uS4w1kDzxZI3YcuT/y17adfx2Z/K59uyg6O2sueTDxYzG4fvCmvW7dxbnosf/bV lccayMfsSunMeO+VCY6U/HxxgUWU+P8AFDEqt6YFAAA= Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 12:02:49 -0000 VGhlIGFwcHJvYWNoIGRvY3VtZW50ZWQgaW4gdGhlIGRyYWZ0IGNvbXBsaWVzIGFuZCBpcyBjb21w YXRpYmxlIHdpdGggY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgYW5kIHNwZWNpZmljYXRpb25zIGFz IGl0IHBlcnRhaW5zIHRvIHByaXZhY3kgYWRkcmVzc2luZy4gIElmIGFuIG9wZXJhdG9yIG9mIHN1 Y2ggYSBkZXBsb3ltZW50IGFsc28gd2lzaGVzIHRvIGFsdGVyIG9yIHJhbmRvbWl6ZSBob3cgcHJl Zml4ZXMgKHVwcGVyIDY0IGJpdHMpIGFyZSBwcm92aXNpb25lZCBhbmQgdHJhbnNtaXR0ZWQgbm90 aGluZyBjaGFuZ2VzLCBvdXIgYWJpbGl0eSB0byBzdXBwb3J0IHByaXZhY3kgYWRkcmVzc2luZyBp cyB1bmNoYW5nZWQuDQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRFkgS2ltIDxkeWtpbTZAZ21haWwuY29tPg0KRGF0ZTogU3VuZGF5 LCBBdWd1c3QgNiwgMjAxNyBhdCAwMzo0NA0KVG86IEpvaG4gQnJ6b3pvd3NraSA8Sm9obl9Ccnpv em93c2tpQENhYmxlLkNvbWNhc3QuY29tPiwgR3VudGVyIFZhbiBkZSBWZWxkZSA8Z3VudGVyLnZh bl9kZV92ZWxkZUBub2tpYS5jb20+DQpDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVj dDogcHJpdmFjeTogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qt MDcNCg0KICAgIEhpIGF1dGhvcnMsDQogICAgDQogICAgSSBoYWQgc29tZSBxdWVzdGlvbnMgb24g U2VjLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiB0aGUgZG9jdW1lbnQuIEl0IGlzIHNhaWQ6 DQogICAgDQogICAgCVRoZSBtZWNoYW5pY3Mgb2YgSVB2NiBwcml2YWN5IGV4dGVuc2lvbnMgUkZD NDk0MSBpcw0KICAgICAgIAljb21wYXRpYmxlIHdpdGggYXNzaWdubWVudCBvZiBhbiBVbmlxdWUg SVB2NiBQcmVmaXggcGVyIEhvc3QuDQogICAgDQogICAgSW4gdGhlIGNhc2Ugb2YgdW5pcXVlIHBy ZWZpeGVzIHBlciBob3N0LCB0aGUgcHJpdmFjeSBvZiBpbnRlcmVzdCBpcyBpbiByZWdhcmQgdG8g dGhlIGhvc3QgcHJlZml4LCBub3QgdGhlIElJRC4gUHJpdmFjeSBvZiBhIGhvc3Qgd291bGQgYmUg Y29tcHJvbWlzZWQgYnkgdXNlIG9mIGl0cyBwcmVmaXgsIG5vdCBvZiBpdHMgSUlEIGFueW1vcmUu IFRoYXQgaXMsIHRoZSBwcml2YWN5IGV4dGVuc2lvbiBtZWNoYW5pc21zIHByb3Bvc2VkIGluIHJm YzQyOTEgb3IgZWxzZXdoZXJlIGluIHNpbWlsYXIgd2F5cyB3b3VsZCBiZWNvbWUgcG9pbnRsZXNz IGZvciBob3N0IHByZWZpeGVzLg0KICAgIA0KICAgIEhvdyB3b3VsZCB5b3UgYWNjZXNzIHRoaXMg c2l0dWF0aW9uPw0KICAgIA0KICAgIEFuIGFsdGVybmF0aXZlIG1pZ2h0IGJlIHlvdSBhcHBseSBh IHByaXZhY3kgZXh0ZW5zaW9uIG1lY2hhbmlzbSB0byB0aGUgaG9zdCBwcmVmaXhlcy4gSG93ZXZl ciwgdGhlIHBvb2wgb2YgdGhlIGF2YWlsYWJsZSBwcmVmaXhlcyB3b3VsZCBzaWduaWZpY2FudGx5 IGJlIHJlZHVjZWQgZnJvbSAyKio2NCBmb3IgSUlEIGRvd24gdG86DQogICAgDQogICAgCW8gMioq MTYgaWYgdGhlIGNvbnRyb2xsZWQgZG9tYWluIGlzIGEgdXN1YWwgLzQ4IHNpdGUNCiAgICAJbyAy KiozMiwgZS5nLiwgaWYgdGhlIGRvbWFpbiBpcyBhIC8zMiBuZXR3b3JrIHNvbWV3aGVyZSB1cHN0 cmVhbSBpbiBhbiBJU1ANCiAgICANCiAgICBBcmVu4oCZdCB0aGVzZSBudW1iZXJzIHRvbyBzbWFs bCBjb21wYXJlZCB3aXRoIDIqKjY0IGluIG9yZGVyIHRvIGJlbmVmaXQgZnJvbSBhbnkgc3VjaCBw cml2YWN5IG1lY2hhbmlzbXM/DQogICAgDQogICAgLS0tDQogICAgRFkNCiAgICANCiAgICANCiAg ICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Mon Aug 7 05:38:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1C132190 for ; Mon, 7 Aug 2017 05:38:50 -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 QnB0RaRgsTbN for ; Mon, 7 Aug 2017 05:38:49 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9A7132026 for ; Mon, 7 Aug 2017 05:38:49 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y192so303343pgd.1 for ; Mon, 07 Aug 2017 05:38:49 -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=Gq6FZGUgLd7CST6aStzj0B5v0xzdDfjJT7xEsXFJK6I=; b=RBYhx6OvdbKcmK9Sid1/++MjflvRVcHH40Iqiq869ubcyvv4Wfr4H6maQc084wWapn vXaaPEzXpLZwgcop1Cln3o9T0HjfUi0CU6ahgenAHUX4AJaGO1cVC/pQ+Kwm74s7Duy8 FcsOnRsHWlIdJSgbOcMpny2ZDX0LO436ruBSzJDGCn/z4iDqkxpjOfefoox4289JAx36 toYcx/XC1SBrwlwCqhFMI4F1snCF2mXCk7s1+lEn0agdwYp0ikeIoV3NzzAoph7SBNPZ iQaOHwjXWNnVah7p130xHvUZGLxdS63XQXFgObacD5ZfMpgDLeq7GfXD1TOTTOZpE1CB pDZw== 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=Gq6FZGUgLd7CST6aStzj0B5v0xzdDfjJT7xEsXFJK6I=; b=Z4RO1P0/BtKJGFIfcp3U3wB5atOOA8f1qdDoWhbRrbFrOE00Eg1CooY0UZthS2KsVC s89BBFViHY74n5sfXdKjeql6qmHuesq/4GGQ4XvLZZO4mbl2l89qWXM9g/oGQcc4Xn8p SU5cGIwvy4yp0K3zEp268tMhSUoF9Dq8Tw5fI6IIn1fDbEiOp86SPDXRmwfH7sWPNThx 6qzfYmVSKt2F2GdMBORjsw1trJaAD138XwgR7vr0HS1NVhZBD3JIxWMEg2QojlYjBzOo 5VeRnDAbqRvzPmMy1NEEVH/MfE8ajmW7OBckT6NGJFm14ldS8ai6yLQNuPyhg9Muaeg+ hLHQ== X-Gm-Message-State: AHYfb5i85XDjIXwH2+wzpP/sm9J/9jayDEwjhrb/KeCiLzu5RRSXI/+M oVHVQzPE8TDgPw== X-Received: by 10.98.13.70 with SMTP id v67mr444539pfi.182.1502109529284; Mon, 07 Aug 2017 05:38:49 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id r82sm18580558pfe.0.2017.08.07.05.38.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 05:38:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> Date: Mon, 7 Aug 2017 21:38:42 +0900 Cc: "gunter.van_de_velde@nokia.com" , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> To: "Brzozowski, John" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 12:38:50 -0000 So, you mean randomizing, e.g., IID in the case (wherein each host has a = unique /64 prefix) still helps privacy of the host? Well,=E2=80=A6 As soon as I figure out that the site is implementing Unique IPv6 Prefix = per Host (there could be many rather easy way to figure that out, I=E2=80=99= d presume), I would rather chase the /64 prefixes rather than the whole = /128 addresses, in order to chase a specific host and so compromise its = privacy. --- DY > On 7 Aug 2017, at 21:02, Brzozowski, John = wrote: >=20 > our ability to support privacy addressing is unchanged. From nobody Mon Aug 7 05:49:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA959129A92 for ; Mon, 7 Aug 2017 05:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpIEdPau14jy for ; Mon, 7 Aug 2017 05:49:12 -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 9EDA4128C81 for ; Mon, 7 Aug 2017 05:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502110150; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=dsAeskZ+d0Z9y+ue0/Quqm245QgBVssrVzCTwgkyi88=; b=FtT+egNaD/MkU0EUEMlW3EzH9B/evnCoyKrN09ZrxwxBdz+ifHdN0R7QvcrI0ARAYtC+6F2NatH/C1FdHQOxHTryJ3Tp9Jhs2xY9b9Rq2Bo7S2kEFisVLzxVO24LvPC63w3k/V0xuJkTN1E3WngRc4suHtnT48dsh0wzhVCxZvk= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0088.outbound.protection.outlook.com [94.245.120.88]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-42-BCtNfXJgMZuWQJWYYWq2gA-1; Mon, 07 Aug 2017 13:49:06 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1156.eurprd07.prod.outlook.com (10.163.188.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Mon, 7 Aug 2017 12:49:05 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 12:49:05 +0000 From: Tim Chown To: Gert Doering CC: Mikael Abrahamsson , v6ops list Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt Thread-Index: AQHTDdGB+HQZzf+4OUiIy6ehixgf+KJ2mRuAgAARjoCAAME1AIAAOwAAgAAmjACAAJ4ugIAAQiEAgAAIZoCAAAkJAIAAA7mAgAAD1oCAAAVGgIAAD3iA Date: Mon, 7 Aug 2017 12:49:05 +0000 Message-ID: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170807115341.GI45648@Space.Net> In-Reply-To: <20170807115341.GI45648@Space.Net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [212.188.254.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1156; 20:SMQwxjZLj7wiUmNFElR26xM4ZmzVRojdBaLyGF7/nQFR8kXwHHt6X1sk1CdmajcMEYf/UhRFOazGRqGFQmE1b+lFevk4paNcVWLgYoeiz7Be3tOHIoyKl3eO2IeGAQ5WQtxmi4lZ8uCbZLIgPpSRfW+NlKAUndHuWgECM27CQ2Q= x-ms-office365-filtering-correlation-id: 28c075ca-d70e-483a-4592-08d4dd92aff4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1156; x-ms-traffictypediagnostic: AM3PR07MB1156: x-exchange-antispam-report-test: UriScan:(21532816269658); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1156; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1156; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(189002)(199003)(24454002)(2950100002)(66066001)(53936002)(99286003)(5660300001)(42882006)(6916009)(6512007)(106356001)(3660700001)(105586002)(86362001)(50986999)(54906002)(82746002)(76176999)(68736007)(2906002)(101416001)(33656002)(3280700002)(97736004)(230783001)(72206003)(81156014)(6506006)(189998001)(4326008)(8676002)(7736002)(6436002)(36756003)(102836003)(478600001)(3846002)(25786009)(5250100002)(53546010)(14454004)(57306001)(2900100001)(8936002)(6116002)(38730400002)(83716003)(110136004)(74482002)(50226002)(6246003)(305945005)(6486002)(81166006)(229853002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1156; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <7E18704030F76749AF7FFC9BE2D2AD47@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 12:49:05.2286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1156 X-MC-Unique: BCtNfXJgMZuWQJWYYWq2gA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 12:49:16 -0000 PiBPbiA3IEF1ZyAyMDE3LCBhdCAxMjo1MywgR2VydCBEb2VyaW5nIDxnZXJ0QHNwYWNlLm5ldD4g d3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IE9uIE1vbiwgQXVnIDA3LCAyMDE3IGF0IDAxOjM0OjQ5 UE0gKzAyMDAsIE1pa2FlbCBBYnJhaGFtc3NvbiB3cm90ZToNCj4+IEhvdyBzaG91bGQgdGhlIG5l dHdvcmsgZGlmZmVyZW50aWF0ZSBtZSBmcm9tICJqdXN0IGEgc2luZ2xlIGhvc3QiIHdoZW4gSSAN Cj4+IGNvbm5lY3QgdG8gdGhlIElFVEYgd2lmaT8NCj4gDQo+IERIQ1B2Ni1QRCBjb21lcyB0byBt aW5kLi4uICBhcyB0aGUgbmV4dCBwZXJzb24gdG8gc3BlYWsgdXAgd2lsbCB3YW50DQo+IGEgcm91 dGVkIHNldHVwIHdpdGggbWFueSBsYXllcnMgaW4gdGhlaXIgVk0gc3RhY2sgb24gdGhlaXIgbGFw dG9wLCANCj4gInNvbWV0aGluZyB3aXRoIHJvdXRlZCBzdWJuZXRzIiBpcyAob2J2aW91c2x5KSBu ZWVkZWQuDQo+IA0KPiBPdGhlcndpc2UsIHlvdSdyZSBiYWNrIHRvICJ5b3VyIFZNIHN0YWNrIG5l ZWRzIHRvIGRvIGJyaWRnaW5nIiwgd2hpY2gNCj4gdGhleSBub3RvcmlvdXNseSBjYW5ub3QgZ2V0 IHJpZ2h0IGZvciB0aGUgZ2VuZXJpYyAiYnJpZGdpbmcgdG8gd2lmaSINCj4gY2FzZS4NCg0KVGhl IGRyYWZ0IGRlc2NyaWJlcyBSQS1iYXNlZCBwcm92aXNpb24sIHdpdGggLzY0IGFzIOKAnGN1cnJl bnTigJ0gcHJhY3RpY2UuICBUaGVyZeKAmXMgbW9yZSBkZXRhaWwgaW4gdGhlIG9yaWdpbmFsIG5v bi1XRyB2ZXJzaW9uIC0gZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv c3QtMDANCg0KVGhlcmUgd2FzIHB1c2hiYWNrIG9uIERIQ1AtUEQgZm9yIGhvc3RzIGluIHRoZSBS RkM2NDM0LWJpcyBkaXNjdXNzaW9uLCBhbmQgREhDUC1QRCBpcyBub3QgbWVudGlvbmVkIGluIHRo aXMgZHJhZnQuDQoNClRpbQ== From nobody Mon Aug 7 06:06:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50BB1321BE for ; Mon, 7 Aug 2017 06:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHY9S9ujbqe9 for ; Mon, 7 Aug 2017 06:06:56 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7571D1321A6 for ; Mon, 7 Aug 2017 06:06:56 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3739A4292F for ; Mon, 7 Aug 2017 15:06:54 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 26C0442919; Mon, 7 Aug 2017 15:06:54 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 2329D24D9E; Mon, 7 Aug 2017 15:06:54 +0200 (CEST) Date: Mon, 7 Aug 2017 15:06:54 +0200 From: Gert Doering To: Tim Chown Cc: Gert Doering , Mikael Abrahamsson , v6ops list Message-ID: <20170807130654.GM45648@Space.Net> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170807115341.GI45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ye+fncnJnvuoUcW1" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:06:59 -0000 --Ye+fncnJnvuoUcW1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 07, 2017 at 12:49:05PM +0000, Tim Chown wrote: > There was pushback on DHCP-PD for hosts in the RFC6434-bis discussion, an= d DHCP-PD is not mentioned in this draft. I'm aware of that, and of course, DHCPv6 is the worst protocol on earth. My point could be reworded as "you need some mechanism to tell the network what your host wants" - because whatever generic mechanism we devices that will handle all the superspecialcase variants of "I have a complete ISP with many levels of prefix delegation running as VMs on my routers" will excercise pressure on the "how many /64 prefixes can we afford to keep arou= nd for a single wifi pool?" side. To do some reality check. My laptop usually wants *one* IPv6 address, which better should not change while it's attached (because it would break my SSH sessions). If I happen to run VMs, each VM needs one IPv6 address - which didn't work last time at all because vmware had issues bridging IPv6 to wifi (so I used NATted IPv4 instead). Even with all VMs I have on my laptop, I do not expect that I will ever nee= d=20 a /64 on it. A /120 would be perfectly fine today, a /96 would be extremely spacious. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Ye+fncnJnvuoUcW1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmIZesACgkQ31bAZeTO f8WijQ/7BlUMW9gP/AIxBH9lIWW45suH4zbUkjjYyRQ7D1PxbfudFv6wbh0SQkGb ZRrEvW6+acK5RdaoBvaSMlAuKSs6k6sxdIfSrEYtKBOqkAnYYUOCjCUhOJ6zC0wN B8He9WMYhv8+AGVkDgTN3bZ1IGpA7wsuXRbUpumK4UfA5SK/jo6oNAkot8N0d5CC 1uFnKpo6To4WLAvnYQXrUNOqDhE5BFA16iVjYjlJc0JAipmgmbEJiZJd+ncTCvFw mzFyejFrisEltoNKe2z2xCvrRkMVPI+pTFx0pr+FvCoXuHxD2VJZ3H4RWEGQHhiW S1M8/NCPfiaRtRMqLDJhWXywdNuOixj8nM/6kvWRbe1UEPKV7efGJtW3uVmGIm58 Bp2kwlO0+yw/rm+G9B/6YLyc6w25SppjlpZrRZL0gMINXEm9U3yuUu+LS2aWPCoo h3Y9dK6+EhfPKzMUN6JrjsuXk6mfq2JgIUd+FGFviaFmly+QyDXZ4v12bX18sbt8 MAkdEgtONBqjl0RKdYIzwG0OSdAOuOMdvo6IOEx9W4Y0cfWUYGvOHZjO9l1P0oRe OKinQdq4xy34GAUfnT3nQaI5/IEZi6fU8i0Xej4J66rfkzstQdgy4xDLYCgn9bc1 wUmmKdu3NIKm2zcoNNFVOKMe9yPbbZlYkdHr3s0DO9tauMrYgyo= =MW4o -----END PGP SIGNATURE----- --Ye+fncnJnvuoUcW1-- From nobody Mon Aug 7 06:07:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B5F12EC11 for ; Mon, 7 Aug 2017 06:07: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t1UsjMBDmd1 for ; Mon, 7 Aug 2017 06:07:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A51132190 for ; Mon, 7 Aug 2017 06:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502111243; x=1502716043; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=+ESt2eJnv7VgyVfgvoOPUWliu NH/Si++l1pyrxsYVvA=; b=sFZDEfbASiN02eeKVf/DzyQ4aECjvLAueGtsDGOnC yyxHP4auMCtVbaRnm797NF0M7LIU/MbrR7NiAUZ4OvV869IqRCOVFyejD+SPzg+f wTIrnwbcY5q+Sh5Rpuy6PN49ZhcJ9ZpB0F84vjPVre0O7zvRz49fQtB1Fc/CJ9tT yU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ak+jqVYH1OMBpZXCfZgJocfGilkLfhHq2QRt/pUZ3/dqhKFmoGiNa6KSMgbK DoIgsOenraEyyd0Ek6IGvf5CwHvm1Q61n8keWg+bNXHQnw5yI9IJUcz7L l9pvyrJ6qT6UB91gE6nlpj5i9YBaV+OQF0fpBL8/9tg96sR8lAKzR4=; X-MDAV-Processed: mail.consulintel.es, Mon, 07 Aug 2017 15:07:23 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 07 Aug 2017 15:07:22 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005498485.msg for ; Mon, 07 Aug 2017 15:07:20 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170807:md50005498485::zBpMujHj6QZ0LLj1:0000A2U2 X-Return-Path: prvs=13920e8dc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 07 Aug 2017 15:07:18 +0200 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: <831C0221-2C95-4B49-9CE3-A7FA92AE138B@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> In-Reply-To: <20170807110746.GG45648@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:07:30 -0000 I=E2=80=99m not saying that this will apply to =E2=80=9Cevery=E2=80=9D site= , and I guess that in most of the cases, if they have already a /48, they m= ay want to use part of it the way is described in this document, not necess= arily the complete /48. For example, from the /48, you may be using a /56 i= n a data center which has servers with tons of VMs. So the difficulty here is to find the way to justify those cases that reall= y need this, if there are cases that need, for example instead of a /48, a = /47, /46 or /44, etc. Regards, Jordi =20 -----Mensaje original----- De: Gert Doering Responder a: Fecha: lunes, 7 de agosto de 2017, 13:07 Para: JORDI PALET MARTINEZ CC: v6ops list Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-hos= t-07.txt Hi, =20 On Mon, Aug 07, 2017 at 12:35:25PM +0200, JORDI PALET MARTINEZ wrote: > Most of the RIR policies allow a shorter prefix than /48 for a single= site=20 > if justified.=20 =20 "If justified" has traditionally been along the lines of "number of bui= ldings, number of subnets, number of aggregation levels", so, number of *networ= ks*. =20 "Number of hosts" has not been a justification argument in (at least) RIPE IPv6 policy, so that would be a fairly significant change. =20 Personally, I would be very careful here - permitting assignments of=20 larger address blocks because we *waste* a /64 on a potentially very=20 large number of hosts in a network might cause shortage further up. =20 And yes, I think this is extremely wastive, well over the limits of wha= t is normal "do not care about wasting addresses!" level of IPv6 normal. =20 On a subnet, having a "it is big enough for everything, no matter how many hosts" is a desirable property because it makes network planning m= uch easier - single size fits all, focus on more interesting work. A /64 is already excessive here, but given that the number of subnets is bound by factors like "how many different purposes can you come up with?", "router config", etc. I'm willing to accept a /64 here. =20 A /64 per *host* is much less bound - while far beyond anything you can configure on that host, so the trade-off "waste vs. useful number of bi= ts" is not reasonable for me. =20 =20 Should this topic come up in RIPE policy discussion, I'll chair the discussion and refrain from having an opinion, but will reserve the rig= ht=20 for a "told you so" later. =20 Gert Doering -- RIPE APWG chair --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Aug 7 06:13:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3AE1321B7 for ; Mon, 7 Aug 2017 06:13:13 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ietOXXqQaYSp for ; Mon, 7 Aug 2017 06:13:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE60E1321D2 for ; Mon, 7 Aug 2017 06:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502111589; x=1502716389; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=KJ26UsnFnIf58NO6vd6obS5lg jhcUIpG6rf2xkXhLk0=; b=U019ziszICTipO0KOje3Zr55xO9nEHpaSZigAuYmp QP2ly2+8LAL07TC/9AK4Ao+LnG8lr+xRDy6SU8bvojaST3EDnVC2wpzvsba6u4pa NCuNiy9EWN/I9FsRswqlzUwYyhu6YmsWT/tqw+Njm2xXrS2vRccihjq1ok24CMkU dU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=oQdESmraAqQ8lhrOFZuXiQ3MrUUFZ37rhdWy57q9RlFz55KQ92KvPHWHlqvQ s7+Nfl78/fHyvfOJ0IUGfBmWKMK1j95u5b8CFNEyhHGRtk3m34cX+lBG6 I4+NeL1KjkMu55zyYpP9DsDvAU/4D/KMcJor2v2zsiJWDj16JHQAKc=; X-MDAV-Processed: mail.consulintel.es, Mon, 07 Aug 2017 15:13:09 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 07 Aug 2017 15:13:08 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005498490.msg for ; Mon, 07 Aug 2017 15:13:07 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170807:md50005498490::STRENcalg++vkADW:00000/gW X-Return-Path: prvs=13920e8dc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 07 Aug 2017 15:13:05 +0200 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:13:14 -0000 I see the need of this document more for servers or devices that may have m= ultiple VMs than =E2=80=9Cindividual=E2=80=9D PCs where privacy is an issue= . It may happen, of course, but even if you have a /64 in a single laptop, = the privacy issues are actually =E2=80=9Clower=E2=80=9D than if you have a = single /128 address. I think many sites will have a mix of =E2=80=9Cregular=E2=80=9D SLAAC/DHCPv= 6 usage with one address per host, and one /64 per host, so not sure how yo= u will be able to identify that. How you know if several /128 from the same= /64 are in the same host running many VMs or they are actually different h= osts? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de DY Kim Responder a: Fecha: lunes, 7 de agosto de 2017, 14:39 Para: "Brzozowski, John" CC: v6ops list , "gunter.van_de_velde@nokia.com" Asunto: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 So, you mean randomizing, e.g., IID in the case (wherein each host has = a unique /64 prefix) still helps privacy of the host? =20 Well,=E2=80=A6 =20 As soon as I figure out that the site is implementing Unique IPv6 Prefi= x per Host (there could be many rather easy way to figure that out, I=E2=80= =99d presume), I would rather chase the /64 prefixes rather than the whole = /128 addresses, in order to chase a specific host and so compromise its pri= vacy. =20 --- DY =20 =20 =20 =20 =20 =20 =20 =20 > On 7 Aug 2017, at 21:02, Brzozowski, John wrote: >=20 > our ability to support privacy addressing is unchanged. =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 use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Aug 7 06:52:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E491131CD5 for ; Mon, 7 Aug 2017 06:52: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 EJeNZUYnEuyJ for ; Mon, 7 Aug 2017 06:52:04 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1091D13202A for ; Mon, 7 Aug 2017 06:52:03 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1deiRq-001mUz-D9; Mon, 07 Aug 2017 15:51:58 +0200 Date: Mon, 7 Aug 2017 15:51:58 +0200 From: David Lamparter To: DY Kim Cc: "Brzozowski, John" , v6ops list , "gunter.van_de_velde@nokia.com" Message-ID: <20170807135158.GW773745@eidolon> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:52:06 -0000 On Mon, Aug 07, 2017 at 09:38:42PM +0900, DY Kim wrote: > So, you mean randomizing, e.g., IID in the case (wherein each host has > a unique /64 prefix) still helps privacy of the host? > > Well,… > > As soon as I figure out that the site is implementing Unique IPv6 > Prefix per Host (there could be many rather easy way to figure that > out, I’d presume), I would rather chase the /64 prefixes rather than > the whole /128 addresses, in order to chase a specific host and so > compromise its privacy. I had a hacked-up implementation of this draft where the router actually implements a lifetime for the entire /64 assigned to the host. After a configurable amount of time, it would advertise a different /64 to the client (while keeping the old one around for some period of overlap, with valid-lft but not preferred-lft.) This has the downside of the router "controlling" client privacy, but then again if you're the router you can always leak client's L2 addresses. It also has the upside of the router "forcing" client privacy even on clients that don't care for privacy addrs ;) This is not explicitly suggested by the draft, it just seemed the obvious approach to me. You need to somehow track and expire client prefixes anyway. Cheers, -David P.S.: I'm currently hacking on FRR's RA codebase anyway, I may or may not find time to resurrect the old hack, so there may or may not be an additional implementation. No promises ;) From nobody Mon Aug 7 07:39:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8681F1323B1 for ; Mon, 7 Aug 2017 07:39: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBrAtu-vVkCo for ; Mon, 7 Aug 2017 07:39:29 -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 9F0031323AE for ; Mon, 7 Aug 2017 07:39:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 461611A071 for ; Mon, 7 Aug 2017 14:39:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <20170807135158.GW773745@eidolon> Date: Mon, 7 Aug 2017 15:39:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <012F35DD-24F6-4EA9-B19D-B7F186382AF6@thehobsons.co.uk> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> <20170807135158.GW773745@eidolon> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 14:39:31 -0000 David Lamparter wrote: > I had a hacked-up implementation of this draft where the router = actually > implements a lifetime for the entire /64 assigned to the host. After = a > configurable amount of time, it would advertise a different /64 to the > client (while keeping the old one around for some period of overlap, > with valid-lft but not preferred-lft.) >=20 > This has the downside of the router "controlling" client privacy, but > then again if you're the router you can always leak client's L2 > addresses. It also has the upside of the router "forcing" client > privacy even on clients that don't care for privacy addrs ;) But, doesn't this then preclude the client keeping any persistent = connections open ? I'd be "very annoyed" if (for example) I found all my = SSH terminal sessions suddenly closed due to having an address change = forced on my machine.= From nobody Mon Aug 7 08:03:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17EF1324D6 for ; Mon, 7 Aug 2017 08:03:40 -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 3R1LYoR4TNIu for ; Mon, 7 Aug 2017 08:03:38 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A375C132483 for ; Mon, 7 Aug 2017 08:03:38 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1dejZA-001nba-I2; Mon, 07 Aug 2017 17:03:36 +0200 Date: Mon, 7 Aug 2017 17:03:36 +0200 From: David Lamparter To: Simon Hobson Cc: v6ops list Message-ID: <20170807150336.GX773745@eidolon> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> <20170807135158.GW773745@eidolon> <012F35DD-24F6-4EA9-B19D-B7F186382AF6@thehobsons.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012F35DD-24F6-4EA9-B19D-B7F186382AF6@thehobsons.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:03:41 -0000 On Mon, Aug 07, 2017 at 03:39:24PM +0100, Simon Hobson wrote: > David Lamparter wrote: > > > I had a hacked-up implementation of this draft where the router actually > > implements a lifetime for the entire /64 assigned to the host. After a > > configurable amount of time, it would advertise a different /64 to the > > client (while keeping the old one around for some period of overlap, > > with valid-lft but not preferred-lft.) > > > > This has the downside of the router "controlling" client privacy, but > > then again if you're the router you can always leak client's L2 > > addresses. It also has the upside of the router "forcing" client > > privacy even on clients that don't care for privacy addrs ;) > > But, doesn't this then preclude the client keeping any persistent > connections open ? I'd be "very annoyed" if (for example) I found all > my SSH terminal sessions suddenly closed due to having an address > change forced on my machine. Yes it does. It's really only appropriate for use cases where you have some reasonable value that you can set a client prefix's valid-lft to, e.g. 24h for setups where clients go away overnight. Coincidentally, the hack also expired a client's prefix if the client's linklocal address was unreachable for more than a configurable (lower) time, so that it wouldn't reassign the same prefix if the client comes back. All of this is really from the viewpoint of public / venue / ephemeral networks. -David From nobody Mon Aug 7 08:44:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ACA132421 for ; Mon, 7 Aug 2017 08:44:05 -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 JZvo0DgNq9vw for ; Mon, 7 Aug 2017 08:44:04 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F5313241D for ; Mon, 7 Aug 2017 08:44:04 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id p13so728888pfd.4 for ; Mon, 07 Aug 2017 08:44:04 -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=bnjb1UzXfC63MGrWIicJjQl/BZEDdsKDsml19MkQ5Dc=; b=DR6X6J0f2vTxoaNXBZZZu9hNEgXwNdYhM0zUbuoMsf9Lb8ODVpopJOnS12bWtv/fIA Jbd0DuBDgmL/M80F+Yf9h8FSSuNAoOUqk3+zhqV6qkqeCOgkpieqWBXICEdI+8wHi4L+ BcsFofjSmDBo58qA8oXbbKHNVUr+6c5LbSu/8cuHypa6Csb25hPTBn3CGCsXPbA6Lxxj OVZhC3m25ZMGjh6zaMuSU3zlwQrFaopz+ySJLNHDwjOX0hqFCYymokE/MbRIbZqPG6Lc 190M1V/uDq3WPqfxVSkk/G/cRUgB1K1+icWECN/qFJz7kOU52nkt9GsU/4UCUrL2gGF2 aFHw== 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=bnjb1UzXfC63MGrWIicJjQl/BZEDdsKDsml19MkQ5Dc=; b=bslPa+cUaslzTtbe+i1aXnRJBu7Y6xuy+eNQCYIV3aXxieiSnUc5pEScXxkbc0Z2f9 tyROmvU9DiCVk2+AJzm9+q9A5t9Z0UDVLdNjDWzdN+j1bvywaVwo8aDxSDiqzhFihke0 UMfGriW34Wy0W86lRgJCO4b40n+c1EWeXZUB7PVCJ822VMbrNxbazTo/4yipkYvAZt+s hq0mGI9l3qIbun+GVFpemYXYfpVlA1eYkeBUa29wl5ghVOw38H6sXF9ZjHs/BBSY9whZ Ur+xj+4knk6kkC2KfzzSN2gur2xk9ydZsyoFIQupOjbiMidQtBGHl26AB3JH2Lbetx5r jrWg== X-Gm-Message-State: AHYfb5jyuHdu1ACbXzM9IuvfawL0iOPk+JMfJt90uoguADPS159tegUP ov77ZNNWKNgG6Q== X-Received: by 10.84.217.140 with SMTP id p12mr1034037pli.323.1502120644098; Mon, 07 Aug 2017 08:44:04 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id p28sm778299pgc.28.2017.08.07.08.44.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 08:44:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Tue, 8 Aug 2017 00:43:59 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <9592B3F4-A26A-4C8B-BA74-B18E6F834B2D@gmail.com> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:44:06 -0000 inline.. --- DY > On 7 Aug 2017, at 22:13, JORDI PALET MARTINEZ = wrote: >=20 > I think many sites will have a mix of =E2=80=9Cregular=E2=80=9D = SLAAC/DHCPv6 usage with one address per host, and one /64 per host, Can there be a mix? Really? Does the doc imply or explicitly state a = mixed mode? > so not sure how you will be able to identify that. How you know if = several /128 from the same /64 are in the same host running many VMs or = they are actually different hosts? I=E2=80=99d (hack and) open my connection for a /64 prefix and absorb = any addresses under that prefix. I=E2=80=99d watch there are only single = or only very few addresses for that prefix. It/they may change over = time, perhaps, due to regular IID randomization, but still I could = figure, with high success chance, that the site should be implementing = this doc=E2=80=99s scheme. If the site should be a =E2=80=98regular=E2=80=99= site, there could be a bunch of addresses under the prefix, each = further being randomized regularly, producing a big bunch of addresses. Or some other hacking techniques=E2=80=A6 there should be lots of smart = hackers...= From nobody Mon Aug 7 08:50:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E74C132510 for ; Mon, 7 Aug 2017 08:50:11 -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 tYHbPvHNQLIt for ; Mon, 7 Aug 2017 08:50:10 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686BD13250C for ; Mon, 7 Aug 2017 08:50:10 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id c65so762343pfl.0 for ; Mon, 07 Aug 2017 08:50:10 -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=mxlh2cIsWMvJvrU9NHupQSCMPqrUnv3m3j6Wd+KqnoI=; b=O0C3rwZY6nR8AkR5f+Lun4aQ4ZAgg9T0rYGc41U0NcZVCTz/lxaemPFQwCSTC/yqb0 pkYC1OjzfCsgwnkxiBRSggiRo2Sz74fi0we0M63Fyyo4qS/0NXcCtbTjLRx1l7gBTaRL zoxZVkDCLGrd4kcv2wB7rzFFWKu++6IYKA1/2FgU7wrP4fLX4/7HssskTWdR/++1In3Y M9PqWVSjATr65VH/wJJMQf2Cr5nlG+FDd7QnFll9NT3vZ2rfc7QCci9onuxyTT+MrXgY 9g/fn5W5Tz3RHxyQhD+fQf3WCjRdebBSLiuR4DEAibhZeeoLhDwIanwLLXYaP/BKKaGa oPAQ== 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=mxlh2cIsWMvJvrU9NHupQSCMPqrUnv3m3j6Wd+KqnoI=; b=c1NGPBgBIYx9ib9QYvpXAosn2ot0hbbe1dACNgbWMRryFlxZelcPGht918+UTj1Pex gpRbpBxTV9fNdCiwnloi1BN/g77YBhmMr1SMVXB+jb8BB88tyn80nyvLlFlSdnEHTeQo RXdWB1K9xgb6DNx4lEXfWBFuWjGY26iGFBYPexTjejb10JEeLaw1u8RTct7NVp+u7KqN QPhLmyPYoN4oWK8eEvbpuvTUBX+oFF2HesZuQBVzn66namvxTjlZ8HDuKh1t/UwoWv5l cDhNhl6+Yojxcrv9UhndQ84kAW/V2WYEAkQRT4cwK6ycN5MSnWevY4XT9gADXwe9YXx0 xQOQ== X-Gm-Message-State: AHYfb5iCVbHrF2dzvf01v7AT3/CH7f3iVi+igVPKc2IFblEIsaJkT/Fo zfHldrMl1s9h9w== X-Received: by 10.99.120.193 with SMTP id t184mr935685pgc.35.1502121010031; Mon, 07 Aug 2017 08:50:10 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id p126sm14800398pfp.28.2017.08.07.08.50.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 08:50:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <20170807135158.GW773745@eidolon> Date: Tue, 8 Aug 2017 00:50:06 +0900 Cc: "Brzozowski, John" , v6ops list , "gunter.van_de_velde@nokia.com" Content-Transfer-Encoding: quoted-printable Message-Id: <4202847A-DD84-4E7B-BF2E-D974F8B48AF9@gmail.com> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> <20170807135158.GW773745@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:50:11 -0000 That=E2=80=99s possible. But, assuming you=E2=80=99re on a =E2=80=98normal= =E2=80=99 site of /48 prefix, your freedom of obfuscation for the /64 = prefixes is 2^16 which may not be big enough for the purpose. On the other hand, what I=E2=80=99d be more concerned would be the = usefulness of the IID randomization. I=E2=80=99m afraid it loses its = usefulness for protection of the host privacy... --- DY > On 7 Aug 2017, at 22:51, David Lamparter wrote: >=20 > After a > configurable amount of time, it would advertise a different /64 to the > client From nobody Mon Aug 7 08:51:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A56131EA2 for ; Mon, 7 Aug 2017 08:51:26 -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 NkLs8LeBy-nn for ; Mon, 7 Aug 2017 08:51:25 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030E3132038 for ; Mon, 7 Aug 2017 08:51:25 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u185so3235879pgb.1 for ; Mon, 07 Aug 2017 08:51:24 -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=nv/eZBx9z66LX0j+oFpSRkn0jClySVYYTuw3SJ9uWNc=; b=Idh2QTlrPcjQBRcXPLPl9sF8vuJKddrA6Lif+oXjrTbJcd4R09faCfoT45iM6+Z8QT ReUGkvjkWzc2FVHJO8JrWs+sk86kwbVGKsEgCG4eOC22FdGL/Y1EhP0u+YVyujurmBmP KvGdO6ycqrrdJZ4FbRdqzmOKjyT8jfDdyeKgkEAK/BIIFjPlXpxSohCM+iuXCEB34u43 zcXYd7qA0mbs2dI5vzKSjE+ydj4g3ACp9NlTcwkUFyIiiPiRkErMHTO7y8ZS7ERjt0/D eEcmEcKrxhokD9XHkOs9CuGxARQbfIYFuu7tuy3/nNQ8HYaRiTZs/FkSh4rBvuVAtgU7 vosA== 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=nv/eZBx9z66LX0j+oFpSRkn0jClySVYYTuw3SJ9uWNc=; b=t3QQCz/2Arpb90AVmZ+mslCLrPRs2/DAhvh3J3rXlw4RPbU3SSP0Mp8uAhN4ZaNRsn Py7QV+5MlXFz1D3MPfKX0z04GsJTnnNCdGvvaksfhQSkUiBJ1ttb79NmB8tSA64OkBOp KP0G8wyrYS2JbrnzCqq93Awm+UOYYFySEVKh3AN4E7efJyS/s3Mybz3acAMvJ+cWeVrl yr3kbhik8idEVS7G0RJzEZtM+P8NJ0GQbTRoF4VlJTlRXcysAn4QDpsHIHzMZZk+NLNH 9MWpKsX/5ReSRqYplbZkb/9dRakPSq3jM7fvAZyIrlUwXKdN1QRzbGhLdVmd9u54lfCL 37NA== X-Gm-Message-State: AHYfb5iUYsrbnyw3Bkr9kKSNQWJYQUv6jkj2QFHcrs0DVeWSz0Q5hCRe dI/ing6sdT+tSveJeEY= X-Received: by 10.84.216.25 with SMTP id m25mr1112418pli.420.1502121084620; Mon, 07 Aug 2017 08:51:24 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id o17sm15117483pgn.52.2017.08.07.08.51.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 08:51:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <012F35DD-24F6-4EA9-B19D-B7F186382AF6@thehobsons.co.uk> Date: Tue, 8 Aug 2017 00:51:22 +0900 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <672D64FD-91E1-457A-9F61-E4C2596878DD@gmail.com> References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> <20170807135158.GW773745@eidolon> <012F35DD-24F6-4EA9-B19D-B7F186382AF6@thehobsons.co.uk> To: Simon Hobson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:51:27 -0000 +1 --- DY > On 7 Aug 2017, at 23:39, Simon Hobson wrote: >=20 > David Lamparter wrote: >=20 >> I had a hacked-up implementation of this draft where the router = actually >> implements a lifetime for the entire /64 assigned to the host. After = a >> configurable amount of time, it would advertise a different /64 to = the >> client (while keeping the old one around for some period of overlap, >> with valid-lft but not preferred-lft.) >>=20 >> This has the downside of the router "controlling" client privacy, but >> then again if you're the router you can always leak client's L2 >> addresses. It also has the upside of the router "forcing" client >> privacy even on clients that don't care for privacy addrs ;) >=20 > But, doesn't this then preclude the client keeping any persistent = connections open ? I'd be "very annoyed" if (for example) I found all my = SSH terminal sessions suddenly closed due to having an address change = forced on my machine. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 7 09:00:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4242213263C for ; Mon, 7 Aug 2017 09:00:37 -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 sPQn-SOvL6qD for ; Mon, 7 Aug 2017 09:00:36 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 309E11325D3 for ; Mon, 7 Aug 2017 09:00:36 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id y129so735570pgy.3 for ; Mon, 07 Aug 2017 09:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6bSYNnsU4Eq+vfvJ7GJOuQIvgQVJaGKMlQcBNBmIHaE=; b=TZNssbsHnD0v44F3iBaNWml+xccRtYECMjOJATUR+nrEyTGHkl46R5ux6iN5a0Vmk8 1SaXdj9/rflI0wXZshVMiYsrS8yxBJ1sjkZpCg5WfkMjiIDkit3L8MuBB9z0VfK6dpF0 597RdddTrrOvdVK10lqff1yYg9EFIDHnMF8XhVbdxqWc4rq/hMHZiF9Jl01RMLQQq7Pi Lj26U7hA1c4Yz7cAJiiHEdeLxysk+OXxQbTEZdkVA+eWKX2nEX9A6DL0kdoDJnLcha1D XvuoWMWPht84ZgftsaX8vLkfhmxVF7l3FdfTrZ6/3y4VB/PHm4ScF56b6AdO4Xt6XhMb TnHA== 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=6bSYNnsU4Eq+vfvJ7GJOuQIvgQVJaGKMlQcBNBmIHaE=; b=Z/exoCbYr8CV+yThj35N0uvC0wMq4JmVO+8H9JO7BQB34Uat1/Q6jZ1HmCHyu/WMV1 vl3JohMgm165k2U9k/hO3AypV4HC/MZve7hkXHUxWjDliTuXeoFHm2HJYtvRDnd1zs5Z uwmUQNHmi6JKgE8278V2CWw03wW9WIwLjG735GJRTunyw4Wu2xOZTfxlvqqI0oorQtn0 5906wvflWWKq49fukoeIfKSE1tn/BeeoGGwuIEyGQcOdVEB82fGKSUJl7iJ5r3EYEfzQ qi/ol5nLveZx8UrgdD1pe3ORPlK+nJsuXWh8bLMK5aJ1w1HZY2CctWLQ2JW/V8oI9QVF MKjQ== X-Gm-Message-State: AHYfb5g/A2S5+PaP0WCjPXeMzwxSBZBHbSLx9xO9U5Q5rzusoHjaBTF4 OmtrfaulSYh7mQ== X-Received: by 10.98.59.193 with SMTP id w62mr1001134pfj.335.1502121635766; Mon, 07 Aug 2017 09:00:35 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id o1sm12528921pgq.10.2017.08.07.09.00.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 09:00:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <20170807130654.GM45648@Space.Net> Date: Tue, 8 Aug 2017 01:00:31 +0900 Cc: Tim Chown , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <9F44126D-2067-450F-A787-40C981319B22@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170807115341.GI45648@Space.Net> <20170807130654.GM45648@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:00:37 -0000 +1. With a /96, you still have 2^32 addresses to give out to your VMs, = virtually the size of the whole Internet IPv4 could accommodate. A /64 prefix and so 2^64 addresses at your (unsolicited) disposal would = be way high and so high even to make yourself guilty of unethical = resource consumption. --- DY > On 7 Aug 2017, at 22:06, Gert Doering wrote: >=20 > a /96 would be extremely spacious. From nobody Mon Aug 7 09:09:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76F2132499 for ; Mon, 7 Aug 2017 09: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7MbLQngC6MT for ; Mon, 7 Aug 2017 09:09:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36EF132387 for ; Mon, 7 Aug 2017 09:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502122166; x=1502726966; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=k7JaEJNRJGQ2zCL96t4DHxWB7 oxA1kosDV60ke0d0Pg=; b=BIQ+/gmLhiZmBbllFonRqRKWa2/TpzrghAKC+5b8k glauEJSLlTYCGz7JIkaSpoqZlrgq1VH0ItAZ2+xXIYZ021CEn5d1/Lr/Kbnnt1oH gXdhUjUZQ34jAeL4ICRhp76LfGTIp/Znuz9BGmJb13XuCnUmlR0vK0d4nUzu/56f RQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lk445+KQpTOsKQC6TpIQMyRNhcoYl5euodDTdgILF3Qwmhu4H73psNgCGnOP DGUObHomaqtqzQ59RAx/h/eC33f7zjiGNPMx4zpSA12bEEi/MdZDYhTkP GlEQdPBD7gXyIrOimI/Z1Tj7cj9luE4HAeuaP5uyZXScWWmoLp4Zek=; X-MDAV-Processed: mail.consulintel.es, Mon, 07 Aug 2017 18:09:26 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 07 Aug 2017 18:09:24 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005498568.msg for ; Mon, 07 Aug 2017 18:09:24 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170807:md50005498568::gHNNvywJtI5C/fw8:00008utJ X-Return-Path: prvs=13920e8dc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 07 Aug 2017 18:09:20 +0200 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 References: <9DE1921C-C764-45E4-9EF6-4170072B0E46@gmail.com> <43DE8D2A-F623-4286-89C0-E8E8ECAECEAA@cable.comcast.com> <9592B3F4-A26A-4C8B-BA74-B18E6F834B2D@gmail.com> In-Reply-To: <9592B3F4-A26A-4C8B-BA74-B18E6F834B2D@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:09:30 -0000 Just in case what I said was misunderstood =E2=80=A6 I=E2=80=99m not saying= using the =E2=80=9Csame=E2=80=9D /64 for the mixed mode. For example, you = have a /48 and use one /56 out of it for a datacenter with servers that use= one /64 each one (as they have many VMs each host). In my opinion, privacy is a matter of =E2=80=9Cpersons=E2=80=9D, not machin= es (so if the unique-ipv6-prefix-per-host is used for servers, devices, etc= ., no people =E2=80=9Cbrowsing=E2=80=9D there is not a privacy issue). Priv= acy is broken today not just because detecting addresses, but many other = =E2=80=9Csignals=E2=80=9D, =E2=80=9Cfootprints=E2=80=9D and =E2=80=9Chints= =E2=80=9D that apps, browsers, etc., see for example https://panopticlick.e= ff.org/ Regards, Jordi =20 -----Mensaje original----- De: DY Kim Responder a: Fecha: lunes, 7 de agosto de 2017, 17:44 Para: CC: v6ops list Asunto: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-0= 7 inline.. =20 --- DY =20 > On 7 Aug 2017, at 22:13, JORDI PALET MARTINEZ wrote: >=20 > I think many sites will have a mix of =E2=80=9Cregular=E2=80=9D SLAAC= /DHCPv6 usage with one address per host, and one /64 per host, =20 Can there be a mix? Really? Does the doc imply or explicitly state a mi= xed mode? =20 > so not sure how you will be able to identify that. How you know if se= veral /128 from the same /64 are in the same host running many VMs or they = are actually different hosts? =20 I=E2=80=99d (hack and) open my connection for a /64 prefix and absorb a= ny addresses under that prefix. I=E2=80=99d watch there are only single or = only very few addresses for that prefix. It/they may change over time, perh= aps, due to regular IID randomization, but still I could figure, with high = success chance, that the site should be implementing this doc=E2=80=99s sch= eme. If the site should be a =E2=80=98regular=E2=80=99 site, there could be= a bunch of addresses under the prefix, each further being randomized regul= arly, producing a big bunch of addresses. =20 Or some other hacking techniques=E2=80=A6 there should be lots of smart= hackers... ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Aug 7 09:21:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BD51321DC for ; Mon, 7 Aug 2017 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 RMiIIzltSMDA for ; Mon, 7 Aug 2017 09:21:42 -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 66004132035 for ; Mon, 7 Aug 2017 09:21:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id B018469E for ; Mon, 7 Aug 2017 16:21:29 +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 ATeSQX3mJbTf for ; Mon, 7 Aug 2017 11:21:29 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 6C20453F for ; Mon, 7 Aug 2017 11:21:29 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id h2so2916661uaf.5 for ; Mon, 07 Aug 2017 09:21:29 -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=dk7+dnv4eMPavzkherClnEKzdIH3qsGQSLUg1jGhRqU=; b=p/G7SWHA9iqzsID+BNraoLXOHyDmLnDTmZpjFl3zOou3FSr+sht8D6sHMYeEYwv/5V OdhVG7JgSHIT0TVoSUSNDsZch37byNOBS3tr/owq9vTKK6p95HUV+wDsIQ6M661XmHV2 gVsCEWGPMrJhXslvVmBNUsrnURxTHZPOrYahr0szGyeqGGuavRc8cv1zZhV89DyH8ajm QkzdRLeMw5Mt/E2sCP/ddBb0vUxZVB0R09Lrs1fMTVDFQR5F9o+0JD2VXKsI9VePsdne sgEqO+lO3jummNjvQCMHqDaOqty+YkmwzJr4KBc4tKv3C4rrZSIbFOQWDaQBMsUroUqy kgtg== 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=dk7+dnv4eMPavzkherClnEKzdIH3qsGQSLUg1jGhRqU=; b=GeSHPTre90VonHgJEBVJEnouesc0CgNzU5kuX0YEDuZRmTy+TyXk8eLEMsOxRk61qV DZ2OQKnHVO5IIIesWuHe8emRNJecSiDmCFlEKqqO6IeYFxhHZmWVlHCmACjP+Vctuu+4 YboeH8vIF4MDvQqncXyMWqfy57KH7BpHOzcD0Jy8XrlqSrhLl8iNQFwSmjX5K0Q/SfIw Di+1pviBgcYsSK0EmBlNTxc2Vr+oV2MkKV96vzhX0f9Kwc4/10cEwhJ6c4qwwmDCNZPO fcG4J/m+OLpfldlnJCQm+0ucoHsAgSnJtDelHSv6RZcfXWF0XMeLdxvEs1Mox6MlCl2v 1s5Q== X-Gm-Message-State: AHYfb5jCi+khsHhQt4DiBnL9XuQCON+XP94Y7v0T7Ed/N4sUv2+qbuo/ +bA6zV+m0utD446S+ZrDzFZ9fuZ3msS7PK+1+cVUru3E0AdyzUYFuCZjZoQQ0vqm/6/7Li61YUm 2Kov972QCtoBCXJOY X-Received: by 10.31.2.67 with SMTP id 64mr637035vkc.7.1502122888866; Mon, 07 Aug 2017 09:21:28 -0700 (PDT) X-Received: by 10.31.2.67 with SMTP id 64mr637024vkc.7.1502122888649; Mon, 07 Aug 2017 09:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Mon, 7 Aug 2017 09:21:27 -0700 (PDT) In-Reply-To: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> From: David Farmer Date: Mon, 7 Aug 2017 11:21:27 -0500 Message-ID: To: Tim Chown Cc: Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a113dc5f42ffdba05562c3dd9" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:21:45 -0000 --001a113dc5f42ffdba05562c3dd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 7, 2017 at 5:05 AM, Tim Chown wrote: > Hi, > > > On 7 Aug 2017, at 07:08, David Farmer wrote: > > > > On the other hand as I have been listening to this discussion, and I've > become a little concerned that some may think this new model of a /64 per > host should replace or obsolete the more traditional subnet model of > multiple hosts within a subnet for any and all use cases. However, it > should be noted that the primary use case for this model is public intern= et > access, or public WiFi. There are several arguments that the traditional > subnet model has always been a bad fit for this use case, in that you end > up mixing totally unrelated users and hosts on the same subnet, there are > several security and privacy issues with that. This isn't necessarily tru= e > of other use cases. > > > > So, the /64 prefix per host model solves some important problems for > this, and maybe other use cases too. But, that doesn't mean it should be > viewed as a universal replacement for the traditional multiple host per > subnet model for all use cases we have. There are plenty of use cases lef= t > where traditional multiple host per subnet model still works just fine. > > The question though, as and as you say it=E2=80=99s not one really in the= IETF=E2=80=99s > scope, more the RIR communities, is if a site has a /48, and uses it up (= or > 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-pe= r-host, > will that be deemed appropriate use to allow a further assignment? > > A large university may choose to implement this on its wifi/eduroam, for > example. > I don't think dedicating a /48 or even a few /48s for wifi/eduroam at a large University would be a waste of address space. I'll use our network here at UMN Twin Cites as an example, we have almost 65,000 staff, students, and faculty, with many thousands of visitors on a daily basis, and many people have multiple devices. We had almost 80,000 unique devices on WiFi for first day of classes last year, Fall of 2016, across the the whole day, but only somewhere around 20,000 to 30,0000 devices at any moment. We expect that to be more like 100,000 first day of classes this year, in about a month. So a couple /48s seems like more than enough, maybe growing to 3 or 4 over the next few years. However, reuse of addresses as users come and go creates additional privacy for individual users, so we don't want too large of a pool either. Maybe forcing the use of a new prefix overnight for devices that are continuously on campus. We currently use a few dozen /64 subnets for WiFi, and we have some issues with ND scaling in our environment. So we are eagerly awaiting our WiFi gear and routers supporting this model. I think we need to be careful, and keep an eye on this over the next few years, but I think there is still plenty of IPv6 address space available in 2000::/3. This shouldn't be used as excuse to totally eliminate traditional multiple host per subnet model, but I don't see it as an excuse to eliminate /64 subnet model either. 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 --001a113dc5f42ffdba05562c3dd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 7, 2017 at 5:05 AM, Tim Chown <Tim.Chown@jisc.ac.uk= > wrote:
Hi,=

> On 7 Aug 2017, at 07:08, David Farmer <farmer@umn.edu> wrote:
>
> On the other hand as I have been listening to this discussion, and I&#= 39;ve become a little concerned that some may think this new model of a /64= per host should replace or obsolete the more traditional subnet model of m= ultiple hosts within a subnet for any and all use cases. However, it should= be noted that the primary use case for this model is public internet acces= s, or public WiFi. There are several arguments that the traditional subnet = model has always been a bad fit for this use case, in that you end up mixin= g totally unrelated users and hosts on the same subnet, there are several s= ecurity and privacy issues with that. This isn't necessarily true of ot= her use cases.
>
> So, the /64 prefix per host model solves some important problems for t= his, and maybe other use cases too. But, that doesn't mean it should be= viewed as a universal replacement for the traditional multiple host per su= bnet model for all use cases we have. There are plenty of use cases left wh= ere traditional multiple host per subnet model still works just fine.

The question though, as and as you say it=E2=80=99s not one really in the I= ETF=E2=80=99s scope, more the RIR communities, is if a site has a /48, and = uses it up (or 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-i= pv6-prefix-per-host, will that be deemed appropriate use to allow a fu= rther assignment?

A large university may choose to implement this on its wifi/eduroam, for ex= ample.

I don't think dedicating a /= 48 or even a few /48s for wifi/eduroam at a large University would be a was= te of address space.=C2=A0 I'll use our network here at UMN Twin Cites = as an example, we have almost 65,000 staff, students, and faculty, with man= y thousands of visitors on a daily basis, and many people have multiple dev= ices.=C2=A0

We had almost 80,000 unique devices on= WiFi for first day of classes last year, Fall of 2016, across the the whol= e day, but only somewhere around 20,000 to 30,0000 devices at any moment. W= e expect that to be more like 100,000 first day of classes this year, in ab= out a month. So a couple /48s seems like more than enough, maybe growing to= 3 or 4 over the next few years.=C2=A0 However, reuse of addresses as users= come and go creates additional privacy for individual users, so we don'= ;t want too large of a pool either.=C2=A0 Maybe forcing the use of a new pr= efix overnight for devices that are continuously on campus.=C2=A0 We curren= tly use a few dozen /64 subnets for WiFi, and we have some issues with ND s= caling in our environment. So we are eagerly awaiting our WiFi gear and rou= ters supporting this model. =C2=A0=C2=A0

I think w= e need to be careful, and keep an eye on this over the next few years, but = I think there is still plenty of IPv6 address space available in 2000::/3. = This shouldn't be used as excuse to totally eliminate traditional multi= ple host per subnet model, but I don't see it as an excuse to eliminate= /64 subnet model either.

Thanks.
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommun= ication Services
Office of Information Technology
University of Minne= sota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-995= 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a113dc5f42ffdba05562c3dd9-- From nobody Mon Aug 7 11:20:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE711329BB for ; Mon, 7 Aug 2017 11:20: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6-QyyN0_41eL for ; Mon, 7 Aug 2017 11:20:08 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195171329BA for ; Mon, 7 Aug 2017 11:20:08 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id h68so4630619pfk.0 for ; Mon, 07 Aug 2017 11:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZkeiN4HupSew3f+Js+Kp7TFXOU6Nl+t64MFRZdigXCU=; b=KsduEkHYRIZyE4x7mclqJCvOh/Cex3FOhdfctAF0W2PRY4VgFFnQnB/A2IIhJCArgt toymllMs9C+NEpAqG85LsXtptWNNgKsRFXbuiXLOVKrXPkpeWiUWtToIEbKTW2pe3uMa VLcXSoj44Nuvg/7uAuSmfie1SobXcYVlS60JaaejO5j1Rn3ZV9Ku/Uxlvi1stWq0JK2l 5dAYnXXGRHIDBRk/bTmejzszYNBduXWLfK8EfIdNz9Jm9RMknM6Equw/Wzv1UKYOE80X ZJUHmRNFKvLSFDFoV1qMz8MbZoNhy7E2mhDz9KvAC45Ik2rcwnQKdVs0/uTMpwGI73tK WLww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ZkeiN4HupSew3f+Js+Kp7TFXOU6Nl+t64MFRZdigXCU=; b=s5chIVZB/jkcRuqznUM+VxTr5tyrkAAGFf7CxQJAHWIRvKeZ/BiRaZ9jBP0XxkgR9b agZjrXuB0nS7hcFCOgWrOuRLKiD8pW9JFTIivYwpXmUT4yVhlr1yqb0KwyjsUb70M6IC 3BvLcPJmnBkx3A2uX3AFHPsE+M4tX1NZFgHzdQxQQyfoRKWYeW7h4Mmht8W4SrlYsvK+ RdhlFTDubP4hG7Q+U6jZeS/+S/VS6w7Pms13d3nzcQxH8/8tLs6CHbplSLbRxzYCTl/e lrL2EeySfAECKrfWQCyqvp3Ykae5D74qUEO2CEBX5hAGnouxQE92TLQwvZbAOiieDZCZ uStw== X-Gm-Message-State: AHYfb5gkSABYLJsifvMiiCPNeA+o4msY4UXqLI4mML2FuYdt325+AzzL SW8JlxX+QwGMUOplb9ZGCw== X-Received: by 10.84.225.134 with SMTP id u6mr1579524plj.176.1502129634316; Mon, 07 Aug 2017 11:13:54 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:44a4:92bd:ba55:fb55? ([2620:0:10e7:10:44a4:92bd:ba55:fb55]) by smtp.gmail.com with ESMTPSA id h71sm14021446pfh.120.2017.08.07.11.13.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 11:13:53 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_6C1C8F9D-CA18-48C0-BE63-0490DB7E9084" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 11:13:52 -0700 References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> To: v6ops list In-Reply-To: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> Message-Id: <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:20:10 -0000 --Apple-Mail=_6C1C8F9D-CA18-48C0-BE63-0490DB7E9084 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 5, 2017, at 20:21, Brian E Carpenter = wrote: >=20 > [=E2=80=A6] If there's a problem, it's not in the area of a shortfall = of /128s. This is where I point out that diamonds, unlike grains of sand, are just = sufficiently uncommon that monopoly power admits the inducement of = artificial scarcity to inflate market prices.=20 > If there's a shortfall of /64s, it's human error. There is more to the analogy than meets the eye, i.e. the error may be = one of political and economic philosophy, and not a technical one, and = moreover, the analogy may break down around the ways that numbers are = not the same as stones. After all, if the point of the game is to create = an artificial scarcity of numbers, what difference does it make where = you put the prefix boundary in the process? You can set it anywhere you = like and achieve the same effect. --james woodyatt > --Apple-Mail=_6C1C8F9D-CA18-48C0-BE63-0490DB7E9084 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 5, 2017, at 20:21, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

[=E2=80=A6] If = there's a problem, it's not in the area of a shortfall of = /128s.

This is = where I point out that diamonds, unlike grains of sand, are just = sufficiently uncommon that monopoly power admits the inducement of = artificial scarcity to inflate market prices. 

If there's a = shortfall of /64s, it's human error.

There is more to the = analogy than meets the eye, i.e. the error may be one of political and = economic philosophy, and not a technical one, and moreover, the analogy = may break down around the ways that numbers are not the same as stones. = After all, if the point of the game is to create an artificial scarcity = of numbers, what difference does it make where you put the prefix = boundary in the process? You can set it anywhere you like and achieve = the same effect.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_6C1C8F9D-CA18-48C0-BE63-0490DB7E9084-- From nobody Mon Aug 7 13:11:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A097D1324AC for ; Mon, 7 Aug 2017 13:11: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 pMTn6eGKqfc7 for ; Mon, 7 Aug 2017 13:11:38 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 AB20E132630 for ; Mon, 7 Aug 2017 13:11:38 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id t83so1323622pfj.3 for ; Mon, 07 Aug 2017 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fwqzqh1jTBH13/CqiRCvBvItaN9pEZXBBFsKOei6SXA=; b=axZScXnv4osxZmCf16WQvyK9AHDmMVeNhhOmCoSauMbpceO4nQg6jwhpngK+fwiQKq UQE/xDCNSatbA2kc4Hvkd725r5/9+sLsgeiVazrUl4u1XlrtlZKYr6sIrFdl55jZvdQZ toRZlbK6R56g1joNXGAHlokg3qIvceMG0uQim+hDdxm7bqCbUCJcz+zq70N5Hgu2zx52 3HiCfPCs2DQv3F1ouQGI0qJz1ZkBmiAmM7dUFUFYwLY7PbBJODpE3K35Bz63CEQ0YOkF DPX/YZlWkatdPa2nZRBVjfY0HXV7qlrDNIGE7YLlk1aMQ3latNLa6iDp/3aMqy9ReFzs WgUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fwqzqh1jTBH13/CqiRCvBvItaN9pEZXBBFsKOei6SXA=; b=rMaF6rTAvuyDULUAHLuq7fFOdWqMHhHjINEWCAxyVyVF0qCghxEuxyg1NvZYiB8HA8 Wdrh8jfLUcp6DZKB4xjIl2WlESN/2yeZ0BgvYJWVT4wDeMJUIhTZc1oCUyB5rECEFGjT iDWbDjdhBrO/013Wu+He9f2t97IaaI0OhBeAU7BBD24G40zlzPnvlJZoUdJnobczme5b IHN5Lz39OfFRt2z5ztlVwgQCyu0vHAlbuvKAp0V1woqcrIype5RxeJsD7uC68DPEQFSm /qJgGjMchjc/vhT40chI/pzAQ0wFQ/q3DNnxr40W99pKrAutdR5Kx7pyhpSxWwyg0/C3 zfBg== X-Gm-Message-State: AHYfb5jcug3adyENQi4kyNXbii61/qNHYaPR/NsKMC0HyNKP7Hb97L4p Zw5AgErl+dKFvfWx X-Received: by 10.84.167.2 with SMTP id c2mr1945619plb.365.1502136698069; Mon, 07 Aug 2017 13:11:38 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j71sm16115429pfj.44.2017.08.07.13.11.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 13:11:37 -0700 (PDT) To: james woodyatt , v6ops list References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2e7d3e7c-f47d-19b7-e078-e74881c17429@gmail.com> Date: Tue, 8 Aug 2017 08:11:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:11:41 -0000 On 08/08/2017 06:13, james woodyatt wrote: > On Aug 5, 2017, at 20:21, Brian E Carpenter wrote: >> >> [=E2=80=A6] If there's a problem, it's not in the area of a shortfall = of /128s. >=20 > This is where I point out that diamonds, unlike grains of sand, are jus= t sufficiently uncommon that monopoly power admits the inducement of arti= ficial scarcity to inflate market prices.=20 >=20 >> If there's a shortfall of /64s, it's human error. >=20 >=20 > There is more to the analogy than meets the eye, i.e. the error may be = one of political and economic philosophy, and not a technical one, and mo= reover, the analogy may break down around the ways that numbers are not t= he same as stones. After all, if the point of the game is to create an ar= tificial scarcity of numbers, what difference does it make where you put = the prefix boundary in the process? You can set it anywhere you like and = achieve the same effect. Exactly correct. As engineers who care about making the Internet work bet= ter, we should certainly work to avoid artificial scarcity, having create= d IPv6 to overcome a real scarcity. But *we* can't actually prevent inten= tional creation of artificial scarcity - that's an economic and fair trad= e issue which will play out in RIR policy and beyond. That said, I want to support what David Farmer said recently: > So, the /64 prefix per host model solves some important problems for th= is, > and maybe other use cases too. But, that doesn't mean it should be view= ed > as a universal replacement for the traditional multiple host per subnet= > model for all use cases we have. There are plenty of use cases left whe= re > traditional multiple host per subnet model still works just fine. There's nothing wrong with either model and they will both find their pla= ce in the market. Brian From nobody Tue Aug 8 09:26:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70751321ED for ; Tue, 8 Aug 2017 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lukhjmmJ4QQj for ; Tue, 8 Aug 2017 09:26:37 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06FA1321D7 for ; Tue, 8 Aug 2017 09:26:36 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z18so22277369qka.4 for ; Tue, 08 Aug 2017 09:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mUm8p3k43WVXhjx8K2l9JaU+DY49d5tUyhQpZXs1JWY=; b=X8+2g1bVwQ4yoanFCTcZdIkjr++3lyzZiel6eHjRt6omPyzbud09I0Zq+0SVSBebb6 4B960dkpKztBn2v8DeLFU+Hy2WeygSQcqI2YoEePmbhSaDOyjAsYewGt1Ik0LzUWYi/Y EnqQj+B9MoIOFCo9J8ADgJP3lwADs1VXqcUQP5rbiAPbGH+OA1DR2vrZilZL/C8/IKft VrRQ4d+ZT3cKC+KaFkMOogz0QBNTYoggnkGGBRbjIIMDZUakoKJ7ps2KZ/9F2apUyM/O ds/Z/boS+NeRZZmK07d3QGiVixYJuBMh3nRu4cXX34wlZwEDsb7QT2V2CXnrAtEMX6Z8 PgAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mUm8p3k43WVXhjx8K2l9JaU+DY49d5tUyhQpZXs1JWY=; b=cX2dF35oap554C7+R3TFngahQ4QgGdaJNTQUhqh+jH1wWvnDimGPcxdXIlIEvHxKcR 1pOBPk67hQVu4DK6nUvEH41rL7j1FfAknoAwHrjM0+7m/h+FIyEH5Fup2PRzkgeTCZ2z VROMRm1hC02tHgJMH/tMvZDYDLII6EAVnPXeL1P+g/A7myXVdXeIxFbYfkoVC+LAy3Dz Gz2CMkeu7T2/C8fpTFbMUtfcwoz+Mq3hgCHS+p02ZgVsjBt2Zg8zI1W+nI0ODwAoq/Ez Rbhp9yrkWLk4HUIMSrZSDa62QjRSJb3rpcnDE2Pg7jP7/JqIGXijcCsBtDfX9rkosKRJ WeaA== X-Gm-Message-State: AHYfb5hEEy2mKV4EoyagwIdHSKc7Pmx2RP1fsxlbJ8GqzZNP/EaNJp+6 q/LyvsgMGvZ74Ntpbu3sBs3gyOK3iIgHjzM= X-Received: by 10.55.92.130 with SMTP id q124mr5982899qkb.274.1502209595938; Tue, 08 Aug 2017 09:26:35 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 8 Aug 2017 09:26:35 -0700 (PDT) In-Reply-To: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 8 Aug 2017 09:26:35 -0700 X-Google-Sender-Auth: C6nFt3Fg31PLXILndpfSS68Z7b4 Message-ID: To: Fred Baker Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 16:26:39 -0000 At Thu, 3 Aug 2017 19:55:32 -0700, Fred Baker wrote: > As discussed in Prague, this opens a two week WGLC on this > draft. This will end on 18 August. Please read the draft now and > comment on it. The chairs are interested to know about experiments > using the old and modified behaviors, and a quantification of the > improvement (or lack thereof) if such exists. We are also interested > in the clarity and utility of the proposal. I've just taken a quick look at draft-ietf-v6ops-rfc6555bis-03. I don't think it even ready for a WGLC. As far as I can see the 03 version doesn't address any of my previous comments https://www.ietf.org/mail-archive/web/v6ops/current/msg26611.html, not even a quite trivial editorial glitch. Actually I've not even seen any followup discussion on the comments in the list. I'm not saying these comments are necessarily addressed. Some of them may turn out to be invalid or too minor and dismissed. That's totally fine, but from the fact there's not even been a discussion seems to suggest the authors have not really checked all feedback yet. I'd suggest the authors do it first, discuss those in this list, make a decision on how/whether to address these points, get rough consensus, and then ask for a WGLC. -- JINMEI, Tatuya From nobody Tue Aug 8 10:06:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1711323BB for ; Tue, 8 Aug 2017 10:06: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, 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=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 pZjgnbBT1BKz for ; Tue, 8 Aug 2017 10:06:53 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 7B5A41321D6 for ; Tue, 8 Aug 2017 10:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502211978; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/4NZOqVF668xyd6/w+Ue3aAtCKOgYpvz38rMcrujJdw=; b=C8vVT/9jJOSIUVgPFBn/qnsL1kvZ51cD/u+0faKsHyzAluSlUDXsOgL28DHC6LDG +oT7hQ1tdn6ze9BHZpIXeN5q5ef/HXhR/zmVzS9Gxj5KuC6LTodWa+OgtwcdR/cN 2Ync/bmuGDBe1c2KGx3136Hn5pKSLc4cyHOEmFs36Q2kwvN0Hxu30BxUa/eKSLgX wzM12MIUiUsGXotsOW0pP3vBuaodk2Ha4yghNUDulxS1r4jYXwV5tpc0DyLgxKb2 6/Ie8BtQmSzOHe43qFcX/s/nfFlyXqcGv0ieCUQzPCi0TYRozWtbeTIJaiUq42Ga pgl7r1YsV9l788wXpfsXmg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 03.FE.05744.A8FE9895; Tue, 8 Aug 2017 10:06:18 -0700 (PDT) X-AuditID: 11ab0219-dacb19c000001670-e1-5989ef8a3316 Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id 40.DA.10385.A8FE9895; Tue, 8 Aug 2017 10:06:18 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.101.93] (unknown [17.234.101.93]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUD007RKM6EWX90@jimbu.apple.com>; Tue, 08 Aug 2017 10:06:18 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Tue, 08 Aug 2017 10:06:12 -0700 Cc: Fred Baker , "v6ops@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FAYodv1vjPS4PIqbYvbXxtYLRbtPsBm cfrYXmYHZo+ds+6yeyxZ8pPJY+/TY2wBzFFcNimpOZllqUX6dglcGcd232YpWChU8fHyKpYG xid8XYycHBICJhKz5v1h7mLk4hASWMMk8a6jixkm8e/aR6jEBkaJ7iebWUESvAKCEj8m32Pp YuTgYBZQl5gyJRckLCTwn1FiykRREFtYQFqi68JdVghbQ+Lps+VMIOVsAloSB9YYgYQ5BYIl FjetYgOxWQRUJXr/XgSzmQV8JJbM/MAEYWtLPHl3gRWklVfARmL57iiITS8ZJebP5gAJiwBd uemBE8TBshK3Zl8CO1hCYAebROu1J0wTGIVnIbl5FsLNs5AsWMDIvIpRODcxM0c3M8/IVC+x oCAnVS85P3cTIyjQVzNJ7mD8+trwEKMAB6MSD++NPZ2RQqyJZcWVuYcYpTlYlMR5bdiBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhin/9FLv/PSV0NlS/xxphuTYxgmrbh8Zuf6/G8c7d3B zc/6y2YutnlrKq3rIRK+y8ei83jZoRtrNQIfr/25dnZglrb3hunnP0+rSrW+8Pnz1py1IUFu USKTM60nTghJfcW1SSPVverK4ZgjE9h9S/ZVR5s6XwrJd6rp35nybM9qEaPlFQs8frApsRRn JBpqMRcVJwIAf8MnJlUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUiON1OVbfrfWekwd6NIha3vzawWizafYDN 4vSxvcwOzB47Z91l91iy5CeTx96nx9gCmKO4bFJSczLLUov07RK4Mo7tvs1SsFCo4uPlVSwN jE/4uhg5OSQETCT+XfvI3MXIxSEksIFRovvJZlaQBK+AoMSPyfdYuhg5OJgF1CWmTMkFCQsJ /GeUmDJRFMQWFpCW6LpwlxXC1pB4+mw5E0g5m4CWxIE1RiBhToFgicVNq9hAbBYBVYnevxfB bGYBH4klMz8wQdjaEk/eXWAFaeUVsJFYvjsKYtNLRon5szlAwiJAV2564ARxsKzErdmXmCcw CsxCcuYshDNnIZm5gJF5FaNAUWpOYqWpXmJBQU6qXnJ+7iZGUFg2FEbsYPy/zOoQowAHoxIP r8H+zkgh1sSy4srcQ4wSHMxKIrwMp4BCvCmJlVWpRfnxRaU5qcWHGKuAPpnILCWanA+MmbyS eEMTEwMTY2MzY2NzE3OqCCuJ8+7f0hEpJJCeWJKanZpakFoEs5yJg1OqgfFW29IZDhl/Vyis 7dPuub+ypdPvlovHxKvTH8gzFk9tcDy1/DUX4zuZluNrj8vl5q5Zs35n8mVtRpvnocoGRTZx L3bck2U9uu7TS+O2gp2v181Y05i17xLT8v51te8E4zdb/2u3VyuSWM/wyvHc4hvMe7RygzTf PSvMELPeGVXM97jFU+LQxp1KLMUZiYZazEXFiQBUF416pgIAAA== Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:06:55 -0000 Hi Jinmei, We have read the feedback and addressed the ones we thought relevant. It does appear that I did not respond to the email you linked, and = failed to take into account your editorial comment. For both of these I apologize. Most of your comments were regarding asynchronous DNS, which I believe the working group has reached rough consensus on. While there is still a vocal minority advocating that asynchronous DNS is "too hard", those implementations are free to only implement Happy Eyeballs v1. The chairs should correct me if they disagree, but I feel the working group overall agrees that the benefits of asynchronous DNS are worth it. Thanks, David Schinazi > On Aug 8, 2017, at 09:26, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Thu, 3 Aug 2017 19:55:32 -0700, > Fred Baker wrote: >=20 >> As discussed in Prague, this opens a two week WGLC on this >> draft. This will end on 18 August. Please read the draft now and >> comment on it. The chairs are interested to know about experiments >> using the old and modified behaviors, and a quantification of the >> improvement (or lack thereof) if such exists. We are also interested >> in the clarity and utility of the proposal. >=20 > I've just taken a quick look at draft-ietf-v6ops-rfc6555bis-03. I > don't think it even ready for a WGLC. >=20 > As far as I can see the 03 version doesn't address any of my previous > comments = https://www.ietf.org/mail-archive/web/v6ops/current/msg26611.html, > not even a quite trivial editorial glitch. Actually I've not even > seen any followup discussion on the comments in the list. >=20 > I'm not saying these comments are necessarily addressed. Some of them > may turn out to be invalid or too minor and dismissed. That's totally > fine, but from the fact there's not even been a discussion seems to > suggest the authors have not really checked all feedback yet. I'd > suggest the authors do it first, discuss those in this list, make a > decision on how/whether to address these points, get rough consensus, > and then ask for a WGLC. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From pierre-jean.grenier@polytechnique.edu Tue Aug 8 09:57:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AFB132358 for ; Tue, 8 Aug 2017 09:57:07 -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 AMCr1MHfoE4q for ; Tue, 8 Aug 2017 09:57:04 -0700 (PDT) Received: from mx-a.polytechnique.fr (mx-a.polytechnique.fr [129.104.30.14]) by ietfa.amsl.com (Postfix) with ESMTP id 538AC132190 for ; Tue, 8 Aug 2017 09:57:03 -0700 (PDT) Received: from zimbra.polytechnique.fr (zimbra.polytechnique.fr [129.104.69.30]) by mx-a.polytechnique.fr (tbp 5.3.2/2.0.7) with ESMTP id v78GUIbE016615; Tue, 8 Aug 2017 18:30:19 +0200 Received: from localhost (localhost [127.0.0.1]) by zimbra.polytechnique.fr (Postfix) with ESMTP id D75ED7200D4; Tue, 8 Aug 2017 18:30:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.polytechnique.fr Received: from zimbra.polytechnique.fr ([127.0.0.1]) by localhost (zimbra.polytechnique.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BIWNs0X85U6L; Tue, 8 Aug 2017 18:30:18 +0200 (CEST) Received: from [10.105.239.11] (webmail.polytechnique.fr [129.104.30.43]) by zimbra.polytechnique.fr (Postfix) with ESMTPSA id 250837200D1; Tue, 8 Aug 2017 18:30:18 +0200 (CEST) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 From: "Grenier Pierre-Jean (ASP)" Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 8 Aug 2017 18:30:16 +0200 To: v6ops@ietf.org Cc: David Schinazi , tpauly@apple.com, Pierre Pfister , Mark Townsley , Jason Fesler X-Mailer: iPhone Mail (14F89) Archived-At: X-Mailman-Approved-At: Tue, 08 Aug 2017 11:07:23 -0700 Subject: [v6ops] Experiments over Happy Eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:10:12 -0000 Hi all! I know you are reviewing a proposal for updating the RFC6555 about the Happy= Eyeballs. I recently designed a tool to experiment over any implementation o= f the algorithm and showed it to David Schinazi and Tommy Pauly, who wrote t= he draft. They suggested I should let you know about it. So here it is: http://ds.ds.6cn-prs.6cn.io. It allows the user to introduce d= elays over A and AAAA DNS answers, but most importantly over the SYN-ACK ans= wers from the server. You can thus manipulate the delays that directly influ= ence a Happy Eyeballs' decision. In other terms: it allows you to test your i= mplementation of Happy Eyeballs, or compare the efficiency of two different i= mplementations (see how often you go over IPv4 or IPv6, see how long the cli= ent had to wait between the initial request and the final answer, etc.). I hope this can be helpful. Please feel free to use it if needed. Regards, =E2=80=94 Pierre-Jean Grenier= From nobody Tue Aug 8 12:28:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B75B132B11 for ; Tue, 8 Aug 2017 12:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwMsTgzJcWb7 for ; Tue, 8 Aug 2017 12:27:57 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E93132946 for ; Tue, 8 Aug 2017 12:27:57 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id u207so27520921ywc.3 for ; Tue, 08 Aug 2017 12:27:57 -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; bh=e7rx70ebKKOkKaY/SVrdaFe/cLhsUC2U0Ld3E5B7Gu4=; b=fxynFttMCHvi9JXNkNm50xCIr/2hzhaKSbaV58xPPkh0IitfaTHWfBuCMugqIniw3z 19JXQT6kv8FAoMJrBDJnqq82WnYeRuZpvjkDOax9LnCWYubeg4E5r6hriF8WQdiNyiQh C05Fp/MLQy7rjg0QxOe57ix6xhLeypuRzaG+2ov4UG+bAHnSEB0YGb8zM9oVM4+OzrnS E8SwmLKZrBCszUWoDo7msmsyudd0lC1ElmY8/IenoxRSULzInexV4YyciDHL5rBg5aG+ QgUb2zVWGU8bL+3OVEwHQtbVNI65XzDGt25AiflgW99UtP4CvrmdoQ+hMKMzY7IY08dH yJ5g== 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; bh=e7rx70ebKKOkKaY/SVrdaFe/cLhsUC2U0Ld3E5B7Gu4=; b=IS23qwmkTatdgA1b6+NixYIPvbPXJPgbuhCAXoZDRWqhoiQab1Xz1vx3r0IDxEpyq1 IgjWeSKIskmVzjJiHFcVZpKjXzX9Y0KlpPdAHn5icn2/Xu3qcEXyX91zNqtv4B8lix+l zvRFoOArx1fVBFMo1JGDbqlsYxQLCU7mktjmM58X556t0rhc5BOXsuA8Pj1PfW6dYN8W 8DMg7Go5VWNQS4k1DRwldwA6WwpJkmoITa9B/I2kqXnX/PTXd86cc92mfRnm70L5MM8y H2LorDof2PU4QPpX01EydFL6dpzrV2QYtR4YufIru/8MkkFzyDHD+yCq5DypZBjK1ZW1 F3xA== X-Gm-Message-State: AHYfb5goexJmMACgqe3yoL1y9PoPP3vbMYTie3bLUjQ/bolG1rw5sOWP IiJO6e0spG7ySlGnvqb8KzqEWPDfLg== X-Received: by 10.129.161.13 with SMTP id y13mr4629478ywg.121.1502220476479; Tue, 08 Aug 2017 12:27:56 -0700 (PDT) MIME-Version: 1.0 References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> In-Reply-To: From: Ca By Date: Tue, 08 Aug 2017 19:27:45 +0000 Message-ID: To: Fred Baker , v6ops@ietf.org Content-Type: multipart/alternative; boundary="001a114f82dee017a9055642f542" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:27:59 -0000 --001a114f82dee017a9055642f542 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 7:55 PM Fred Baker wrote: > As discussed in Prague, this opens a two week WGLC on this draft. This > will end on 18 August. Please read the draft now and comment on it. The > chairs are interested to know about experiments using the old and modified > behaviors, and a quantification of the improvement (or lack thereof) if > such exists. We are also interested in the clarity and utility of the > proposal. > I have read the i-d. I believe the I-D is clear, provides a high level of utility, and is ready to move forward. Section 7 for handling ipv6-only networks is especially helpful Regards, Cameron > Sent using a machine that autocorrects in interesting ways... > > On Aug 3, 2017, at 7:50 PM, Fred Baker wrote: > > Thanks > > Sent using a machine that autocorrects in interesting ways... > > On Aug 2, 2017, at 7:41 PM, David Schinazi wrote: > > Hi v6ops chairs, > > As discussed in Prague, we have published a minor revision to RFC655bis: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-03 > > I think the document is ready to start Working Group Last Call. > > Thanks, > David Schinazi > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114f82dee017a9055642f542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Aug 3, 2017 a= t 7:55 PM Fred Baker <fredba= ker.ietf@gmail.com> wrote:
<= div dir=3D"auto">
As discussed in Prague, this opens a two week WGLC on= this draft. This will end on 18 August. Please read the draft now and comm= ent on it. The chairs are interested to know about experiments using the ol= d and modified behaviors, and a quantification of the improvement (or lack = thereof) if such exists. We are also interested in the clarity and utility = of the proposal.

I have read the i-d.=C2=A0

I believe the I-D is clear, provides a high level of uti= lity, and is ready to move forward.=C2=A0

=
Section 7 for handling ipv6-only networks is especially h= elpful

Regards,
Cameron


Sent using a machine that autocorr= ects in interesting ways...

On Aug 3, 2017, at 7:50 PM, Fred = Baker <fre= dbaker.ietf@gmail.com> wrote:

Thanks

Sent using a machine that autocorrects in interest= ing ways...

On Aug 2, 2017, at 7:41 PM, David Schinazi <dschinazi@apple.com<= /a>> wrote:

Hi v6ops chairs,=

As discussed in Prague, we have published a minor revis= ion to RFC655bis:

I think the document= is ready to start Working Group Last Call.

Thanks= ,
David Schinazi
_______________________________= ________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114f82dee017a9055642f542-- From nobody Tue Aug 8 12:38:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D321327F6 for ; Tue, 8 Aug 2017 12:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiQ8571jiZu3 for ; Tue, 8 Aug 2017 12:38:51 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874F513270A for ; Tue, 8 Aug 2017 12:37:03 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id s143so27657302ywg.1 for ; Tue, 08 Aug 2017 12:37:03 -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=Q8NChQuDRkvUebxo/HAOPoQ9Qa4VLXwkSOgCC0r1SF4=; b=QEK5g/24bCmepmE31lxcogc7zpr+tkR69VIMZczehECBxnkuzeNpgjw/fDt9ucLfWL NZD/oYvMslVezAqh1HDKcLZTtPQEn+EV84UchC/WTnpTtNRtHYswhXZb8bocHMms3uRO 1kIv+WoXjEwMhYNuVrqbjbODnnVNQcvA/VDYS9sY4mdxIDNuwM8XfNLgU20/jHlNg+Ok Yb06rWHDHiCFvb3RxyBKMneud3Nh8l7egIZvJ9PVh7LIfDjeXK61VaZqMzXkFCcwNRqM Hh8X1wCWerD9xcZ1IKvAG47R8TBeNeXUFuxjSQkbvPbmf8YZYJDVowvybHcgQ5D1Vv5H Fg+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q8NChQuDRkvUebxo/HAOPoQ9Qa4VLXwkSOgCC0r1SF4=; b=Wg7H/MxRfD+sPo4u2Qv2qrqyYqMn5cYljDUAtaSLJt2GUU0KcA/CzedWv/6maz/VTR Dtp18CPUq2OzBn5gZQUf5eEzjBq0+UfGMUhSqX1j3MNqcgIqzYubapkMIh7D8lS4Wf1J bsSwuZci8Ss0JFXPOzHntpPvkqD3C16UBBJmNbGFU+LXAesNAB4GnCy1fR1Mn4do8rgJ RDkiEiQp9UDnuUeHfuifHbNmMH3EB5dkc6JRWnVsYb979am+Qntw5qqYTuE95RFKEKGh BfHOlJN5CVmkkFEXxzDheNPzYbQ8pI7Qh51/P39fkn3GqRTWvuY3PlIlzw47TLJVZgIF gqXw== X-Gm-Message-State: AHYfb5gc/cctcpHUg4479EyQoTua2zDwz6uWdudm3RPNmZXZYcbkHZ3Z 3JH6kuOc3IX29DBE9nyr91Y16UBuGA== X-Received: by 10.13.213.72 with SMTP id x69mr4403340ywd.362.1502221022795; Tue, 08 Aug 2017 12:37:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ca By Date: Tue, 08 Aug 2017 19:36:52 +0000 Message-ID: To: "Grenier Pierre-Jean (ASP)" , IPv6 Ops WG Cc: Mark Townsley , Pierre Pfister Content-Type: multipart/alternative; boundary="001a114fd442702071055643167c" Archived-At: Subject: Re: [v6ops] Experiments over Happy Eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:38:55 -0000 --001a114fd442702071055643167c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Neat tool. Using an ipv6-only iphone on 11 beta, i was not able to trigger an ipv4 result with high delay numbers. No failures either, it was always success on v6. It would be interesting if you could update the tool to exercise some of the functions in section 7 of the I-D, especially 7.2 using the =E2=80=9CLa= st Resort=E2=80=9D Thanks, Cameron On Tue, Aug 8, 2017 at 11:07 AM Grenier Pierre-Jean (ASP) < pierre-jean.grenier@polytechnique.edu> wrote: > Hi all! > > I know you are reviewing a proposal for updating the RFC6555 about the > Happy Eyeballs. I recently designed a tool to experiment over any > implementation of the algorithm and showed it to David Schinazi and Tommy > Pauly, who wrote the draft. They suggested I should let you know about it= . > > So here it is: http://ds.ds.6cn-prs.6cn.io. It allows the user to > introduce delays over A and AAAA DNS answers, but most importantly over t= he > SYN-ACK answers from the server. You can thus manipulate the delays that > directly influence a Happy Eyeballs' decision. In other terms: it allows > you to test your implementation of Happy Eyeballs, or compare the > efficiency of two different implementations (see how often you go over IP= v4 > or IPv6, see how long the client had to wait between the initial request > and the final answer, etc.). > > I hope this can be helpful. Please feel free to use it if needed. > > Regards, > =E2=80=94 Pierre-Jean Grenier > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114fd442702071055643167c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Neat tool.=C2=A0

Using an ipv6-only iphone on 11 beta, i was not able to tri= gger an ipv4 result with high delay numbers. No failures either, it was alw= ays success on v6.=C2=A0

It would be interesting if you could update the tool to exercise some of t= he functions in section 7 of the I-D, especially 7.2 using the =E2=80=9CLas= t Resort=E2=80=9D


Thanks,
Cameron

On Tue, Aug 8, 2017 at 11:07 AM Grenier Pierre-J= ean (ASP) <pier= re-jean.grenier@polytechnique.edu> wrote:
Hi all!

I know you are reviewing a proposal for updating the RFC6555 about the Happ= y Eyeballs. I recently designed a tool to experiment over any implementatio= n of the algorithm and showed it to David Schinazi and Tommy Pauly, who wro= te the draft. They suggested I should let you know about it.

So here it is: http://ds.ds.6cn-prs.6cn.io. It allows the user to int= roduce delays over A and AAAA DNS answers, but most importantly over the SY= N-ACK answers from the server. You can thus manipulate the delays that dire= ctly influence a Happy Eyeballs' decision. In other terms: it allows yo= u to test your implementation of Happy Eyeballs, or compare the efficiency = of two different implementations (see how often you go over IPv4 or IPv6, s= ee how long the client had to wait between the initial request and the fina= l answer, etc.).

I hope this can be helpful. Please feel free to use it if needed.

Regards,
=E2=80=94 Pierre-Jean Grenier
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114fd442702071055643167c-- From nobody Tue Aug 8 18:53:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEB0131CF0 for ; Tue, 8 Aug 2017 18:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFUevqlXowLr for ; Tue, 8 Aug 2017 18:53:18 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76028131CEC for ; Tue, 8 Aug 2017 18:53:18 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id i133so3087392vka.5 for ; Tue, 08 Aug 2017 18:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j09GTtlmqlCUC+s7IFgtmupsAq58VlK9kbJp1r8CysY=; b=pVOvpx1TViNapIEWO2Z/h1xNBsSQgEHCSoBOByMY4AsuhvD36zw/kt1CD+vyJXi2HD QdgAgCjBbFsI3rcQzvU62QYhN4WwzGQGBV+nTyOj9gEzg5vRgwWfNUKe9O7igFeZlhbA Dw9KMnOkv0F6kKO7ESa7dh+e8BAZrilY0L+KkRJ+1nX8mV8Zz7wCKd8qBPNYIMHWD05y tQj47TNDL7x0HueRWHPvf3KOn8uuoxLOggJR/CBUlu3Vm9j2FQ+Wy7RhIXURvqwXms0R 1uur+J/YVzLpw638ErnW+G8L72x7pcHLEQX5oic+SmwVhTJJ7E4c/VR/9etCvaJkbi1F rv8A== 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=j09GTtlmqlCUC+s7IFgtmupsAq58VlK9kbJp1r8CysY=; b=ocIdKpT8YvWI4BgFuIZtgYQNHzttTAzPC/2ibpPjK9m4ZrAO5c9yoSbeO1z/j1NWg6 /DwDTTROEW4ox0NvLPJHnVcWqGM3AqW6lGTK9GmguJVvAh7bbSDft2Fcfcb3trEWTv3n xWURAAs5e40c3/0OrLh1R9vtMZa+yLm39Bw4PLk50OL2h61DMvvd4WOKk5q5FDhLkT3r tOCWyy+YGRSqHBVhrdphQaeDaIKYhJlKMMV+fffl1h/4oHh/1SmPc34P81bU5K2puwYV elu+Uhu5CKdYUS70IIRBeRsV0JcSx6dWUG64oZKXjOmPcaPpUuY7p11yMGNL3iCTaYCB BfuA== X-Gm-Message-State: AHYfb5jhyUDPSoa+vLvJG292JgJ6ngP9pfUqYpST1S3v+GpJSwbVjIt5 rtt3+9oxqbDdILBmUIrvLhOIPTIdtw== X-Received: by 10.31.64.70 with SMTP id n67mr4176190vka.41.1502243597522; Tue, 08 Aug 2017 18:53:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.22.105 with HTTP; Tue, 8 Aug 2017 18:52:46 -0700 (PDT) In-Reply-To: <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> From: Mark Smith Date: Wed, 9 Aug 2017 11:52:46 +1000 Message-ID: To: james woodyatt Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 01:53:20 -0000 On 8 August 2017 at 04:13, james woodyatt wrote: > On Aug 5, 2017, at 20:21, Brian E Carpenter > wrote: > > > [=E2=80=A6] If there's a problem, it's not in the area of a shortfall of = /128s. > > > This is where I point out that diamonds, unlike grains of sand, are just > sufficiently uncommon that monopoly power admits the inducement of > artificial scarcity to inflate market prices. > > If there's a shortfall of /64s, it's human error. > > > There is more to the analogy than meets the eye, i.e. the error may be on= e > of political and economic philosophy, and not a technical one, and moreov= er, > the analogy may break down around the ways that numbers are not the same = as > stones. After all, if the point of the game is to create an artificial > scarcity of numbers, what difference does it make where you put the prefi= x > boundary in the process? You can set it anywhere you like and achieve the > same effect. > So it was a metaphor. It's demonstrating the contrast between how we value and handle diamonds (IPv4) verses how we value and handle sand (IPv6). I hadn't thought to think of it literally as Brian did, however I'm not all that surprised for sand it is literal. It is probably fairly literal for diamonds too. Diamonds are rare, and therefore the dominant cost is in finding/discovering them and extracting them. Transport and handling after that are a trivial cost in comparison. Significantly reducing the cost of diamonds would involve reducing the discovery and extraction costs. Sand is plentiful, so transport and handling becomes the dominant cost. Reducing the cost of transport and handling directly reduces the cost of sand. Similarly, as IPv6 addresses are plentiful (once the infrastructure to support IPv6 exists), "handling" them far outweighs the cost of "finding" them. One of the ways to reduce the cost of IPv6 is to reduce the cost of handling IPv6 addresses. That's why I think simple universal sizes/boundaries like /48 per site and /64 for subnets/64 bit IIDs are better. They reduce the cost of handling - the cost of humans becoming involved to be parsimonious with addresses and numbers of /64 prefixes increases the handling cost of IPv6 addresses. They reduce costs in other places too - having a single, common and generic IID size rather than a per link-specific IID size means development and implementation of IPv6-over-foo specifications is cheaper, because there does not have to be any per link-specific IID size related effort. The boundaries themselves are arbitrary, as long as they facilitate all the requirements (in our IPv6 specific case, functionality, ideally avoidance and tolerance of error (e.g., duplication of addresses is rare, so DAD succeeds most of the time), security and privacy). The important priority should be to have the least number of boundaries. For IPv6 to be as successful as we here want it to be, we want to make adopting and using the technology as cheap as it possibly can be. That will only encourage its use. Regards, Mark. From nobody Tue Aug 8 21:08:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92410131CF0 for ; Tue, 8 Aug 2017 21:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfOAgbggsPtx for ; Tue, 8 Aug 2017 21:08:51 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A94124B18 for ; Tue, 8 Aug 2017 21:08:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 386FFA2; Wed, 9 Aug 2017 06:08:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502251728; bh=Gt7jx+hQIheBejHWDJfAepRaw4oK5q0lJsFqwfN41vc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p36hg5NhUhsK0FiFOO+AJpHGZwDDNPvQsiI4lJObv0IdPmtYEcUEPBVNJdhufzV5F +piS21Vs6qXaExG87oSFuGJfmHvM4GQI1jeK1Oh3OCxhwrsZB4IaJ9HWCpXWCKzbEj Uq3IkVse1jJtdylVJXT5Eb70cEgMoB1tqLKOzX50= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1FED2A1; Wed, 9 Aug 2017 06:08:48 +0200 (CEST) Date: Wed, 9 Aug 2017 06:08:48 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 04:08:54 -0000 On Thu, 3 Aug 2017, Fred Baker wrote: > As discussed in Prague, this opens a two week WGLC on this draft. This > will end on 18 August. Please read the draft now and comment on it. The > chairs are interested to know about experiments using the old and > modified behaviors, and a quantification of the improvement (or lack > thereof) if such exists. We are also interested in the clarity and > utility of the proposal. I have re-read this i-d in its entirety. It's clear, useful, and I support it being moved towards publication. As a side note, we might sometime in the future want to bis this document with source address selection as well (to try with multiple source addresses if the inital attempts do not work). Currently in 4, it only deals with destination address selection. Actually, thinking of it, this draft doesn't say anything about source address selection. It just says: "First, the client MUST sort the addresses using Destination Address Selection ([RFC6724], Section 6)." Is the presumtion that RFC6724 section 5 (source address selection) is already being performed one by one on all destination addresses being processed, and that the source address selection is out of scope for this document? Do we need this to be explicitly stated? This is not a show stopper for me, I don't have a strong opinion on the matter. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 9 02:03:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD4713208E for ; Wed, 9 Aug 2017 02:03:38 -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 JMT0rAJSgWhi for ; Wed, 9 Aug 2017 02:03:36 -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 2F5C612940A for ; Wed, 9 Aug 2017 02:03:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id D59891A071 for ; Wed, 9 Aug 2017 09:03:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 9 Aug 2017 10:03:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71BB8015-C352-479E-8B18-E518A27B86E1@thehobsons.co.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <97B919E8-9E1D-4F5F-99C9-1B21B617AC61@google.com> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 09:03:38 -0000 Mark Smith wrote: > That's why I think simple universal sizes/boundaries like /48 per site > and /64 for subnets/64 bit IIDs are better. They reduce the cost of > handling - the cost of humans becoming involved to be parsimonious > with addresses and numbers of /64 prefixes increases the handling cost > of IPv6 addresses. They reduce costs in other places too - having a > single, common and generic IID size rather than a per link-specific > IID size means development and implementation of IPv6-over-foo > specifications is cheaper, because there does not have to be any per > link-specific IID size related effort. Why do you think there will be any development cost saving - UNLESS you = specifically rule out flexibility to handle unforeseen (or even = foreseen) usage cases ? So, lets assume we run with the "there will be no network with other = than a /64 prefix" option. Devs can ignore any need to store or handle = prefix lengths - very very marginal saving in dev time (lets face it, = this code already exists to handle 32 bit numbers). So what happens when someone does have a need to handle (say) a /65 = because of some reason that's out of their control - perhaps all they = get from upstream is a single /64 and they need to divide it. Answer - = they can't, because for a very small saving up front, that flexibility = has been ruled out. I'm not saying that /64 can't or shouldn't be the default, but given all = the comments about "not blocking future innovation" it seems a bit = contrary to then insist on causing known problems for a marginal (and = questionable) saving on development. AFAICS, there is agreement that = there isn't actually any technical reason for HAVING to use a /64 = anywhere (other than LL which is a special case anyway), and the only = remaining technical reason is the now deprecated method of forming SLAAC = addresses. So is there ANY valid technical reason why implementations should not be = required to handle arbitrary prefix lengths, since if you can handle any = length, then you can easily handle 64 - but if you hardcode in 64 = (probably by coding differently) then handling any other length may = become impossible. Or put another way, do you want to be one of those people who in 10, 20, = ... years time are the target of "WTF were they thinking of ?" comments = when/if there emerges a good case for a different prefix length and it = can't be done because there's too much hardcoded /64 built into the = system ? BTW - the sand analogy breaks down once you consider that it too is = limited. There may be more grains of sand on the beaches than we can = count, but I can't just pop down to the beach and dig up a trailer load = to build my new garage with without getting into trouble with the law ! = The price soon starts adding up once you are buying it from the builders = merchant. From nobody Wed Aug 9 14:05:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D481323B8 for ; Wed, 9 Aug 2017 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOungq0FrvJW for ; Wed, 9 Aug 2017 14:05:09 -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 5F13C132445 for ; Wed, 9 Aug 2017 14:05:09 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x3so73239984oia.1 for ; Wed, 09 Aug 2017 14:05:09 -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=9WrGuF18bREfwNDPqIBZMA1p7IoGuN4dlmEmVcT9MxY=; b=ROaDWTnP+OqI6rUb+cBR/mJdNkLEwhFemnAuSr3aNmIaeFGJLnTyLOSgWAk+p3w8zs GMtf/gpM/TCSKI2Mlp9AOiSZpcsYoq/Y3H1NTTMhc8rCvkeIz2lcDo2509v3Pwfz2hau Lxx1oHvL2ttT/X0BuHM1XTMjR4W3m6tAvOOhVapFSpFnbexSguXhRJmEqBudKeIB04De 5yi5UvydZWnUQxc0VI6V9b8/+BW4QfJKdRuIsitJxuo41FY7JCU3So2hEizlyfj9hRtX CkExXVDuvPW8qShReM3CfYz6SiZ4BTjKhB4mzOZMPAn6JmPB2gmDEowP7b/XeS/JL5x0 pSOw== 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=9WrGuF18bREfwNDPqIBZMA1p7IoGuN4dlmEmVcT9MxY=; b=eYCKyABEd52tCUUBp94/h7pX+DWyRzo9H/y46VodMV7PS38QabRWcyy751TP9PFrsW w9TM1nv5GVP/uaLUyt21zjWH6HcN0KfmSC0eSS2j6aQOof1VKf7VF0AYoijKh5IMSKfv 2H7Mn6+f/RRj5x16Ry8qUM5hjd88GZRZSDTFMziWqfdKaZfOg+lqpHcN2Kmb0/qMpUX0 AtoyD8wpv4B7w3OUBwmggUmj7ocQFdMf0+u08k2aDFUKbUUBh1PObDzOTqc8ifh9Aa2M q9aM+EeR9Hxegk1Cenx33j5QLZVW+erDo7rfEfxFQYS4QfGYM6Sooam9ON8c6VdY/PT/ p1Tg== X-Gm-Message-State: AHYfb5gqxGrLey2YrhzPdte7AbznfdcYSjOA7oZfbejac/6aY5vFzHwh pClf50gVBcBRkG1xVK0= X-Received: by 10.202.67.6 with SMTP id q6mr11268596oia.144.1502312708683; Wed, 09 Aug 2017 14:05:08 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1848? ([2600:8802:5600:1e::1848]) by smtp.gmail.com with ESMTPSA id w134sm5297530oif.32.2017.08.09.14.05.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 14:05:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3441.0.1\)) From: Fred Baker In-Reply-To: Date: Wed, 9 Aug 2017 14:05:00 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1AAF35FF-8CB7-4022-BA81-81D8F7BE603C@gmail.com> References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3441.0.1) Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:05:11 -0000 I could be wrong, and in any event this is "no hats". My perception is that the application (which is to say, the code that = calls the socket API) selects the destination, tells the socket API, and = the OS then selects the source address. If I were allowed to specify = that interface, I would have the application give an ASCII literal = string (which might contain an encoded address, a DNS name, or something = else specific to the OS) to the API, which would select both the source = and destination addresses on the OS side of the API. If the socket API = worked that way, we wouldn't have to change applications to deploy IPv6, = which would be a huge win.=20 If we're not allowed to change the API, I don't think we're in a = position to discuss source address selection in this document. The code = that selects the destination doesn't (at least usually) also select the = source. Happy to be corrected. > On Aug 8, 2017, at 9:08 PM, Mikael Abrahamsson = wrote: >=20 > On Thu, 3 Aug 2017, Fred Baker wrote: >=20 >> As discussed in Prague, this opens a two week WGLC on this draft. = This will end on 18 August. Please read the draft now and comment on it. = The chairs are interested to know about experiments using the old and = modified behaviors, and a quantification of the improvement (or lack = thereof) if such exists. We are also interested in the clarity and = utility of the proposal. >=20 > I have re-read this i-d in its entirety. It's clear, useful, and I = support it being moved towards publication. >=20 > As a side note, we might sometime in the future want to bis this = document with source address selection as well (to try with multiple = source addresses if the inital attempts do not work). Currently in 4, it = only deals with destination address selection. >=20 > Actually, thinking of it, this draft doesn't say anything about source = address selection. It just says: >=20 > "First, the client MUST sort the addresses using Destination Address > Selection ([RFC6724], Section 6)." >=20 > Is the presumtion that RFC6724 section 5 (source address selection) is = already being performed one by one on all destination addresses being = processed, and that the source address selection is out of scope for = this document? Do we need this to be explicitly stated? This is not a = show stopper for me, I don't have a strong opinion on the matter. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 9 16:53:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15E91324C7 for ; Wed, 9 Aug 2017 16:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlVnDnAiqNuY for ; Wed, 9 Aug 2017 16:53:20 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77711324C5 for ; Wed, 9 Aug 2017 16:53:19 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id f9so34862874uaf.4 for ; Wed, 09 Aug 2017 16:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ilorXJVi3Gfd2JFCxf3dmudbnLS6twrDM2MKn+KUutU=; b=UHgyfII6MYU6AfEVJGfWHcTHnWEpRvf1eYRqDlt9BNIQoDc0Ct259J+7Ld2vNK4KyO TNOF+/LGUzNsM5yGi89crsWa+Nd1vjqWBNWz3HsKnCvHWCRMY+E8w0AsDLC8oXUNrxZU m2q4t2FfahVHllB+oXPqK3zokd6EQ0F97iAU5wfNqTx7zZTm/n3yLO5VJ4CuA44+Pg8w cu+NjOXP8rLukHrKT3hWciOkjQxPNsDEgpuEj1yRXLeApKgHg1I9/aghpU8IyHnYDYXw whEAYM9L1Xnv/eu34aWOxI5+vaOk65m1zmtR0xA49diI7bkcX9uIuDNgRiut4iJVTK+k yaJQ== 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=ilorXJVi3Gfd2JFCxf3dmudbnLS6twrDM2MKn+KUutU=; b=SIkw3SY1zcMU8uL+M1Auu21OlfD1ijA254rxLEy0FME7jmIvPrvMAr0cO7jxk5YfNT HoLz57GgmX8IZgOvsGRprT8O1s/VAxpI1vVsq9fugPnbBcQ6STr7tvgFQMC7zeVoaq0F L4BSMrrERLZRXKsH+BwgXlb/7x+oMqqDNAvMzPB/oQZPyPMdkrmaJahpzqkAijL5NFnu FOJYwCrazbJcLlz1EL9v8NJrdk3Nuxu7JzG5fZBFPLBbTUx8s/G8AYLbpRfNmC7nR7Xu l3Ui60u/TlD0s4xF4HHCtysSwz6/31WYb8Rw0/QWa6H5l3aWFAZEXYYc5Cl3tbnQnR/B ptgw== X-Gm-Message-State: AHYfb5jKPUg2oC0eSWskQbr7Xe+0SO7UBtfz7F47BTZoyX+GPfQLG0sB D0qagOdRvd0L1LYPGQMejrWZKyU0ZA== X-Received: by 10.176.86.87 with SMTP id z23mr6879691uaa.170.1502322798857; Wed, 09 Aug 2017 16:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.22.105 with HTTP; Wed, 9 Aug 2017 16:53:18 -0700 (PDT) Received: by 10.176.22.105 with HTTP; Wed, 9 Aug 2017 16:53:18 -0700 (PDT) In-Reply-To: <4B4511FB-5E38-46B9-870C-3882B55F852B@thehobsons.co.uk> References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <4B4511FB-5E38-46B9-870C-3882B55F852B@thehobsons.co.uk> From: Mark Smith Date: Thu, 10 Aug 2017 09:53:18 +1000 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: multipart/alternative; boundary="f403045df280c3948105565ac8ce" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:53:22 -0000 --f403045df280c3948105565ac8ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Analysis of the 64-bit Boundary in IPv6 Addressing" https://tools.ietf.org/rfc/rfc7421.txt On 7 Aug. 2017 8:26 pm, "Simon Hobson" wrote: > Tim Chown wrote: > > > The question though, as and as you say it=E2=80=99s not one really in t= he IETF=E2=80=99s > scope, more the RIR communities, is if a site has a /48, and uses it up (= or > 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-pe= r-host, > will that be deemed appropriate use to allow a further assignment? > > > > A large university may choose to implement this on its wifi/eduroam, fo= r > example. > > Presumably that means another separate prefix. And when 2003:: is used, > 2004:: will get allocated and so on. > At what point will people be suggesting that we could have avoided the > routing table bloat by allowing better use of the prefixes ? > > AFAICS the insistence that it must be /64 per host, rather than anything > else (eg /80/host or /96/host) seems to be more religion than technical > requirement. > I can see the security (through obscurity) and privacy reasons why > individual addresses should come from a /64 (or at least, large) prefix - > but I fail to see much, if any, merit in allocating 2^64 addresses to a > single host "because we can". > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045df280c3948105565ac8ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
=
"Analysis of the 64-bit Boundary in IPv6 Addressing"
https://tools.ietf.org/rfc/rfc7=
421.txt

On 7 Aug. 2017 8:26 pm, "Simon Hobson" <linux@thehobsons.co.uk> wrote:<= br type=3D"attribution">
Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> The question though, as and as you say it=E2=80=99s not one really in = the IETF=E2=80=99s scope, more the RIR communities, is if a site has a /48,= and uses it up (or 16,384 /64s of it up) implementing draft-ietf-v6ops-uni= que-ipv6-prefix-per-host, will that be deemed appropriate use to allow= a further assignment?
>
> A large university may choose to implement this on its wifi/eduroam, f= or example.

Presumably that means another separate prefix. And when 2003:: is used, 200= 4:: will get allocated and so on.
At what point will people be suggesting that we could have avoided the rout= ing table bloat by allowing better use of the prefixes ?

AFAICS the insistence that it must be /64 per host, rather than anything el= se (eg /80/host or /96/host) seems to be more religion than technical requi= rement.
I can see the security (through obscurity) and privacy reasons why individu= al addresses should come from a /64 (or at least, large) prefix - but I fai= l to see much, if any, merit in allocating 2^64 addresses to a single host = "because we can".

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--f403045df280c3948105565ac8ce-- From nobody Wed Aug 9 17:26:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372B11324CE for ; Wed, 9 Aug 2017 17:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 wl1C-sIwF7Ry for ; Wed, 9 Aug 2017 17:26:20 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 302FA13202D for ; Wed, 9 Aug 2017 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502324779; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4xxOC4Af5GKh4+FPYtqDwMwYQZbg+mAde3SjwMnBNII=; b=uaaXkbCroO2bg9SlTcbSf+51AYDhBcEbKUQmST2Dv5gO80IO5pgaxFjKfLiHJULs kOrSliCtOeJ8zXERsGqOWMd0GL4lRxRBeF/+3EpBdyo71vxyC+ngU4KEybYQSWQz YHV93PN0wN3LirPGNIQxslC036+WhSCtrJzLcq5NOPjWYYwq6IYiPO/FwmDq+cDe udLr9v8083/aPgay7pL8MTAN+t0e6K1yM3AiQDoztXDNfvH6+NO0s8+mWnbFJF5Q TjyDiFUCjIEXZXNDSns6YQHfLuTbhWcQ0MD+hSRcJWsShZYupm6zRVALS54533e1 MKqmNRPAhzjrtHhJPkVOhw==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 95.FD.06195.B28AB895; Wed, 9 Aug 2017 17:26:19 -0700 (PDT) X-AuditID: 11973e16-8b5f19c000001833-15-598ba82b7c20 Received: from nwk-phonehomebzp-sz01.apple.com (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay7.apple.com (Apple SCV relay) with SMTP id 18.E2.07283.B28AB895; Wed, 9 Aug 2017 17:26:19 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.0.1.17] (76-14-73-28.sf-cable.astound.net [76.14.73.28]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUG00F5Q17VJC30@nwk-phonehomebzp-sz01.apple.com>; Wed, 09 Aug 2017 17:26:19 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <1AAF35FF-8CB7-4022-BA81-81D8F7BE603C@gmail.com> Date: Wed, 09 Aug 2017 17:26:17 -0700 Cc: Mikael Abrahamsson , v6ops@ietf.org Message-id: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <1AAF35FF-8CB7-4022-BA81-81D8F7BE603C@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FCYqqu9ojvS4NwjK4vbXxtYLV4u3cpm cfrYXmYHZo+ds+6yeyxZ8pPJ4++kh0wBzFFcNimpOZllqUX6dglcGR9ff2UrOC5VseX2ZrYG xmOiXYycHBICJhJd/TdYQWwhgTVMEvtm8cPE/91Yw9TFyAUUv8Ao8fjZb3aQBK+AoMSPyfdY uhg5OJgF5CUOnpcFCTMLaEl8f9TKAlG/hUli2f05zCAJYQFpia4Ld1khbA2Jp8+WM4H0sgE1 HFhjBBLmFLCVePxuJhuIzSKgKtHWv40RYqalxN2r7SwQa20kZjY9hJrfyyTxYWkLWIOIgKbE 7XXTmCCOlpW4NfsSM0iRhMAWNolVt46xTmAUnoXk7lkId89CcvcCRuZVjEK5iZk5upl55nqJ BQU5qXrJ+bmbGEHBPt1ObAfjw1VWhxgFOBiVeHgTRLsjhVgTy4orcw8xSnOwKInzurUChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTCGNHilPHJ7aaJoqckcq/Skz0btBi/zmrcPPW6FWAWW dy96altUZz29o/AuY5nYJ/fiP4cPSC1cru/45Ob9FvXjwfXnXi7Nr/ww7+jF2TNrvj5zMSrV WnZz25UA5ZdNh4ICGqsEp0jZPJnx8UrgLq+CIO4IWyP1vl4+7VRWK9u5V7+ma69dckaJpTgj 0VCLuag4EQB3IQeUVwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUiON3OQVd7RXekwaetZha3vzawWrxcupXN 4vSxvcwOzB47Z91l91iy5CeTx99JD5kCmKO4bFJSczLLUov07RK4Mj6+/spWcFyqYsvtzWwN jMdEuxg5OSQETCT+3VjD1MXIxSEkcIFR4vGz3+wgCV4BQYkfk++xdDFycDALyEscPC8LEmYW 0JL4/qiVBaJ+C5PEsvtzmEESwgLSEl0X7rJC2BoST58tZwLpZQNqOLDGCCTMKWAr8fjdTDYQ m0VAVaKtfxsjxExLibtX21kg1tpIzGx6CDW/l0niw9IWsAYRAU2J2+umMUEcLStxa/Yl5gmM ArOQnDoL4dRZSE5dwMi8ilGgKDUnsdJcL7GgICdVLzk/dxMjKDwbClN3MDYutzrEKMDBqMTD myDaHSnEmlhWXJl7iFGCg1lJhDdjOlCINyWxsiq1KD++qDQntfgQYxXQAxOZpUST84Gxk1cS b2hiYmBibGxmbGxuYk4VYSVx3hkdQJsF0hNLUrNTUwtSi2CWM3FwSjUwyjHI3z7/w/fn+lv5 5/8cLnaY/DHtnkcip41QpmePRZCx2cfqb8trJi78nNz2QbduVYhv792EhAqhz0/DDV3N4vgm PC1NLbjEGPzNqCQ73LhROug/5/aoXp4FjWxvud0Sqk4WP+uNO3yy+fY1qxVZT7Wsj035fd/l 52e+b1kTFDluBdx+XbJViaU4I9FQi7moOBEApN4kuaoCAAA= Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:26:22 -0000 I agree with Fred. As currently specified, Happy Eyeballs (both v1 and v2) only discuss destination addresses. For each destination address that Happy Eyeballs wants to connect to, the OS picks a corresponding source address via RFC 6724. I believe source address selection is out of scope of RFC 6555bis and already well documented in RFC 6724. We could however explicitly say the above in the document. Regarding Mikael's proposal of trying multiple source addresses for one given destination, this would be a non-trivial amount of work to specify, as doing it "wrong" can cause serious issues (e.g. a server can trick you into leaking your stable address), so I'll consider it future work. David Schinazi > On Aug 9, 2017, at 14:05, Fred Baker wrote: > > I could be wrong, and in any event this is "no hats". > > My perception is that the application (which is to say, the code that calls the socket API) selects the destination, tells the socket API, and the OS then selects the source address. If I were allowed to specify that interface, I would have the application give an ASCII literal string (which might contain an encoded address, a DNS name, or something else specific to the OS) to the API, which would select both the source and destination addresses on the OS side of the API. If the socket API worked that way, we wouldn't have to change applications to deploy IPv6, which would be a huge win. > > If we're not allowed to change the API, I don't think we're in a position to discuss source address selection in this document. The code that selects the destination doesn't (at least usually) also select the source. > > Happy to be corrected. > >> On Aug 8, 2017, at 9:08 PM, Mikael Abrahamsson wrote: >> >> On Thu, 3 Aug 2017, Fred Baker wrote: >> >>> As discussed in Prague, this opens a two week WGLC on this draft. This will end on 18 August. Please read the draft now and comment on it. The chairs are interested to know about experiments using the old and modified behaviors, and a quantification of the improvement (or lack thereof) if such exists. We are also interested in the clarity and utility of the proposal. >> >> I have re-read this i-d in its entirety. It's clear, useful, and I support it being moved towards publication. >> >> As a side note, we might sometime in the future want to bis this document with source address selection as well (to try with multiple source addresses if the inital attempts do not work). Currently in 4, it only deals with destination address selection. >> >> Actually, thinking of it, this draft doesn't say anything about source address selection. It just says: >> >> "First, the client MUST sort the addresses using Destination Address >> Selection ([RFC6724], Section 6)." >> >> Is the presumtion that RFC6724 section 5 (source address selection) is already being performed one by one on all destination addresses being processed, and that the source address selection is out of scope for this document? Do we need this to be explicitly stated? This is not a show stopper for me, I don't have a strong opinion on the matter. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 9 18:25:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57E1324EF for ; Wed, 9 Aug 2017 18:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atcfumGttV-H for ; Wed, 9 Aug 2017 18:25:20 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878D11324E7 for ; Wed, 9 Aug 2017 18:25:20 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d124so31931250vkf.2 for ; Wed, 09 Aug 2017 18:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R4X+W2wkCk+38ipAx3TCVtDFBxSdOpt1fzYJIR9TLNM=; b=t3Eo/ImfJAjcXWRK8+NT2/v2+MZQALW4jknxq4kiRnMKPze800Q1RWuE0DoVDUyIc3 FlTYeU5EgIofBLwE2dwOMO94GDp2WYH+catGVVBr0Rcy+g1Ba/no0RpGhTMNA8bxzwqV c/ccOwEg0fvI/rGrOX2KVpeMFiyTqHarX9SdMF7A3NVBl4OUrrLaSMrjDE74KiPYfEZg WythHiJOkbcOiGFp6YVTWnFcIyCNswmp2n+HDgVyMXkIdCMBWG/78hfdXFRUuxrZWybq gyRjMpCBL6G7iWbtCRi8YdG//WPuWusYJMEzb/SXYEJFVqSMAcjzusA5zt9jhiAa/u3B qD6g== 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=R4X+W2wkCk+38ipAx3TCVtDFBxSdOpt1fzYJIR9TLNM=; b=IOpyA6AVNpdY6NGzrQ1JpM+rqiK6V4dJqYL7yDnyh24dIfyZQwj0pWJXDbYoellufj wV+41TJiW47C4XR0G2z6mgyineFVDzbbxmvG5/rCpNbuOPkJfblCFCUDmwzIQvNrn7Ym 44IdZcjZUJ6fTDgtHFF9MADLROnDlHCpueRkbA0XG/DwdeQlw2O/PXfTjY62HZX0ttjH TITDYmsc/ryvpZvRbHsuBjm9xfWipk/aVl+R3vpW00wAIiNDB3YjEnUMeV69RtWYCiGF VZ2UI2NvdDntv7yQJJLqLUNARQ7HKv+Q2vuPibUK+WtJ7RD6eTIYZVP1kBWfxwOz7gfJ 4cHA== X-Gm-Message-State: AHYfb5ixSJXy/B6gUUpHzaxp/d5tXr5goiDYmanX3XzQc5+v5OtPRaGF SsqrvLHLnmeGlgaaW3zibrPAy7rkvg== X-Received: by 10.31.215.6 with SMTP id o6mr6715516vkg.179.1502328319529; Wed, 09 Aug 2017 18:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.22.105 with HTTP; Wed, 9 Aug 2017 18:24:48 -0700 (PDT) In-Reply-To: <20170807110746.GG45648@Space.Net> References: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> From: Mark Smith Date: Thu, 10 Aug 2017 11:24:48 +1000 Message-ID: To: Gert Doering Cc: JORDI PALET MARTINEZ , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 01:25:23 -0000 On 7 August 2017 at 21:07, Gert Doering wrote: > Hi, > > On Mon, Aug 07, 2017 at 12:35:25PM +0200, JORDI PALET MARTINEZ wrote: >> Most of the RIR policies allow a shorter prefix than /48 for a single site >> if justified. > > "If justified" has traditionally been along the lines of "number of buildings, > number of subnets, number of aggregation levels", so, number of *networks*. > > "Number of hosts" has not been a justification argument in (at least) > RIPE IPv6 policy, so that would be a fairly significant change. > > Personally, I would be very careful here - permitting assignments of > larger address blocks because we *waste* a /64 on a potentially very > large number of hosts in a network might cause shortage further up. > > And yes, I think this is extremely wastive, well over the limits of what > is normal "do not care about wasting addresses!" level of IPv6 normal. > So it's worth considering what the word "waste" means. It means getting no value at all from some quantity of a resource. That quantity of resource isn't being used for anything of value to the resource's user. What we get from /64s/64 bit IIDs is simplicity (in planning and operation), robustness (because if there is only one valid value for something, every other value is an error and easy to see), and the ability to give a addresses useful privacy and security properties. They are all of use and value to the end-users users of the Internet, so /64s/64 bit IIDs are not wasteful. Of course, it would be possible to be reckless with resource consumption such that you encounter unexpected and unnecessary resource scarcity. The induced scarcity will then cause people to have to start to make choices and trade-offs as to which beneficial uses and values they get from the resource to give up. So there needs to be a balance. Consumption must not be reckless, however it also should not be so intentionally and artificially constrained that trade-offs between beneficial uses and values have to be made. Brian's beach sand maths shows that there isn't a scarcity of /64s, in particular as his calculations were within the 1/8th of the IPv6 address space we are currently using for global addresses (i.e., 2000::/3). Leaving 1/8th for ULAs, Loopback etc., would still have enough /64s in the other 6/8ths of the IPv6 address space to give one to each grain of beach sand on 6 other Earth like planets. > On a subnet, having a "it is big enough for everything, no matter how > many hosts" is a desirable property because it makes network planning much > easier - single size fits all, focus on more interesting work. A /64 > is already excessive here, but given that the number of subnets is > bound by factors like "how many different purposes can you come up > with?", "router config", etc. I'm willing to accept a /64 here. > > A /64 per *host* is much less bound - while far beyond anything you can > configure on that host, so the trade-off "waste vs. useful number of bits" > is not reasonable for me. > I don't think anybody is suggesting that a "host shared /64" model is to be universally replaced with a universal "per-host /64 prefix" model. It is an alternative option that has benefits in some situations. Sticking with a /64 boundary in this prefix per host model is for simplicity and compatibility with existing specifications and implementations. We should only give it up (and pay the costs of giving it up) if it can be shown it can't work. > > Should this topic come up in RIPE policy discussion, I'll chair the > discussion and refrain from having an opinion, but will reserve the right > for a "told you so" later. > I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion /64s? If an ISP isn't giving out at least /56s to customers, the problem isn't with the /64 boundary, it is the ISP carrying IPv4 address scarcity management practices over to IPv6 where they aren't needed. We are wasting our time (getting no value from it) trying to accommodate unneeded IPv4 practices carried over to IPv6. We end up trying to make things accommodate more and more perverse and unnecessarily conservative IPv4 carried over practices. If we accommodate them, we're also tacitly endorsing them. Regards, Mark. From nobody Wed Aug 9 22:47:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C5B132519 for ; Wed, 9 Aug 2017 22:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWAKQfCWaWqB for ; Wed, 9 Aug 2017 22:47:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17776131CF0 for ; Wed, 9 Aug 2017 22:47:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A9F0DA2; Thu, 10 Aug 2017 07:47:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502344025; bh=FHY86iJqQPkmy05NgXh+kczaprP5tn1pKVz/fKgHAZY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3neW9t+g2lZLPZQrGHB/UOiEklfwbnjAtOe5ffCiq8avohv7ACEunF1gbqvhhH8yy mCQ06GERzV3/OaEpRsYscUV1xpuOoJcOBKdB7p1uNQdVy6Ay/39R33G4mE4W448XHP jBc/3G+ocyNzh4NSOZVCEHHMdYB9buzCIkxUhDGA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 911E3A1; Thu, 10 Aug 2017 07:47:05 +0200 (CEST) Date: Thu, 10 Aug 2017 07:47:05 +0200 (CEST) From: Mikael Abrahamsson To: David Schinazi cc: Fred Baker , v6ops@ietf.org In-Reply-To: Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <1AAF35FF-8CB7-4022-BA81-81D8F7BE603C@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 05:47:12 -0000 On Wed, 9 Aug 2017, David Schinazi wrote: > Regarding Mikael's proposal of trying multiple source addresses for one > given destination, this would be a non-trivial amount of work to > specify, as doing it "wrong" can cause serious issues (e.g. a server can > trick you into leaking your stable address), so I'll consider it future > work. That's a good point. I still think we need to do this at some point in the future, but I agree that it's out of scope for this document. Thanks! -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 9 22:58:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB7132557 for ; Wed, 9 Aug 2017 22:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYARimyJPYXb for ; Wed, 9 Aug 2017 22:58:23 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0A4132556 for ; Wed, 9 Aug 2017 22:58:22 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F32454291C for ; Thu, 10 Aug 2017 07:58:19 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E222D42916; Thu, 10 Aug 2017 07:58:19 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id DE6B9178F9; Thu, 10 Aug 2017 07:58:19 +0200 (CEST) Date: Thu, 10 Aug 2017 07:58:19 +0200 From: Gert Doering To: Mark Smith Cc: Gert Doering , JORDI PALET MARTINEZ , v6ops list Message-ID: <20170810055819.GQ45648@Space.Net> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dadxls/0Fulk8RKG" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 05:58:26 -0000 --Dadxls/0Fulk8RKG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 10, 2017 at 11:24:48AM +1000, Mark Smith wrote: > > And yes, I think this is extremely wastive, well over the limits of what > > is normal "do not care about wasting addresses!" level of IPv6 normal. >=20 > So it's worth considering what the word "waste" means. It means > getting no value at all from some quantity of a resource. That > quantity of resource isn't being used for anything of value to the > resource's user. Waste can also mean "I have used up something without actually needing it, and now it's missing somewhere *else*". [..] > > Should this topic come up in RIPE policy discussion, I'll chair the > > discussion and refrain from having an opinion, but will reserve the rig= ht > > for a "told you so" later. >=20 > I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion > /64s? If an ISP isn't giving out at least /56s to customers, the > problem isn't with the /64 boundary, it is the ISP carrying IPv4 > address scarcity management practices over to IPv6 where they aren't > needed. So how useful is a /56 to a customer if the customer wants to do /64-per-host? If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it's all of a sudden becoming tight for slightly larger customer sites. > We are wasting our time (getting no value from it) trying to > accommodate unneeded IPv4 practices carried over to IPv6. We end up > trying to make things accommodate more and more perverse and > unnecessarily conservative IPv4 carried over practices. If we > accommodate them, we're also tacitly endorsing them. I could point out that "a /64 everyhwere" is repeating the "Class A, B, C" mistakes from IPv4. Your turn. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Dadxls/0Fulk8RKG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmL9fgACgkQ31bAZeTO f8Xmmw//dOjpNlxEizqpMnHxm7glUfGJO1RXKzSAlbn5O5pWJ9eEplKMPvyGQHEA 2MeCZhwAI2MwPgUfPLLm745hKB0+SVhmFU1ZeAOOqTjg0xgDrFXcqKCpqgbHP9NI dkRZkTKZ4YMcGBaWRxSqG48Q9KKq6WJl2RMHyc2d0MGhxgUCkdmYzcFbH5vyS0jj SbjMXPfm5EuX7+U2L7UleI2CgwWTTNCnosp22W9ayG/RiHqhtSTA4IWNhbH7jwAN C/gdq3VqE7PJw8fSGGsCzdwwXrygaBbdM6Ge2Ooe7VjfMQdeUI8moNSAAZoKglLM UuHm1+vbEZpkdyQSNDvkerp9GGZ4PMgFET8KXRfyc6wqHSvUaQeQbPHw8FrocqWD Tu1IvxLxoeT3/FNezUy9jrm5QixmHvwyg1a7ITriSRjfMjk93bj/7yg+DegJvtr3 58fuHbViQPd4PTI1GUSo8m+ISmru2YU0MUwPAK5l/5+iPszZIO6wrMSKg4jSjTds RXiuSEKCgT+arNyGy1N0TIhClIXET1sHnXiA1gY43zbX1AdKAs5MT1Gco1Wk2QMN lvAhaDXEwqJzrBNvk7MmeLNI+nmuSAOyWn6SBG5V76o5T+qxBmAot6xQ+VZX/c3L oFqzgX4UguqjDDj/Cotl2CWEOBy0bt/7cNF9nxQFFFKRMrdITOg= =E452 -----END PGP SIGNATURE----- --Dadxls/0Fulk8RKG-- From nobody Thu Aug 10 11:13:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22891323C1 for ; Thu, 10 Aug 2017 11:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0YWEWw8skoH for ; Thu, 10 Aug 2017 11:13:50 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BFF132256 for ; Thu, 10 Aug 2017 11:13:49 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id s6so9168820qtc.1 for ; Thu, 10 Aug 2017 11:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bUibxriZUA9DzN5FwZS44FtJLbeu8pOdFpy0ObxDeyo=; b=JO+lYEJ6SkK/iJRghmderwENUZplOlQujxIB7Qpv2LvCJSbVyYFQzC8TSL+b3Xpedo iAbmBJEpvphH2xitZ4UvQAhwHbiT9odOvYDEz0xM79R17jqYuQ86iz2i6Y+o+MAbXaMb 6EyI60jTse1P4VbsR4er+8i9o/vZJu7b2b+jgaTzieQPhKmYlpNW0U/xmBKBZpZfMwJk wBHXjys9Pg4qKJpbGc79z1gofsnXBmlVhKegZwIQqvc4WQabWX6lI7rya1JfRinpx7a/ ChyCHf8/1jXN/MxITF/xb0guZgT5jQcSoPvKctl3fiv90XwLzf6uxBOKYkQOuq7gKeOC AR6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bUibxriZUA9DzN5FwZS44FtJLbeu8pOdFpy0ObxDeyo=; b=b2Vaz2cYsBjrFbYLo+MtfvEVU0KC/EKrxKfXbdJJAJhf8jHXP4H2vYBRYroegcaZGt 48cW2lJ5HGzD9Z1d9Tdk9LCv0b/KE7WG3rjUK3zRlHa+juACbunrW39VDq0Z7FUv4FHl fiA+D+fJMC7NsGdS8u4bS3DLeuFGVmbqtlTKfTxFUQWKS5uazf5jN3Ep1R6A5/UtEqJf EtiNBcj9WzsgkrclAGS/pNKRbt4uNK8RyCQQYet37Z1otmPeFaIN5xQoGQwH233Zk3kG kkGOaby3qfb+4nLmVfu9EGdUnY3seuAanOOEt/IY2iAsfFB7Qmn15zwRRPyrvnTphNIQ EOrw== X-Gm-Message-State: AHYfb5hTBqUQsYFC2opQQ1Kw8DFttPyEUJymR1zDs3Qr8c5fB34X9XNV E9iHmDOBhq5VwCbicxIQB3prCAjqaRPzyu8= X-Received: by 10.200.44.13 with SMTP id d13mr16813449qta.192.1502388828949; Thu, 10 Aug 2017 11:13:48 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Thu, 10 Aug 2017 11:13:48 -0700 (PDT) In-Reply-To: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 10 Aug 2017 11:13:48 -0700 X-Google-Sender-Auth: FcoGEJGsTCQ46WkyY83w6lsLf98 Message-ID: To: David Schinazi Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:13:52 -0000 At Tue, 08 Aug 2017 10:06:12 -0700, David Schinazi wrote: > Most of your comments were regarding asynchronous DNS, which I believe > the working group has reached rough consensus on. While there is still a > vocal minority advocating that asynchronous DNS is "too hard", those > implementations are free to only implement Happy Eyeballs v1. The chairs > should correct me if they disagree, but I feel the working group overall > agrees that the benefits of asynchronous DNS are worth it. Hmm, if the wg has reached consensus on the use of a MUST for asynchronous DNS, I'm not opposed to it myself. I thought it was still open: as far as I remember I've not seen a declaration of the consensus in this list, and I can't see it in the Prague minutes: https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops (and I wasn't there or didn't participate in it remotely). And, while I personally don't have a strong opinion on the matter itself, I tend to agree with those opposing to it in that a MUST sounds too strong. But, again, if we've already reached a consensus on it that I have simply overlooked, that's fine. -- JINMEI, Tatuya From nobody Thu Aug 10 12:50:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02E0132430 for ; Thu, 10 Aug 2017 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92moQ7vIDR04 for ; Thu, 10 Aug 2017 12:50:40 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4517132359 for ; Thu, 10 Aug 2017 12:50:40 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id g131so16388071oic.3 for ; Thu, 10 Aug 2017 12:50:40 -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=krE2jwLK0Qdr0tXbOhbE/oBliV6IVazan2Orf1whwlk=; b=dcZPda52M6yzEv8gcrSQpq0kDXNRStXhqHOXzP/FpmFU1OOH+EgnyszlW9p4Y20834 Kfj1sGcHfppMmE9mVYbuCLbaVCwKOpPU0TPRju4/T08uXm5RiogIvDczGZrWOlYs0Enh FPkrB3HC+CfNi2gFO0MdIUXYMsoK7VWgT0+xUdrxImHDQjPOHq+w31sIWMDtvVf4b0fr 7mqAdSN9DG8RKR+6EsSYwElyNwXxQECDMm3VVUBRRPVDD8ZhNvBxPgI/6hAmF7jDSLUB kaGTv5Zfx0F3gaPUNpJZoEyEGqlV+xB8fyXRsfbtRPWfmHCZWyJshVtnqEu6SzLwo7Hd R/tQ== 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=krE2jwLK0Qdr0tXbOhbE/oBliV6IVazan2Orf1whwlk=; b=ebz4nAtk9SspxQYmPpFh6SRBdoNJ9xOxNySWIbrHXjLRA2BJU24hypEBsO2o6dtPbZ lQ0Mdpo+ZVq6928pIvZIF9iw+NbK//ju91EjzKp8x23njRk/MDJzJ4qepcQEF3CYyYWl rzme67aKodmhVUE2cBt9bDFIOVk1NlhUpUafIDCq3OKN62ieI0JZbUaMmyxb/o5GdZYO UMKWLqyJp1+13YcyBrd48E4RD/1gbBrsHAKnmAMo74lMzfwrBv+xXQa2rAW1atH6B+3T oSMAZXSEmSNAzt2mfNoXqqkAlzlHk/5u265HecMk6wBehAukAQ9loQ81e9IrCa5rKxAy /2ww== X-Gm-Message-State: AHYfb5ju89BG6Nkr5VMn6B5LHeiYGweOf9yG6YSEpgVcZD7c2fgDCzty n4TKYBnUlIwp4Q== X-Received: by 10.202.60.133 with SMTP id j127mr13881725oia.7.1502394640136; Thu, 10 Aug 2017 12:50:40 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1848? ([2600:8802:5600:1e::1848]) by smtp.gmail.com with ESMTPSA id k64sm7343229oif.35.2017.08.10.12.50.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 12:50:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3443.1\)) From: Fred Baker In-Reply-To: Date: Thu, 10 Aug 2017 12:50:37 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= , David Schinazi X-Mailer: Apple Mail (2.3443.1) Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:50:43 -0000 To my knowledge, the chairs have not asserted a consensus. > On Aug 10, 2017, at 11:13 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Tue, 08 Aug 2017 10:06:12 -0700, > David Schinazi wrote: >=20 >> Most of your comments were regarding asynchronous DNS, which I = believe >> the working group has reached rough consensus on. While there is = still a >> vocal minority advocating that asynchronous DNS is "too hard", those >> implementations are free to only implement Happy Eyeballs v1. The = chairs >> should correct me if they disagree, but I feel the working group = overall >> agrees that the benefits of asynchronous DNS are worth it. >=20 > Hmm, if the wg has reached consensus on the use of a MUST for > asynchronous DNS, I'm not opposed to it myself. I thought it was > still open: as far as I remember I've not seen a declaration of the > consensus in this list, and I can't see it in the Prague minutes: > https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops > (and I wasn't there or didn't participate in it remotely). And, while > I personally don't have a strong opinion on the matter itself, I tend > to agree with those opposing to it in that a MUST sounds too strong. > But, again, if we've already reached a consensus on it that I have > simply overlooked, that's fine. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 10 18:42:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E671204DA for ; Thu, 10 Aug 2017 18:42:40 -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 LKRLVa9oyorc for ; Thu, 10 Aug 2017 18:42:38 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089D6131F21 for ; Thu, 10 Aug 2017 18:42:37 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B563324AE96; Fri, 11 Aug 2017 01:42:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 48F8E160041; Fri, 11 Aug 2017 01:42:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 33FBA16004A; Fri, 11 Aug 2017 01:42:32 +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 lgqawRcoKZ_J; Fri, 11 Aug 2017 01:42:32 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D8884160041; Fri, 11 Aug 2017 01:42:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 747B98208B3C; Fri, 11 Aug 2017 11:42:29 +1000 (AEST) To: Fred Baker Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , David Schinazi , "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> In-reply-to: Your message of "Thu, 10 Aug 2017 12:50:37 -0700." Date: Fri, 11 Aug 2017 11:42:29 +1000 Message-Id: <20170811014229.747B98208B3C@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 01:42:40 -0000 It breaks address selection rules (RFC 6724) as they require that A and AAAA lookups succeeding and are intended to move traffic to using IPv6 as a transport if it is available. 50ms is doesn't even allow for speed-of-light responses from the other side of the world to arrive or is the IETF demanding that every zone be served by commercial DNS hosters that have multiple points of presence on every continent on the planet. At the moment you are measuring if there is a cached A/AAAA response or not. It's not that asynchronous is too hard. It's that it results in bad behaviour with the timers presented here. Its speed vs correctness with no reasonable delay to allow for a correct response to arrive. Do we want traffic to move to IPv6 by default or the absolute fastest connections possible? You can't have both. Mark In message , Fred Baker writes: > To my knowledge, the chairs have not asserted a consensus. > > > On Aug 10, 2017, at 11:13 AM, wrote: > > > > At Tue, 08 Aug 2017 10:06:12 -0700, > > David Schinazi wrote: > > > >> Most of your comments were regarding asynchronous DNS, which I believe > >> the working group has reached rough consensus on. While there is still > a > >> vocal minority advocating that asynchronous DNS is "too hard", those > >> implementations are free to only implement Happy Eyeballs v1. The > chairs > >> should correct me if they disagree, but I feel the working group > overall > >> agrees that the benefits of asynchronous DNS are worth it. > > > > Hmm, if the wg has reached consensus on the use of a MUST for > > asynchronous DNS, I'm not opposed to it myself. I thought it was > > still open: as far as I remember I've not seen a declaration of the > > consensus in this list, and I can't see it in the Prague minutes: > > https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops > > (and I wasn't there or didn't participate in it remotely). And, while > > I personally don't have a strong opinion on the matter itself, I tend > > to agree with those opposing to it in that a MUST sounds too strong. > > But, again, if we've already reached a consensus on it that I have > > simply overlooked, that's fine. > > > > -- > > JINMEI, Tatuya > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 10 21:16:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E57913243D for ; Thu, 10 Aug 2017 21:16:42 -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=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 PUeSNnpZRqEa for ; Thu, 10 Aug 2017 21:16:39 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 A07051321CE for ; Thu, 10 Aug 2017 21:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502424998; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vDGKIleFTXxK4ZrJkd7DJjO44yGTnWT7Mb/cBgBgo8k=; b=gxhQsb0WwyN3OoUDD7XxC97jHo7lBwUeR+z48OQgjoJW1JFk6EsxXLcPUfUnYoRS KfeOidhIcji8F1UgJ99ycWt7Sy0xNI/FkKF3cVffdVoDCJ1gmjzbK4IaNwbQ1XF6 /vuuz6/97csDUul2mOjEd0nwcv8Hunr6HaIzozXmowOQ70wtljusKxIweKmzck+H t4bHcSBvYhivW3lq8hA7u9HjdNPvI7tgPTzURKIggpxjb12nQoQGQYBT6dVSaBP0 n4yztpdp/4pF/0dfdLJx5sz9jTR4nfVdRtUxyMU6w5P1cbWM08E25BR+GJzqYX2g n6L5eYactXRUF5uzPlCi4w==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 57.F8.07017.5AF2D895; Thu, 10 Aug 2017 21:16:38 -0700 (PDT) X-AuditID: 11ab0215-43f899c000001b69-96-598d2fa55891 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay8.apple.com (Apple SCV relay) with SMTP id 40.F9.06978.5AF2D895; Thu, 10 Aug 2017 21:16:37 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_x5jcefJPlaDbDKiXlZTu6Q)" Received: from [17.234.82.182] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUI0099M6JN5F70@nwk-mmpp-sz10.apple.com>; Thu, 10 Aug 2017 21:16:37 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> Date: Thu, 10 Aug 2017 21:16:34 -0700 In-reply-to: <20170811014229.747B98208B3C@rock.dv.isc.org> Cc: Fred Baker , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= To: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FCYprtMvzfSYM15KYvbXxtYLRbtPsBm ceXFfRaL08f2MjuweOycdZfdY8mSn0weDx6/Y/bY+/QYWwBLFJdNSmpOZllqkb5dAlfG2vOP mQpOfGSs2Hj6EFsD455LjF2MnBwSAiYSLydPZOli5OIQEljLJHFm9TOgBAdY4tzjEoj4IUaJ Sf8es4E08AoISvyYfI8FxGYWCJN4sbeLDaLoK6NE59LJTCDNwgISEpv3JILUsAmoSBz/toEZ otdGYm//D7A5wgIaEk+fLWcCsVkEVCXWrjvBAtLKKWAlcX+7MshIZoEGRont53tZQWpEBBQk 2t6+YoLYdYxZYs6eU1CHykos/RMCEpcQeM0m0Xmtn2UCo9AsJLfOQnIrhK0l8f1RK1CcA8iW lzh4XhYirCnx7N4ndghbW+LJuwusCxjZVjEK5yZm5uhm5hkZ6iUWFOSk6iXn525iBMXNaibR HYzzXxkeYhTgYFTi4fU41BMpxJpYVlyZe4hRmoNFSZzX6BFQSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA6PGL+s9AopF3BnH/924mmx4WSXjcp7cblOv/Uwt/tc3nr8rNr9acMKGB68ddBbU e8R2njT6W8aUKmkQbWUSFbxOl1Ww52+ByHSvZ/YV7ceXyAZ90ApTfSHrtsA+rCC0eTfrf/3j VycFRp7kWePtGdh502sDd2i/zEH1E1vz8j59XD1fUTz8phJLcUaioRZzUXEiAFPD+ux8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUi2FBcpbtUvzfSYPIsA4vbXxtYLRbtPsBm ceXFfRaL08f2MjuweOycdZfdY8mSn0weDx6/Y/bY+/QYWwBLFJdNSmpOZllqkb5dAlfG2vOP mQpOfGSs2Hj6EFsD455LjF2MHBwSAiYS5x6XdDFycQgJHGKUmPTvMVsXIycHr4CgxI/J91hA bGaBMIkXe7vYIIq+Mkp0Lp3MBNIsLCAhsXlPIkgNm4CKxPFvG5ghem0k9vb/AJsjLKAh8fTZ ciYQm0VAVWLtuhMsIK2cAlYS97crg4xkFmhglNh+vpcVpEZEQEGi7e0rJohdx5gl5uw5BXWo rMTSPyETGPlnITlvFpLzIGwtie+PWoHiHEC2vMTB87IQYU2JZ/c+sUPY2hJP3l1gXcDItopR oCg1J7HSQi+xoCAnVS85P3cTIzjIC9N2MDYttzrEKMDBqMTD63GoJ1KINbGsuDIXGEYczEoi vDaivZFCvCmJlVWpRfnxRaU5qcWHGCcyAj05kVlKNDkfGIN5JfGGJiYGJsbGZsbG5ibmtBRW Eued3tEdKSSQnliSmp2aWpBaBHMUEwenVANjWeGayT0pUXkbT6+rn3puDvumfeK7pc7zBpat K6p5eDk3hUPrY274ercVlj9tStol1Dc1cez4YOt24dBGH6X2pDi3e8kRLSvn7z1zlNlQevmu dy/StLTSNCv6/krU3d/zdemjnYtML/+ZrMtrpi21mtvYSOCqY+2uHz3rj11vWbPefh9T9Zki JZbijERDLeai4kQAfNpu4eUCAAA= Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 04:16:42 -0000 --Boundary_(ID_x5jcefJPlaDbDKiXlZTu6Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Mark, I'd like to clarify the role of the 50ms delay. This is not a delay from the beginning of the DNS query, but a delay from when the A record returns, and when the AAAA record later comes back. There should not be a significant difference in the query response time between A and AAAA generally, which is why the delay is short. The only time cached results would come into play is if only one family is cached, and not the other. There are essentially three options with regards to when you start a TCP connection after sending the DNS queries: 1. Start the first TCP connection immediately upon receiving the first DNS response. Downside here is that if A comes back 2 milliseconds or so before the AAAA, you've biased towards IPv4 for no good reason. 2. Start the first TCP connection after a grace period delay after receiving the first DNS response (we recommend 50 ms). This guarantees that you never wait beyond the delay before trying some connection, but you also won't bias towards IPv4 for just a couple milliseconds. 3. Start the first TCP connection after receiving both A and AAAA always. This is the synchronous DNS option that was used previously, which means that if there is an error with one response, you have the penalty of waiting a very long time. I think that (2) is the best option both for user experience and for the promotion of IPv6. We can certainly try to have both, at least! The timer values may need to be tuned in the future, but in our measurements, the 50ms window is the right tradeoff on the current Internet. Thanks, Tommy > On Aug 10, 2017, at 6:42 PM, Mark Andrews wrote: > > > It breaks address selection rules (RFC 6724) as they require that > A and AAAA lookups succeeding and are intended to move traffic to > using IPv6 as a transport if it is available. > > 50ms is doesn't even allow for speed-of-light responses from the > other side of the world to arrive or is the IETF demanding that > every zone be served by commercial DNS hosters that have multiple > points of presence on every continent on the planet. At the moment > you are measuring if there is a cached A/AAAA response or not. > > It's not that asynchronous is too hard. It's that it results in > bad behaviour with the timers presented here. Its speed vs correctness > with no reasonable delay to allow for a correct response to arrive. > > Do we want traffic to move to IPv6 by default or the absolute fastest > connections possible? You can't have both. > > Mark > > In message >, Fred Baker writes: >> To my knowledge, the chairs have not asserted a consensus. >> >>> On Aug 10, 2017, at 11:13 AM, > wrote: >>> >>> At Tue, 08 Aug 2017 10:06:12 -0700, >>> David Schinazi wrote: >>> >>>> Most of your comments were regarding asynchronous DNS, which I believe >>>> the working group has reached rough consensus on. While there is still >> a >>>> vocal minority advocating that asynchronous DNS is "too hard", those >>>> implementations are free to only implement Happy Eyeballs v1. The >> chairs >>>> should correct me if they disagree, but I feel the working group >> overall >>>> agrees that the benefits of asynchronous DNS are worth it. >>> >>> Hmm, if the wg has reached consensus on the use of a MUST for >>> asynchronous DNS, I'm not opposed to it myself. I thought it was >>> still open: as far as I remember I've not seen a declaration of the >>> consensus in this list, and I can't see it in the Prague minutes: >>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops >>> (and I wasn't there or didn't participate in it remotely). And, while >>> I personally don't have a strong opinion on the matter itself, I tend >>> to agree with those opposing to it in that a MUST sounds too strong. >>> But, again, if we've already reached a consensus on it that I have >>> simply overlooked, that's fine. >>> >>> -- >>> JINMEI, Tatuya >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_x5jcefJPlaDbDKiXlZTu6Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Mark,

I'd like to = clarify the role of the 50ms delay. This is not a delay from the = beginning of the DNS query, but a delay from when the A record returns, = and when the AAAA record later comes back. There should not be a = significant difference in the query response time between A and AAAA = generally, which is why the delay is short. The only time cached results = would come into play is if only one family is cached, and not the = other.

There = are essentially three options with regards to when you start a TCP = connection after sending the DNS queries:

1. Start the first TCP connection = immediately upon receiving the first DNS response. Downside here is that = if A comes back 2 milliseconds or so before the AAAA, you've biased = towards IPv4 for no good reason.
2. Start the first = TCP connection after a grace period delay after receiving the first DNS = response (we recommend 50 ms). This guarantees that you never wait = beyond the delay before trying some connection, but you also won't bias = towards IPv4 for just a couple milliseconds.
3. = Start the first TCP connection after receiving both A and AAAA always. = This is the synchronous DNS option that was used previously, which means = that if there is an error with one response, you have the penalty of = waiting a very long time.

I think that (2) is the best option both for user experience = and for the promotion of IPv6. We can certainly try to have both, at = least! The timer values may need to be tuned in the future, but in our = measurements, the 50ms window is the right tradeoff on the current = Internet.

Thanks,
Tommy

On Aug 10, 2017, at 6:42 PM, Mark Andrews <marka@isc.org> = wrote:


It breaks address selection rules (RFC =  6724) as they require that
A and AAAA lookups succeeding = and are intended to move traffic to
using IPv6 as a transport if it = is available.

50ms is doesn't even allow for = speed-of-light responses from the
other side of the world to = arrive or is the IETF demanding that
every zone be served by = commercial DNS hosters that have multiple
points of presence on every = continent on the planet.  At the moment
you are measuring if there is a cached A/AAAA = response or not.

It's not that asynchronous is = too hard.  It's that it results in
bad behaviour with the timers = presented here.  Its speed vs correctness
with no reasonable delay to allow for a correct = response to arrive.

Do we want traffic to move to IPv6 by default or = the absolute fastest
connections possible?  You = can't have both.

Mark
In message <BBD427A9-C97A-46F8-8F72-F5DE8457FB44@gmail.com>, Fred Baker = writes:
To my knowledge, the chairs have not asserted a consensus.

On Aug = 10, 2017, at 11:13 AM,  <jinmei@wide.ad.jp> wrote:

At Tue, 08 Aug 2017 10:06:12 -0700,
David = Schinazi <dschinazi@apple.com> wrote:

Most of your comments = were regarding asynchronous DNS, which I believe
the = working group has reached rough consensus on. While there is still
a
vocal = minority advocating that asynchronous DNS is "too hard", those
implementations are free to only implement Happy Eyeballs v1. = The
chairs
should correct me if they disagree, but I feel the working = group
overall
agrees that the benefits of asynchronous DNS are worth it.

Hmm, if the wg has reached = consensus on the use of a MUST for
asynchronous DNS, I'm = not opposed to it myself.  I thought it was
still = open: as far as I remember I've not seen a declaration of the
consensus in this list, and I can't see it in the Prague = minutes:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6= ops
(and I wasn't there or didn't participate in it = remotely).  And, while
I personally don't have a = strong opinion on the matter itself, I tend
to agree with = those opposing to it in that a MUST sounds too strong.
But, = again, if we've already reached a consensus on it that I have
simply overlooked, that's fine.

--
JINMEI, Tatuya

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, = NSW 2117, Australia
PHONE: +61 2 9871 4742 =             &n= bsp;   INTERNET: marka@isc.org
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Boundary_(ID_x5jcefJPlaDbDKiXlZTu6Q)-- From nobody Thu Aug 10 22:59:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464D21324D5 for ; Thu, 10 Aug 2017 22:59:00 -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 1jVc-BlMpD52 for ; Thu, 10 Aug 2017 22:58:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4731324D4 for ; Thu, 10 Aug 2017 22:58:58 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id BA2E324BA75; Fri, 11 Aug 2017 05:57:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 56A03160041; Fri, 11 Aug 2017 05:57:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4442916004A; Fri, 11 Aug 2017 05:57:38 +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 u5Xoy-wkMeoy; Fri, 11 Aug 2017 05:57:38 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E500B160041; Fri, 11 Aug 2017 05:57:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C543A82149BB; Fri, 11 Aug 2017 15:57:35 +1000 (AEST) To: Tommy Pauly Cc: Fred Baker , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> In-reply-to: Your message of "Thu, 10 Aug 2017 21:16:34 -0700." <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> Date: Fri, 11 Aug 2017 15:57:35 +1000 Message-Id: <20170811055735.C543A82149BB@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 05:59:00 -0000 In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com>, Tommy Pauly writes : > > Hi Mark, > > I'd like to clarify the role of the 50ms delay. This is not a delay from > the beginning of the DNS query, but a delay from when the A record returns, > and when the AAAA record later comes back. There should not be a significant > difference in the query response time between A and AAAA generally, which > is why the delay is short. The only time cached results would come into > play is if only one family is cached, and not the other. Which happens all the time. Negative responses have different TTLs to positive responses almost all the time so they leave the cache at different times. Also if you have a mix of IPv4 only clients and dual stack clients talking to a common resolver the A/AAAA records when both are present become unsyncronised even if they are published with the same TTL. With lossless DNS we should be picking IPv6 connections all the time. 50 ms won't achieve that. Somewhere up around 250ms might. Really small amounts of IPv4 traffic will stop people turning off IPv4. They won't investigate to see if the IPv4 traffic could have been served by IPv6. Picking IPv4 when there is IPv6 because a DNS transaction was lost is acceptable. It shouldn't happen if the wasn't a lost transaction. > There are essentially three options with regards to when you start a TCP > connection after sending the DNS queries: > > 1. Start the first TCP connection immediately upon receiving the first > DNS response. Downside here is that if A comes back 2 milliseconds or > so before the AAAA, you've biased towards IPv4 for no good reason. > 2. Start the first TCP connection after a grace period delay after > receiving the first DNS response (we recommend 50 ms). This guarantees > that you never wait beyond the delay before trying some connection, but > you also won't bias towards IPv4 for just a couple milliseconds. > 3. Start the first TCP connection after receiving both A and AAAA always. > This is the synchronous DNS option that was used previously, which means > that if there is an error with one response, you have the penalty of > waiting a very long time. > > I think that (2) is the best option both for user experience and for > the promotion of IPv6. We can certainly try to have both, at least! The > timer values may need to be tuned in the future, but in our measurements, > the 50ms window is the right tradeoff on the current Internet. > > Thanks, > Tommy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 10 23:23:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76224131D22 for ; Thu, 10 Aug 2017 23:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUwwnwt7yoUn for ; Thu, 10 Aug 2017 23:22:58 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFEB132517 for ; Thu, 10 Aug 2017 23:22:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 32C8CA2; Fri, 11 Aug 2017 08:22:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502432575; bh=KJH5Js0lgWy0PWvCP32J/OaVwPUaC3utORP9PyrWH+Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ItkbzIm45MleUDQEOGib8aXrXf6ojFqNmv7P7d8YksFQAawNdl/kOR2bRwc12dZa1 ZRcYqfa/aFOUOFOSCqB0RWB7tZ4NsHATMcFCXcnjZeTJU4DndyVYQCzqhwgqVQtad8 ITepbeosM0MTq/3tJLVZm4ZS0haLeK7uDUZdStIg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 30D19A1; Fri, 11 Aug 2017 08:22:55 +0200 (CEST) Date: Fri, 11 Aug 2017 08:22:55 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: Tommy Pauly , "v6ops@ietf.org" In-Reply-To: <20170811055735.C543A82149BB@rock.dv.isc.org> Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 06:22:59 -0000 On Fri, 11 Aug 2017, Mark Andrews wrote: > With lossless DNS we should be picking IPv6 connections all the time. > 50 ms won't achieve that. Somewhere up around 250ms might. Really small > amounts of IPv4 traffic will stop people turning off IPv4. They won't > investigate to see if the IPv4 traffic could have been served by IPv6. > > Picking IPv4 when there is IPv6 because a DNS transaction was lost is > acceptable. It shouldn't happen if the wasn't a lost transaction. I think this is premature. Apple started with 0ms IPv6 head start, then from what I understand, gathered data, then decided 50ms would not hurt customer experience. I would fully expect that in 3-5 years we will have a new document that says "look, now there is so much IPv6 out there and it works so well, that 250ms is a great value". It could even be 500ms. Or 2 seconds, using the 6555bis value for "Last Resort Local Synthesis Delay". But doing 250ms today is premature in my opinion. 50ms will give IPv6 enough of a head start for now. There is enough broken AAAA pointers out there still yet. People won't turn off IPv4 for services in the next 3-5 years anyway. I believe I saw numbers before that with 50ms head start for IPv6, the connection rate over IPv6 was in the 95% or more range? I can't find it now however. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Aug 11 06:42:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C494F126C7A for ; Fri, 11 Aug 2017 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSAR6iyzjhh9 for ; Fri, 11 Aug 2017 06:42:04 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1515E132461 for ; Fri, 11 Aug 2017 06:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502458920; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=KnPeQUX8D7zehhhbgHrgr2fQEFdBZPbV9BCICxPDk4w=; b=VcqGKOPTXUipj1gDGdn+PzbuEOOt1wh+W7+7qTSkoLFHebkKK01FA/rjaOnOdRc49DDXutvaKFA+2TtuboWRdn+D13Tg+HMkwdTJTzwQPgNqZClgPARzJ0DXL4W4GokqFtVI5uygggvg9nLd5QOfMUq6B03NXT2GEUldxbWPFm0= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0150.outbound.protection.outlook.com [213.199.154.150]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-131-CkznTredM2u8YKrT1JMDsA-1; Fri, 11 Aug 2017 14:41:55 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0727.eurprd07.prod.outlook.com (10.160.6.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Fri, 11 Aug 2017 13:41:54 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.01.1341.013; Fri, 11 Aug 2017 13:41:54 +0000 From: Tim Chown To: Tommy Pauly CC: Mark Andrews , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] WGLC for RFC6555bis Thread-Index: AQHTEGMuGjHH5vjCHk+2sKtTDeVJZqJ6sH8AgAM3jQCAABsNgIAAYn1EgAAq3wCAAJ3zgA== Date: Fri, 11 Aug 2017 13:41:54 +0000 Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> In-Reply-To: <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [212.188.254.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0727; 20:QSlSSkfwJEKAnNhmPNmqyqEZfh7m6vQyI0CgsxJlsRVRPb6AVBKGeXbvgFVYU3kUPmw7Ur0rKbWo4DeNA/BdROdjl13ZQ47SMDbOmOAOuWnIUIQnQqt4b28Vj3oOFUC5ItSROHWsfMWrsD423SuQIXchy9gxNawHsxoMh7tjPTM= x-ms-office365-filtering-correlation-id: 2f4e9e30-8587-415b-9db8-08d4e0beba5d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0727; x-ms-traffictypediagnostic: AM3PR07MB0727: x-exchange-antispam-report-test: UriScan:(80524489315369)(120809045254105)(100405760836317)(31960201722614); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0727; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0727; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377454003)(189002)(24454002)(51444003)(53546010)(110136004)(189998001)(72206003)(99286003)(8666007)(83716003)(14454004)(54906002)(106356001)(2906002)(2900100001)(3280700002)(105586002)(3660700001)(966005)(5660300001)(4326008)(102836003)(6116002)(3846002)(25786009)(36756003)(53936002)(6246003)(86362001)(6512007)(6306002)(97736004)(478600001)(76176999)(101416001)(68736007)(229853002)(50986999)(66066001)(6436002)(82746002)(6486002)(50226002)(42882006)(81166006)(8936002)(81156014)(305945005)(6916009)(7736002)(33656002)(8676002)(93886004)(6506006)(57306001)(5250100002)(2950100002)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0727; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <76F62C76482A704699C462BBB83998B6@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 13:41:54.0562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0727 X-MC-Unique: CkznTredM2u8YKrT1JMDsA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:42:09 -0000 SGksDQoNCj4gT24gMTEgQXVnIDIwMTcsIGF0IDA1OjE2LCBUb21teSBQYXVseSA8dHBhdWx5QGFw cGxlLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBNYXJrLA0KPiANCj4gSSdkIGxpa2UgdG8gY2xhcmlm eSB0aGUgcm9sZSBvZiB0aGUgNTBtcyBkZWxheS4gVGhpcyBpcyBub3QgYSBkZWxheSBmcm9tIHRo ZSBiZWdpbm5pbmcgb2YgdGhlIEROUyBxdWVyeSwgYnV0IGEgZGVsYXkgZnJvbSB3aGVuIHRoZSBB IHJlY29yZCByZXR1cm5zLCBhbmQgd2hlbiB0aGUgQUFBQSByZWNvcmQgbGF0ZXIgY29tZXMgYmFj ay4gVGhlcmUgc2hvdWxkIG5vdCBiZSBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgaW4gdGhlIHF1 ZXJ5IHJlc3BvbnNlIHRpbWUgYmV0d2VlbiBBIGFuZCBBQUFBIGdlbmVyYWxseSwgd2hpY2ggaXMg d2h5IHRoZSBkZWxheSBpcyBzaG9ydC4gVGhlIG9ubHkgdGltZSBjYWNoZWQgcmVzdWx0cyB3b3Vs ZCBjb21lIGludG8gcGxheSBpcyBpZiBvbmx5IG9uZSBmYW1pbHkgaXMgY2FjaGVkLCBhbmQgbm90 IHRoZSBvdGhlci4NCj4gDQo+IFRoZXJlIGFyZSBlc3NlbnRpYWxseSB0aHJlZSBvcHRpb25zIHdp dGggcmVnYXJkcyB0byB3aGVuIHlvdSBzdGFydCBhIFRDUCBjb25uZWN0aW9uIGFmdGVyIHNlbmRp bmcgdGhlIEROUyBxdWVyaWVzOg0KPiANCj4gMS4gU3RhcnQgdGhlIGZpcnN0IFRDUCBjb25uZWN0 aW9uIGltbWVkaWF0ZWx5IHVwb24gcmVjZWl2aW5nIHRoZSBmaXJzdCBETlMgcmVzcG9uc2UuIERv d25zaWRlIGhlcmUgaXMgdGhhdCBpZiBBIGNvbWVzIGJhY2sgMiBtaWxsaXNlY29uZHMgb3Igc28g YmVmb3JlIHRoZSBBQUFBLCB5b3UndmUgYmlhc2VkIHRvd2FyZHMgSVB2NCBmb3Igbm8gZ29vZCBy ZWFzb24uDQo+IDIuIFN0YXJ0IHRoZSBmaXJzdCBUQ1AgY29ubmVjdGlvbiBhZnRlciBhIGdyYWNl IHBlcmlvZCBkZWxheSBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0IEROUyByZXNwb25zZSAod2Ug cmVjb21tZW5kIDUwIG1zKS4gVGhpcyBndWFyYW50ZWVzIHRoYXQgeW91IG5ldmVyIHdhaXQgYmV5 b25kIHRoZSBkZWxheSBiZWZvcmUgdHJ5aW5nIHNvbWUgY29ubmVjdGlvbiwgYnV0IHlvdSBhbHNv IHdvbid0IGJpYXMgdG93YXJkcyBJUHY0IGZvciBqdXN0IGEgY291cGxlIG1pbGxpc2Vjb25kcy4N Cj4gMy4gU3RhcnQgdGhlIGZpcnN0IFRDUCBjb25uZWN0aW9uIGFmdGVyIHJlY2VpdmluZyBib3Ro IEEgYW5kIEFBQUEgYWx3YXlzLiBUaGlzIGlzIHRoZSBzeW5jaHJvbm91cyBETlMgb3B0aW9uIHRo YXQgd2FzIHVzZWQgcHJldmlvdXNseSwgd2hpY2ggbWVhbnMgdGhhdCBpZiB0aGVyZSBpcyBhbiBl cnJvciB3aXRoIG9uZSByZXNwb25zZSwgeW91IGhhdmUgdGhlIHBlbmFsdHkgb2Ygd2FpdGluZyBh IHZlcnkgbG9uZyB0aW1lLg0KPiANCj4gSSB0aGluayB0aGF0ICgyKSBpcyB0aGUgYmVzdCBvcHRp b24gYm90aCBmb3IgdXNlciBleHBlcmllbmNlIGFuZCBmb3IgdGhlIHByb21vdGlvbiBvZiBJUHY2 LiBXZSBjYW4gY2VydGFpbmx5IHRyeSB0byBoYXZlIGJvdGgsIGF0IGxlYXN0ISBUaGUgdGltZXIg dmFsdWVzIG1heSBuZWVkIHRvIGJlIHR1bmVkIGluIHRoZSBmdXR1cmUsIGJ1dCBpbiBvdXIgbWVh c3VyZW1lbnRzLCB0aGUgNTBtcyB3aW5kb3cgaXMgdGhlIHJpZ2h0IHRyYWRlb2ZmIG9uIHRoZSBj dXJyZW50IEludGVybmV0Lg0KDQpJIGFncmVlICgyKSBzZWVtcyByZWFzb25hYmxlLg0KDQpJdOKA mXMgYSBoYWNrLCBidXQgYXMgZWxlZ2FudC9nb29kIGEgb25lIHRoYXQgd2UgY291bGQgcmVhc29u YWJseSB1c2UgcmlnaHQgbm93LiAgSXQgaW1wcm92ZXMgb24gdGhlIGN1cnJlbnQgUkZDNjU1NSBi ZWhhdmlvdXIuDQoNCk9uIGNsYXJpZnlpbmcgdGhlIHJlbGF0aW9uc2hpcCB0byBSRkM2NzI0LCBz ZWN0aW9uIDQgZG9lcyBhbHJlYWR5IG1lbnRpb24gaXQsIGJ1dCBwZXJoYXBzIHRoZSBzY29wZSBv ZiBIRTIgY2FuIGJlIGNsZWFyZXIgaW4gdGhlIGludHJvZHVjdGlvbi4gIEFsc28sIHVzaW5nIHRo ZSB3b3JkIOKAmGRlc3RpbmF0aW9u4oCZIG1vcmUgaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRyb2R1 Y3Rpb24gbWF5IGhlbHAgdG9vLg0KDQpJdCB3YXMgZ29vZCB0byBzZWUgcHJlc2VudGF0aW9ucyBh dCBQcmFndWUgb24gdGhlIGltcGFjdCBvZiB0aW1lcnMsIGFuZC9vciBzdWdnZXN0ZWQgY2hhbmdl cyBmb3IgdGhlbS4NCg0KSSBzdXBwb3J0IGl0cyBwdWJsaWNhdGlvbi4NCg0KVGltDQoNCj4+IE9u IEF1ZyAxMCwgMjAxNywgYXQgNjo0MiBQTSwgTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPiB3 cm90ZToNCj4+IA0KPj4gDQo+PiBJdCBicmVha3MgYWRkcmVzcyBzZWxlY3Rpb24gcnVsZXMgKFJG QyAgNjcyNCkgYXMgdGhleSByZXF1aXJlIHRoYXQNCj4+IEEgYW5kIEFBQUEgbG9va3VwcyBzdWNj ZWVkaW5nIGFuZCBhcmUgaW50ZW5kZWQgdG8gbW92ZSB0cmFmZmljIHRvDQo+PiB1c2luZyBJUHY2 IGFzIGEgdHJhbnNwb3J0IGlmIGl0IGlzIGF2YWlsYWJsZS4NCj4+IA0KPj4gNTBtcyBpcyBkb2Vz bid0IGV2ZW4gYWxsb3cgZm9yIHNwZWVkLW9mLWxpZ2h0IHJlc3BvbnNlcyBmcm9tIHRoZQ0KPj4g b3RoZXIgc2lkZSBvZiB0aGUgd29ybGQgdG8gYXJyaXZlIG9yIGlzIHRoZSBJRVRGIGRlbWFuZGlu ZyB0aGF0DQo+PiBldmVyeSB6b25lIGJlIHNlcnZlZCBieSBjb21tZXJjaWFsIEROUyBob3N0ZXJz IHRoYXQgaGF2ZSBtdWx0aXBsZQ0KPj4gcG9pbnRzIG9mIHByZXNlbmNlIG9uIGV2ZXJ5IGNvbnRp bmVudCBvbiB0aGUgcGxhbmV0LiAgQXQgdGhlIG1vbWVudA0KPj4geW91IGFyZSBtZWFzdXJpbmcg aWYgdGhlcmUgaXMgYSBjYWNoZWQgQS9BQUFBIHJlc3BvbnNlIG9yIG5vdC4NCj4+IA0KPj4gSXQn cyBub3QgdGhhdCBhc3luY2hyb25vdXMgaXMgdG9vIGhhcmQuICBJdCdzIHRoYXQgaXQgcmVzdWx0 cyBpbg0KPj4gYmFkIGJlaGF2aW91ciB3aXRoIHRoZSB0aW1lcnMgcHJlc2VudGVkIGhlcmUuICBJ dHMgc3BlZWQgdnMgY29ycmVjdG5lc3MNCj4+IHdpdGggbm8gcmVhc29uYWJsZSBkZWxheSB0byBh bGxvdyBmb3IgYSBjb3JyZWN0IHJlc3BvbnNlIHRvIGFycml2ZS4NCj4+IA0KPj4gRG8gd2Ugd2Fu dCB0cmFmZmljIHRvIG1vdmUgdG8gSVB2NiBieSBkZWZhdWx0IG9yIHRoZSBhYnNvbHV0ZSBmYXN0 ZXN0DQo+PiBjb25uZWN0aW9ucyBwb3NzaWJsZT8gIFlvdSBjYW4ndCBoYXZlIGJvdGguDQo+PiAN Cj4+IE1hcmsNCj4+IA0KPj4gSW4gbWVzc2FnZSA8QkJENDI3QTktQzk3QS00NkY4LThGNzItRjVE RTg0NTdGQjQ0QGdtYWlsLmNvbT4sIEZyZWQgQmFrZXIgd3JpdGVzOg0KPj4+IFRvIG15IGtub3ds ZWRnZSwgdGhlIGNoYWlycyBoYXZlIG5vdCBhc3NlcnRlZCBhIGNvbnNlbnN1cy4NCj4+PiANCj4+ Pj4gT24gQXVnIDEwLCAyMDE3LCBhdCAxMToxMyBBTSwgIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3Jv dGU6DQo+Pj4+IA0KPj4+PiBBdCBUdWUsIDA4IEF1ZyAyMDE3IDEwOjA2OjEyIC0wNzAwLA0KPj4+ PiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+ Pj4gTW9zdCBvZiB5b3VyIGNvbW1lbnRzIHdlcmUgcmVnYXJkaW5nIGFzeW5jaHJvbm91cyBETlMs IHdoaWNoIEkgYmVsaWV2ZQ0KPj4+Pj4gdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHJlYWNoZWQgcm91 Z2ggY29uc2Vuc3VzIG9uLiBXaGlsZSB0aGVyZSBpcyBzdGlsbA0KPj4+IGENCj4+Pj4+IHZvY2Fs IG1pbm9yaXR5IGFkdm9jYXRpbmcgdGhhdCBhc3luY2hyb25vdXMgRE5TIGlzICJ0b28gaGFyZCIs IHRob3NlDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgYXJlIGZyZWUgdG8gb25seSBpbXBsZW1lbnQg SGFwcHkgRXllYmFsbHMgdjEuIFRoZQ0KPj4+IGNoYWlycw0KPj4+Pj4gc2hvdWxkIGNvcnJlY3Qg bWUgaWYgdGhleSBkaXNhZ3JlZSwgYnV0IEkgZmVlbCB0aGUgd29ya2luZyBncm91cA0KPj4+IG92 ZXJhbGwNCj4+Pj4+IGFncmVlcyB0aGF0IHRoZSBiZW5lZml0cyBvZiBhc3luY2hyb25vdXMgRE5T IGFyZSB3b3J0aCBpdC4NCj4+Pj4gDQo+Pj4+IEhtbSwgaWYgdGhlIHdnIGhhcyByZWFjaGVkIGNv bnNlbnN1cyBvbiB0aGUgdXNlIG9mIGEgTVVTVCBmb3INCj4+Pj4gYXN5bmNocm9ub3VzIEROUywg SSdtIG5vdCBvcHBvc2VkIHRvIGl0IG15c2VsZi4gIEkgdGhvdWdodCBpdCB3YXMNCj4+Pj4gc3Rp bGwgb3BlbjogYXMgZmFyIGFzIEkgcmVtZW1iZXIgSSd2ZSBub3Qgc2VlbiBhIGRlY2xhcmF0aW9u IG9mIHRoZQ0KPj4+PiBjb25zZW5zdXMgaW4gdGhpcyBsaXN0LCBhbmQgSSBjYW4ndCBzZWUgaXQg aW4gdGhlIFByYWd1ZSBtaW51dGVzOg0KPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvOTkvbWF0ZXJpYWxzL21pbnV0ZXMtOTktdjZvcHMNCj4+Pj4gKGFuZCBJIHdhc24n dCB0aGVyZSBvciBkaWRuJ3QgcGFydGljaXBhdGUgaW4gaXQgcmVtb3RlbHkpLiAgQW5kLCB3aGls ZQ0KPj4+PiBJIHBlcnNvbmFsbHkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHRoZSBt YXR0ZXIgaXRzZWxmLCBJIHRlbmQNCj4+Pj4gdG8gYWdyZWUgd2l0aCB0aG9zZSBvcHBvc2luZyB0 byBpdCBpbiB0aGF0IGEgTVVTVCBzb3VuZHMgdG9vIHN0cm9uZy4NCj4+Pj4gQnV0LCBhZ2Fpbiwg aWYgd2UndmUgYWxyZWFkeSByZWFjaGVkIGEgY29uc2Vuc3VzIG9uIGl0IHRoYXQgSSBoYXZlDQo+ Pj4+IHNpbXBseSBvdmVybG9va2VkLCB0aGF0J3MgZmluZS4NCj4+Pj4gDQo+Pj4+IC0tDQo+Pj4+ IEpJTk1FSSwgVGF0dXlhDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+Pj4gdjZvcHNA aWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+Pj4gdjZvcHNAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiANCj4+IC0tIA0KPj4g TWFyayBBbmRyZXdzLCBJU0MNCj4+IDEgU2V5bW91ciBTdC4sIER1bmRhcyBWYWxsZXksIE5TVyAy MTE3LCBBdXN0cmFsaWENCj4+IFBIT05FOiArNjEgMiA5ODcxIDQ3NDIgICAgICAgICAgICAgICAg IElOVEVSTkVUOiBtYXJrYUBpc2Mub3JnDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3Bz QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Fri Aug 11 10:19:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01B1321C1 for ; Fri, 11 Aug 2017 10:19:27 -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=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 6-71C4e6Z66r for ; Fri, 11 Aug 2017 10:19:25 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 28F271321AE for ; Fri, 11 Aug 2017 10:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502471965; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JabmNHCNMwd0TMndH24MmG6dJTTWeQV5uYPvt32PLwE=; b=xrCEFSA0cpaPaLmEhU3gzYBQ9e6/WrBrYa/6gpg3L4E3G7VIHHDOS1S/xI0U+txh 0icI0Ec5G1LUV9NjMNW4/k4VbniB0NnmKknEyI0smCnPESYp8SbU+wPbtGMU22xV 04gDSdwZWSUVj8mtlIPhFGmY9/SFPmFFhrUIWekEUtddPRnHNigkYQ7TDKIVFLGv rmVfyqMz2qtTkX5mt/nK9ntJGw+CzN0E/+fwyn9qBqZTDwS3Zi2FYS8NmRnDkjIq AmU32SD742qtD5nLT/I8FgtKFMa3OqexAvddBHEFGk4AYDtDsNaL8OIBHmmV4uou uox0x7AhQ/onGwVZQVpLrg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 03.FC.06336.C17ED895; Fri, 11 Aug 2017 10:19:24 -0700 (PDT) X-AuditID: 11973e12-0ffd89c0000018c0-44-598de71c1036 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay6.apple.com (Apple SCV relay) with SMTP id 0C.45.24226.C17ED895; Fri, 11 Aug 2017 10:19:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7atn8NqBNF/bLG7+tXDokw)" Received: from [17.114.152.107] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUJ0025P6SC0P10@nwk-mmpp-sz13.apple.com>; Fri, 11 Aug 2017 10:19:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> Date: Fri, 11 Aug 2017 10:19:23 -0700 In-reply-to: <20170811055735.C543A82149BB@rock.dv.isc.org> Cc: Fred Baker , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= To: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FAYpSvzvDfSYPYBG4vbXxtYLRbtPsBm ceXFfRaL08f2MjuweOycdZfdY8mSn0weDx6/Y/bY+/QYWwBLFJdNSmpOZllqkb5dAlfG3rZZ jAXbbjJW3OjqYG1g3L2bsYuRk0NCwERi/uanzF2MXBxCAquZJE5c7GOGSaybc4odInGIUWLD 1eUsIAleAUGJH5PvgdnMAmESPw99ZIMo+sYoMffDHqAEB4ewgITE5j2JIDVsAioSx79tYIbo tZHYsHIuK4gtLKAh8fTZciYQm0VAVeJg7302EJtTwEpi+ZX9jCAzmQUaGCW2n+8FaxARUJBo e/sKrEFIYCWLxISJaiC7JARkJZb+CQGplxA4wiax5/M75gmMQrOQ3DoLya0QtpbE90etQHEO IFte4uB5WYiwpsSze5/YIWxtiSfvLrAuYGRbxSiUm5iZo5uZZ6KXWFCQk6qXnJ+7iREUN9Pt hHYwnlpldYhRgINRiYdX4XRvpBBrYllxZe4hRmkOFiVx3hcPeyKFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MC5cf1d+iugat6pSdm6VHxnyp6bYHEoVqutV/q+nd/HT2s2qtz/mVZt8uSaa dicoZ3eYjLvo8QkN85O9qlNP3MoyW6h5zJun5YJxzwcDnUBZ8xkcbBvNnswpV9UuXlli1/Fe 7IL+5X1dsxot8qP5DeObK3/3957e/PCUtEZ4juaDmbnWF4xPKrEUZyQaajEXFScCAEyiZo18 AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FB8Q1fmeW+kQctvc4vbXxtYLRbtPsBm ceXFfRaL08f2MjuweOycdZfdY8mSn0weDx6/Y/bY+/QYWwBLFJdNSmpOZllqkb5dAlfG3rZZ jAXbbjJW3OjqYG1g3L2bsYuRk0NCwERi3ZxT7F2MXBxCAocYJTZcXc4CkuAVEJT4MfkemM0s ECbx89BHNoiib4wScz/sAUpwcAgLSEhs3pMIUsMmoCJx/NsGZoheG4kNK+eygtjCAhoST58t ZwKxWQRUJQ723mcDsTkFrCSWX9nPCDKTWaCBUWL7+V6wBhEBBYm2t6/AGoQEVrJITJioBrJL QkBWYumfkAmM/LOQnDcLyXkQtpbE90etQHEOIFte4uB5WYiwpsSze5/YIWxtiSfvLrAuYGRb xShQlJqTWGmml1hQkJOql5yfu4kRHOaFUTsYG5ZbHWIU4GBU4uGtONsbKcSaWFZcmQsMIw5m JRHe5/eAQrwpiZVVqUX58UWlOanFhxilOViUxHmndXRHCgmkJ5akZqemFqQWwWSZODilGhhd l906oJFg7B6p6fn8Om8BB282t2TzvufrJq5SPVibqHvbW3nbIbmVPj/O6sh6P90qsrQ+U04m 7PnqSpUratvsVuw1MFv7vWTWPn5Xc5Nrzy/qftfiTv766mXAm8Q7juZ2Xv9Ub9r85l1l32Le FrR6+waeFZ+6o/c/u+h+RGOG+qZs3xOTN/xVYinOSDTUYi4qTgQAzGTGsW8CAAA= Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 17:19:27 -0000 --Boundary_(ID_7atn8NqBNF/bLG7+tXDokw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Mark, The case in which one query (A) is cached locally, while the other (AAAA) needs to be fetched, should only affect a particular device's connection to a host once. Before our device makes any queries, it will either be the case that: a) No other device on the local network has made any queries for that hostname, so no answers are cached. b) A single-stack device on the local network has made an A query, so only the A answer is cached. c) A dual-stack device on the local network has made both A and AAAA queries, so both answers are cached. In cases (a) and (c), there shouldn't be any significant difference between the response times when our device makes its A and AAAA queries. The case you're concerned about is (b). While it may have been common 10 years ago have most devices on a network be single-stack, almost all consumer operating systems in recent years are dual-stack by default, so we are very rarely in case (b). If you have measured data to show otherwise, I'd love to see it! We've been running metrics for over a year on Happy Eyeballs behavior, and we see good behavior with this algorithm. When our device sends out its A and AAAA queries, even if we had fallen into the bad case of (b), the caches on the local resolver and the on-device cache will be populated with both answers once both returns. An IPv4 connection may have been established during that time, but any subsequent connections to the same hostname will benefit by the caching, and will choose IPv6 in the future. I'd like to also emphasize that the spec does say that these delay values are expected to change and be extended beyond current values in the future: "For that reason, it is expected that these values will change over time. Implementors should feel welcome to use different values without changing this specification." The main point is that the ability to have this logic, and not block on waiting for both answers, is key. If you'd like to set your implementation to use 250ms, that's fine! Thanks, Tommy > On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: > > > In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com >, Tommy Pauly writes > : >> >> Hi Mark, >> >> I'd like to clarify the role of the 50ms delay. This is not a delay from >> the beginning of the DNS query, but a delay from when the A record returns, >> and when the AAAA record later comes back. There should not be a significant >> difference in the query response time between A and AAAA generally, which >> is why the delay is short. The only time cached results would come into >> play is if only one family is cached, and not the other. > > Which happens all the time. Negative responses have different TTLs > to positive responses almost all the time so they leave the cache > at different times. Also if you have a mix of IPv4 only clients > and dual stack clients talking to a common resolver the A/AAAA > records when both are present become unsyncronised even if they are > published with the same TTL. > > With lossless DNS we should be picking IPv6 connections all the > time. 50 ms won't achieve that. Somewhere up around 250ms might. > Really small amounts of IPv4 traffic will stop people turning off > IPv4. They won't investigate to see if the IPv4 traffic could have > been served by IPv6. > > Picking IPv4 when there is IPv6 because a DNS transaction was lost > is acceptable. It shouldn't happen if the wasn't a lost transaction. > >> There are essentially three options with regards to when you start a TCP >> connection after sending the DNS queries: >> >> 1. Start the first TCP connection immediately upon receiving the first >> DNS response. Downside here is that if A comes back 2 milliseconds or >> so before the AAAA, you've biased towards IPv4 for no good reason. >> 2. Start the first TCP connection after a grace period delay after >> receiving the first DNS response (we recommend 50 ms). This guarantees >> that you never wait beyond the delay before trying some connection, but >> you also won't bias towards IPv4 for just a couple milliseconds. >> 3. Start the first TCP connection after receiving both A and AAAA always. >> This is the synchronous DNS option that was used previously, which means >> that if there is an error with one response, you have the penalty of >> waiting a very long time. >> >> I think that (2) is the best option both for user experience and for >> the promotion of IPv6. We can certainly try to have both, at least! The >> timer values may need to be tuned in the future, but in our measurements, >> the 50ms window is the right tradeoff on the current Internet. >> >> Thanks, >> Tommy > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --Boundary_(ID_7atn8NqBNF/bLG7+tXDokw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Mark,

The case in = which one query (A) is cached locally, while the other (AAAA) needs to = be fetched, should only affect a particular device's connection to a = host once. 

Before our device makes any queries, it will either be the = case that:
a) No other device on the local = network has made any queries for that hostname, so no answers are = cached.
b) A single-stack device on the = local network has made an A query, so only the A answer is = cached.
c) A dual-stack device on the = local network has made both A and AAAA queries, so both answers are = cached.

In = cases (a) and (c), there shouldn't be any significant difference between = the response times when our device makes its A and AAAA queries. The = case you're concerned about is (b). While it may have been common 10 = years ago have most devices on a network be single-stack, almost all = consumer operating systems in recent years are dual-stack by default, so = we are very rarely in case (b). If you have measured data to show = otherwise, I'd love to see it! We've been running metrics for over a = year on Happy Eyeballs behavior, and we see good behavior with this = algorithm.

When = our device sends out its A and AAAA queries, even if we had fallen into = the bad case of (b), the caches on the local resolver and the on-device = cache will be populated with both answers once both returns. An IPv4 = connection may have been established during that time, but any = subsequent connections to the same hostname will benefit by the caching, = and will choose IPv6 in the future.

I'd like to also emphasize that the = spec does say that these delay values are expected to change and be = extended beyond current values in the future: 
"For that reason, it is expected that these values will = change over time.
   Implementors should = feel welcome to use different values without
  =  changing this specification."
The main point is = that the ability to have this logic, and not block on waiting for both = answers, is key. If you'd like to set your implementation to use 250ms, = that's fine!

Thanks,
Tommy

On Aug = 10, 2017, at 10:57 PM, Mark Andrews <marka@isc.org> wrote:


In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com>, Tommy Pauly = writes
:

Hi Mark,

I'd like to clarify the role of the 50ms = delay. This is not a delay from
the beginning of the DNS = query, but a delay from when the A record returns,
and = when the AAAA record later comes back. There should not be a = significant
difference in the query response time between = A and AAAA generally, which
is why the delay is short. The = only time cached results would come into
play is if only = one family is cached, and not the other.

Which happens all the time.  Negative = responses have different TTLs
to positive responses almost all = the time so they leave the cache
at different times.  Also = if you have a mix of IPv4 only clients
and dual stack clients talking = to a common resolver the A/AAAA
records when both are present = become unsyncronised even if they are
published with the same = TTL.

With lossless DNS we should be = picking IPv6 connections all the
time.  50 ms won't achieve = that.  Somewhere up around 250ms might.
Really small amounts of IPv4 traffic will stop = people turning off
IPv4.  They won't investigate to see = if the IPv4 traffic could have
been served by IPv6.
Picking IPv4 when there is IPv6 because a DNS = transaction was lost
is acceptable.  It = shouldn't happen if the wasn't a lost transaction.
There are essentially three = options with regards to when you start a TCP
connection = after sending the DNS queries:

1. Start the = first TCP connection immediately upon receiving the first
DNS response. Downside here is that if A comes back 2 = milliseconds or
so before the AAAA, you've biased towards = IPv4 for no good reason.
2. Start the first TCP connection = after a grace period delay after
receiving the first DNS = response (we recommend 50 ms). This guarantees
that you = never wait beyond the delay before trying some connection, but
you also won't bias towards IPv4 for just a couple = milliseconds.
3. Start the first TCP connection after = receiving both A and AAAA always.
This is the synchronous = DNS option that was used previously, which means
that if = there is an error with one response, you have the penalty of
waiting a very long time.

I = think that (2) is the best option both for user experience and for
the promotion of IPv6. We can certainly try to have both, at = least! The
timer values may need to be tuned in the = future, but in our measurements,
the 50ms window is the = right tradeoff on the current Internet.

Thanks,
Tommy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, = NSW 2117, Australia
PHONE: +61 2 9871 4742 =             &n= bsp;   INTERNET: marka@isc.org

= --Boundary_(ID_7atn8NqBNF/bLG7+tXDokw)-- From nobody Fri Aug 11 11:08:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB2131EA9 for ; Fri, 11 Aug 2017 11:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ-18q1o4lol for ; Fri, 11 Aug 2017 11:08:23 -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 AED8A131E08 for ; Fri, 11 Aug 2017 11:08:23 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id p3so25393123qtg.2 for ; Fri, 11 Aug 2017 11:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EBv0dmJ1BSmtBKnjaSFZaXUqzhwzXG0aTTcdrlJmJWk=; b=ontXnXqrFSvjHj9vvNY6v+T2SvH4PsxN2YNfpzWD+PebLmLZ37SULlHo1dk42W9zkK 3gzAgK7ME2b3E7Rn7eVJ0tFZk6Y082rxkawYF+bOCdsXb3Tw4hASHqB9E4qquwuYWHab 6qiIEvjUIjxQsNOZwwDeut9NGCSpLfzACJbLcikU2j6+UkDe03LcZeiMZO31c1Eb+6o1 vbmI7Vin6M+6mIwBwuB7e7oV+4DJYM/+a7h6Xn1rZgZkihHM5fIxGnpfoLwO2v4K90H2 sR8fYfTa2tOq4CMfPlDjDHk4gHAcVoaEU067O+PjnEV3aJTkqfjaVI331853aODOuWDu hvww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EBv0dmJ1BSmtBKnjaSFZaXUqzhwzXG0aTTcdrlJmJWk=; b=hGybltHru9SZvbyQKDeuXhy8JCAvM/e4xcHpBdpoO8O6qYRTHjkWleGDIyBsSvyqpI f4j/7TKDLn5dN2VmAHOfK05Xpkj9fTY8bQ1H3N/zNfWGLuR+VlN9gibfVyhZDq7Jf8tw H5HmM/8K5TeIycCFnpNBWFZhMvf8J44CZim+Xr+VNpXAd6hCvwVEljbfKzqTPI7iIgRo J3a1JfoaDOY1vPUApUlBHLTxLTSA+TbtwcMvan0xNgXwy3HR8ZeqFOVXyJZBPlY2yiTt ZIo55WTHox9r7f+wdSYn8qiIcz4zK5m2jvAf3xHEvhrbNBLhyXQfSBHTALnbbUGv/eUp pd1g== X-Gm-Message-State: AHYfb5gqDSGUwEl8LK1A8St9aHDhzHXVP4DGArg1/f1IRjaZ9Z0rhxLP 6rn+ZBGc0lCuqqiddg7RBD6DenALNg== X-Received: by 10.200.44.212 with SMTP id 20mr23670395qtx.282.1502474902662; Fri, 11 Aug 2017 11:08:22 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 11 Aug 2017 11:08:22 -0700 (PDT) In-Reply-To: <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 11 Aug 2017 11:08:22 -0700 X-Google-Sender-Auth: g2_4O4d04mkFkUxbsUDmkf_KAL0 Message-ID: To: Tommy Pauly Cc: Mark Andrews , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 18:08:26 -0000 At Fri, 11 Aug 2017 10:19:23 -0700, Tommy Pauly wrote: > The case in which one query (A) is cached locally, while the other (AAAA) needs to be fetched, should only affect a particular device's connection to a host once. > > Before our device makes any queries, it will either be the case that: > a) No other device on the local network has made any queries for that hostname, so no answers are cached. > b) A single-stack device on the local network has made an A query, so only the A answer is cached. > c) A dual-stack device on the local network has made both A and AAAA queries, so both answers are cached. > > In cases (a) and (c), there shouldn't be any significant difference > between the response times when our device makes its A and AAAA > queries. The case you're concerned about is (b). While it may have > been common 10 years ago have most devices on a network be > single-stack, almost all consumer operating systems in recent years > are dual-stack by default, so we are very rarely in case (b). If you > have measured data to show otherwise, I'd love to see it! We've been > running metrics for over a year on Happy Eyeballs behavior, and we > see good behavior with this algorithm. Regarding measurement, I'd be curious whether you have collected statistics on ios devices to show if there's any significant difference between the AAAA TTL and the A TTL of received RRsets. If you have actual data that prove these are largely identical most of the time, it would be more convincing. -- JINMEI, Tatuya From nobody Sat Aug 12 03:50:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB56132690; Sat, 12 Aug 2017 03:50:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150253502438.26577.987884026906699315.idtracker@ietfa.amsl.com> Date: Sat, 12 Aug 2017 03:50:24 -0700 Archived-At: Subject: [v6ops] Alexey Melnikov's No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 10:50:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Radius should have an informative reference on first use. From nobody Sun Aug 13 16:31:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E4D133AC4 for ; Sun, 13 Aug 2017 16:31:50 -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 3qcXdLXPv3LJ for ; Sun, 13 Aug 2017 16:31:49 -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 19F9E133AC3 for ; Sun, 13 Aug 2017 16:31:48 -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 1681434A496; Sun, 13 Aug 2017 23:31:46 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 00C7D1600B0; Sun, 13 Aug 2017 23:31:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E35EF1600AE; Sun, 13 Aug 2017 23:31:45 +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 jkyY9Zc6eXM4; Sun, 13 Aug 2017 23:31:45 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 666C9160050; Sun, 13 Aug 2017 23:31:45 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EEEAF82278E9; Mon, 14 Aug 2017 09:31:41 +1000 (AEST) To: Tommy Pauly Cc: Fred Baker , "v6ops@ietf.org" , =?utf-8?B?56We5piO6YGU5ZOJ?= From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> In-reply-to: Your message of "Fri, 11 Aug 2017 10:19:23 -0700." <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> Date: Mon, 14 Aug 2017 09:31:41 +1000 Message-Id: <20170813233141.EEEAF82278E9@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 23:31:50 -0000 In message <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com>, Tommy Pauly writes: > Hi Mark, > > The case in which one query (A) is cached locally, while the other (AAAA) > needs to be fetched, should only affect a particular device's connection > to a host once. Whether they will remain unsynchronised or not depends on what queries arriving when around the ttl expiry period. Yes, this will happen again and again and again. We regularly see cases where your have sets of records that you know originally arrived with the same TTL value in the same response packet ending up with different TTL values over time. That's just how DNS caches work. I've looks at thousands of cache dumps over the years. Seen it happen lots of the time. > Before our device makes any queries, it will either be the case that: > a) No other device on the local network has made any queries for > that hostname, so no answers are cached. > b) A single-stack device on the local network has made an A > query, so only the A answer is cached. > c) A dual-stack device on the local network has made both A and > AAAA queries, so both answers are cached. > > In cases (a) and (c), there shouldn't be any significant difference > between the response times when our device makes its A and AAAA queries. > The case you're concerned about is (b). While it may have been common 10 > years ago have most devices on a network be single-stack, almost all > consumer operating systems in recent years are dual-stack by default, > so we are very rarely in case (b). If you have measured data to show > otherwise, I'd love to see it! We've been running metrics for over a > year on Happy Eyeballs behavior, and we see good behavior with this algorithm. There is still a lot of equipement being shipped today which is IPv4 only. Caches don't keep TTLs of different RRsets synchronised. > When our device sends out its A and AAAA queries, even if we had fallen > into the bad case of (b), the caches on the local resolver and the > on-device cache will be populated with both answers once both returns. Which will have different TTL values. > An IPv4 connection may have been established during that time, but any > subsequent connections to the same hostname will benefit by the caching, > and will choose IPv6 in the future. Until the AAAA record expires from the cache and need to be refreshed at which time there will be a A record in the cache and you get a cache miss on the AAAA record resulting in IPv4 traffic. This is assuming that there was a lookup of the A (and possibly AAAA) record between when the A record expires and the AAAA record expires. > I'd like to also emphasize that the spec does say that these delay values > are expected to change and be extended beyond current values in the future: > "For that reason, it is expected that these values will change over time. > Implementors should feel welcome to use different values without > changing this specification." > The main point is that the ability to have this logic, and not block on > waiting for both answers, is key. If you'd like to set your implementation > to use 250ms, that's fine! What I do, doesn't have statistical impact, in a world following this document. As for changing in the future, all that is doing is leaving a long tail of devices with bad timer values that have to be dealt with. ISP's and providers need to know when to switch off IPv4. To do that they will look at the amount of IPv4 traffic they are getting. Devices that initiate IPv4 connections when there is a full working IPv6 path just because there was a DNS cache miss don't help anyone make that decision. 50ms is measuring cache misses not broken / misconfigure authoritative servers and turning them into IPv4 traffic. 250ms is less so. 500ms is more less so. This is just with plain DNS. Add DNSSEC into the mix where a cache miss may well require multiple queries as DNSKEY and DS RRsets have also expired 250ms is becoming too small. Mark > Thanks, > Tommy > > > On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: > > > > > > In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com > -B7D6-2591506E0B07@apple.com>>, Tommy Pauly writes > > : > >> > >> Hi Mark, > >> > >> I'd like to clarify the role of the 50ms delay. This is not a delay > from > >> the beginning of the DNS query, but a delay from when the A record > returns, > >> and when the AAAA record later comes back. There should not be a > significant > >> difference in the query response time between A and AAAA generally, > which > >> is why the delay is short. The only time cached results would come into > >> play is if only one family is cached, and not the other. > > > > Which happens all the time. Negative responses have different TTLs > > to positive responses almost all the time so they leave the cache > > at different times. Also if you have a mix of IPv4 only clients > > and dual stack clients talking to a common resolver the A/AAAA > > records when both are present become unsyncronised even if they are > > published with the same TTL. > > > > With lossless DNS we should be picking IPv6 connections all the > > time. 50 ms won't achieve that. Somewhere up around 250ms might. > > Really small amounts of IPv4 traffic will stop people turning off > > IPv4. They won't investigate to see if the IPv4 traffic could have > > been served by IPv6. > > > > Picking IPv4 when there is IPv6 because a DNS transaction was lost > > is acceptable. It shouldn't happen if the wasn't a lost transaction. > > > >> There are essentially three options with regards to when you start a > TCP > >> connection after sending the DNS queries: > >> > >> 1. Start the first TCP connection immediately upon receiving the first > >> DNS response. Downside here is that if A comes back 2 milliseconds or > >> so before the AAAA, you've biased towards IPv4 for no good reason. > >> 2. Start the first TCP connection after a grace period delay after > >> receiving the first DNS response (we recommend 50 ms). This guarantees > >> that you never wait beyond the delay before trying some connection, but > >> you also won't bias towards IPv4 for just a couple milliseconds. > >> 3. Start the first TCP connection after receiving both A and AAAA > always. > >> This is the synchronous DNS option that was used previously, which > means > >> that if there is an error with one response, you have the penalty of > >> waiting a very long time. > >> > >> I think that (2) is the best option both for user experience and for > >> the promotion of IPv6. We can certainly try to have both, at least! The > >> timer values may need to be tuned in the future, but in our > measurements, > >> the 50ms window is the right tradeoff on the current Internet. > >> > >> Thanks, > >> Tommy > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Aug 13 23:51:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CAE126E3A for ; Sun, 13 Aug 2017 23:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q62FVOr2T8wH for ; Sun, 13 Aug 2017 23:51:39 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DC3126BF0 for ; Sun, 13 Aug 2017 23:51:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 55A2DAF; Mon, 14 Aug 2017 08:51:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502693497; bh=I4k/6YOv26JUZfoWHjZSQcdRYW6Gdf0a4RXBF4T83gk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BdDD1vI/MsLZ54AETrw75GVtXQdSdXtCZDO2571RSaBSdbzGfwcZtDf9VyG6/wA5R Nu8/0ri0k9VP8ybJ7T+mHC+xSED6UhDz5FqDMv4AOFla3nBIqhJAn1DWUXcVpE6jmK FFzItbwmJAbK6G6H2gXudKjvFL4Q0RZPwNbAdOsI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3E32584; Mon, 14 Aug 2017 08:51:37 +0200 (CEST) Date: Mon, 14 Aug 2017 08:51:37 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: Tommy Pauly , "v6ops@ietf.org" In-Reply-To: <20170813233141.EEEAF82278E9@rock.dv.isc.org> Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 06:51:42 -0000 On Mon, 14 Aug 2017, Mark Andrews wrote: > ISP's and providers need to know when to switch off IPv4. To do > that they will look at the amount of IPv4 traffic they are getting. > Devices that initiate IPv4 connections when there is a full working > IPv6 path just because there was a DNS cache miss don't help anyone > make that decision. 50ms is measuring cache misses not broken / > misconfigure authoritative servers and turning them into IPv4 > traffic. 250ms is less so. 500ms is more less so. This is just > with plain DNS. Add DNSSEC into the mix where a cache miss may > well require multiple queries as DNSKEY and DS RRsets have also > expired 250ms is becoming too small. You are correct, however, this problem should be solved in DNS land, not in setting a really high advantage for IPv6 over IPv4 (at this point in time). So while everything you say is correct, I do not agree with your prioritization of "avoid long tail IPv4 usage" as opposed to "if IPv6 is broken, the user will turn off IPv6 (forever) because it slows down the user experience once". I also think that the caching resolver should refresh soon-to-be-expired RRs that are getting close to their TTL=0. For instance, if someone is asking for an RR and it has less than 5% of its TTL left, then just refresh it. I believe there are drafts regarding this in DNSOP? https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 is one. I thought there was another one, but I can't find it right now. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 14 01:44:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3297213207A for ; Mon, 14 Aug 2017 01:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKjhQZV9T_77 for ; Mon, 14 Aug 2017 01:44:54 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29218132076 for ; Mon, 14 Aug 2017 01:44:54 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f15so38144876wmg.1 for ; Mon, 14 Aug 2017 01:44:54 -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-transfer-encoding:content-language; bh=fdGA1fTBBXWBwSk60EKO4n8JIWV+mtmE662pFnzF+gk=; b=YcJHaT01pQt/tF/2xAQntsri8ytr7q0rhzJ00NP5+d2g+1af50HjCI80ZXiq92BJrj mGaYYsk71qrdVCjsSqkn/Lr+sPL8zKTst9M2o6/dbyIV0kErsh7TshS3za262QGwa7/o jFy8CXrOjqULhecTF+gOZbJSOwjv1G+ze8/otPboLeslMocV0aLOaYHRYU9GumRCPkUe koJhHje9cDkeSXEBveX75ycsSHOzHl9mMn7au60NlPqffntmFifqMXHQ56uwmCe1bSUL RenBgnu0ZblnwDqzDBxNm97RN//6ysEJYBvYCOihurZmHSEH+cECqwN9YU9BAIKKxdZJ 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-transfer-encoding :content-language; bh=fdGA1fTBBXWBwSk60EKO4n8JIWV+mtmE662pFnzF+gk=; b=Uz4P1kLBSkL+GYyZdzYmgdNDhkfQptq4C64iPUtozc8d3VRLemYhInmfU7nuK6jL4l TK/0RNSilLaFkLmD1suewd4PjmGweQVBLabk7ka01YLeNTz75FNMufls9SLHl7vh5GY6 lFSepSwjpgG2hA3j223DeTQPn2I84WSF7ZtOX0r5SX1yk/OMMp0lSYO2LUtIk/ALS8Ic 32UNGuAy95p0bZhIUjeHqtJob2SyNY/GJkzAYvmCubAL8z2wKITh/62R6aNlSkjZKo/5 5miQRpfp+f1BXVTX1dPXnAelqvGqvypioQSDUZz4ZNC9v+BWwXxqAZDrIB7inB+d5d3d 1Jcw== X-Gm-Message-State: AHYfb5g1guPOrnsqhHMxgEGT0TpQEADOzzu7M+D0VtYAE3cCmCx0HYrS thZpWmvIrYP4sA== X-Received: by 10.80.216.75 with SMTP id v11mr23961343edj.234.1502700292571; Mon, 14 Aug 2017 01:44:52 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:f0d2:352a:c310:3701]) by smtp.gmail.com with ESMTPSA id c23sm4190680edb.24.2017.08.14.01.44.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 01:44:51 -0700 (PDT) To: Mark Andrews , Tommy Pauly Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> From: Stephen Strowes Message-ID: <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> Date: Mon, 14 Aug 2017 10:44:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170813233141.EEEAF82278E9@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 08:44:56 -0000 On 14/08/2017 01:31, Mark Andrews wrote: > 50ms is measuring cache misses not broken / > misconfigure authoritative servers and turning them into IPv4 > traffic. 250ms is less so. 500ms is more less so. Regarding bounds for delays and the eyeballs we aim to make happy: Your comment triggered an old memory. ITU-T G.114 [1], fig. 1, looks at human tolerance of one-way delay for real-time comms. Modelling a web session against the tolerances they describe implies a click-to-seeing-a-page-load delay of <= 290ms for eyeballs to be satisfied, and <= 200ms to be practically ecstatic. So in terms of human-level responsiveness, perhaps the time taken to resolve the A record plus, say, 200ms is usually within the bounds of acceptability even on the long-end of that timer. This would suggest that the timer after the A record is received doesn't have to be as tight as 50ms. Since measurements have been done and 6555bis recommends timers for the first time, I'd love to see more data! I'd love to know if people get real mad with a 100ms failover. The most recent public study on happy eyeballs that comes to mind -- which doesn't factor in DNS resolution times -- is probably [2]; lots of HTTP content is within a few milliseconds on either side. S. [1] http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.114-200305-I!!PDF-E&type=items [2] http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-he-anrw-2016.pdf >>> On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: >>> >>> >>> In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com >> > -B7D6-2591506E0B07@apple.com>>, Tommy Pauly writes >>> : >>>> Hi Mark, >>>> >>>> I'd like to clarify the role of the 50ms delay. This is not a delay >> from >>>> the beginning of the DNS query, but a delay from when the A record >> returns, >>>> and when the AAAA record later comes back. There should not be a >> significant >>>> difference in the query response time between A and AAAA generally, >> which >>>> is why the delay is short. The only time cached results would come into >>>> play is if only one family is cached, and not the other. >>> Which happens all the time. Negative responses have different TTLs >>> to positive responses almost all the time so they leave the cache >>> at different times. Also if you have a mix of IPv4 only clients >>> and dual stack clients talking to a common resolver the A/AAAA >>> records when both are present become unsyncronised even if they are >>> published with the same TTL. >>> >>> With lossless DNS we should be picking IPv6 connections all the >>> time. 50 ms won't achieve that. Somewhere up around 250ms might. >>> Really small amounts of IPv4 traffic will stop people turning off >>> IPv4. They won't investigate to see if the IPv4 traffic could have >>> been served by IPv6. >>> >>> Picking IPv4 when there is IPv6 because a DNS transaction was lost >>> is acceptable. It shouldn't happen if the wasn't a lost transaction. >>> >>>> There are essentially three options with regards to when you start a >> TCP >>>> connection after sending the DNS queries: >>>> >>>> 1. Start the first TCP connection immediately upon receiving the first >>>> DNS response. Downside here is that if A comes back 2 milliseconds or >>>> so before the AAAA, you've biased towards IPv4 for no good reason. >>>> 2. Start the first TCP connection after a grace period delay after >>>> receiving the first DNS response (we recommend 50 ms). This guarantees >>>> that you never wait beyond the delay before trying some connection, but >>>> you also won't bias towards IPv4 for just a couple milliseconds. >>>> 3. Start the first TCP connection after receiving both A and AAAA >> always. >>>> This is the synchronous DNS option that was used previously, which >> means >>>> that if there is an error with one response, you have the penalty of >>>> waiting a very long time. >>>> >>>> I think that (2) is the best option both for user experience and for >>>> the promotion of IPv6. We can certainly try to have both, at least! The >>>> timer values may need to be tuned in the future, but in our >> measurements, >>>> the 50ms window is the right tradeoff on the current Internet. >>>> >>>> Thanks, >>>> Tommy >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> From nobody Mon Aug 14 01:54:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4313207A for ; Mon, 14 Aug 2017 01:54:12 -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 XKni4dtA08ES for ; Mon, 14 Aug 2017 01:54:10 -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 6F34813208E for ; Mon, 14 Aug 2017 01:54:10 -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 4052D34A5FC; Mon, 14 Aug 2017 08:51:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2C8A4160045; Mon, 14 Aug 2017 08:51:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 149A4160050; Mon, 14 Aug 2017 08:51:15 +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 Pw3OBD-xYHMF; Mon, 14 Aug 2017 08:51:15 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 815BE160045; Mon, 14 Aug 2017 08:51:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 63308823972C; Mon, 14 Aug 2017 18:51:12 +1000 (AEST) To: Mikael Abrahamsson Cc: Tommy Pauly , "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> In-reply-to: Your message of "Mon, 14 Aug 2017 08:51:37 +0200." Date: Mon, 14 Aug 2017 18:51:12 +1000 Message-Id: <20170814085112.63308823972C@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 08:54:13 -0000 In message , Mikael Abraha msson writes: > On Mon, 14 Aug 2017, Mark Andrews wrote: > > > ISP's and providers need to know when to switch off IPv4. To do > > that they will look at the amount of IPv4 traffic they are getting. > > Devices that initiate IPv4 connections when there is a full working > > IPv6 path just because there was a DNS cache miss don't help anyone > > make that decision. 50ms is measuring cache misses not broken / > > misconfigure authoritative servers and turning them into IPv4 > > traffic. 250ms is less so. 500ms is more less so. This is just > > with plain DNS. Add DNSSEC into the mix where a cache miss may > > well require multiple queries as DNSKEY and DS RRsets have also > > expired 250ms is becoming too small. > > You are correct, however, this problem should be solved in DNS land, not > in setting a really high advantage for IPv6 over IPv4 (at this point in > time). The document fails to account for cache misses. It assumes that there will be *no* A or AAAA records present or that both A and AAAA records will be present in the cache. In both those caches ~50ms is fine as it accounts for variance in the lookups. When only one of A or AAAA RRsets is present in the cache you have lookup times < 10ms for the RRset that is present in the cache and ~200ms for the RRset that isn't in the cache but the nameserver information is present. Waiting a realistic period for the cache miss to be filled is not "setting a really high advantage for IPv6 over IPv4". It's giving them equal standing. Another way to express this would be to require that the AAAA lookup has a minimum amount of time to succeed before failing over to IPv4 which is of the order of the time of a cache refresh. Below is a example of a cache miss for bbc.co.uk/A where the answer is fetched from the other side of the world. Thats one UDP there and one UDP packet back. [rock:~/git/bind9] marka% dig a bbc.co.uk ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> a bbc.co.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38363 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d3a9ce37593e504dfd7a68a45991596c1a2a6c63bc284349 (good) ;; QUESTION SECTION: ;bbc.co.uk. IN A ;; ANSWER SECTION: bbc.co.uk. 300 IN A 212.58.246.79 bbc.co.uk. 300 IN A 212.58.244.23 bbc.co.uk. 300 IN A 212.58.244.22 bbc.co.uk. 300 IN A 212.58.246.78 ;; Query time: 206 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Aug 14 18:03:56 AEST 2017 ;; MSG SIZE rcvd: 130 [rock:~/git/bind9] marka% > So while everything you say is correct, I do not agree with your > prioritization of "avoid long tail IPv4 usage" as opposed to "if IPv6 is > broken, the user will turn off IPv6 (forever) because it slows down the > user experience once". When IPv6 lookups are broken they usually take significantly longer than a additional 200ms to complete as you end up with multiple queries being made. > I also think that the caching resolver should refresh soon-to-be-expired > RRs that are getting close to their TTL=0. For instance, if someone is > asking for an RR and it has less than 5% of its TTL left, then just > refresh it. Which hides some cache misses from the client but not all of them. Been there, done that. > I believe there are drafts regarding this in DNSOP? > > https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 > is one. I thought there was another one, but I can't find it right now. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 14 03:00:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7FD1320DC for ; Mon, 14 Aug 2017 03:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPl-zlhhdhht for ; Mon, 14 Aug 2017 03:00:25 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53CC120721 for ; Mon, 14 Aug 2017 03:00:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BD9ABAF; Mon, 14 Aug 2017 12:00:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502704822; bh=SqX73cZy83IvtFhvq4lxIx4uSwXOkXLR2eR3druE3m4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=m6VUree1cRCBvjgXEM1rHlu4SlKPj4sz6ai7yoDJAZOYhMgB9hjnfizVM/dEqCI2h BBcdasW0nmbaQJYjtNeb08BEaMuGvgLtbtwEoRRYFDKzZsKNpUbhIR6gDn5iCD1Y4X Fc6ASn7TsYNXJ04xjB4xRz0hvL5M8JUd59gwikzA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BB74084; Mon, 14 Aug 2017 12:00:22 +0200 (CEST) Date: Mon, 14 Aug 2017 12:00:22 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: Tommy Pauly , "v6ops@ietf.org" In-Reply-To: <20170814085112.63308823972C@rock.dv.isc.org> Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:00:28 -0000 On Mon, 14 Aug 2017, Mark Andrews wrote: > When only one of A or AAAA RRsets is present in the cache you have > lookup times < 10ms for the RRset that is present in the cache and > ~200ms for the RRset that isn't in the cache but the nameserver > information is present. Waiting a realistic period for the cache > miss to be filled is not "setting a really high advantage for IPv6 > over IPv4". It's giving them equal standing. Yes, but most of the requests will not have this problem, but you want to set the time to take into account this edge case to slow down all fall-back cases to IPv4? Also, I already said you were correct in your analysis, but I just don't agree that we need to bring up the wait period for IPv4 to handle the problem you're describing. Yes it happens, I am not disputing that. I just don't see the huge disadvantage you seem to be seeing in doing a few IPv4 accesses when it could eventually had been used over IPv6 instead. At least not at this point in time. > When IPv6 lookups are broken they usually take significantly longer than > a additional 200ms to complete as you end up with multiple queries being > made. So your proposal is to wait for the AAAA lookup to complete, even if this takes several seconds? Just to make sure we might get an answer, eventually? > Which hides some cache misses from the client but not all of them. Been > there, done that. Happy Eyeballs is all about compromise between user experience and "use IPv6 at all cost". 50ms seems like a good value at this point in time. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 14 03:06:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCED13217D for ; Mon, 14 Aug 2017 03:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7qV-ktMir-S for ; Mon, 14 Aug 2017 03:06:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EABB1320DC for ; Mon, 14 Aug 2017 03:06:09 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id g189so29850391vke.5 for ; Mon, 14 Aug 2017 03:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+eFbrPnPz1ABLMlN26f/TbbqpVvprmyPHLsVMlUiZRs=; b=smCPIBD+wnt83h5zqv0ApA6jQGUZzy8I7ISXf9M8M5CJKQVFocxoGZJd8DuBn1HbKb bkhhZh0lYAsOHpVdcjM0YYKnhOqPDuozi/FrTgV/NZEnVCUVBvduJoM44+v6MoH5tBFO WEJCqAYahaJ4GAhb5CEFjTpX0ubJMY+yTA7PTsT7flih4Af3W0lab2BfPfl29czO5y1Q CjJf1blGgiiO7BZo38iMWl5YaDoJVLOXTFzGzowU3VU4BdHtM8T4FBSNs9FXKsozb0hy soRKCI4XCFQe9vz3KH4FKjhrd2r7hTzgeoCGJI6F6jwA9ED6pT64NHoOhpWxfxI8sNZL 0a8g== 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=+eFbrPnPz1ABLMlN26f/TbbqpVvprmyPHLsVMlUiZRs=; b=ZoLwCe/jAB7dxNS0AbFL2RJQvNkRBWzYH0kAO1n0jvMbSduPLap4AsfK94EbH93ldY 8w8fadXoQ662Em3Kg9tpngT/N2vs91jX+eZtmMQR08qI37Cn1eVsFeCTw1P7RagskUyM U26S/IaPz4Oi7gUjLtGl55nIPQ+jYy5Zc3vVIeAxcMET4zhhZKEnjWK1vBnamH+W+lMO rO/O8mMOcAEcrUHQwBVhPzdowkjIvtrTzJyG4h0BqL1+L9mUTIAwSu15zWObPO2Z2Ki4 2JdD7IKgnmqGQR3OyKF6a8F4cEST5si3q+8ZdKcU7WhHkj1hD7rVvdyBB/xuWtiY9Jvt mXsg== X-Gm-Message-State: AHYfb5gMlc4UFuLAc1V/RWKHo1HiyH3DrAJ8+hht+k7ud+t2Mkinmlm4 9tvzpcGBYFh1flxIOCsN8pxwovS/0Q== X-Received: by 10.31.6.205 with SMTP id 196mr16124850vkg.10.1502705168023; Mon, 14 Aug 2017 03:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Mon, 14 Aug 2017 03:05:37 -0700 (PDT) In-Reply-To: <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> From: Mark Smith Date: Mon, 14 Aug 2017 20:05:37 +1000 Message-ID: To: Stephen Strowes Cc: Mark Andrews , Tommy Pauly , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:06:12 -0000 On 14 August 2017 at 18:44, Stephen Strowes wrote: > On 14/08/2017 01:31, Mark Andrews wrote: >> >> 50ms is measuring cache misses not broken / >> misconfigure authoritative servers and turning them into IPv4 >> traffic. 250ms is less so. 500ms is more less so. > > > Regarding bounds for delays and the eyeballs we aim to make happy: > > Your comment triggered an old memory. ITU-T G.114 [1], fig. 1, looks at > human tolerance of one-way delay for real-time comms. Modelling a web > session against the tolerances they describe implies a > click-to-seeing-a-page-load delay of <= 290ms for eyeballs to be satisfied, > and <= 200ms to be practically ecstatic. > The ITU's values might be worst case values, rather than ideals. "Response Times: The 3 Important Limits" https://www.nngroup.com/articles/response-times-3-important-limits/ "The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]: 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data. ... " So I think the ideal to aim for would be for DNS resolution, TCP connection establishment and web page rendering to start within that 100ms time period. "Powers of 10: Time Scales in User Experience" https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/ is another related article. Regards, Mark. > So in terms of human-level responsiveness, perhaps the time taken to resolve > the A record plus, say, 200ms is usually within the bounds of acceptability > even on the long-end of that timer. This would suggest that the timer after > the A record is received doesn't have to be as tight as 50ms. > > Since measurements have been done and 6555bis recommends timers for the > first time, I'd love to see more data! I'd love to know if people get real > mad with a 100ms failover. > > The most recent public study on happy eyeballs that comes to mind -- which > doesn't factor in DNS resolution times -- is probably [2]; lots of HTTP > content is within a few milliseconds on either side. > > S. > > > [1] > http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.114-200305-I!!PDF-E&type=items > [2] > http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-he-anrw-2016.pdf > > > > >>>> On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: >>>> >>>> >>>> In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com >>> >>> >> -B7D6-2591506E0B07@apple.com>>, Tommy Pauly writes >>>> >>>> : >>>>> >>>>> Hi Mark, >>>>> >>>>> I'd like to clarify the role of the 50ms delay. This is not a delay >>> >>> from >>>>> >>>>> the beginning of the DNS query, but a delay from when the A record >>> >>> returns, >>>>> >>>>> and when the AAAA record later comes back. There should not be a >>> >>> significant >>>>> >>>>> difference in the query response time between A and AAAA generally, >>> >>> which >>>>> >>>>> is why the delay is short. The only time cached results would come into >>>>> play is if only one family is cached, and not the other. >>>> >>>> Which happens all the time. Negative responses have different TTLs >>>> to positive responses almost all the time so they leave the cache >>>> at different times. Also if you have a mix of IPv4 only clients >>>> and dual stack clients talking to a common resolver the A/AAAA >>>> records when both are present become unsyncronised even if they are >>>> published with the same TTL. >>>> >>>> With lossless DNS we should be picking IPv6 connections all the >>>> time. 50 ms won't achieve that. Somewhere up around 250ms might. >>>> Really small amounts of IPv4 traffic will stop people turning off >>>> IPv4. They won't investigate to see if the IPv4 traffic could have >>>> been served by IPv6. >>>> >>>> Picking IPv4 when there is IPv6 because a DNS transaction was lost >>>> is acceptable. It shouldn't happen if the wasn't a lost transaction. >>>> >>>>> There are essentially three options with regards to when you start a >>> >>> TCP >>>>> >>>>> connection after sending the DNS queries: >>>>> >>>>> 1. Start the first TCP connection immediately upon receiving the first >>>>> DNS response. Downside here is that if A comes back 2 milliseconds or >>>>> so before the AAAA, you've biased towards IPv4 for no good reason. >>>>> 2. Start the first TCP connection after a grace period delay after >>>>> receiving the first DNS response (we recommend 50 ms). This guarantees >>>>> that you never wait beyond the delay before trying some connection, but >>>>> you also won't bias towards IPv4 for just a couple milliseconds. >>>>> 3. Start the first TCP connection after receiving both A and AAAA >>> >>> always. >>>>> >>>>> This is the synchronous DNS option that was used previously, which >>> >>> means >>>>> >>>>> that if there is an error with one response, you have the penalty of >>>>> waiting a very long time. >>>>> >>>>> I think that (2) is the best option both for user experience and for >>>>> the promotion of IPv6. We can certainly try to have both, at least! The >>>>> timer values may need to be tuned in the future, but in our >>> >>> measurements, >>>>> >>>>> the 50ms window is the right tradeoff on the current Internet. >>>>> >>>>> Thanks, >>>>> Tommy >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>> >>> >>> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 14 03:45:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E927132192 for ; Mon, 14 Aug 2017 03:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYMFoSg9t3q0 for ; Mon, 14 Aug 2017 03:45:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E894132196 for ; Mon, 14 Aug 2017 03:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502707548; x=1503312348; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=QIeJmPn/BQUCn+z/63DsNYwAP ADLFi0deSZafrqN7mA=; b=qcX1kW9Cx4nu5T9c5ltvRiFaeZFmMDoUgVZptdsdc SA5SuxoR5VzoQb96FPMPLl3kkKc2OQW+bGn6K7lgWN8zre8vpk8FsN/J4yXrk76b gGGBPjjXWjHdiQjB3N+K+n1VLyhvfvt/zuN+lG6bmf4rDQI1KJvuIu0APChj0Mop cU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ftvMzZ1EHJZH5EIHcsUeSuvTN/ibA8BXHjqIOfRk49OgJQUad0uuvRNSCAGA jvRWcElBta+mKeZ7faN0oY8xrGhv2t+eYT/qICDpxPqNhNTuurJueMpoN vf19OFWWQ+eLKIBy8hDzOVaHzeXCVA9xR8BHO3JKR6o/Y4iwA0jtm0=; X-MDAV-Processed: mail.consulintel.es, Mon, 14 Aug 2017 12:45:48 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 14 Aug 2017 12:45:46 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005504715.msg for ; Mon, 14 Aug 2017 12:45:45 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170814:md50005504715::zooUQKjhuWZ2ziK2:00004PJB X-Return-Path: prvs=1399dff034=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Mon, 14 Aug 2017 12:45:41 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <70C286AE-F826-44A2-BA92-28C5950EE24F@consulintel.es> Thread-Topic: [v6ops] WGLC for RFC6555bis References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:45:53 -0000 Looking at the latest work from Vaibhav, which was presented at the last v6= ops meeting: https://datatracker.ietf.org/meeting/99/materials/slides-99-v6ops-sessa-a-l= ongitudinal-view-of-dual-stacked-websites-failures-latency-and-happy-eyebal= ls It looks like the correct value, instead of 50ms will be 150. I will be in favor of a higher default value, something around 250ms maybe,= in order to, not damage =E2=80=9Ctoo much=E2=80=9D the user experience, bu= t 1) ensure that IPv6 get as much preference as possible and, 2) if somethi= ng is broken, users complain and operators realize that HE is hiding some p= roblem in their networks. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Mark Smith Responder a: Fecha: lunes, 14 de agosto de 2017, 12:06 Para: Stephen Strowes CC: "v6ops@ietf.org" , =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= Asunto: Re: [v6ops] WGLC for RFC6555bis On 14 August 2017 at 18:44, Stephen Strowes = wrote: > On 14/08/2017 01:31, Mark Andrews wrote: >> >> 50ms is measuring cache misses not broken / >> misconfigure authoritative servers and turning them into IPv4 >> traffic. 250ms is less so. 500ms is more less so. > > > Regarding bounds for delays and the eyeballs we aim to make happy: > > Your comment triggered an old memory. ITU-T G.114 [1], fig. 1, looks = at > human tolerance of one-way delay for real-time comms. Modelling a web > session against the tolerances they describe implies a > click-to-seeing-a-page-load delay of <=3D 290ms for eyeballs to be sa= tisfied, > and <=3D 200ms to be practically ecstatic. > =20 The ITU's values might be worst case values, rather than ideals. =20 "Response Times: The 3 Important Limits" https://www.nngroup.com/articles/response-times-3-important-limits/ =20 "The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]: =20 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. =20 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data. =20 ... =20 " =20 So I think the ideal to aim for would be for DNS resolution, TCP connection establishment and web page rendering to start within that 100ms time period. =20 =20 "Powers of 10: Time Scales in User Experience" https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/ =20 is another related article. =20 =20 Regards, Mark. =20 =20 =20 > So in terms of human-level responsiveness, perhaps the time taken to = resolve > the A record plus, say, 200ms is usually within the bounds of accepta= bility > even on the long-end of that timer. This would suggest that the timer= after > the A record is received doesn't have to be as tight as 50ms. > > Since measurements have been done and 6555bis recommends timers for t= he > first time, I'd love to see more data! I'd love to know if people get= real > mad with a 100ms failover. > > The most recent public study on happy eyeballs that comes to mind -- = which > doesn't factor in DNS resolution times -- is probably [2]; lots of HT= TP > content is within a few milliseconds on either side. > > S. > > > [1] > http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.114-2003= 05-I!!PDF-E&type=3Ditems > [2] > http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-he-an= rw-2016.pdf > > > > >>>> On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: >>>> >>>> >>>> In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com >>> >>> >> -B7D6-2591506E0B07@apple.com>>, Tommy Pauly writes >>>> >>>> : >>>>> >>>>> Hi Mark, >>>>> >>>>> I'd like to clarify the role of the 50ms delay. This is not a del= ay >>> >>> from >>>>> >>>>> the beginning of the DNS query, but a delay from when the A recor= d >>> >>> returns, >>>>> >>>>> and when the AAAA record later comes back. There should not be a >>> >>> significant >>>>> >>>>> difference in the query response time between A and AAAA generall= y, >>> >>> which >>>>> >>>>> is why the delay is short. The only time cached results would com= e into >>>>> play is if only one family is cached, and not the other. >>>> >>>> Which happens all the time. Negative responses have different TTL= s >>>> to positive responses almost all the time so they leave the cache >>>> at different times. Also if you have a mix of IPv4 only clients >>>> and dual stack clients talking to a common resolver the A/AAAA >>>> records when both are present become unsyncronised even if they ar= e >>>> published with the same TTL. >>>> >>>> With lossless DNS we should be picking IPv6 connections all the >>>> time. 50 ms won't achieve that. Somewhere up around 250ms might. >>>> Really small amounts of IPv4 traffic will stop people turning off >>>> IPv4. They won't investigate to see if the IPv4 traffic could hav= e >>>> been served by IPv6. >>>> >>>> Picking IPv4 when there is IPv6 because a DNS transaction was lost >>>> is acceptable. It shouldn't happen if the wasn't a lost transacti= on. >>>> >>>>> There are essentially three options with regards to when you star= t a >>> >>> TCP >>>>> >>>>> connection after sending the DNS queries: >>>>> >>>>> 1. Start the first TCP connection immediately upon receiving the = first >>>>> DNS response. Downside here is that if A comes back 2 millisecond= s or >>>>> so before the AAAA, you've biased towards IPv4 for no good reason= . >>>>> 2. Start the first TCP connection after a grace period delay afte= r >>>>> receiving the first DNS response (we recommend 50 ms). This guara= ntees >>>>> that you never wait beyond the delay before trying some connectio= n, but >>>>> you also won't bias towards IPv4 for just a couple milliseconds. >>>>> 3. Start the first TCP connection after receiving both A and AAAA >>> >>> always. >>>>> >>>>> This is the synchronous DNS option that was used previously, whic= h >>> >>> means >>>>> >>>>> that if there is an error with one response, you have the penalty= of >>>>> waiting a very long time. >>>>> >>>>> I think that (2) is the best option both for user experience and = for >>>>> the promotion of IPv6. We can certainly try to have both, at leas= t! The >>>>> timer values may need to be tuned in the future, but in our >>> >>> measurements, >>>>> >>>>> the 50ms window is the right tradeoff on the current Internet. >>>>> >>>>> Thanks, >>>>> Tommy >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>> >>> >>> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =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 use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Mon Aug 14 04:43:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9298126BFD for ; Mon, 14 Aug 2017 04:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXWg87LxPxH9 for ; Mon, 14 Aug 2017 04:43:15 -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 01ADC1321A4 for ; Mon, 14 Aug 2017 04:43:15 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id y206so14117956wmd.5 for ; Mon, 14 Aug 2017 04:43:14 -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-transfer-encoding:content-language; bh=78jt9EB8R9dV0wrrp87aEUHevsIfStaZAVfJi5HVRbY=; b=QfToZU9TL3Wf/A/0RlF/GJW+BKcxDF+AAak28TFwqrptqYMftfP63xmHWfI5demcOd Vc82gtLAAnUaT89XdhVT4rRUsB3tGffbg9iffd+1P5oWMtyVC9I6b6id2zWvbe5c2Pha DJiMRUPhXuXj2Vnloy/2X7E9/QYGHWq6kyQeEuj0In5fDkOD4PV/GwKvrH4tDRtZzXYw V3OAo0GvihdNL8QYZpnFfmW88XDbQkObdWSkL+7ZAHLm3WOCYi9d37LGeARW+Rga8/ba Nja/K/iLVIrIgQT+DMDu0xXeil/kikZbVFAoioepD5rMouFBksaExKNJtqwz7udsvUPG K2yg== 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-transfer-encoding :content-language; bh=78jt9EB8R9dV0wrrp87aEUHevsIfStaZAVfJi5HVRbY=; b=UgxFVf+kOTxq6kgNnYBUZ5AkdrdJSX6bfs+TN0FuN/2AnBTwimxv0iRGhmUDQh4gcF 5BGDukT4gPNqqBYPLrwkmVLGuhHzJTLb+QG6bFJEzF0Zf+5Rzvw3k3M8oGwnzsU/B3a2 jPmGe5zueIhbukzZX9OKlJRWWnsnHpAjFblLYvrbCDX7Z5qb+LjLVGRN3Po9qDxlk022 8tVU2+1xfa1R6Df1KS7nPc1HI0OjrsiKnio1JRppymNIVVB2tF8Nc/QHTZwane31qXDB k5NrVUhc+ea5vs2Qv9KRhgeD2ugeuRz3L9naR8BnkeatFy6zPJdhImDJFkhq9OgIYG3P RovQ== X-Gm-Message-State: AHYfb5ihGk9X2/v1Mm1MgcLDfRc0c9iYJf6t9MoyfervHrlHLH7sVnIc PPXVYUbLolkOFQ== X-Received: by 10.80.169.100 with SMTP id m33mr23321799edc.31.1502710993417; Mon, 14 Aug 2017 04:43:13 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:f0d2:352a:c310:3701]) by smtp.gmail.com with ESMTPSA id z2sm4083020edl.37.2017.08.14.04.43.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 04:43:12 -0700 (PDT) To: Mark Smith Cc: Mark Andrews , Tommy Pauly , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> From: Stephen Strowes Message-ID: <9390b8c0-53aa-3a73-2b43-fdedbfc260e3@gmail.com> Date: Mon, 14 Aug 2017 13:43:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 11:43:18 -0000 On 14/08/2017 12:05, Mark Smith wrote: > On 14 August 2017 at 18:44, Stephen Strowes wrote: >> On 14/08/2017 01:31, Mark Andrews wrote: >>> 50ms is measuring cache misses not broken / >>> misconfigure authoritative servers and turning them into IPv4 >>> traffic. 250ms is less so. 500ms is more less so. >> >> Regarding bounds for delays and the eyeballs we aim to make happy: >> >> Your comment triggered an old memory. ITU-T G.114 [1], fig. 1, looks at >> human tolerance of one-way delay for real-time comms. Modelling a web >> session against the tolerances they describe implies a >> click-to-seeing-a-page-load delay of <= 290ms for eyeballs to be satisfied, >> and <= 200ms to be practically ecstatic. >> > The ITU's values might be worst case values, rather than ideals. You're right, those values are at the tail ends of their categories in the graph in the document. And real-time comms is different from web responsiveness, of course, but it's an interesting limit. And happy eyeballs is directly about not-displeasing users. > "Response Times: The 3 Important Limits" > https://www.nngroup.com/articles/response-times-3-important-limits/ > > "The basic advice regarding response times has been about the same for > thirty years [Miller 1968; Card et al. 1991]: > > 0.1 second is about the limit for having the user feel that the system > is reacting instantaneously, meaning that no special feedback is > necessary except to display the result. > [...] > So I think the ideal to aim for would be for DNS resolution, TCP > connection establishment and web page rendering to start within that > 100ms time period. Notably the worst case, as recommended, is 300ms after the first DNS answers arrive (50ms AAAA grace period + 250ms connect() failover): a similar range as I understand Chrome's behaviour. 300ms is, as above, on the long end of when users will reach for their pitchforks, so that's probably a good ceiling. If there were data to support, say, a 100ms/200ms balance to help satisfy DNS caching concerns, that'd be neat. S. > >> So in terms of human-level responsiveness, perhaps the time taken to resolve >> the A record plus, say, 200ms is usually within the bounds of acceptability >> even on the long-end of that timer. This would suggest that the timer after >> the A record is received doesn't have to be as tight as 50ms. >> >> Since measurements have been done and 6555bis recommends timers for the >> first time, I'd love to see more data! I'd love to know if people get real >> mad with a 100ms failover. >> >> The most recent public study on happy eyeballs that comes to mind -- which >> doesn't factor in DNS resolution times -- is probably [2]; lots of HTTP >> content is within a few milliseconds on either side. >> >> S. >> >> >> [1] >> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.114-200305-I!!PDF-E&type=items >> [2] >> http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-he-anrw-2016.pdf >> >> >> >> >>>>> On Aug 10, 2017, at 10:57 PM, Mark Andrews wrote: >>>>> >>>>> >>>>> In message <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com >>>> >>> -B7D6-2591506E0B07@apple.com>>, Tommy Pauly writes >>>>> : >>>>>> Hi Mark, >>>>>> >>>>>> I'd like to clarify the role of the 50ms delay. This is not a delay >>>> from >>>>>> the beginning of the DNS query, but a delay from when the A record >>>> returns, >>>>>> and when the AAAA record later comes back. There should not be a >>>> significant >>>>>> difference in the query response time between A and AAAA generally, >>>> which >>>>>> is why the delay is short. The only time cached results would come into >>>>>> play is if only one family is cached, and not the other. >>>>> Which happens all the time. Negative responses have different TTLs >>>>> to positive responses almost all the time so they leave the cache >>>>> at different times. Also if you have a mix of IPv4 only clients >>>>> and dual stack clients talking to a common resolver the A/AAAA >>>>> records when both are present become unsyncronised even if they are >>>>> published with the same TTL. >>>>> >>>>> With lossless DNS we should be picking IPv6 connections all the >>>>> time. 50 ms won't achieve that. Somewhere up around 250ms might. >>>>> Really small amounts of IPv4 traffic will stop people turning off >>>>> IPv4. They won't investigate to see if the IPv4 traffic could have >>>>> been served by IPv6. >>>>> >>>>> Picking IPv4 when there is IPv6 because a DNS transaction was lost >>>>> is acceptable. It shouldn't happen if the wasn't a lost transaction. >>>>> >>>>>> There are essentially three options with regards to when you start a >>>> TCP >>>>>> connection after sending the DNS queries: >>>>>> >>>>>> 1. Start the first TCP connection immediately upon receiving the first >>>>>> DNS response. Downside here is that if A comes back 2 milliseconds or >>>>>> so before the AAAA, you've biased towards IPv4 for no good reason. >>>>>> 2. Start the first TCP connection after a grace period delay after >>>>>> receiving the first DNS response (we recommend 50 ms). This guarantees >>>>>> that you never wait beyond the delay before trying some connection, but >>>>>> you also won't bias towards IPv4 for just a couple milliseconds. >>>>>> 3. Start the first TCP connection after receiving both A and AAAA >>>> always. >>>>>> This is the synchronous DNS option that was used previously, which >>>> means >>>>>> that if there is an error with one response, you have the penalty of >>>>>> waiting a very long time. >>>>>> >>>>>> I think that (2) is the best option both for user experience and for >>>>>> the promotion of IPv6. We can certainly try to have both, at least! The >>>>>> timer values may need to be tuned in the future, but in our >>>> measurements, >>>>>> the 50ms window is the right tradeoff on the current Internet. >>>>>> >>>>>> Thanks, >>>>>> Tommy >>>>> -- >>>>> Mark Andrews, ISC >>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>>> >>>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 14 05:08:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306151321AE for ; Mon, 14 Aug 2017 05:08: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxgmHjayz9WU for ; Mon, 14 Aug 2017 05:08:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id BE2D01321A6 for ; Mon, 14 Aug 2017 05:08:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dhEAb-0000ECC; Mon, 14 Aug 2017 14:08:33 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <73750c5e-53d0-266c-8b59-1d4f07247977@gmail.com> <70C286AE-F826-44A2-BA92-28C5950EE24F@consulintel.es> In-reply-to: Your message of "Mon, 14 Aug 2017 12:45:41 +0200 ." <70C286AE-F826-44A2-BA92-28C5950EE24F@consulintel.es> Date: Mon, 14 Aug 2017 14:08:32 +0200 Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 12:08:40 -0000 > I will be in favor of a higher default value, something around > 250ms maybe, in order to, not damage too much the user experience, > but 1) ensure that IPv6 get as much preference as possible and, 2) > if something is broken, users complain and operators realize that > HE is hiding some problem in their networks. As far as I know, it is extremely rare that an AAAA query will timeout where an A query succeeds. (Not impossible, just very rare). So this whole async DNS business is just an attempt to benefit from cached A records at the expense of having more IPv4 connections go through CGN boxes. From nobody Mon Aug 14 06:56:43 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BB71321CB; Mon, 14 Aug 2017 06:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150271899593.445.14670939084263166578.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 06:56:35 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-v6ops-unique-ipv6-prefix-per-host-07=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 13:56:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up. From nobody Mon Aug 14 11:19:09 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B73A1323CA; Mon, 14 Aug 2017 11:19:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273474543.479.3530847986772979740.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:19:05 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-v6ops-unique-ipv6-prefix-per-host-07=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:19:05 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review. Please also consider the following comment from the gen-art review (Thanks Joel!): "The issue of status for the document (BCP vs Informational) is for the IESG to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chosen throughout the document makes it appear that the underlying decision about such a deployment is also a recommended practice." I agree that wording could be made clearer here! From nobody Mon Aug 14 11:45:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE26A1323B5 for ; Mon, 14 Aug 2017 11:45: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UXTXmpwvhHf5 for ; Mon, 14 Aug 2017 11:45:45 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E240D132399 for ; Mon, 14 Aug 2017 11:45:44 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id i12so1602692pgr.3 for ; Mon, 14 Aug 2017 11:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=uDQ+he1/dWtR+adlJuZJVZfDLPIl/4ErEcqQ10DYq4k=; b=oeTOyWplK7c6X2CS8vN1r+YTfitnhAqjcXDWWFas5cWS4kZ6iB6CY8LIFpcA/5EsTB 719IuJCkPmir9UQdcTBpfzU4I8F9blE7JG6jZkfSBxKrGO6b+zRCh5f3hgR9d9G6ddJu 3Ji/Ub+gZsXsgrPFGB8MLTZd6t5Gkkzo3l6HPa3EDGcYNmHCtnzWnLVSLJube6cQyHdf McgnjLGaw0Hna7fJ6o/PywTYiSyTXO+2S0hf56upGAjnUgo3ZzSHL6Qjsdpx8qeivu5O LVROiMBljALSsIUeU6DoOMO6pxgXKy9KZg0i9fK9gg4iN9C6n9uvoM1b9XcsaBHZlXAw pCxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=uDQ+he1/dWtR+adlJuZJVZfDLPIl/4ErEcqQ10DYq4k=; b=A7nWp1m7S7o2lk5/nKuVEzkw0d2/Abq15sAeF6q3OQY0cNp6v/geusXZToJ4xnBJaf ecrmtD9UuGSXp1aUzZ8yzdM/ou332YzZnFbf5abLAU68hF40y7LGxQ34Px55MFoqZhx9 35MwwoMkn66cFDHm6m6cbC2/lsIUzP57+abmMoT62p7C+HcGL1fFLU4gcKsS2dMuwSW8 rqXEVOe/XqtzUKQgSkGrp7NceUM+tyDVNPmpjSO7x7JNTk+oqXi/doDu+jqPMmmWt/Uf qTi+j4IdO6sM4U7c3ItBFozLkeK81kLsTaY1RK39rniGFB99wXkrAQKXs54VPntV4SPa 7Ubg== X-Gm-Message-State: AHYfb5ioMs41yPS4Qeg0iVeyXJ67eZpkzB5uCQkI88emG23rWF+KZevH 4nKNfjXZRbnFviYZhEUboQ== X-Received: by 10.98.217.10 with SMTP id s10mr26260122pfg.204.1502736344093; Mon, 14 Aug 2017 11:45:44 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:ccbc:81e6:20a8:21cf? ([2620:0:10e7:10:ccbc:81e6:20a8:21cf]) by smtp.gmail.com with ESMTPSA id d3sm14053953pgf.75.2017.08.14.11.45.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 11:45:43 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_82B4B358-719A-42EB-B078-E5488BE5F326" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 14 Aug 2017 11:46:01 -0700 References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> To: "v6ops@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:45:47 -0000 --Apple-Mail=_82B4B358-719A-42EB-B078-E5488BE5F326 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 13, 2017, at 23:51, Mikael Abrahamsson wrote: >=20 > I also think that the caching resolver should refresh = soon-to-be-expired RRs that are getting close to their TTL=3D0. For = instance, if someone is asking for an RR and it has less than 5% of its = TTL left, then just refresh it. >=20 > I believe there are drafts regarding this in DNSOP? You know what would be really terrible? If caching resolvers did this = for A records without also doing it for corresponding AAAA records. --james woodyatt > --Apple-Mail=_82B4B358-719A-42EB-B078-E5488BE5F326 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Aug 13, 2017, at 23:51, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

I also think that the caching resolver should refresh soon-to-be-expired RRs that are getting close to their TTL=0. For instance, if someone is asking for an RR and it has less than 5% of its TTL left, then just refresh it.

I believe there are drafts regarding this in DNSOP?

You know what would be really terrible? If caching resolvers did this for A records without also doing it for corresponding AAAA records.

--james woodyatt <jhw@google.com>



--Apple-Mail=_82B4B358-719A-42EB-B078-E5488BE5F326-- From nobody Mon Aug 14 12:16:07 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D776B13240D; Mon, 14 Aug 2017 12:16:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273816483.10517.3138745446079306628.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 12:16:04 -0700 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 100 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:16:05 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima Second Priority: opsec intarea mtgvenue sunset4 Third Priority: dnsop tsvwg spring rtgwg People who must be present: Fred Baker Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 14 12:17:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A0E13240F for ; Mon, 14 Aug 2017 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93W3Yzw5E9cx for ; Mon, 14 Aug 2017 12:17:52 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B962F13240D for ; Mon, 14 Aug 2017 12:17:52 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x3so93223184oia.1 for ; Mon, 14 Aug 2017 12:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:mime-version:subject:date:references:to:message-id; bh=WAMveVGcJviHAuBfgIx9nniPBJgUgDhi6wJljKr0n/U=; b=q7FXWgxFXkFlxn0StS/mKFB8fpNaV47kwAaGVe6r3esAQYsDTvEdXsW8SaKE/faJbE uxXg5/0VcezCWrcmoibshKVj8SpixHT/XUvKwycwyp29b1laikm/zT2/IZ9Egw/SMZre DN61WobTBKfrpKKBOOXlwGsY3F/hBahOneoo0JBiY8KdlqfK+1xyn0Sqh5TLzefZbOf0 J0d8vAuhHaJZRX0mYUTIIoZa0HwiIessrpIgE7RA6zKHSYEtQtzqrfazSGV8PM20++C2 16emL4yTeFysGs9KLoExiXJwIQYH1izqawPGLrjZMNt6EuUxp4nTzh3axz31nsnqnYGo dw7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:date :references:to:message-id; bh=WAMveVGcJviHAuBfgIx9nniPBJgUgDhi6wJljKr0n/U=; b=JS6+i6eDiidHdbp+FrLzeX6j3J5I8BAdNkQ3EpqNgzOlS/Wy2sYR5mI9AgrjHLlBuu w8pKCyWbsgt/2Ntbu7zlwkWzFMXb+14+YJaAwAUGtMeaG+xl5MMu/Suo1jdWyw5W+Nrg u9U8zL1aJ/Nzlkr0JD+u8y5E0vmGzbrEfxH0edoX9BkSa0dbkbGGgA00B9gSt5rGd9cL WHXBbO5To1M+aDArAcvvRsKbgnkW0QVrBqGob3uQ+QgFoOG1WNwSiVtWCfT+cgyM4HJs whTE/8n8ygL5CeXcILZ2+AEEVf64Ek3lzTN5+kQJOY581sCYINOSFKCTQePo55XBG8Jn Q9cw== X-Gm-Message-State: AHYfb5ikQ+QP6aIV6bCHmkj2TXB9IUZuohhGDCUB35d1sSr6p0Luq28F JUgjYxlu6miTuJi3HMw= X-Received: by 10.202.198.23 with SMTP id w23mr26965721oif.168.1502738271908; Mon, 14 Aug 2017 12:17:51 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1281? ([2600:8802:5600:1e::1281]) by smtp.gmail.com with ESMTPSA id e136sm14338917oih.36.2017.08.14.12.17.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 12:17:51 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_9EA07DB7-576F-438D-B3C5-0AD6BA63BE32" Reply-To: V6ops Chairs Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3443.1\)) Date: Mon, 14 Aug 2017 12:17:49 -0700 References: <150273816483.10517.3138745446079306628.idtracker@ietfa.amsl.com> To: IPv6 Ops WG Message-Id: <4EFCC01E-8AD1-4983-BE44-766192B9ADAE@gmail.com> X-Mailer: Apple Mail (2.3443.1) Archived-At: Subject: [v6ops] Fwd: v6ops - New Meeting Session Request for IETF 100 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:17:54 -0000 --Apple-Mail=_9EA07DB7-576F-438D-B3C5-0AD6BA63BE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have just put in a request for meetings at IETF #100. Please look = through the clash list and see if you want something added to it. If so, = let the chairs know. > Begin forwarded message: >=20 > From: IETF Meeting Session Request Tool > Subject: v6ops - New Meeting Session Request for IETF 100 > Date: August 14, 2017 at 12:16:04 PM PDT > To: > Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, = fredbaker.ietf@gmail.com >=20 >=20 >=20 > A new meeting session request has just been submitted by Fred Baker, a = Chair of the v6ops working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 2 > Length of Session(s): 2 Hours, 2 Hours > Number of Attendees: 150 > Conflicts to Avoid:=20 > First Priority: 6man 6lo 6tisch homenet opsawg anima > Second Priority: opsec intarea mtgvenue sunset4 > Third Priority: dnsop tsvwg spring rtgwg >=20 >=20 > People who must be present: > Fred Baker > Ron Bonica > Lee Howard > Warren Kumari >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 --Apple-Mail=_9EA07DB7-576F-438D-B3C5-0AD6BA63BE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have just put in a request for meetings at IETF #100. Please look = through the clash list and see if you want something added to it. If so, = let the chairs know.

Begin forwarded = message:

From: = IETF Meeting Session Request = Tool <session-request@ietf.org>
Subject: = v6ops - New = Meeting Session Request for IETF 100
Date: = August 14, 2017 at 12:16:04 PM = PDT
To: = <session-request@ietf.org>
Cc: = warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com



A= new meeting session request has just been submitted by Fred Baker, a = Chair of the v6ops working group.


---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: = Operations and Management Area
Session Requester: Fred = Baker

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 150
Conflicts to Avoid: =
First Priority: 6man 6lo 6tisch homenet opsawg anima
Second Priority: opsec intarea mtgvenue sunset4
= Third Priority: dnsop tsvwg spring rtgwg

People who must be present:
 Fred = Baker
 Ron Bonica
 Lee Howard
 Warren Kumari

Resources = Requested:

Special Requests:

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


= --Apple-Mail=_9EA07DB7-576F-438D-B3C5-0AD6BA63BE32-- From nobody Mon Aug 14 17:26:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132A6132467 for ; Mon, 14 Aug 2017 17:26:03 -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, 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 297M24BTpqps for ; Mon, 14 Aug 2017 17:26:01 -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 36872132466 for ; Mon, 14 Aug 2017 17:26:01 -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 07F9634B753; Tue, 15 Aug 2017 00:25:58 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E98F8160045; Tue, 15 Aug 2017 00:25:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D73701600B0; Tue, 15 Aug 2017 00:25:57 +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 GzpzznCqbDnU; Tue, 15 Aug 2017 00:25:57 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 55674160045; Tue, 15 Aug 2017 00:25:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id ED9B482504CE; Tue, 15 Aug 2017 10:25:53 +1000 (AEST) To: Mikael Abrahamsson Cc: Tommy Pauly , "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> In-reply-to: Your message of "Mon, 14 Aug 2017 12:00:22 +0200." Date: Tue, 15 Aug 2017 10:25:53 +1000 Message-Id: <20170815002553.ED9B482504CE@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 00:26:03 -0000 In message , Mikael Abraha msson writes: > On Mon, 14 Aug 2017, Mark Andrews wrote: > > > When only one of A or AAAA RRsets is present in the cache you have > > lookup times < 10ms for the RRset that is present in the cache and > > ~200ms for the RRset that isn't in the cache but the nameserver > > information is present. Waiting a realistic period for the cache > > miss to be filled is not "setting a really high advantage for IPv6 > > over IPv4". It's giving them equal standing. > > Yes, but most of the requests will not have this problem, but you want to > set the time to take into account this edge case to slow down all > fall-back cases to IPv4? You obviously do not understand the message you replied to if that is the message you took out of it. Please go bag and re-read it. No I'm not asking to slow down all fall-back cases to IPv4. > Also, I already said you were correct in your analysis, but I just don't > agree that we need to bring up the wait period for IPv4 to handle the > problem you're describing. Yes it happens, I am not disputing that. I just > don't see the huge disadvantage you seem to be seeing in doing a few IPv4 > accesses when it could eventually had been used over IPv6 instead. At > least not at this point in time. I design software so that it will be behaving well in 10, 15 years time. I do this because I know people are still running the software I released 20 years ago. I was also doing this 20 years ago. The way RFC6555bis is at the moment the timers are such that you do not even wait for a reply from a single authoritative server. Now if I was trying to do the absolute fastest connection that would be the strategy I would be using but that strategy does not match IETF consensus that IPv6 should be tried before IPv4. Just waiting 50ms doesn't come close to meeting that consensus. > > When IPv6 lookups are broken they usually take significantly longer than > > a additional 200ms to complete as you end up with multiple queries being > > made. > > So your proposal is to wait for the AAAA lookup to complete, even if this > takes several seconds? I don't know where you are getting this several seconds from. If we have a cache hit and a cache miss the server will usually have NS and associated address records for the zone so you are looking at a single packet exchange most of the time which was the timer value I was talking about. That's all 200ms gives you. I'm not asking to wait for the AAAA lookup to always complete. I'm just asking for it to have a fair chance to succeed rather than having almost no chance of succeeding. 50ms give 1% of IPv4 traffic if I'm correctly understanding what was presented in the video from Prague. Why are we happy with a 1% error rate? Why not 0.1% or 0.01%? > Just to make sure we might get an answer, eventually? I also don't know where you are getting the "eventually" from but AAAA lookups succeed (NOERROR/NXDOMAIN) 99.78% (0.22% failure) of the time over the Alexa top 1 Million for names where A lookups succeed (0.28% failure rate). It's companies that decide to use load balancers and then misconfigure them (they have the wrong backing zone behind the load balancer) that see AAAA lookups fail or those that host parked zones and instead of configuring a individual zone configure a .com or root zone with a wildcard record resulting in the wrong SOA record being returned. These misconfigurations cause the recursive server to try all of the authoritative servers for a answer before returning SERVFAIL. > > Which hides some cache misses from the client but not all of them. Been > > there, done that. > > Happy Eyeballs is all about compromise between user experience and "use > IPv6 at all cost". 50ms seems like a good value at this point in time. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 14 19:25:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610441324A1 for ; Mon, 14 Aug 2017 19:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Me3mnp4F8k1d for ; Mon, 14 Aug 2017 19:25:44 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 384E0132489 for ; Mon, 14 Aug 2017 19:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502763943; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6S3wElCEdhMXQGHJD+6SxLafTwlpCtQqG65z/lIU3vI=; b=bvofAhjgjA3MqPM8ikgEmMInrnLPTIfVxUgYJ/kAc7Bq6wL4lGsFxBLojovYRMxd I8U9N5Nc3MBQdKx6f1DNckJXBAX6y+uzVOp9gv07kzPNirntOKMLasRvpwrRloOv 1ajlAKnrDRxfRkPISsyGN2kqBqrTnfwFuNhKUNkzz85yM1joYydv1tGWdqzoFD62 KtbwVNL+vSiPyjYHgbUggfVt6g4l0y6zJJ4jnA0XgdcgawVMesryyTEPvf4NYmF4 HIHN103mh6O6m30xjA0mP6qWDqZL9776LtvtLoL6OgqVWU3TwyrI9jvOGkyVF3fh zPmA9B53gjXND//7qJIFyA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 38.0E.07214.7AB52995; Mon, 14 Aug 2017 19:25:43 -0700 (PDT) X-AuditID: 11973e11-327ff70000001c2e-00-59925ba7f31b Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id C2.B9.10385.7AB52995; Mon, 14 Aug 2017 19:25:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.125.69] (unknown [17.234.125.69]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUP00FXPG2R4R10@jimbu.apple.com>; Mon, 14 Aug 2017 19:25:43 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <20170815002553.ED9B482504CE@rock.dv.isc.org> Date: Mon, 14 Aug 2017 19:25:38 -0700 Cc: Mikael Abrahamsson , "v6ops@ietf.org" Message-id: <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com> References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FAYobs8elKkwaobuhZXXtxnsXi5dCub xelje5kdmD2WLPnJ5PHg8Ttmj7+THjIFMEdx2aSk5mSWpRbp2yVwZSyc1sdacFq3YseXcywN jF0qXYwcHBICJhJHXph2MXJxCAmsZpJYf3gHcxcjJ1j81/8LjCC2kMAGRon1X3lAbF4BQYkf k++xgPQyC8hLHDwvCxJmFtCS+P6olQVizn9Gieu75oD1CgtIS3RduMsKYWtIPH22nAmklw2o 4cAaI5Awp4CVxK3+s4wgYRYBVYlnj3IgRvpIfPrUwgKx1UZi7+PbzBDj77BJ7H0+GywhIqAg 0fb2FRPEybISt2ZfAiuSENjCJnFhXSfrBEbhWUjOnoVw9iwkZy9gZF7FKJSbmJmjm5lnpJdY UJCTqpecn7uJERTo0+0EdzAeX2V1iFGAg1GJh5fjwsRIIdbEsuLK3EOM0hwsSuK81haTIoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw3rPqfnFZdo+D7Tprk1bN12/9T305+/G4kMK+tXqc 3S6KAd7FvbsZnayMi77a8n1P0bFxnSH0N/X4+sMti5vNbH/fKp9uHeM0eRX3KV9O398HHAr2 Gh8SevRYljf46bm1qvnML3cEab9VunjY7Jaa50/et/v+7Lxc+8Yn0m1KhoTOh/3rd7UkKrEU ZyQaajEXFScCAM1z9UxVAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUiON1OVXd59KRIg4u7NCyuvLjPYvFy6VY2 i9PH9jI7MHssWfKTyePB43fMHn8nPWQKYI7isklJzcksSy3St0vgylg4rY+14LRuxY4v51ga GLtUuhg5OSQETCR+/b/ACGILCWxglFj/lQfE5hUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnv j1qBwlxA5f8ZJa7vmgPWKywgLdF14S4rhK0h8fTZciaQXjaghgNrjEDCnAJWErf6zzKChFkE VCWePcqBGOkj8elTCwvEVhuJvY9vM0OMv8Mmsff5bLCEiICCRNvbV0wQJ8tK3Jp9iXkCo8As JJfOQrh0FpJLFzAyr2IUKErNSaw01UssKMhJ1UvOz93ECArNhsKIHYz/l1kdYhTgYFTi4d1w dmKkEGtiWXFl7iFGCQ5mJRFeJfVJkUK8KYmVValF+fFFpTmpxYcYq4Dun8gsJZqcD4ybvJJ4 QxMTAxNjYzNjY3MTc6oIK4nzTu/ojhQSSE8sSc1OTS1ILYJZzsTBKdXA6BJ3OjLG2LM59pRu 8w0zzr3MPPuYrZeb7NI+ceHplQlWlosZD+xd+UnFqj79QdM6aa7e0p0u1gdusjiLLzyTe8au 7G2LjiW7aFS+sYGcxRnBjw7SuuI/vJx+NDfrpc/65f3dw17yUWabCq/Cu1mx/707a4MvH27g W8v97qD/017Rc/xhXkeVWIozEg21mIuKEwFbhQOAqAIAAA== Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 02:25:46 -0000 Mark, Most general-purpose consumer operating systems have been dual-stack for a while now. On dual-stack networks, when modern devices make DNS queries, they'll almost always ask for both A and AAAA. This means that in most cases the cache at the recursive resolver will either contain both or neither response. In that case the time to get either response is roughly the same. So 50ms is a generous time to account for many standard deviations between both responses. Better yet, we've deployed this to over a billion devices for several years now, and we have collected data from networks worldwide indicating that we do indeed prefer IPv6, and your edge-cases are negligible in practice. The 50ms timer optimizes user experience will ensuring that the overwhelming majority of connections (>99%) go over IPv6. If we assume that the average packet loss rate of the internet is 1%, then you have roughly a 1.95% chance of having either the AAAA query or response lost with neither the A request nor response lost. In that case it will only be retransmitted 1s later so any timer value less than 1s will not be able to catch that. They just waste the user's time. So, while I understand your concerns, data shows they are theoretical and impractical. You can set 200ms on your own devices and still be compliant with RFC6555bis. David Schinazi > On Aug 14, 2017, at 17:25, Mark Andrews wrote: > > > In message , Mikael Abraha > msson writes: >> On Mon, 14 Aug 2017, Mark Andrews wrote: >> >>> When only one of A or AAAA RRsets is present in the cache you have >>> lookup times < 10ms for the RRset that is present in the cache and >>> ~200ms for the RRset that isn't in the cache but the nameserver >>> information is present. Waiting a realistic period for the cache >>> miss to be filled is not "setting a really high advantage for IPv6 >>> over IPv4". It's giving them equal standing. >> >> Yes, but most of the requests will not have this problem, but you want to >> set the time to take into account this edge case to slow down all >> fall-back cases to IPv4? > > You obviously do not understand the message you replied to if that is > the message you took out of it. Please go bag and re-read it. No I'm > not asking to slow down all fall-back cases to IPv4. > >> Also, I already said you were correct in your analysis, but I just don't >> agree that we need to bring up the wait period for IPv4 to handle the >> problem you're describing. Yes it happens, I am not disputing that. I just >> don't see the huge disadvantage you seem to be seeing in doing a few IPv4 >> accesses when it could eventually had been used over IPv6 instead. At >> least not at this point in time. > > I design software so that it will be behaving well in 10, 15 years > time. I do this because I know people are still running the software > I released 20 years ago. I was also doing this 20 years ago. > > The way RFC6555bis is at the moment the timers are such that you > do not even wait for a reply from a single authoritative server. > Now if I was trying to do the absolute fastest connection that would > be the strategy I would be using but that strategy does not match > IETF consensus that IPv6 should be tried before IPv4. Just waiting 50ms > doesn't come close to meeting that consensus. > >>> When IPv6 lookups are broken they usually take significantly longer than >>> a additional 200ms to complete as you end up with multiple queries being >>> made. >> >> So your proposal is to wait for the AAAA lookup to complete, even if this >> takes several seconds? > > I don't know where you are getting this several seconds from. If > we have a cache hit and a cache miss the server will usually have > NS and associated address records for the zone so you are looking > at a single packet exchange most of the time which was the timer > value I was talking about. That's all 200ms gives you. I'm not > asking to wait for the AAAA lookup to always complete. I'm just > asking for it to have a fair chance to succeed rather than having > almost no chance of succeeding. > > 50ms give 1% of IPv4 traffic if I'm correctly understanding what > was presented in the video from Prague. Why are we happy with a > 1% error rate? Why not 0.1% or 0.01%? > >> Just to make sure we might get an answer, eventually? > > I also don't know where you are getting the "eventually" from but > AAAA lookups succeed (NOERROR/NXDOMAIN) 99.78% (0.22% failure) of > the time over the Alexa top 1 Million for names where A lookups > succeed (0.28% failure rate). It's companies that decide to use > load balancers and then misconfigure them (they have the wrong > backing zone behind the load balancer) that see AAAA lookups fail > or those that host parked zones and instead of configuring a > individual zone configure a .com or root zone with a wildcard record > resulting in the wrong SOA record being returned. These misconfigurations > cause the recursive server to try all of the authoritative servers > for a answer before returning SERVFAIL. > >>> Which hides some cache misses from the client but not all of them. Been >>> there, done that. >> >> Happy Eyeballs is all about compromise between user experience and "use >> IPv6 at all cost". 50ms seems like a good value at this point in time. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 14 20:45:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C31132412 for ; Mon, 14 Aug 2017 20:45:51 -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, 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 NN_lRCBX1jA7 for ; Mon, 14 Aug 2017 20:45:49 -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 6A3F3132125 for ; Mon, 14 Aug 2017 20:45:49 -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 1DEF934BFBC; Tue, 15 Aug 2017 03:45:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0C893160045; Tue, 15 Aug 2017 03:45:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EADB4160067; Tue, 15 Aug 2017 03:45:41 +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 t1A3RrAVdpan; Tue, 15 Aug 2017 03:45:41 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 61B81160045; Tue, 15 Aug 2017 03:45:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2022A825C569; Tue, 15 Aug 2017 13:45:39 +1000 (AEST) To: David Schinazi Cc: Mikael Abrahamsson , "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com> In-reply-to: Your message of "Mon, 14 Aug 2017 19:25:38 -0700." <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com> Date: Tue, 15 Aug 2017 13:45:39 +1000 Message-Id: <20170815034539.2022A825C569@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 03:45:52 -0000 In message <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com>, David Schinazi wri tes: > Mark, > > Most general-purpose consumer operating systems have been dual-stack > for a while now. On dual-stack networks, when modern devices make DNS > queries, they'll almost always ask for both A and AAAA. This means that > in most cases the cache at the recursive resolver will either contain > both or neither response. In that case the time to get either response > is roughly the same. So 50ms is a generous time to account for many > standard deviations between both responses. > > Better yet, we've deployed this to over a billion devices for several > years now, and we have collected data from networks worldwide indicating > that we do indeed prefer IPv6, and your edge-cases are negligible in > practice. The 50ms timer optimizes user experience will ensuring that > the overwhelming majority of connections (>99%) go over IPv6. > > If we assume that the average packet loss rate of the internet is 1%, > then you have roughly a 1.95% chance of having either the AAAA query > or response lost with neither the A request nor response lost. In that > case it will only be retransmitted 1s later so any timer value less > than 1s will not be able to catch that. They just waste the user's time. Does it hurt to have a 300ms timer that starts when the AAAA query is issued which stops the A RRset being used until that timer clears unless there has been a reply to the AAAA lookup? I'm asking for there being a chance that a cache miss on the AAAA lookup can succeed in getting a AAAA RRset returned. Today there is almost no chance. This does not slow down queries where both A and AAAA responses are cached (as you should get both answers in well under that time) or neither are cached. If there ttls remain sychronised this degenerates to what you already have and if they don't it allows for a single refresh to succeed. It isn't waiting for packet loss retransmission except for authoritative servers that are known to be topologicaly close based on their previous response times. Yes, recursive servers use sub-second retransmission timers. e.g. max(50, (300 - elasped-time-ms)) Mark > So, while I understand your concerns, data shows they are theoretical > and impractical. You can set 200ms on your own devices and still be > compliant with RFC6555bis. Don't insult my intelligence by repeating this again. What I do has no statistical signicicance. Whats in the document does. > David Schinazi > > > > On Aug 14, 2017, at 17:25, Mark Andrews wrote: > > > > > > In message , Mikael Ab > raha > > msson writes: > >> On Mon, 14 Aug 2017, Mark Andrews wrote: > >> > >>> When only one of A or AAAA RRsets is present in the cache you have > >>> lookup times < 10ms for the RRset that is present in the cache and > >>> ~200ms for the RRset that isn't in the cache but the nameserver > >>> information is present. Waiting a realistic period for the cache > >>> miss to be filled is not "setting a really high advantage for IPv6 > >>> over IPv4". It's giving them equal standing. > >> > >> Yes, but most of the requests will not have this problem, but you want to > >> set the time to take into account this edge case to slow down all > >> fall-back cases to IPv4? > > > > You obviously do not understand the message you replied to if that is > > the message you took out of it. Please go bag and re-read it. No I'm > > not asking to slow down all fall-back cases to IPv4. > > > >> Also, I already said you were correct in your analysis, but I just don't > >> agree that we need to bring up the wait period for IPv4 to handle the > >> problem you're describing. Yes it happens, I am not disputing that. I just > > >> don't see the huge disadvantage you seem to be seeing in doing a few IPv4 > >> accesses when it could eventually had been used over IPv6 instead. At > >> least not at this point in time. > > > > I design software so that it will be behaving well in 10, 15 years > > time. I do this because I know people are still running the software > > I released 20 years ago. I was also doing this 20 years ago. > > > > The way RFC6555bis is at the moment the timers are such that you > > do not even wait for a reply from a single authoritative server. > > Now if I was trying to do the absolute fastest connection that would > > be the strategy I would be using but that strategy does not match > > IETF consensus that IPv6 should be tried before IPv4. Just waiting 50ms > > doesn't come close to meeting that consensus. > > > >>> When IPv6 lookups are broken they usually take significantly longer than > >>> a additional 200ms to complete as you end up with multiple queries being > >>> made. > >> > >> So your proposal is to wait for the AAAA lookup to complete, even if this > >> takes several seconds? > > > > I don't know where you are getting this several seconds from. If > > we have a cache hit and a cache miss the server will usually have > > NS and associated address records for the zone so you are looking > > at a single packet exchange most of the time which was the timer > > value I was talking about. That's all 200ms gives you. I'm not > > asking to wait for the AAAA lookup to always complete. I'm just > > asking for it to have a fair chance to succeed rather than having > > almost no chance of succeeding. > > > > 50ms give 1% of IPv4 traffic if I'm correctly understanding what > > was presented in the video from Prague. Why are we happy with a > > 1% error rate? Why not 0.1% or 0.01%? > > > >> Just to make sure we might get an answer, eventually? > > > > I also don't know where you are getting the "eventually" from but > > AAAA lookups succeed (NOERROR/NXDOMAIN) 99.78% (0.22% failure) of > > the time over the Alexa top 1 Million for names where A lookups > > succeed (0.28% failure rate). It's companies that decide to use > > load balancers and then misconfigure them (they have the wrong > > backing zone behind the load balancer) that see AAAA lookups fail > > or those that host parked zones and instead of configuring a > > individual zone configure a .com or root zone with a wildcard record > > resulting in the wrong SOA record being returned. These misconfigurations > > cause the recursive server to try all of the authoritative servers > > for a answer before returning SERVFAIL. > > > >>> Which hides some cache misses from the client but not all of them. Been > >>> there, done that. > >> > >> Happy Eyeballs is all about compromise between user experience and "use > >> IPv6 at all cost". 50ms seems like a good value at this point in time. > >> > >> -- > >> Mikael Abrahamsson email: swmike@swm.pp.se > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 14 22:17:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6F1323C4 for ; Mon, 14 Aug 2017 22:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfLPkqKKe-tc for ; Mon, 14 Aug 2017 22:17:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE301324C1 for ; Mon, 14 Aug 2017 22:17:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E1BACAF; Tue, 15 Aug 2017 07:17:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502774245; bh=gSkZqpcoNq+3r4xL7655/YEdl1KDkgU0iFO5nCSQ/vc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Cw6UMNNu1fjaxmAW/uxGNsr0fcUHyUJVvMT2FF9/J9MRRYs6wsQBtDaffU9Ir9tci cwA2jjqTAn6qwa62V+QbtCX6Gk/IHPkzHZndh4nmI44As/gkvCGTlczYgU0kIeQK1V tfZJvMtIUgwLNeF/StYRk5H7+UPUgi3BTLW55tUc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C9CF384; Tue, 15 Aug 2017 07:17:25 +0200 (CEST) Date: Tue, 15 Aug 2017 07:17:25 +0200 (CEST) From: Mikael Abrahamsson To: Tommy Pauly , Mark Andrews cc: "v6ops@ietf.org" In-Reply-To: <20170815002553.ED9B482504CE@rock.dv.isc.org> Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 05:17:32 -0000 On Tue, 15 Aug 2017, Mark Andrews wrote: > I don't know where you are getting this several seconds from. If > we have a cache hit and a cache miss the server will usually have > NS and associated address records for the zone so you are looking > at a single packet exchange most of the time which was the timer > value I was talking about. That's all 200ms gives you. I'm not 200ms doesn't give you a response if the authoritative server is on the other side of the world. Australia is 350ms or more away from me. I've regularily seen 450ms RTT to places. Where did this 200ms figure come from? This is why I am referring to "seconds", because if you want to make sure to get any available A and AAAA for a lot of different corner cases, then you soon end up with very big numbers. Also, what about James Woodyatts idea of having the resolver sync AAAA and A queries so that if there is A or AAAA query and there is an impending TTL expire of any of them, this should fire up a refresh of the soon-to-be-expired information in the caching resolver? This would mean that the caching resolver would "always" have information in its cache for both A and AAAA records. I think this is a better place to solve your concern than to increase the timers in the HE implementation. However... Tommy/David, do you have numbers on how often the problem Mark is talking about, actually occurs? Ie lookup times for A and AAAA, and when the IPv4 goes into "Start TCP" in https://www.ietf.org/proceedings/99/slides/slides-99-v6ops-sessa-happy-eyeballs-v2-00.pdf slide 4, and IPv6 didn't even start because the AAAA response arrived much later? Or are the DNS lookup time and TCP established time lumped together in your data (which was my takeaway when I saw the presentation). I have no idea what the packet loss rate are for resolver lookups (traffic between client and resolver). Do we have data on that? Because if the packet loss rate is very low then what I feared wouldn't be a problem. Right now it seems DNSresolve+TCP is 50ms head start for IPv6, right? To solve what Mark wants to solve (if I understand it correctly), this would have to be bumped up to 200ms, BUT, to solve your (and mine) TCP establishment concerns, as soon as the IPv6 DNS+TCP subflow goes into TCP SYN, it should send a signal to the IPv4 subflow to say "I'm going into TCP syn now, you can decrease your timer to 50ms if it's higher than 50ms". This would mean that any DNS induced delay would be 200ms max, but any TCP induced delay would be max 50ms. Mark, would this solve most of your concerns? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Aug 14 23:39:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623351204DA for ; Mon, 14 Aug 2017 23:38:53 -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, 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 WJ4DXDeaLz48 for ; Mon, 14 Aug 2017 23:38:51 -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 88A901323C4 for ; Mon, 14 Aug 2017 23:38:51 -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 2A28F349C69; Tue, 15 Aug 2017 06:36:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 18DB1160045; Tue, 15 Aug 2017 06:36:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F2466160067; Tue, 15 Aug 2017 06:36:26 +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 fHFNRgXfO-jE; Tue, 15 Aug 2017 06:36:26 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 58E28160045; Tue, 15 Aug 2017 06:36:26 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DDA228266470; Tue, 15 Aug 2017 16:36:23 +1000 (AEST) To: Mikael Abrahamsson Cc: Tommy Pauly , "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> In-reply-to: Your message of "Tue, 15 Aug 2017 07:17:25 +0200." Date: Tue, 15 Aug 2017 16:36:23 +1000 Message-Id: <20170815063623.DDA228266470@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 06:38:53 -0000 In message , Mikael Abraha msson writes: > On Tue, 15 Aug 2017, Mark Andrews wrote: > > > I don't know where you are getting this several seconds from. If > > we have a cache hit and a cache miss the server will usually have > > NS and associated address records for the zone so you are looking > > at a single packet exchange most of the time which was the timer > > value I was talking about. That's all 200ms gives you. I'm not > > 200ms doesn't give you a response if the authoritative server is on the > other side of the world. Australia is 350ms or more away from me. I've > regularily seen 450ms RTT to places. Where did this 200ms figure come > from? This is why I am referring to "seconds", because if you want to make > sure to get any available A and AAAA for a lot of different corner cases, > then you soon end up with very big numbers. The UK is ~200ms from here in Sydney, Australia. The example I posted up thread was 206ms. Yes, I was only allowing for a single query to the other side of the world. Most of the time that is all that is needed as the recursive server will still have the NS records and associated adddress records. Whether the time is 200ms or 400ms is negotiable. The current 50ms makes most of the world unreachable. > Also, what about James Woodyatts idea of having the resolver sync AAAA and > A queries so that if there is A or AAAA query and there is an impending > TTL expire of any of them, this should fire up a refresh of the > soon-to-be-expired information in the caching resolver? This would mean > that the caching resolver would "always" have information in its cache for > both A and AAAA records. Actually it wont and it wouldn't fix this issue where there is a cache miss on the AAAA and a cache hit on the A record. What we are designing should work when A records have TTLs of 3600 and AAAA records have 0 and 1 second TTLs. As it currently is designed it won't work (produce IPv6 connections most of the time) and it should. The design is wrong if it doesn't. It shouldn't depend on authoritative server operators having equal value TTLs for A and AAAA RRsets for it to work regardles of how common that is. > I think this is a better place to solve your concern than to increase the > timers in the HE implementation. However... > > Tommy/David, do you have numbers on how often the problem Mark is talking > about, actually occurs? Ie lookup times for A and AAAA, and when the IPv4 > goes into "Start TCP" in > https://www.ietf.org/proceedings/99/slides/slides-99-v6ops-sessa-happy-eyebal > ls-v2-00.pdf > slide 4, and IPv6 didn't even start because the AAAA response arrived much > later? Or are the DNS lookup time and TCP established time lumped together > in your data (which was my takeaway when I saw the presentation). > > I have no idea what the packet loss rate are for resolver lookups (traffic > between client and resolver). Do we have data on that? Because if the > packet loss rate is very low then what I feared wouldn't be a problem. > > Right now it seems DNSresolve+TCP is 50ms head start for IPv6, right? To > solve what Mark wants to solve (if I understand it correctly), this would > have to be bumped up to 200ms, BUT, to solve your (and mine) TCP > establishment concerns, as soon as the IPv6 DNS+TCP subflow goes into TCP > SYN, it should send a signal to the IPv4 subflow to say "I'm going into > TCP syn now, you can decrease your timer to 50ms if it's higher than > 50ms". > > This would mean that any DNS induced delay would be 200ms max, but any TCP > induced delay would be max 50ms. > > Mark, would this solve most of your concerns? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 14 23:51:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060641323C4 for ; Mon, 14 Aug 2017 23:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlvGHU4LEn2R for ; Mon, 14 Aug 2017 23:51:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9278B126C22 for ; Mon, 14 Aug 2017 23:51:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 55E07AF; Tue, 15 Aug 2017 08:51:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502779871; bh=O/GGPY/KL2eYZetVjSMyxac7fn+1mBodxtmNUuPsgEY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AW2J/XpvUZ3+o9FuctgZNlbj1oxYe93wZ4C6/1h0TP2NYI0nmc6uY66abc0o46mOA H1f0eol7+TSMP7aQty0QzPpsmeoAUQA4zO6XV1XQaf9NecCMhNg+bZ17g1DHVTwv3b jxbfqcBqXh20m7CLyCYo1tEyEKSPDpM6iXFDlHY8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 52D8884; Tue, 15 Aug 2017 08:51:11 +0200 (CEST) Date: Tue, 15 Aug 2017 08:51:11 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: Tommy Pauly , "v6ops@ietf.org" In-Reply-To: <20170815063623.DDA228266470@rock.dv.isc.org> Message-ID: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> <20170815063623.DDA228266470@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 06:51:16 -0000 On Tue, 15 Aug 2017, Mark Andrews wrote: > The UK is ~200ms from here in Sydney, Australia. The example I > posted up thread was 206ms. Yes, I was only allowing for a single > query to the other side of the world. Most of the time that is all > that is needed as the recursive server will still have the NS records > and associated adddress records. Whether the time is 200ms or 400ms > is negotiable. The current 50ms makes most of the world unreachable. 200ms RTT? What path do you take then? That seems very low. > Actually it wont and it wouldn't fix this issue where there is a cache > miss on the AAAA and a cache hit on the A record. What we are designing > should work when A records have TTLs of 3600 and AAAA records have 0 and > 1 second TTLs. As it currently is designed it won't work (produce IPv6 > connections most of the time) and it should. The design is wrong if it > doesn't. It shouldn't depend on authoritative server operators having > equal value TTLs for A and AAAA RRsets for it to work regardles of how > common that is. As I said, I have 350ms RTT to Australia. So in the above example, 200ms won't be enough. We need it to be at least 500ms to solve the problem you describe above. I think that's too much. What if the authoritiative nameserver is two satellite hops away, then we need 2 seconds? Also it doesn't depend on them having equal values, it depends on them having a value that is more than 5-10 seconds TTL and there are frequent queries. Putting in a 500ms (or more) delay just because someone might set a 1 second TTL, that seems extreme to me. Because there are other failure scenarios where 500ms delay will cause a severe customer experience degradation, where it's completely unneccesary to wait that long. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 00:29:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98013257B for ; Tue, 15 Aug 2017 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8JTxOcn3zkV for ; Tue, 15 Aug 2017 00:29:18 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816851200B9 for ; Tue, 15 Aug 2017 00:29:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id k20so21878685wmg.0 for ; Tue, 15 Aug 2017 00:29:18 -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-transfer-encoding:content-language; bh=UVayUsSAbzVHP6lp1SBEZrDEQfBS4Tp+r5Og60Cbtjk=; b=pmeHcvylIsHR1nJTaGxudR+UljH0AxnB0PGld01fVJJXG471pO7KrvgTRcSAm8baWk ND2XB27G5XNDMFIw9Jd4zWq7Sdta5ue6xcQzunoDHhya9YfcTUgEZvt2bP2XZEYZU2tk ryMDGnDx1/449kL7sjeraHyKigYFVjzKF/S98EIVqi1IsL952JHyyoIgqzxEhZ/jsi0i uPJOIG7YOsteuq1ougz5zAUXwHgqJV0jDdiSrLsDGeG4rd201XrClg8UsTvXEGYqLtBd O7tJJ7f1You/lXg9vGiPOqj8/oTNcib8Area+K7L/tCp6mSuMu3ziFYPsmFnGH06m9mn k7cg== 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-transfer-encoding :content-language; bh=UVayUsSAbzVHP6lp1SBEZrDEQfBS4Tp+r5Og60Cbtjk=; b=QAsKBzsFMfXzPfHoG+a3Dc8sn+BXgs1O4imGKkpfZXp0tEQPOtjZt1c4F+AQr+gbav aOiJM1F98KiPa27neq1PgWp42oNJIAfPOqRN4kYwVZ50HS2372N4YicS0ipDMyIYGEHZ hy2azPRmJIYdONVj4IFyIsR9f5xN2hYzZR665Xt9AA/6ecXbZ8iZ8ei8g5Sx9WE/XC7m Qnlp6U18lnLxGJiA41tTJHIdbVw9X26+HOyZWrJqHYA8/5hmWUP+SW9rQBT6XTTWpYlY EF50/RZxAxwyyo346+NXbX9qck5iORLWpt9trw6/lZam/I+c5H0s3PlxebH0+exDYYIl xrAQ== X-Gm-Message-State: AHYfb5hP3cwI9IYhN01dt22QZhkMabn8QtuR4+18cOyeG7qCNAg2vkeG onoXu72jyqZj0D4hPSc= X-Received: by 10.80.222.66 with SMTP id a2mr26859489edl.249.1502782156652; Tue, 15 Aug 2017 00:29:16 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:4097:eaf8:630b:e09e]) by smtp.gmail.com with ESMTPSA id z88sm4737756ede.36.2017.08.15.00.29.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 00:29:15 -0700 (PDT) To: "v6ops@ietf.org" References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <20170811014229.747B98208B3C@rock.dv.isc.org> <4CEEB2DC-CF09-45B4-B7D6-2591506E0B07@apple.com> <20170811055735.C543A82149BB@rock.dv.isc.org> <304BCCE2-C4BF-4392-B4DD-B36F35FD9F23@apple.com> <20170813233141.EEEAF82278E9@rock.dv.isc.org> <20170814085112.63308823972C@rock.dv.isc.org> <20170815002553.ED9B482504CE@rock.dv.isc.org> <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com> From: Stephen Strowes Message-ID: <7f63b757-461c-fbc8-c2fd-25270e4a22e4@gmail.com> Date: Tue, 15 Aug 2017 09:29:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <9046603A-EDA6-43E4-95C2-65FE8F26BCD5@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 07:29:21 -0000 On 15/08/2017 04:25, David Schinazi wrote: > Most general-purpose consumer operating systems have been dual-stack for a while now. On dual-stack networks, when modern devices make DNS queries, they'll almost always ask for both A and AAAA. This means that in most cases the cache at the recursive resolver will either contain both or neither response. In that case the time to get either response is roughly the same. So 50ms is a generous time to account for many standard deviations between both responses. Got numbers? What are the tail-end p-tiles for some of these? How do those compare per-region, per-country? I mean, I believe you. The world didn't burn down a couple years back when some of these changes started popping up, and I was watching. But data is useful, both here and in the draft. S. > >> On Aug 14, 2017, at 17:25, Mark Andrews wrote: >> >> >> In message , Mikael Abraha >> msson writes: >>> On Mon, 14 Aug 2017, Mark Andrews wrote: >>> >>>> When only one of A or AAAA RRsets is present in the cache you have >>>> lookup times < 10ms for the RRset that is present in the cache and >>>> ~200ms for the RRset that isn't in the cache but the nameserver >>>> information is present. Waiting a realistic period for the cache >>>> miss to be filled is not "setting a really high advantage for IPv6 >>>> over IPv4". It's giving them equal standing. >>> Yes, but most of the requests will not have this problem, but you want to >>> set the time to take into account this edge case to slow down all >>> fall-back cases to IPv4? >> You obviously do not understand the message you replied to if that is >> the message you took out of it. Please go bag and re-read it. No I'm >> not asking to slow down all fall-back cases to IPv4. >> >>> Also, I already said you were correct in your analysis, but I just don't >>> agree that we need to bring up the wait period for IPv4 to handle the >>> problem you're describing. Yes it happens, I am not disputing that. I just >>> don't see the huge disadvantage you seem to be seeing in doing a few IPv4 >>> accesses when it could eventually had been used over IPv6 instead. At >>> least not at this point in time. >> I design software so that it will be behaving well in 10, 15 years >> time. I do this because I know people are still running the software >> I released 20 years ago. I was also doing this 20 years ago. >> >> The way RFC6555bis is at the moment the timers are such that you >> do not even wait for a reply from a single authoritative server. >> Now if I was trying to do the absolute fastest connection that would >> be the strategy I would be using but that strategy does not match >> IETF consensus that IPv6 should be tried before IPv4. Just waiting 50ms >> doesn't come close to meeting that consensus. >> >>>> When IPv6 lookups are broken they usually take significantly longer than >>>> a additional 200ms to complete as you end up with multiple queries being >>>> made. >>> So your proposal is to wait for the AAAA lookup to complete, even if this >>> takes several seconds? >> I don't know where you are getting this several seconds from. If >> we have a cache hit and a cache miss the server will usually have >> NS and associated address records for the zone so you are looking >> at a single packet exchange most of the time which was the timer >> value I was talking about. That's all 200ms gives you. I'm not >> asking to wait for the AAAA lookup to always complete. I'm just >> asking for it to have a fair chance to succeed rather than having >> almost no chance of succeeding. >> >> 50ms give 1% of IPv4 traffic if I'm correctly understanding what >> was presented in the video from Prague. Why are we happy with a >> 1% error rate? Why not 0.1% or 0.01%? >> >>> Just to make sure we might get an answer, eventually? >> I also don't know where you are getting the "eventually" from but >> AAAA lookups succeed (NOERROR/NXDOMAIN) 99.78% (0.22% failure) of >> the time over the Alexa top 1 Million for names where A lookups >> succeed (0.28% failure rate). It's companies that decide to use >> load balancers and then misconfigure them (they have the wrong >> backing zone behind the load balancer) that see AAAA lookups fail >> or those that host parked zones and instead of configuring a >> individual zone configure a .com or root zone with a wildcard record >> resulting in the wrong SOA record being returned. These misconfigurations >> cause the recursive server to try all of the authoritative servers >> for a answer before returning SERVFAIL. >> >>>> Which hides some cache misses from the client but not all of them. Been >>>> there, done that. >>> Happy Eyeballs is all about compromise between user experience and "use >>> IPv6 at all cost". 50ms seems like a good value at this point in time. >>> >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 15 10:09:41 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D151713228D; Tue, 15 Aug 2017 10:09:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281697383.21119.5857202226751657961.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:09:33 -0700 Archived-At: Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:09:34 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One nit: Please consider moving Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. to the first paragraph of the Abstract. I’m assuming that this explains the “needs that have arisen” in the first sentence of the Abstract, of course. From nobody Tue Aug 15 13:39:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441E132418 for ; Tue, 15 Aug 2017 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_BkYRznKxDp for ; Tue, 15 Aug 2017 13:39:45 -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 4EC7E13247A for ; Tue, 15 Aug 2017 13:39:45 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id e124so18265104oig.2 for ; Tue, 15 Aug 2017 13:39:45 -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=fsKaX+E9sZgVz97lRCIRu6ykG4eKjzDWL4Fav4ZduYo=; b=IiBVpIitDYiCvGYO6P18SYY8Ru5Q/HEg66fe4dtmvhVeuOM+JtvUfUb6+coDXmYeds DANjL5pq4Bixd/r26DoSKM8fP1DSvdZAo+fGPOtursZ/uWIGx0NFRtQbwqVpV86jUI4b j33a6WbUjD7SdICt5GtGsXkEJxrRHd2hhUSEvsxogtnYx5Uq8NG5KbdFOXPS0ZqJWtpW 0zoZjzKoCT3o8Z/umjNtdWGVf16uejHzfJY3lQXoEW8JYAaIjuPpTRjimtzByaSSi1Bk XYdIT+TqzcekONVjBqUPcGH0gHc58SVLYiMafSpEITgfmyOunCi5ZICFkpCZUWegSten 5YUA== 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=fsKaX+E9sZgVz97lRCIRu6ykG4eKjzDWL4Fav4ZduYo=; b=Kq5qYHnYctLruQHueu9opljk0H7ClQDzZtHtlkSO1dz0kUI2yILNc4LuKJ3jTlMLw0 hZ79zGjulyWvoct0ogFrCzYv+v79oxdkohdP7BVzgth7kFtUBGfwJCqzcqjQosEgUzsQ A9Qz4yZI/9QFxajrHhHF84xiw55+rr26dSABPH17xV8qPQwWuOR6AFSVXeUBHFMarou2 vxBJP3aedu0EUWjFNfHcbGHNKq6mqU4Tu80P5L03tHP87rMAeei6oKSYbTmZC53hXl63 9t7O8Xrt6FOxoCtiiAL7YahCZhUDXSRCb01+U3HIh1ENId8D+lzGPMxJHpVsmxarXMXa uqmg== X-Gm-Message-State: AHYfb5gqFt7jXal/XwnT/CVsSBtltslKyn6AfpYWoU4C+8qEW6sqitbD WzIS5Jb0FJDnjJnQrEQ= X-Received: by 10.202.226.207 with SMTP id z198mr34638537oig.226.1502829584407; Tue, 15 Aug 2017 13:39:44 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1281? ([2600:8802:5600:1e::1281]) by smtp.gmail.com with ESMTPSA id p127sm13754893oic.48.2017.08.15.13.39.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 13:39:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3443.1\)) From: Fred Baker In-Reply-To: Date: Tue, 15 Aug 2017 13:39:41 -0700 Cc: David Schinazi , =?utf-8?B?56We5piO6YGU5ZOJ?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.3443.1) Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 20:39:47 -0000 When David and Jinmei started using the word "consensus" and asked what = the chairs thought, the chairs went off in a huddle. This is us coming = back. If the working group has a consensus regarding this draft, we think the = consensus is that it likes the direction the draft is going. = Interpreting that as a consensus around an individual point in the draft = contains, I think, an instance of a fallacy - it deserves careful = consideration before making vast pronouncements. That's why we're having = a WGLC - to test the consensus. Our perception is that very few issues have been raised in the draft; = the working group appears to have consensus around most of what it = contains. One question the chairs have is "what are we missing?" If our = perception is not true, we're looking for comments on the list. Regarding Asynchronous DNS resolution, the statement in the draft is = that=20 Implementations MUST NOT wait for both families of answers to return before attempting connection establishment.=20 Our perception of the difference between David and Jinmei here surrounds = getaddrinfo(); David wants all implementations to use the AAAA record = the instant it comes back, and the A record only if the AAAA record is = significantly delayed, while Jinmei wants to grandfather implementations = using existing APIs that insist on having both or seeing a timeout. We = (the chairs) have sympathy in both directions, but suspect that Jinmei's = is more realistic. =46rom a strategic perspective, we want all = applications to do this; making it harder reduces the probability of it = happening, and making it easy makes it more likely. Not all OS's (think = IOT RTOS's) have threads, and not all have asynchronous DNS resolution. = Practically, we suspect that implementors will do what is = straightforward, and not do the rest - HEv1.5, if you will. In addition, = at least the way I use "MUST" in an RFC, when I say something MUST (or = MUST NOT) be done, failing on the point results in something dramatic. = If I say that a TCP implementation MUST eventually acknowledge every = segment it correctly receives in sequence, and someone doesn't, the = result is a perpetual TCP session transmitting and retransmitting the = same data. That's pretty fundamental. I don't see an interoperability = failure if an implementation doesn't resolve DNS asynchronously; I do = see a delay, and a reason that an asynchronous implementation might be = preferred in the market. So to me, this sounds more like "SHOULD/SHOULD = NOT" - we would like folks to do this, and if they don't they should = understand the implications of not doing so, but it doesn't break in any = fundamental way. So, question for the WG: do we agree with the statement in the draft, or = would we grandfather existing APIs (which HE 1.0 does). > On Aug 10, 2017, at 11:13 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Tue, 08 Aug 2017 10:06:12 -0700, > David Schinazi wrote: >=20 >> Most of your comments were regarding asynchronous DNS, which I = believe >> the working group has reached rough consensus on. While there is = still a >> vocal minority advocating that asynchronous DNS is "too hard", those >> implementations are free to only implement Happy Eyeballs v1. The = chairs >> should correct me if they disagree, but I feel the working group = overall >> agrees that the benefits of asynchronous DNS are worth it. >=20 > Hmm, if the wg has reached consensus on the use of a MUST for > asynchronous DNS, I'm not opposed to it myself. I thought it was > still open: as far as I remember I've not seen a declaration of the > consensus in this list, and I can't see it in the Prague minutes: > https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops > (and I wasn't there or didn't participate in it remotely). And, while > I personally don't have a strong opinion on the matter itself, I tend > to agree with those opposing to it in that a MUST sounds too strong. > But, again, if we've already reached a consensus on it that I have > simply overlooked, that's fine. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 15 13:58:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF74132646 for ; Tue, 15 Aug 2017 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4vAkb2TAQXM for ; Tue, 15 Aug 2017 13:58:24 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2866C13263D for ; Tue, 15 Aug 2017 13:58:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7A9A549; Tue, 15 Aug 2017 22:58:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502830695; bh=Z4XtSQR6NsuBESh9RfS zh/xoeJPkOp46UpSEbw3g+/g=; b=Q0KjGqzr4ziEYCyNuMMI4dr4Zr+EesOD3CC v1zXmePn8o76ui7D8+SGMKajNKpQus97eSwFfRPdN/1raJvCsOhPtpNm2FgXtKeg 3eHkHLdSC0FDWuc7YlDaqHYRdKe1TqmN6fVpqNtB/6f8k5SqGAVLbTmLk8SIvXWw /UkN0Lm4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lo281s0ZE8IK; Tue, 15 Aug 2017 22:58:15 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:ad32:25eb:9e41:c390] (unknown [IPv6:2a02:a213:a301:7880:ad32:25eb:9e41:c390]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 65DC63C; Tue, 15 Aug 2017 22:58:13 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <4049F026-7C89-43CD-ACC1-44EF8EA975A9@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_96AD7CED-F2AB-47C9-BE27-8E84DBF4A8BE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 Aug 2017 22:58:13 +0200 In-Reply-To: Cc: "v6ops@ietf.org" To: Fred Baker References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 20:58:26 -0000 --Apple-Mail=_96AD7CED-F2AB-47C9-BE27-8E84DBF4A8BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, > I don't see an interoperability failure if an implementation doesn't = resolve DNS asynchronously; I do see a delay, and a reason that an = asynchronous implementation might be preferred in the market. So to me, = this sounds more like "SHOULD/SHOULD NOT" - we would like folks to do = this, and if they don't they should understand the implications of not = doing so, but it doesn't break in any fundamental way. This reasoning sounds good. I think "SHOULD/SHOULD NOT" is the best = choice here. We definitely would strongly like asynchronous DNS, but a = well-informed decision not to doesn't make the HE implementation = completely useless. Cheers, Sander --Apple-Mail=_96AD7CED-F2AB-47C9-BE27-8E84DBF4A8BE 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----- iQEcBAEBCAAGBQJZk2BlAAoJEKAtA7D+JBO5xkMH/jPkOwhiI0B3vbTSzQrhGK2c SU6B2oCwmWYzE9VFnWv6QQiBj0mNbDqV9Q7Kau4wQSj0Tjs2OpxMF902iGNmSKvo phw1iYA5pN0TcGjBfA8cayybm9v7jak99SXr8vv+q+v4aDV+XLBqmkryi94w+qcs C583iPRBhN28GEcWvZCcRoU+5v9dMWRNZg9GasyQa1mDhtA7yj7H1Kiawy3id7by zAMf1CSwnBQtUYUYatgH9EI83KPbfr9T6YvLHi0tDsNIRQaWW48f3ACbAmZ+b+Gv tcOYknxQqA+nCe4A6w5bXjMa3bbXJPeDHQq8K0J7+esWC9CGsQGDaCWtYvOq1VA= =7ri9 -----END PGP SIGNATURE----- --Apple-Mail=_96AD7CED-F2AB-47C9-BE27-8E84DBF4A8BE-- From nobody Wed Aug 16 00:36:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2925C13263F for ; Wed, 16 Aug 2017 00:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqIMnkoqyRoP for ; Wed, 16 Aug 2017 00:36:41 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3552132646 for ; Wed, 16 Aug 2017 00:36:36 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id t138so28386189wmt.1 for ; Wed, 16 Aug 2017 00:36:36 -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-transfer-encoding:content-language; bh=1WFaCvpzDYGq7aNzxN/5UDfdS/56NyQe4peHQEiKO9g=; b=e2M2a+ND1YhMewyhr4kbivofYIgArIh8/w7IzJ2VbRtXfcv/dltF6Mb9iErMaEc4DL BZNiwpUNghVIVTTWgcQtJrFGsZkLMK8VCgRm3TkscjRnC6RXh/7r6tR50dKkbjwqnwMF xx6zoH1l4fJlkSfm439wTP4A0jeT7fGrkSxE6cSwyuC+gJt1wVCLRBa1n4P/W34qeD3J o7a5zLoi69PiPVtURY9gqlkmaYaBZ2i1W9z8AyER4MF2dlO+Z9Q3tXdDASCsb1JRYm7T K2anll0Kv8SmgLH3vrhkE/z0mEmUPkLy5+ddBazmtnvtRftJz6mw+TY0eCLloPNtIL7R nKfQ== 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-transfer-encoding :content-language; bh=1WFaCvpzDYGq7aNzxN/5UDfdS/56NyQe4peHQEiKO9g=; b=fOh6xDlQkhUSc/4hlMUDVgNV/X+h47BqLIBlCQa8Cj7iC0wzXNd+Tdl4GPyRDXnNbI 3Ki5NJ5888/kJbIxJEPMFb3kOwEKFWOjPEfUD70dYPj7P2Zsq33K+MpnpNMSVdllvEJZ 5//vOFM35mbhCFWCQxBw1drLyJ01xrjmjO+pFnE4nDExihc2Sj5mLdnQfG6oegnNvd/t 5w5lNzVLuFWo3yAPDbHtCulnYANfcCfLNWCpSwY14zCMh0gzwb93npPGax+Ned36iGTY BPp/r/RlL6khrlytP27SDhsd3OW37YatQfPa0alvgC80UfKLlSQbODgVD5OJ1dkQQg98 CcdQ== X-Gm-Message-State: AHYfb5iAXhzsiKaPgd8xw1g8ouRU/lnz0JvwBXsclPT287WYGgPOvJaL sA9ARb2Kjj7dWeSsrL4= X-Received: by 10.80.183.234 with SMTP id i39mr1146318ede.210.1502868995354; Wed, 16 Aug 2017 00:36:35 -0700 (PDT) Received: from dhcp-21-121.ripe.net ([2001:67c:2e8:110:e1c7:786f:a0d9:ea64]) by smtp.gmail.com with ESMTPSA id y53sm336089edb.54.2017.08.16.00.36.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 00:36:34 -0700 (PDT) To: Fred Baker , "v6ops@ietf.org" Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> From: Stephen Strowes Message-ID: Date: Wed, 16 Aug 2017 09:36:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 07:36:43 -0000 On 15/08/2017 22:39, Fred Baker wrote: > Regarding Asynchronous DNS resolution, the statement in the draft is that > > Implementations MUST NOT wait for both families of answers to return > before attempting connection establishment. > > Practically, we suspect that implementors will do what is straightforward, and not do the rest - HEv1.5, if you will. In addition, at least the way I use "MUST" in an RFC, when I say something MUST (or MUST NOT) be done, failing on the point results in something dramatic. If I say that a TCP implementation MUST eventually acknowledge every segment it correctly receives in sequence, and someone doesn't, the result is a perpetual TCP session transmitting and retransmitting the same data. That's pretty fundamental. I don't see an interoperability failure if an implementation doesn't resolve DNS asynchronously; I do see a delay, and a reason that an asynchronous implementation might be preferred in the market. So to me, this sounds more like "SHOULD/SHOULD NOT" - we would like folks to do this, and if they don't they should understand the implications of not doing so, but it doesn't break in any fundamental way. I agree with SHOULD/SHOULD NOT. Sections 4 and 5 already read linearly and are not at all confusing if the DNS resolution is synchronous. Modifying section 3 should allow it to become an optional part of the algorithm with very little wordsmithing. S. >> On Aug 10, 2017, at 11:13 AM, 神明達哉 wrote: >> >> At Tue, 08 Aug 2017 10:06:12 -0700, >> David Schinazi wrote: >> >>> Most of your comments were regarding asynchronous DNS, which I believe >>> the working group has reached rough consensus on. While there is still a >>> vocal minority advocating that asynchronous DNS is "too hard", those >>> implementations are free to only implement Happy Eyeballs v1. The chairs >>> should correct me if they disagree, but I feel the working group overall >>> agrees that the benefits of asynchronous DNS are worth it. >> Hmm, if the wg has reached consensus on the use of a MUST for >> asynchronous DNS, I'm not opposed to it myself. I thought it was >> still open: as far as I remember I've not seen a declaration of the >> consensus in this list, and I can't see it in the Prague minutes: >> https://datatracker.ietf.org/meeting/99/materials/minutes-99-v6ops >> (and I wasn't there or didn't participate in it remotely). And, while >> I personally don't have a strong opinion on the matter itself, I tend >> to agree with those opposing to it in that a MUST sounds too strong. >> But, again, if we've already reached a consensus on it that I have >> simply overlooked, that's fine. >> >> -- >> JINMEI, Tatuya >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 16 02:22:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5741200B9 for ; Wed, 16 Aug 2017 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] 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 YjVGvHgDXCqJ for ; Wed, 16 Aug 2017 02:21:55 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D37713201E for ; Wed, 16 Aug 2017 02:21:55 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id u133so10258470vke.3 for ; Wed, 16 Aug 2017 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OyXZn0yHiSmBmrysvLp2f2ZhRgprZ6bxHFCYi543ayA=; b=c2x7yOiD6PKEq4Cx5W27pkNjsqmcQXCRlj1W7kjPOZde2nfuTl/BU4XljxEaI2hXN6 1deLfM94yuI/j69zpYP6mpzYU8r29IYRlgCf4TQ2rVCOV+VfXV+MewoQ+nakSXFxvjc0 hn6rnxN4uaz+wMQFyFelsNncomnNo1mTcDODERYUTAb5PnqK5KT0G7kMq3ia5u2Zulb/ 0RNlDn1vsMR2WG4c8hh1jWOPQ5+gMWoaz54oppd8L6/1PxhuhPxFLkw1Z6aM4+vPBCcg vzhdAPPEPtc+KzanxjN1Min67CRWHqfsBkbhbmSJamAfg8eBLbswwAnLNAqaQXjlvsQU CWfQ== 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=OyXZn0yHiSmBmrysvLp2f2ZhRgprZ6bxHFCYi543ayA=; b=Qh4hpZCUiDt5lN26b1Y0Frq9echwZff2TtJaC0zk+mkA9XM4A70asoIEj0SPf51mLu PjX8lYbSS8eCABJCpiGEjR5VENyk7nftaThKywO+RYVw3QWqKQ2fqRjUm+eQIrHvaqk0 rZ/IEduYddtLmOPZOcpwH7sf5VA98pkdxQDwoMJBXchIkTDEZMah+Hu6hZ4JlXc94loO X/oI4R6NiGL+UlmIhvR3q6S++7qJW6Rx17Z4Uo/HrFu0o/cRo+P5a25JxRxwMv88orgf A+vJMbHCNZlVhc9Z7SUhX/5yvF4BjLNLrK2BanOc+iQ4vzGDaldysTUeGHk75Co6wXzn xP4A== X-Gm-Message-State: AHYfb5g4d8aVmLLFH24+kqjqSfn29oLO78vH/gWVQamuAzTF5IShByfW BN1+01ClWqCLbVNm6ZcURXSwlX1idA== X-Received: by 10.31.107.145 with SMTP id k17mr517588vki.163.1502875314238; Wed, 16 Aug 2017 02:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Wed, 16 Aug 2017 02:21:23 -0700 (PDT) In-Reply-To: <20170810055819.GQ45648@Space.Net> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> From: Mark Smith Date: Wed, 16 Aug 2017 19:21:23 +1000 Message-ID: To: Gert Doering Cc: JORDI PALET MARTINEZ , v6ops list Content-Type: multipart/alternative; boundary="001a11478e443f3a4e0556db6d11" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:21:59 -0000 --001a11478e443f3a4e0556db6d11 Content-Type: text/plain; charset="UTF-8" On 10 Aug. 2017 15:58, "Gert Doering" wrote: Hi, On Thu, Aug 10, 2017 at 11:24:48AM +1000, Mark Smith wrote: > > And yes, I think this is extremely wastive, well over the limits of what > > is normal "do not care about wasting addresses!" level of IPv6 normal. > > So it's worth considering what the word "waste" means. It means > getting no value at all from some quantity of a resource. That > quantity of resource isn't being used for anything of value to the > resource's user. Waste can also mean "I have used up something without actually needing it, and now it's missing somewhere *else*". Do we have to purposely make something hard and costly to use before we can make it easy and cheap to use? Do we have to treat IPv6 addresses like diamonds, before eventually accepting the *maths* that shows they're at least as common as grains of sand. [..] > > Should this topic come up in RIPE policy discussion, I'll chair the > > discussion and refrain from having an opinion, but will reserve the right > > for a "told you so" later. > > I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion > /64s? If an ISP isn't giving out at least /56s to customers, the > problem isn't with the /64 boundary, it is the ISP carrying IPv4 > address scarcity management practices over to IPv6 where they aren't > needed. So how useful is a /56 to a customer if the customer wants to do /64-per-host? If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it's all of a sudden becoming tight for slightly larger customer sites. /56 entirely inappropriate for slightly larger sites. Give them a /48. If an ISP thinks they can't get bigger than a /32 from their RIR, or that they have to squeeze everything into a /32 "because it is so large and therefore that's all I'll ever be able to justify getting", they need to be corrected. > We are wasting our time (getting no value from it) trying to > accommodate unneeded IPv4 practices carried over to IPv6. We end up > trying to make things accommodate more and more perverse and > unnecessarily conservative IPv4 carried over practices. If we > accommodate them, we're also tacitly endorsing them. I could point out that "a /64 everyhwere" is repeating the "Class A, B, C" mistakes from IPv4. Classes weren't a really a mistake. They were a workaround for not having enough address bits and not being able to easily change the number of address bits. IP addresses went through many format and size changes between 1974 ("A Protocol for Packet Network Intercommunication") and 1978 before 32 bits was chosen as the fixed address size in September of 1978 (IEN54), with a format of 8 bit network number and 24 bit hosts i.e. N.H.H.H. (There were two different attempts at having variable length addresses that were abandoned, RFC675 and IEN21.) That persisted until RFC791, in September of 1981, where Class A, B, C, D and E address types were introduced. Also at that time, show in RFC790, there were already 42 what would now become "Class A" network numbers assigned. So there was at least 3 years of happy and successful operation with a simple N.H.H.H address format (i.e., no complexity due to classes, subnets, subnet masks or prefix lengths) between IEN54 and RFC791. I've called classes, subnets, CIDR etc. a series of neat hacks to get around the 32 bit address space limit. At the time I asked Vint Cerf for some more context. https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html "Date: Sat, 3 Apr 2010 08:17:28 -0400 From: Vint Cerf To: Mark Smith Cc: Andrew Gray <3356 at blargh.com>, NANOG List Subject: Re: legacy /8 When the Internet design work began, there were only a few fairly large networks around. ARPANET was one. The Packet Radio and Packet Satellite networks were still largely nascent. Ethernet had been implemented in one place: Xerox PARC. We had no way to know whether the Internet idea was going to work. We knew that the NCP protocol was inadequate for lossy network operation (think: PRNET and Ethernet in particular). This was a RESEARCH project. We assumed that national scale networks were expensive so there would not be too many of them. And we certainly did not think there would be many built for a proof of concept. So 8 bits seemed reasonable. Later, with local networks becoming popular, we shifted to the class A-D address structure and when class B was near exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but perhaps others also) came up with CIDR and the use of masks to indicate the size of the "network" part of the 32 bit address structure. By 1990 (7 years after the operational start of the Internet and 17 years since its basic design), it seemed clear that the 32 bit space would be exhausted and the long debate about IPng that became IPv6 began. CIDR slowed the rate of consumption through more efficient allocation of network addresses but now, in 2010, we face imminent exhaustion of the 32 bit structure and must move to IPv6. Part of the reason for not changing to a larger address space sooner had to do with the fact that there were a fairly large number of operating systems in use and every one of them would have had to be modified to run a new TCP and IP protocol. So the "hacks" seemed the more convenient alternative. There had been debates during the 1976 year about address size and proposals ranged from 32 to 128 bit to variable length address structures. No convergence appeared and, as the program manager at DARPA, I felt it necessary to simply declare a choice. At the time (1977), it seemed to me wasteful to select 128 bits and variable length address structures led to a lot of processing overhead per packet to find the various fields of the IP packet format. So I chose 32 bits. vint" People who believe IPv4 addressing that we have today is an ideal that we should be aiming for in IPv6 are probably unlikely to be aware of IPv4 history of addressing evolution, or the research or proof-of-concept network context it was originally designed and chosen for. IPv6 is really the first true Internet protocol, and should not be artificially inhibited by the legacy of IPv4's design context, practices, constraints and workarounds. Regards, Mark. --001a11478e443f3a4e0556db6d11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On 10 Aug. 2017 15:58, "Gert Doering" = <gert@space.net&= gt; wrote:
Hi,<= br>

On Thu, Aug 10, 2017 at 11:24:48AM +1000, Mark Smith wrote:
> > And yes, I think this is extremely wastive, well over the limits = of what
> > is normal "do not care about wasting addresses!" level = of IPv6 normal.
>
> So it's worth considering what the word "waste" means. I= t means
> getting no value at all from some quantity of a resource. That
> quantity of resource isn't being used for anything of value to the=
> resource's user.

Waste can also mean "I have used up something without actually n= eeding
it, and now it's missing somewhere *else*".
=


Do we have to p= urposely make something hard and costly to use before we can make it easy a= nd cheap to use? Do we have to treat IPv6 addresses like diamonds, before e= ventually accepting the *maths* that shows they're at least as common a= s grains of sand.


=

[..]
> > Should this topic come up in RIPE policy discu= ssion, I'll chair the
> > discussion and refrain from having an opinion, but will reserve t= he right
> > for a "told you so" later.
>
> I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion > /64s? If an ISP isn't giving out at least /56s to customers, the > problem isn't with the /64 boundary, it is the ISP carrying IPv4 > address scarcity management practices over to IPv6 where they aren'= ;t
> needed.

So how useful is a /56 to a customer if the customer wants to do
/64-per-host?

If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it&#= 39;s
all of a sudden becoming tight for slightly larger customer sites.

/56= entirely inappropriate for slightly larger sites. Give them a /48. If an I= SP thinks they can't get bigger than a /32 from their RIR, or that they= have to squeeze everything into a /32 "because it is so large and the= refore that's all I'll ever be able to justify getting", they = need to be corrected.


> We are wasting our time (getting no value from it) trying to
> accommodate unneeded IPv4 practices carried over to IPv6. We end up > trying to make things accommodate more and more perverse and
> unnecessarily conservative IPv4 carried over practices. If we
> accommodate them, we're also tacitly endorsing them.

I could point out that "a /64 everyhwere" is repeating the = "Class A, B, C"
mistakes from IPv4.
Classes weren't a really a mistake. They were = a workaround for not having enough address bits and not being able to easil= y change the number of address bits.

= IP addresses went through many format and size changes between 1974 ("= A Protocol for Packet Network Intercommunication") and 1978 before 32 = bits was chosen as the fixed address size in September of 1978 (IEN54), wit= h a format of 8 bit network number and 24 bit hosts i.e. N.H.H.H. (There we= re two different attempts at having variable length addresses that were aba= ndoned, RFC675 and IEN21.)

That persisted until RF= C791, in September of 1981, where Class A, B, C, D and E address types were= introduced. Also at that time, show in RFC790, there were already 42 what = would now become "Class A" network numbers assigned. So there was= at least 3 years of happy and successful operation with a simple N.H.H.H a= ddress format (i.e., no complexity due to classes, subnets, subnet masks or= prefix lengths) between IEN54 and RFC791.

I&#= 39;ve called classes, subnets, CIDR etc. a series of neat hacks to get arou= nd the 32 bit address space limit. At the time I asked Vint Cerf for some m= ore context.


"Date: Sat, 3 Apr 2010 = 08:17:28 -0400
From: Vint Cerf <vint at google.com>
To: Mark Smith
Gray <3356 at blargh.com>, NANOG List <nanog at nanog.org> Subject: Re:
legacy /8

When the Internet design work began, there were on= ly a few fairly large
networks around. ARPANET was o= ne. The Packet Radio and Packet Satellite
networks w= ere still largely nascent. Ethernet had been implemented in
one place: Xerox PARC. We had no way to know whether the Internet= idea
was going to work. We knew that the NCP protoc= ol was inadequate for
lossy network operation (think= : PRNET and Ethernet in particular). This
was a RESE= ARCH project. We assumed that national scale networks were
expensive so there would not be too many of them.=C2=A0 And we certa= inly did
not think there would be many built for a p= roof of concept. So 8 bits
seemed reasonable. Later,= with local networks becoming popular, we
shifted to= the class A-D address structure and when class B was near
exhaustion, the NSFNET team (I think specifically Hans-Werner Braun = but
perhaps others also) came up with CIDR and the u= se of masks to indicate
the size of the "networ= k" part of the 32 bit address structure. By 1990
(7 years after the operational start of the Internet and 17 years since
its basic design), it seemed clear that the 32 bit sp= ace would be
exhausted and the long debate about IPn= g that became IPv6 began. CIDR
slowed the rate of co= nsumption through more efficient allocation of
netwo= rk addresses but now, in 2010, we face imminent exhaustion of the
32 bit structure and must move to IPv6.

Part of the reason for not changing to a larg= er address space sooner
had to do with the fact that= there were a fairly large number of
operating syste= ms in use and every one of them would have had to be
modified to run a new TCP and IP protocol. So the "hacks" seemed= the
more convenient alternative. There had been deb= ates during the 1976
year about address size and pro= posals ranged from 32 to 128 bit to
variable length = address structures. No convergence appeared and, as the
program manager at DARPA, I felt it necessary to simply declare a
=
choice. At the time (1977), it seemed to me wasteful to s= elect 128 bits
and variable length address structure= s led to a lot of processing
overhead per packet to = find the various fields of the IP packet format.
So = I chose 32 bits.

vint&qu= ot;


Peopl= e who believe IPv4 addressing that we have today is an ideal that we should= be aiming for in IPv6 are probably unlikely to be aware of IPv4 history of= addressing evolution, or the research or proof-of-concept network context = it was originally designed and chosen for. IPv6 is really the first true In= ternet protocol, and should not be artificially inhibited by the legacy of = IPv4's design context, practices, constraints and workarounds.


Regards,
Mark.
--001a11478e443f3a4e0556db6d11-- From nobody Wed Aug 16 03:40:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B4A1321AC for ; Wed, 16 Aug 2017 03:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdLoY8jI2tFD for ; Wed, 16 Aug 2017 03:40:11 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162951323D4 for ; Wed, 16 Aug 2017 03:40:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id A58B21BC37 for ; Wed, 16 Aug 2017 10:40:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 16 Aug 2017 11:40:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 10:40:14 -0000 Mark Smith wrote: > Do we have to purposely make something hard and costly to use before = we can make it easy and cheap to use? Turning that around, do we have to hard-code limitations in that we = cannot know the consequences of ? Even hard-coding /64 doesn't remove the need to be able to work with = variable length prefixes in all but the most trivial of systems, and = given modern hardware capabilities, the processing cost can hardly be = called expensive (even on the most basic of processors). Bear in mind = that it's now hard to buy a processor that isn't orders of magnitude = more powerful (and resource endowed) than the computers that first put = men on the moon. EVERY router must possess the ability to work with variable length = prefixes. Every protocol stack in any OS/firmware that "might" ever be = used for routing mist therefore support variable prefix lengths. So in = the general case, there will be very little (if any) saving in software = costs. In fact, having a /64 hard coded MAY allow a different code = structure - but this is likely to be in addition to the variable prefix = length code, and thus increase the amount of code to be written and = maintained. All this is supposed to be transparent to the end user - so it shouldn't = matter to them. And anyone working with networks will need to understand = variable length prefixes (48 =3D/=3D 56 =3D/=3D 60 =3D/=3D 64) so unless = no-one gets anything but a /64 from their ISP then the argument about = not having to learn about variable prefix lengths goes out the window as = well. So now we have a default of a single /64/customer - and needing = customer involvement if all those nice things (Homenet ?) that want = multiple /64s are to work for them. > Do we have to treat IPv6 addresses like diamonds, before eventually = accepting the *maths* that shows they're at least as common as grains of = sand. Just this week, over on the ISC DHCP users list, there was a question = regarding changing PD sizes which turned out to be a bug in the server = package. However, this ISP defaults to offering a single /64 with the = option to switch to a /56. I did ask why not to default to /56 - the answer being that they've hit = a small number of CPE routers that couldn't handle anything but a /64 = PD. Given the choice between something that "works for most people out = of the box" and having to take support calls and explain why their = cheap-n-nasty router didn't work - they chose the option of a single /64 = by default. I'd suggest that this is a side effect of the "/64 everywhere" mantra. = Someone inexperienced has picked up a spec, seen that "everything is = /64", so they've (incorrectly) assumed all they need to deal with is a = /64. You can argue that the person/group responsible for this pile of rubbish = didn't read the specs correctly. That may well be the case. But when so = many documents all read as though /64 is set in stone, it's not hard to = see why someone reading them quickly (as in manager has told them they = have a short bit of time to learn the subject and bash out some code) = might miss the subtlety. I can see the argument for "make it simple", but that is a recipe for = hardcoding in constraints in the future. Some kit (or bits of software) = goes on and on for a long time. I recall getting bitten a long time ago = when (many years after classless addressing was history) I came across a = bit of kit that enforced class rules - specifically wouldn't allow a = 192.168.nn.nn/23 address to be configured. As a result, I had to = renumber the network into the 172.16/12 block to accommodate this bit of = code. The unit itself wasn't very old (in manufacturing terms), but the = design and the code in it was. > People who believe IPv4 addressing that we have today is an ideal that = we should be aiming for in IPv6 are probably unlikely to be aware of = IPv4 history of addressing evolution, or the research or = proof-of-concept network context it was originally designed and chosen = for. IPv6 is really the first true Internet protocol, and should not be = artificially inhibited by the legacy of IPv4's design context, = practices, constraints and workarounds. I think you are disingenuous labelling the argument in such terms. I'm not arguing against having /64 as the default - but I am arguing = against hardcoding in assumption that may well turn out to be incorrect, = and hard to correct due to having been hardcoded into various = implementations (that might not even be supported by the vendor any = more). I'm sure many developers (or at least, their managers) once thought that = their code would never be used into the year 2000 - that turned out to = be an incorrect assumption. The history of computing is littered with = similar examples where people went for the 'easy" option, only to = hardcode in something which later turned around to bite their backside. = I keep seeing an argument for the easy option of "/64 everywhere" which = is ALREADY causing problems. From nobody Wed Aug 16 07:01:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B18913201E for ; Wed, 16 Aug 2017 07:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8CLC0plYkehK for ; Wed, 16 Aug 2017 07:01:08 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C53132153 for ; Wed, 16 Aug 2017 07:01:06 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c74so13251211iod.4 for ; Wed, 16 Aug 2017 07:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lE5aUFi91uCHyqNOz6R83Lw8UaDiOXd9+JbQRlzgQ38=; b=o0c/lJakmCEG8Agm0E7EbQ1E0WCRm4OJkugayQv2ek7lj7Wq/6Xce9+JWOaMQiruLg YLT4ajsh7GMTSD7sb4KegqpLKil8C/v+jQo2PpxhKrRMtSs7jd7CG5TXOZYUF7N8bLmT M2OPI0Xy5LOsINKqDX8bk2tTUTS8lZteUFF1dcocfPjaBWBu+Xc5zRBYH0iUb2uvW90Z 3MWLS1W2CAv4lvJ+txQUzh5uORtHDEcSdReIOrry35UqkU/LkAa126iClmdA74ujKEaV flxju+bk14o7K2dMyMQlLYeRN5HhDqIPc+Xzu/drwherk5TCRFAIXUf83Icksoc/4UcH rOiA== 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=lE5aUFi91uCHyqNOz6R83Lw8UaDiOXd9+JbQRlzgQ38=; b=DWbrnOC0y1e5PaESJsRNoFUjkZF0iwvmQUuEvmthaB6n3ZHOn113rVO8uvj1W9JvRD HXykH+tNnGxuXqm+SoNUEVM0HIqp4eCdYnjNiudWE/gAgdceOv1QyuS/hxeEdm5LScBB +vGmxFOGnUCu3rJP0wSwT/Df8y5ycOi//SgO1T08GI6UZCB+k6i7qqpSBnZdhHEj77m/ MYY2RpEGVFNwwcEfdJSZQ122hQOzocy3cM9TOv3ZVJiq8HvsyG+89tnYpaqh6zW2OC1Z uujyDAAT3RDDde8OL/qeSMQE+z9WsJZFIZAbx1F4Tm/XVFSmeK3aQAzrcennBUF0rTq9 Ls6A== X-Gm-Message-State: AHYfb5iK3WHDGt8C1qql4NJovg9I32LvdrsqaIRX2J4OwGsTA6L4A2rj fMOIXOJKF/OuCjiyqYwACUKwqLpyXDBdVvA= X-Received: by 10.107.9.195 with SMTP id 64mr1504543ioj.72.1502892064305; Wed, 16 Aug 2017 07:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 07:00:43 -0700 (PDT) In-Reply-To: <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> From: Lorenzo Colitti Date: Wed, 16 Aug 2017 23:00:43 +0900 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: multipart/alternative; boundary="001a113eb696a19ccd0556df53be" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 14:01:11 -0000 --001a113eb696a19ccd0556df53be Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 7:40 PM, Simon Hobson wrote: > Turning that around, do we have to hard-code limitations in that we cannot > know the consequences of ? > Even hard-coding /64 doesn't remove the need to be able to work with > variable length prefixes in all but the most trivial of systems, and given > modern hardware capabilities, the processing cost can hardly be called > expensive (even on the most basic of processors). Bear in mind that it's > now hard to buy a processor that isn't orders of magnitude more powerful > (and resource endowed) than the computers that first put men on the moon. > /64 gives you something that no longer prefix does: the ability to run SLAAC and connect unlimited devices behind the host. I'd suggest that this is a side effect of the "/64 everywhere" mantra. > Someone inexperienced has picked up a spec, seen that "everything is /64", > so they've (incorrectly) assumed all they need to deal with is a /64. > No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly announces it in an RA. That doesn't work because SLAAC only works with 64-bit IIDs, and for good reason. I'm sure many developers (or at least, their managers) once thought that > their code would never be used into the year 2000 - that turned out to be > an incorrect assumption. The history of computing is littered with similar > examples where people went for the 'easy" option, only to hardcode in > something which later turned around to bite their backside. I keep seeing > an argument for the easy option of "/64 everywhere" which is ALREADY > causing problems. Already? 64 everywhere has been the standard for 20 almost years now. It predates pretty much every IPv6 network and every IPv6 implementation out there today. --001a113eb696a19ccd0556df53be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 16, 2017 at 7:40 PM, Simon Hobson <linux@thehobsons.co.uk= > wrote:
Turning that around, d= o we have to hard-code limitations in that we cannot know the consequences = of ?
Even hard-coding /64 doesn't remove the need to be able to work with va= riable length prefixes in all but the most trivial of systems, and given mo= dern hardware capabilities, the processing cost can hardly be called expens= ive (even on the most basic of processors). Bear in mind that it's now = hard to buy a processor that isn't orders of magnitude more powerful (a= nd resource endowed) than the computers that first put men on the moon.
=

/64 gives you something that no longer pre= fix does: the ability to run SLAAC and connect unlimited devices behind the= host.=C2=A0

I'd sug= gest that this is a side effect of the "/64 everywhere" mantra. S= omeone inexperienced has picked up a spec, seen that "everything is /6= 4", so they've (incorrectly) assumed all they need to deal with is= a /64.

No. Someone wrote code that get= s a prefix via DHCPv6 PD, and blindly announces it in an RA. That doesn'= ;t work because SLAAC only works with 64-bit IIDs, and for good reason.

I'm sure many developer= s (or at least, their managers) once thought that their code would never be= used into the year 2000 - that turned out to be an incorrect assumption. T= he history of computing is littered with similar examples where people went= for the 'easy" option, only to hardcode in something which later = turned around to bite their backside. I keep seeing an argument for the eas= y option of "/64 everywhere" which is ALREADY causing problems.

Already? 64 everywhere has been the standard= for 20 almost years now. It predates pretty much every IPv6 network and ev= ery IPv6 implementation out there today.
--001a113eb696a19ccd0556df53be-- From nobody Wed Aug 16 09:27:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7344E1320BE for ; Wed, 16 Aug 2017 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS3lptF7-mwr for ; Wed, 16 Aug 2017 09:27:41 -0700 (PDT) Received: from atl4mhob17.registeredsite.com (atl4mhob17.registeredsite.com [209.17.115.110]) (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 338E6132630 for ; Wed, 16 Aug 2017 09:27:41 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob17.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7GGRbnl017406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Aug 2017 12:27:37 -0400 Received: (qmail 7308 invoked by uid 0); 16 Aug 2017 16:27:37 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 16 Aug 2017 16:27:36 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Wed, 16 Aug 2017 12:27:34 -0400 From: Lee Howard To: Message-ID: Thread-Topic: Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3585731256_1362582" Archived-At: Subject: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 16:27:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3585731256_1362582 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reading through draft-ietf-sunset4-gapanalysis-09 it seemed to me that several problems might be resolvable in documents we currently have open: Can problems 1-5 (indicating that IPv4 is unavailable, disabling IPv4 in th= e LAN) be addressed with recommendations in any, some, or all of: draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for IPv6 Customer Ed= ge Routers" Or other drafts under discussion in v6ops now? Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable? That woul= d have to go to 6man. Or did we do this, and I=E2=80=99ve forgotten in my old age? Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency=E2=80=9D? Can problem 10 be addressed in rfc6555-bis? Thanks, Lee --B_3585731256_1362582 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Reading through draft-ietf-sunset4-gapanalysis-09 i= t seemed to me that several problems might be resolvable in documents we cur= rently have open:

Can problems 1-5 (indicating that IPv4 is unavailable, disabling I= Pv4 in the LAN) be addressed with recommendations in any, some, or all of:
draft-ietf= -v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers"
draft-ietf-v6ops-rfc7084-bis-0= 4  “Basic Requirements for IPv6 Customer Edge Routers"
Or other drafts und= er discussion in v6ops now?
Or do we n= eed new IPv6 signalling (RA?) that IPv4 is unavailable? That would have to g= o to 6man. Or did we do this, and I’ve forgotten in my old age?=


Are problems= 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with draft-ietf-v6op= s-rfc6555bis-03,  "Happy Eyeballs Version 2: Better Connectivity Using = Concurrency”?
Can problem 10 be = addressed in rfc6555-bis?

<= /div>
Thanks,

Lee
--B_3585731256_1362582-- From nobody Wed Aug 16 09:58:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D8120720 for ; Wed, 16 Aug 2017 09:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc7jgpAJ72aT for ; Wed, 16 Aug 2017 09:58:10 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E87213267C for ; Wed, 16 Aug 2017 09:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502902687; x=1503507487; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=zxkkGqEc9b9+t8hqcP86GiBaZlhiNAH59Wl080t+zFU=; b=rLNMbyLL83Jnj NbuojZjGh9ONlflbxSpRdd9TeqyQ1PDOp9BCoM0srPBE+hXyBcPwo+V7QHTCBHR/ O/lCmV9u8lldwGnzKfmxSHAWUxYlFuSOcpGA8+fvJa88c4vpXG8GwVv7TfOs05pq Yy3Ee2KnIBQkLWfrzmr1b0GgIgBHoU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rDDxWE5P8fiM33+wEg1iG3vp4ZySwl6tlk2X1t5gNujKc5YrYwtlYrm2eODL vWXQ9m5Mq3H+nx4geHRefHoQ5dzfbgPzCdYwcZtLmyZin+aDuUr8jvIZv 7oG+xc3DHCTkowLddkKBeQZ0GcI37Ln7pCHub4/tlEpFyVUoFJC09I=; X-MDAV-Processed: mail.consulintel.es, Wed, 16 Aug 2017 18:58:07 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 16 Aug 2017 18:58:07 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005506732.msg for ; Wed, 16 Aug 2017 18:58:06 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170816:md50005506732::H9dEw31aVs9fzMDJ:00004/c3 X-Return-Path: prvs=1401d3a9dd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Wed, 16 Aug 2017 18:58:04 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 16:58:13 -0000 Hi Lee, I=E2=80=99m happy to review draft-ietf-v6ops-rfc7084-bis-04 with possible s= olutions, but we first, as a WG, need to clarify if still want to update RF= C7084 or instead, want to go in the direction of separating the transition = requirements as per draft-palet-v6ops-rfc7084-bis-transition-00. Updating draft-ietf-v6ops-rfc7084-bis-04 could allow what you are asking fo= r. However, if we don=E2=80=99t want to touch RFC7084, seems to me difficult t= hat we can do it in a =E2=80=9Ctransition=E2=80=9D only document. So, do we want to re-consider this decision again? My plan, if time permits, is to update either one or the other document nex= t week. Regarding 6&7, I actually provided text on that to the authors, and one of = my comments was in the direction of RFC6555-bis can somehow sort out those,= but the actual text is still based in RFC6555 until RFC6555-bis become an = RFC, in order to avoid =E2=80=9Cholding=E2=80=9D draft-ietf-sunset4-gapanal= ysis-09, so all depends on how fast we move with one or the other =E2=80=A6 Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Lee Howard Responder a: Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:28 Para: Asunto: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis Reading through draft-ietf-sunset4-gapanalysis-09 it seemed to me that = several problems might be resolvable in documents we currently have open: =20 Can problems 1-5 (indicating that IPv4 is unavailable, disabling IPv4 i= n the LAN) be addressed with recommendations in any, some, or all of: draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for IPv6 C= ustomer Edge Routers" Or other drafts under discussion in v6ops now? Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable? That = would have to go to 6man. Or did we do this, and I=E2=80=99ve forgotten in = my old age? =20 =20 =20 Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with dr= aft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better Connectivi= ty Using Concurrency=E2=80=9D? Can problem 10 be addressed in rfc6555-bis? =20 Thanks, =20 Lee =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 use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Aug 16 11:17:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B419413267B for ; Wed, 16 Aug 2017 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEhPaWLglMOe for ; Wed, 16 Aug 2017 11:17:56 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244C01200F3 for ; Wed, 16 Aug 2017 11:17:56 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id s6so25548016qtc.1 for ; Wed, 16 Aug 2017 11:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5dqhHfbJngIeyGvAGkQeo5MlxRiEV7hBET0CjKQsahQ=; b=Lc68NV+WVDxKEB+JfBUV1+Tc21zrPvmqcBFrIHEME+m+zJCdtm/qK5QeyJRvYzXxql Cv+pRrowZ4+wStKBBQE9mufj95u+lZSzVM8C4IPLTEfcRRJpeZdIP0F8PaTOI0ibSBBn oUQf2kM/TaSvRz5QAHQX+Q9KFuelWlRTVEC9jgDy7UVwQgHqjhMcdgo5JMXnsCt4Kyw4 c77LOwC0j+W1LhmALl3isrwh2Dd4bsZxbcD0Rb0UnRvd8nfKgVVO0Uf6p/pzJE6Onn7o xlLeJjLqjxOnEiftHKdXG6He58B8bvSLktjM7XI2ddyTSH+S2N6mg7pmT2rseIAZWF1Q a+5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5dqhHfbJngIeyGvAGkQeo5MlxRiEV7hBET0CjKQsahQ=; b=HuPzDhi92JH7Y7w6Ro7HT+TiFvgydDaB9eEm2jkmj5zDD2HY29uCe/1xRJwK7JsNzj q/Cw3id86spTu1oF3DzhzI6yKJ//2kcQBmNLUzTQ2T/KDrBuu8SrwJSd/xXoSQz5eJ0l aCUh2XQ+bZey/JYz5mNp9f6YbQ/JixGkMkm//QieAL0ldZ/8/ZZG/IY1osWs0LKo/Rzc rSvu2Vyg1veWkn7ZUlVX8IFXABrnSZIk3HkcGioJvBvyo003WPnuUQWQ692sK0K+TqSW juBjk0jIQOLds+q7+27CZ0+vYzXaPKhdNJiF39hv3t0i97UzC3oM1mHnVhelH8s1csDS +MAQ== X-Gm-Message-State: AHYfb5jOJT2S6tGZUe8Y3ngjZjOt1vIiITRr08Xoitco2AHDBbpWV+Cf YA3oXgqGJBmT/MV0cjAwc+/6GsLrwnG7rtA= X-Received: by 10.200.49.141 with SMTP id h13mr3869594qte.198.1502907475175; Wed, 16 Aug 2017 11:17:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Wed, 16 Aug 2017 11:17:54 -0700 (PDT) In-Reply-To: References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 16 Aug 2017 11:17:54 -0700 X-Google-Sender-Auth: eej42xmjVr_O2XLTifkhml_Jig8 Message-ID: To: Fred Baker Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:17:58 -0000 At Tue, 15 Aug 2017 13:39:41 -0700, Fred Baker wrote: > When David and Jinmei started using the word "consensus" and asked > what the chairs thought, the chairs went off in a huddle. This is us > coming back. [...] > Our perception of the difference between David and Jinmei here > surrounds getaddrinfo(); David wants all implementations to use the > AAAA record the instant it comes back, and the A record only if the > AAAA record is significantly delayed, while Jinmei wants to > grandfather implementations using existing APIs that insist on > having both or seeing a timeout. To be clear, I personally don't have a *strong* opinion on the choice. If the wg without me decides a MUST is more appropriate, that's fine. I raised this point in my review comment just in case it's an oversight since I've observed this has been a controversial point and I don't think I saw an explicit wg consensus about that. But, if what I feel matters, I actually think a MUST is too strong, exactly for the reason you explained below, that is, I just don't see why this requirement must inevitably be a MUST. I also agree SHOULD/SHOULD NOT is more suitable in cases like this. > We (the chairs) have sympathy in both directions, but suspect that > Jinmei's is more realistic. From a strategic perspective, we want > all applications to do this; making it harder reduces the > probability of it happening, and making it easy makes it more > likely. Not all OS's (think IOT RTOS's) have threads, and not all > have asynchronous DNS resolution. Practically, we suspect that > implementors will do what is straightforward, and not do the rest - > HEv1.5, if you will. In addition, at least the way I use "MUST" in > an RFC, when I say something MUST (or MUST NOT) be done, failing on > the point results in something dramatic. If I say that a TCP > implementation MUST eventually acknowledge every segment it > correctly receives in sequence, and someone doesn't, the result is a > perpetual TCP session transmitting and retransmitting the same > data. That's pretty fundamental. I don't see an interoperability > failure if an implementation doesn't resolve DNS asynchronously; I > do see a delay, and a reason that an asynchronous implementation > might be preferred in the market. So to me, this sounds more like > "SHOULD/SHOULD NOT" - we would like folks to do this, and if they > don't they should understand the implications of not doing so, but > it doesn't break in any fundamental way. -- JINMEI, Tatuya From nobody Wed Aug 16 11:50:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8E1326B8 for ; Wed, 16 Aug 2017 11:50:41 -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 oRc7JdUAdxOb for ; Wed, 16 Aug 2017 11:50:39 -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 AD7CB1321B9 for ; Wed, 16 Aug 2017 11:50:39 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7GIjDvY033176; Wed, 16 Aug 2017 14:50:34 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2cctgqb61s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Aug 2017 14:50:34 -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 v7GIoV1W014284; Wed, 16 Aug 2017 14:50:33 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7GIoM1U014085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Aug 2017 14:50:25 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi134.aldc.att.com (RSA Interceptor); Wed, 16 Aug 2017 18:50:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 14:50:08 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis Thread-Index: AQHTFrDkDyopZSCqPECeE9IeBL2bAqKHT+1w Date: Wed, 16 Aug 2017 18:50:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.235.185] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160306 Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:50:42 -0000 PiBIb3dldmVyLCBpZiB3ZSBkb27igJl0IHdhbnQgdG8gdG91Y2ggUkZDNzA4NCwgc2VlbXMgdG8g bWUgZGlmZmljdWx0IHRoYXQgd2UNCj4gY2FuIGRvIGl0IGluIGEg4oCcdHJhbnNpdGlvbuKAnSBv bmx5IGRvY3VtZW50Lg0KDQo8YmhzPiBJIGRpc2FncmVlLiBJIHRoaW5rIGl0IHdvdWxkIGFjdHVh bGx5IGJlIGVhc2llciBpbiBhICJ0cmFuc2l0aW9uIiBvbmx5IGRvY3VtZW50LiBTdWNoIGEgZG9j dW1lbnQgY291bGQgZWFzaWx5IGhhdmUgYSByZXF1aXJlbWVudCBhbG9uZyB0aGUgbGluZXMgb2Y6 DQpJZiBubyBXQU4gSVB2NCBjb25uZWN0aXZpdHkgaXMgcHJlc2VudCAobmF0aXZlIG9yIHRocm91 Z2ggb25lIG9mIHRoZSB0ZWNobm9sb2dpZXMgaW4gdGhpcyBkb2N1bWVudCksIHRoZSBDRSBSb3V0 ZXIgTVVTVCAuLi4NCkknbSBub3Qgc3VyZSB3aGF0IGl0IG11c3QgZG8sIHRob3VnaC4gDQpJIGRv bid0IHRoaW5rIHRoZSBzb2x1dGlvbiBpbnZvbHZlcyBJUHY2IHNpZ25hbGluZywgYW5kIHB1dHRp bmcgTEFOLWZhY2luZyBJUHY0IHByb3RvY29sIHJlcXVpcmVtZW50cyBpbiBSRkM3MDg0YmlzIHdv dWxkIGJlIHByb2JsZW1hdGljLiBCdXQgaXQgd291bGQgbm90IGJlIGEgcHJvYmxlbSBpbiBhICJ0 cmFuc2l0aW9uIiBkb2MuIC0gQmFyYmFyYTwvYmhzPg0KIA0KPiBTbywgZG8gd2Ugd2FudCB0byBy ZS1jb25zaWRlciB0aGlzIGRlY2lzaW9uIGFnYWluPw0KPiANCj4gTXkgcGxhbiwgaWYgdGltZSBw ZXJtaXRzLCBpcyB0byB1cGRhdGUgZWl0aGVyIG9uZSBvciB0aGUgb3RoZXIgZG9jdW1lbnQgbmV4 dA0KPiB3ZWVrLg0KPiANCj4gUmVnYXJkaW5nIDYmNywgSSBhY3R1YWxseSBwcm92aWRlZCB0ZXh0 IG9uIHRoYXQgdG8gdGhlIGF1dGhvcnMsIGFuZCBvbmUgb2YgbXkNCj4gY29tbWVudHMgd2FzIGlu IHRoZSBkaXJlY3Rpb24gb2YgUkZDNjU1NS1iaXMgY2FuIHNvbWVob3cgc29ydCBvdXQgdGhvc2Us DQo+IGJ1dCB0aGUgYWN0dWFsIHRleHQgaXMgc3RpbGwgYmFzZWQgaW4gUkZDNjU1NSB1bnRpbCBS RkM2NTU1LWJpcyBiZWNvbWUgYW4gUkZDLA0KPiBpbiBvcmRlciB0byBhdm9pZCDigJxob2xkaW5n 4oCdIGRyYWZ0LWlldGYtc3Vuc2V0NC1nYXBhbmFseXNpcy0wOSwgc28gYWxsIGRlcGVuZHMNCj4g b24gaG93IGZhc3Qgd2UgbW92ZSB3aXRoIG9uZSBvciB0aGUgb3RoZXIg4oCmDQo+IA0KPiBSZWdh cmRzLA0KPiBKb3JkaQ0KPiANCj4gDQo+IC0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERl OiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIExlZSBIb3dhcmQN Cj4gPGxlZUBhc2dhcmQub3JnPiBSZXNwb25kZXIgYTogPGxlZUBhc2dhcmQub3JnPg0KPiBGZWNo YTogbWnDqXJjb2xlcywgMTYgZGUgYWdvc3RvIGRlIDIwMTcsIDE4OjI4DQo+IFBhcmE6IDx2Nm9w c0BpZXRmLm9yZz4NCj4gQXN1bnRvOiBbdjZvcHNdIFN1bnNldDQgZ2FwIGFuYWx5c2lzOiByZmM2 NTU1YmlzLCBpcHY2cnRyLXJlcXMsIHJmYzcwODQtYmlzDQo+IA0KPiAgICAgUmVhZGluZyB0aHJv dWdoIGRyYWZ0LWlldGYtc3Vuc2V0NC1nYXBhbmFseXNpcy0wOSBpdCBzZWVtZWQgdG8gbWUgdGhh dA0KPiBzZXZlcmFsIHByb2JsZW1zIG1pZ2h0IGJlIHJlc29sdmFibGUgaW4gZG9jdW1lbnRzIHdl IGN1cnJlbnRseSBoYXZlIG9wZW46DQo+IA0KPiAgICAgQ2FuIHByb2JsZW1zIDEtNSAoaW5kaWNh dGluZyB0aGF0IElQdjQgaXMgdW5hdmFpbGFibGUsIGRpc2FibGluZyBJUHY0IGluIHRoZQ0KPiBM QU4pIGJlIGFkZHJlc3NlZCB3aXRoIHJlY29tbWVuZGF0aW9ucyBpbiBhbnksIHNvbWUsIG9yIGFs bCBvZjoNCj4gICAgIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzLTAwICJSZXF1aXJlbWVu dHMgZm9yIElQdjYgUm91dGVycyINCj4gICAgIGRyYWZ0LWlldGYtdjZvcHMtcmZjNzA4NC1iaXMt MDQgIOKAnEJhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lcg0KPiBFZGdlIFJvdXRl cnMiDQo+ICAgICBPciBvdGhlciBkcmFmdHMgdW5kZXIgZGlzY3Vzc2lvbiBpbiB2Nm9wcyBub3c/ DQo+ICAgICBPciBkbyB3ZSBuZWVkIG5ldyBJUHY2IHNpZ25hbGxpbmcgKFJBPykgdGhhdCBJUHY0 IGlzIHVuYXZhaWxhYmxlPyBUaGF0DQo+IHdvdWxkIGhhdmUgdG8gZ28gdG8gNm1hbi4gT3IgZGlk IHdlIGRvIHRoaXMsIGFuZCBJ4oCZdmUgZm9yZ290dGVuIGluIG15IG9sZA0KPiBhZ2U/DQo+IA0K PiANCj4gDQo+ICAgICBBcmUgcHJvYmxlbXMgNiAmIDcgKEhhcHB5IEV5ZWJhbGxzIGFuZCBnZXRh ZGRyaW5mbygpKSBhZGRyZXNzZWQgd2l0aA0KPiBkcmFmdC1pZXRmLXY2b3BzLXJmYzY1NTViaXMt MDMsICAiSGFwcHkgRXllYmFsbHMgVmVyc2lvbiAyOiBCZXR0ZXINCj4gQ29ubmVjdGl2aXR5IFVz aW5nIENvbmN1cnJlbmN54oCdPw0KPiAgICAgQ2FuIHByb2JsZW0gMTAgYmUgYWRkcmVzc2VkIGlu IHJmYzY1NTUtYmlzPw0KPiANCj4gICAgIFRoYW5rcywNCj4gDQo+ICAgICBMZWUNCj4gDQo+ICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAg djZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRT UWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09dXpjY1ZFM1hnV3BjcEZHTVE5 cWpGLUlHaTZaZzd3cE9tMVQxb04tDQo+IFJVWnMmcz1kQW5xRjBJV0FJYnozX3d2WlNtNVNCSnF2 R0dSc3dJajRucEd0SmFQLTdNJmU9DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cuY29uc3VsaW50ZWwuZXMmZD1Ed0lH YVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZy Zm9nJm09dXpjY1ZFM1hnV3BjcEZHTVE5cWpGLUlHaTZaZzd3cE9tMVQxb04tDQo+IFJVWnMmcz1O SHgxbEZQZVpRMTNaRlFLUkhwdk5meDF2VGJqdW1hcUt2Ymh1ek5lYkUwJmU9DQo+IFRoZSBJUHY2 IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNvbmZpZGVudGlhbC4gVGhlIGluZm9y bWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMp DQo+IG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJl IGF3YXJlIHRoYXQgYW55DQo+IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sDQo+IGluY2x1ZGluZyBhdHRh Y2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9 RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+IDhzYzhTWThU cTR2cmZvZyZtPXV6Y2NWRTNYZ1dwY3BGR01ROXFqRi1JR2k2Wmc3d3BPbTFUMW9OLQ0KPiBSVVpz JnM9ZEFucUYwSVdBSWJ6M193dlpTbTVTQkpxdkdHUnN3SWo0bnBHdEphUC03TSZlPQ0K From nobody Wed Aug 16 12:47:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBC0132350 for ; Wed, 16 Aug 2017 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPTlkKsBD-Hp for ; Wed, 16 Aug 2017 12:47:22 -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 5D6A3132143 for ; Wed, 16 Aug 2017 12:47:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 8B1C31BC37 for ; Wed, 16 Aug 2017 19:47:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 16 Aug 2017 20:47:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> To: v6ops list X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 19:47:25 -0000 Lorenzo Colitti wrote: > /64 gives you something that no longer prefix does: the ability to run = SLAAC and connect unlimited devices behind the host.=20 =46rom previous discussions, I am led to believe that SLAAC will work = with other (longer or shorter) prefixes. It is only the deprecated EUI64 = method that *needs* 64 bits. > No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly = announces it in an RA. Are you suggesting that someone who realises that not everything is a = /64 would do that ? You've not really done anything to counter this = being a case of "everything is /64" thinking and thus ignoring the = potential for anything else. It may be a simple case of blindly = re-announcing the prefix you got delegated - but it still comes down to = not understanding that the prefix may be other than /64. > That doesn't work because SLAAC only works with 64-bit IIDs, and for = good reason. As above, I've seen comments here stating that this isn't the case. > Already? 64 everywhere has been the standard for 20 almost years now. = It predates pretty much every IPv6 network and every IPv6 implementation = out there today. And that hardcodes in a restriction which IN THE REAL WORLD is known to = cause issues. For example, you (incorrectly) only get a single /64 from = upstream, but want to something other than a single host or very simple = network. I agree that it shouldn't happen, but in the real world it does = - you either stick with a simple basic network, or you run prefixes = smaller than a /64. From nobody Wed Aug 16 13:21:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3D1326DD for ; Wed, 16 Aug 2017 13:21: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 rvOhTzWvFuXb for ; Wed, 16 Aug 2017 13:21:22 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566D81326EA for ; Wed, 16 Aug 2017 13:21:22 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v189so27996644pgd.2 for ; Wed, 16 Aug 2017 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4FkAF+ItDzcJMqllmyNiJmwHYXH0k6Ldgf4SdlHbP/E=; b=LvrE1wdYYAytSlmTN+BzBmSl/c7l6f+mZktagtvyQPdCEc2FlQ0CuNHZtq0Y/zkmC1 YDkqgLG7pbnsGJfmLh/1ZC+WLYjsMEQ+3kb8ytJ85D3nisC6kA2eFmD3tNWiiWyB6JLj j9HL18EsSwTX3enE/dMPqyhr/eFx86eWQ5WkJfaO56LJxj17t+0gmqfpUetJXTv7uYw2 xDHZ7bqT8zzNYUwffZGxaO+JX4TDRsDY3tkjvKlIfwQktiwY10Gfw8FsLXBWC3z+5jWr GJfxY6eY6BsGUG/1A6gJT3hxpXwI2bbI2B6TvqRqsWloMGd8z8Cme+gCEzzGBjn7njs9 mYRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4FkAF+ItDzcJMqllmyNiJmwHYXH0k6Ldgf4SdlHbP/E=; b=cUqnO1cMqzq+R39JwxfzALneAe6GHfKtDi84MjVa71Gtmq659OF1W3+bht2iHgqmaj /iazgsT/NCptamadrJHVwGGXcxYN9uRoku2/AbTF51EBFQKlvl0JB8h/HzK3PMG6TUC8 z+ufxlljJV1oDg4RDbI2rSciWQYN60cILUV6LsGiTaJP3oO06+Sq6TqofZ0HJy8OvNEK stRUKEIDjg7j1fXo6M2zvinl7H5QrzY5xovVNjN4xcoSG1C9wye7vIN1w/qF41DNoYNR YM24HMSrz3/FlIL0zMaNLuTe9zDA+Aa1wHi8CswAFahPVrBET2jDys5JderdFTnXRPip quVg== X-Gm-Message-State: AHYfb5gX6/Qdnijy1DmyJ6Jl3Qk67QTarWLlCCy/gciwCvAmd0g7ebw5 ry2LB7I/Ucfs/+++ X-Received: by 10.84.253.16 with SMTP id z16mr3016999pll.81.1502914881504; Wed, 16 Aug 2017 13:21:21 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b4sm3017398pgc.9.2017.08.16.13.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 13:21:20 -0700 (PDT) To: Simon Hobson , v6ops list References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 17 Aug 2017 08:21:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 20:21:24 -0000 On 17/08/2017 07:47, Simon Hobson wrote: > Lorenzo Colitti wrote: > > >> /64 gives you something that no longer prefix does: the ability to run SLAAC and connect unlimited devices behind the host. > >>From previous discussions, I am led to believe that SLAAC will work with other (longer or shorter) prefixes. It is only the deprecated EUI64 method that *needs* 64 bits. Properly coded SLAAC will work with any reasonable length, but standards-compliant IPv6-over-foo drivers will *all* inform SLAAC that the length is 64, because that is the parameter set by the addressing architecture. What we are discussing here is not SLAAC, or the fact that each driver has to inform SLAAC about the IID length, but whether the addressing architecture should continue to define a universal constant for that parameter. And we are certainly not discussing whether IPv6 supports variable length subnet masks. Brian From nobody Wed Aug 16 13:37:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEAD1326F5 for ; Wed, 16 Aug 2017 13:37:15 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLwOoOWWJT1R for ; Wed, 16 Aug 2017 13:37:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56C31326DB for ; Wed, 16 Aug 2017 13:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502915831; x=1503520631; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=90PK7/uiF6yU0lSk9w7czl/vA aTQDFEs3qR8XpKGHI0=; b=EhpUPsnplVNZhYjAJQzalMWkXailGKooQoLetx1tl TPLS/oPSkhloyKVRGbhVtYS91eRQ/mGXUBdbgjgqYZf7/0ZoBkVc+CLcgeJIqcnW FQOYYMLcp23PAlRZP8qOMDlD3d1vl4eruWZpiTcaToLMLoSJCeOJbCqEOOIYIWJN Y4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ePQSkFKnbOZITiwFB/uhgxhx703pvJtCNi7/yhcHoSFoHvzR1abSYY4ckDqo xzuIV/IZ0xptXZhlTUoIzRrV9aBtCBO1ET9aeQ3LVMn/f0db9diDHlaQn DpCQRsFGgJRinzIAKw39l4nEbvpAJJ5uP8tV/67BCapacNgnLcA0kA=; X-MDAV-Processed: mail.consulintel.es, Wed, 16 Aug 2017 22:37:11 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 16 Aug 2017 22:37:10 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005507345.msg for ; Wed, 16 Aug 2017 22:37:09 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170816:md50005507345::avqSEj8Eu7R2q9+J:00002Zlq X-Return-Path: prvs=1401d3a9dd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Wed, 16 Aug 2017 22:37:08 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis References: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 20:37:16 -0000 Hi Barbara, draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when IPv= 4 is no longer available. So, if RFC7084 is an IPv6 only-CE (even if the CE can have an IPv4 stack), = then we have those problems when there is no IPv4 connectivity. If the IPv6-CE supports transition, then you never have those problems, bec= ause the goal of the transition support is precisely to avoid them. It is n= ot a matter of IPv4 in the WAN. You can have IPv6-only WAN, but transition = can resolve that. Or I=E2=80=99m missing anything in your opinion? The problem here, in my opinion is that in the actual RFC7084 you =E2=80=9C= allow=E2=80=9D the support of IPv4, so is in that case when, if there is no= transition support, the problems 1-5 may be presented in the LANs. So, one alternative is again considering my proposal of making an RFC7084 w= ith is =E2=80=9Creally=E2=80=9D only-IPv6 (removing ALL the IPv4 support in= that document), and then it make sense to have other documents with the tr= ansition support, etc., and then finding the right one for resolving the pr= oblems above. Actually, some of the problems, in my opinion, can be resolved just in the = OS, but is not a matter here to discuss one by one. For example, problem 1,= some OS may believe there is only =E2=80=9CInternet=E2=80=9D if there is a= DHCP server responding, even if they have IPv6 connectivity, etc., but thi= s can be sorted out in the actual RFC7084 if there is IPv4 stack, and there= is no transition support and there is not IPv4 support, by making sure tha= t the DHCPv4 server in the CE is not turned on in that case =E2=80=A6 Of course, it can probably be done in one more document to =E2=80=9Ccomplem= ent RFC7084=E2=80=9D. Thinking twice, I could, as well, for maybe 1 or 2 of the problems, have so= me text in the transition doc, but I don=E2=80=99t think all them can be re= solved in that doc. So, to do it correctly I think RFC7084 needs to be updated (and maybe then = remove the transition stuff there, so all the transition goes to the transi= tion one). I=E2=80=99m just thinking loud and trying to heard the WG. Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 20:50 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084= -bis > However, if we don=E2=80=99t want to touch RFC7084, seems to me diffi= cult that we > can do it in a =E2=80=9Ctransition=E2=80=9D only document. =20 I disagree. I think it would actually be easier in a "transition"= only document. Such a document could easily have a requirement along the l= ines of: If no WAN IPv4 connectivity is present (native or through one of the te= chnologies in this document), the CE Router MUST ... I'm not sure what it must do, though.=20 I don't think the solution involves IPv6 signaling, and putting LAN-fac= ing IPv4 protocol requirements in RFC7084bis would be problematic. But it w= ould not be a problem in a "transition" doc. - Barbara =20 > So, do we want to re-consider this decision again? >=20 > My plan, if time permits, is to update either one or the other docume= nt next > week. >=20 > Regarding 6&7, I actually provided text on that to the authors, and o= ne of my > comments was in the direction of RFC6555-bis can somehow sort out tho= se, > but the actual text is still based in RFC6555 until RFC6555-bis becom= e an RFC, > in order to avoid =E2=80=9Cholding=E2=80=9D draft-ietf-sunset4-gapana= lysis-09, so all depends > on how fast we move with one or the other =E2=80=A6 >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Lee Howard > Responder a: > Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:28 > Para: > Asunto: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc70= 84-bis >=20 > Reading through draft-ietf-sunset4-gapanalysis-09 it seemed to me= that > several problems might be resolvable in documents we currently have o= pen: >=20 > Can problems 1-5 (indicating that IPv4 is unavailable, disabling = IPv4 in the > LAN) be addressed with recommendations in any, some, or all of: > draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" > draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for = IPv6 Customer > Edge Routers" > Or other drafts under discussion in v6ops now? > Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable?= That > would have to go to 6man. Or did we do this, and I=E2=80=99ve forgott= en in my old > age? >=20 >=20 >=20 > Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed w= ith > draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better > Connectivity Using Concurrency=E2=80=9D? > Can problem 10 be addressed in rfc6555-bis? >=20 > Thanks, >=20 > Lee >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > RUZs&s=3DdAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=3D >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.consulintel.es&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > RUZs&s=3DNHx1lFPeZQ13ZFQKRHpvNfx1vTbjumaqKvbhuzNebE0&e=3D > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the in= dividual(s) > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this info= rmation, > including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > RUZs&s=3DdAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=3D =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Aug 16 14:08:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B116132356 for ; Wed, 16 Aug 2017 14:08:33 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ijOlfDvwqQ5 for ; Wed, 16 Aug 2017 14:08:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5B11323BA for ; Wed, 16 Aug 2017 14:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502917705; x=1503522505; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=Vdp146IovcM1btZacqNm5QBHD E8IvJWMHJCe9ilyoYw=; b=Xfw8q7wSHd2jrIYhmHMTLKxpkYxqpM8PKTHDPOZp8 uhyPR+sdMpRHbo+vI+8MystXhRzTWHjjaLC+2q5/sWrvZyAx9Me7P2Ww1bR5+8Gd uBV4LHX6JqXnKOay+FMVCANhUmf6KMUitx++Z+YMSlzhROYLAT10VqELWPn7yLL2 9A= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=HHMBIUJwseJEebXOioS1w3UQMbF8wGCUGiDZa9dK9DWelzv940hK8uy+ivD9 FuQw4yjihfrY1dPIzzMNemTMjJQlkmR8h0jkg5yQm+YGz23stkZb3cT5L ZARTbgxzBcnkJHGR/QBUAez6U7OLzw2EZK7fu2Fssm/xbnVmDXk2X0=; X-MDAV-Processed: mail.consulintel.es, Wed, 16 Aug 2017 23:08:25 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 16 Aug 2017 23:08:24 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005507444.msg for ; Wed, 16 Aug 2017 23:08:24 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170816:md50005507444::mEhdf4SmyF9ScYLn:00003Wy5 X-Return-Path: prvs=1401d3a9dd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Wed, 16 Aug 2017 23:08:20 +0200 From: JORDI PALET MARTINEZ To: "sunset4@ietf.org" , Message-ID: Thread-Topic: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:08:33 -0000 (copying v6ops) Forgot something here regarding: 4. Write a guidance document for IPv4-on-demand, covering problems 10-14. I think this can be done in draft-palet-v6ops-rfc7084-bis-transition-00, wh= ich I plan to review next week (in this case I believe it belongs to v6ops)= , otherwise, I will draft something else (need to identify then if v6ops, s= unset4 or some other WG). Regards, Jordi =20 -----Mensaje original----- De: sunset4 en nombre de Lee Howard Responder a: Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:27 Para: "Liushucheng (Will Liu)" , "sunset4@ietf.org"= Asunto: Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt I admit, it=E2=80=99s been a long time since I=E2=80=99ve read this dra= ft. =20 One capability gap we still have: there=E2=80=99s no IPv6 version of Fl= owSpec. There is an idr WG draft, but it hasn=E2=80=99t had a lot of discussion= in recent months:=20 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flow-spec-v6-08 =20 Review of the gap-analysis draft: (summary at the bottom) There are 16 specific problems identified. Some solutions are proposed = in Annex A; I=E2=80=99d rather see those incorporated into the text. =20 Can problems 1-5 (indicating that IPv4 is unavailable, disabling IPv4 i= n the LAN) be addressed with recommendations in any, some, or all of: draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for IPv6 C= ustomer Edge Routers" =20 Or other drafts under discussion in v6ops now? Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable (as in A.1.1 and A.1.2)? =20 Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency=E2=80=9D? =20 =20 =20 Problems 8 and 9 are about surprises when IPv4 support is removed from = the kernel. I remember reading about this several years ago; should we have= a hackathon to repeat the experiment? =20 I=E2=80=99m not very clear on the IPv4-on-demand scenario described in = Section 6 (and I don=E2=80=99t understand the solution in A.4). But we should pro= bably write a guidance document on how to handle problems 10-14, don=E2=80=99t you = think? Anyone want to volunteer for that? Could Problem 10 be addressed in Happy Eyeballs v2, rfc6555bis? =20 Problem 15 (IPv4 address literals) is mitigated with most transition technologies, isn=E2=80=99t it? Not NAT64 (requiring DNS64), but 464xla= t, DS-Lite, MAP. =20 I like the solutions proposed for Problem 16 (Router IDs): Just pick a 32-bit number and use it as the last 32 bits of the IPv6 address. If yo= u try, you could use it in multiple prefixes on the same router, includin= g Loopback, Link Local, and even GUAs. I=E2=80=99m not entirely sure this= problem qualifies as a gap, so much as an operational consideration. =20 =20 Summary of proposed actions: 1. Ask authors of draft-ietf-v6ops-ipv6rtr-reqs-00 and draft-ietf-v6ops-rfc7084-bis-04 to consider whether they can respond t= o problems 1-5. 2. Confirm that problems 6-7 are resolved in rfc6555bis, and ask whethe= r problem 10 can be. 3. Hackathon removing IPv6 support from the kernel. If it=E2=80=99s an = IETF Hackathon, need a Champion who is comfortable hacking the kernel. Would= be great to include people from Windows, Apple, Android. 4. Write a guidance document for IPv4-on-demand, covering problems 10-1= 4. =20 =20 I will do the first two things. Do people agree with the other two things? Anyone want to volunteer? =20 Lee =20 =20 =20 =20 On 8/3/17, 7:08 AM, "sunset4 on behalf of Liushucheng (Will Liu)" wrote: =20 >Hi all, > >We've updated the draft according to the comments we received online a= nd >offline. Please take a look and let us know your thought. > >Thanks! > >Will > >-----Original Message----- >From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Tuesday, August 01, 2017 7:32 PM >To: i-d-announce@ietf.org >Cc: sunset4@ietf.org >Subject: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Sunsetting IPv4 WG of the IETF. > > Title : Gap Analysis for IPv4 Sunset > Authors : Will(Shucheng) Liu > Weiping Xu > Cathy Zhou > Tina Tsou > Simon Perreault > Peng Fan > Rong Gu > Chongfeng Xie > Ying Cheng > Filename : draft-ietf-sunset4-gapanalysis-09.txt > Pages : 11 > Date : 2017-08-01 > >Abstract: > Sunsetting IPv4 refers to the process of turning off IPv4 > definitively. It can be seen as the final phase of the transition = to > IPv6. This memo enumerates difficulties arising when sunsetting > IPv4, and identifies the gaps requiring additional work. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis/ > >There are also htmlized versions available at: >https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09 >https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-gapanalysis-0= 9 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sunset4-gapanalysis-09 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 > =20 =20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Aug 16 14:33:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4813271F for ; Wed, 16 Aug 2017 14:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThZOCInJhUuV for ; Wed, 16 Aug 2017 14:33:07 -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 BC1AA13271E for ; Wed, 16 Aug 2017 14:33:07 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7GLQV1r037841; Wed, 16 Aug 2017 17:33:01 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2ccv91c5jy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Aug 2017 17:33:00 -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 v7GLWxgJ024010; Wed, 16 Aug 2017 17:33:00 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7GLWrF5023953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Aug 2017 17:32:54 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi134.aldc.att.com (RSA Interceptor); Wed, 16 Aug 2017 21:32:38 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 17:32:19 -0400 From: "STARK, BARBARA H" To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis Thread-Index: AQHTFrDkDyopZSCqPECeE9IeBL2bAqKHT+1wgABkmgD//8OmYA== Date: Wed, 16 Aug 2017 21:32:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> In-Reply-To: <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.235.185] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160351 Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:33:10 -0000 SW5saW5lLi4uDQpCYXJiYXJhDQoNCj4gZHJhZnQtaWV0Zi1zdW5zZXQ0LWdhcGFuYWx5c2lzLTA5 LCBwcm9ibGVtcyAxLTUsIHJlZmVyIHRvIHRoZSBjYXNlIHdoZW4gSVB2NA0KPiBpcyBubyBsb25n ZXIgYXZhaWxhYmxlLg0KDQpZZXM6IE5vdCBhdmFpbGFibGUgKHRocm91Z2ggYW55IG1lYW5zKSBv biB0aGUgV0FOLiBCdXQgc3RpbGwgdXNlZCBvbiB0aGUgTEFOLg0KDQo+IFNvLCBpZiBSRkM3MDg0 IGlzIGFuIElQdjYgb25seS1DRSAoZXZlbiBpZiB0aGUgQ0UgY2FuIGhhdmUgYW4gSVB2NCBzdGFj ayksIHRoZW4NCj4gd2UgaGF2ZSB0aG9zZSBwcm9ibGVtcyB3aGVuIHRoZXJlIGlzIG5vIElQdjQg Y29ubmVjdGl2aXR5Lg0KDQpZZXM6IFdlIHdpbGwgaGF2ZSB0aGUgZGVzY3JpYmVkIHByb2JsZW1z IGlmIHRoZXJlIGlzIG5vIElQdjQgYXZhaWxhYmxlIG9uIHRoZSBXQU4gKHRocm91Z2ggYW55IG1l YW5zKS4NCg0KPiBJZiB0aGUgSVB2Ni1DRSBzdXBwb3J0cyB0cmFuc2l0aW9uLCB0aGVuIHlvdSBu ZXZlciBoYXZlIHRob3NlIHByb2JsZW1zLA0KPiBiZWNhdXNlIHRoZSBnb2FsIG9mIHRoZSB0cmFu c2l0aW9uIHN1cHBvcnQgaXMgcHJlY2lzZWx5IHRvIGF2b2lkIHRoZW0uIEl0IGlzIG5vdA0KPiBh IG1hdHRlciBvZiBJUHY0IGluIHRoZSBXQU4uIFlvdSBjYW4gaGF2ZSBJUHY2LW9ubHkgV0FOLCBi dXQgdHJhbnNpdGlvbiBjYW4NCj4gcmVzb2x2ZSB0aGF0Lg0KPiANCj4gT3IgSeKAmW0gbWlzc2lu ZyBhbnl0aGluZyBpbiB5b3VyIG9waW5pb24/DQoNClBsZWFzZSBjb3JyZWN0IG1lIGlmIEknbSB3 cm9uZywgYnV0IEkgdGhvdWdodCBhbGwgdGhlIGRlc2NyaWJlZCBtZWNoYW5pc21zIHJlcXVpcmUg YSBjb3JyZWxhdGVkIGNhcGFiaWxpdHkgaW4gdGhlIFdBTi4gSnVzdCBiZWNhdXNlIGEgQ0Ugcm91 dGVyIHN1cHBvcnRzIGFsbCBvZiB0aGVzZSBkb2Vzbid0IG1lYW4gYW55IG9mIHRoZW0gbmVjZXNz YXJpbHkgZXhpc3QgaW4gdGhlIFdBTiwgb3IgdGhhdCBjb25maWd1cmF0aW9uIG9mIGFueSBvZiB0 aGVtIHZpYSBESENQdjYgaXMgc3VwcG9ydGVkIGJ5IHRoZSBJU1AgKFdBTiBtYXkgaGF2ZSBjYXBh YmlsaXR5IGJ1dCByZXF1aXJlcyBtYW51YWwgQ0UgUm91dGVyIGNvbmZpZyB3aGljaCBtYW55IGVu ZCB1c2VycyB3b24ndCBrbm93IGhvdyB0byBkbykuIFNvIEkgdGhpbmsgc3VwcG9ydCBpbiB0aGUg Q0UgUm91dGVyLCBieSBpdHNlbGYsIGlzIGluc3VmZmljaWVudCB0byBlbnN1cmUgSVB2NCBXQU4g YXZhaWxhYmlsaXR5LiBUaGVyZWZvcmUsIGV2ZW4gaWYgYSBDRSBSb3V0ZXIgc3VwcG9ydHMgYWxs IG9mIHRoZXNlLCBpdCBpcyBzdGlsbCBwb3NzaWJsZSBmb3IgdGhlcmUgdG8gYmUgbm8gSVB2NCBX QU4gY29ubmVjdGlvbi4gSU1PLCBDRSBSb3V0ZXIgcmVxdWlyZW1lbnRzIHRoYXQgZXhwbGljaXRs eSB0YXJnZXQgSVB2Ni1vbmx5IG9wZXJhdGlvbiB3b3VsZCBiZSBhIHZlcnkgbG9naWNhbCBwbGFj ZSB0byBpbmNsdWRlIHJlcXVpcmVtZW50cyBmb3IgIndoYXQgdG8gZG8gd2hlbiB0aGVyZSBpcyBu byBJUHY0IGluIHRoZSBXQU4iLg0KDQo+IFRoZSBwcm9ibGVtIGhlcmUsIGluIG15IG9waW5pb24g aXMgdGhhdCBpbiB0aGUgYWN0dWFsIFJGQzcwODQgeW91IOKAnGFsbG934oCdIHRoZQ0KPiBzdXBw b3J0IG9mIElQdjQsIHNvIGlzIGluIHRoYXQgY2FzZSB3aGVuLCBpZiB0aGVyZSBpcyBubyB0cmFu c2l0aW9uIHN1cHBvcnQsIHRoZQ0KPiBwcm9ibGVtcyAxLTUgbWF5IGJlIHByZXNlbnRlZCBpbiB0 aGUgTEFOcy4NCj4gDQo+IFNvLCBvbmUgYWx0ZXJuYXRpdmUgaXMgYWdhaW4gY29uc2lkZXJpbmcg bXkgcHJvcG9zYWwgb2YgbWFraW5nIGFuIFJGQzcwODQNCj4gd2l0aCBpcyDigJxyZWFsbHnigJ0g b25seS1JUHY2IChyZW1vdmluZyBBTEwgdGhlIElQdjQgc3VwcG9ydCBpbiB0aGF0IGRvY3VtZW50 KSwNCj4gYW5kIHRoZW4gaXQgbWFrZSBzZW5zZSB0byBoYXZlIG90aGVyIGRvY3VtZW50cyB3aXRo IHRoZSB0cmFuc2l0aW9uIHN1cHBvcnQsDQo+IGV0Yy4sIGFuZCB0aGVuIGZpbmRpbmcgdGhlIHJp Z2h0IG9uZSBmb3IgcmVzb2x2aW5nIHRoZSBwcm9ibGVtcyBhYm92ZS4NCg0KQmVjYXVzZSBvZiB0 aGUgZXhpc3RlbmNlIG9mIHRoZSBDRSBSb3V0ZXIgSVB2NiBSZWFkeSBjZXJ0aWZpY2F0aW9uIHBy b2dyYW0sIHRoZSBtYW55IHJlZmVyZW5jZXMgdG8gUkZDIDcwODQgbWFkZSBieSBleHRlcm5hbCBv cmdzLCBldGMuIEkgY29udGludWUgdG8gYmUgb3Bwb3NlZCB0byBjaGFuZ2luZyBpdC4gVGhhdCB3 b3VsZCBhbG1vc3QgY2VydGFpbmx5IGNhdXNlIGNvbmZ1c2lvbiwgYW5kIGlzIHVubmVjZXNzYXJ5 LiBSZXF1aXJlbWVudHMgcmVsYXRlZCB0byBJUHY2LW9ubHkgV0FOIGNvbm5lY3Rpb25zICh3aXRo IG9yIHdpdGhvdXQgdGhlIFdBTiBzdXBwb3J0aW5nIGNvbmZpZ3VyYXRpb24gb3IgdGVybWluYXRp b24gb2YgYW4gSVB2NCB0dW5uZWxpbmcgbWVjaGFuaXNtKSBjYW4gYWxsIGxvZ2ljYWxseSBnbyBp biBhIHNpbmdsZSBuZXcgZG9jLg0KDQo+IEFjdHVhbGx5LCBzb21lIG9mIHRoZSBwcm9ibGVtcywg aW4gbXkgb3BpbmlvbiwgY2FuIGJlIHJlc29sdmVkIGp1c3QgaW4gdGhlIE9TLA0KPiBidXQgaXMg bm90IGEgbWF0dGVyIGhlcmUgdG8gZGlzY3VzcyBvbmUgYnkgb25lLiBGb3IgZXhhbXBsZSwgcHJv YmxlbSAxLA0KPiBzb21lIE9TIG1heSBiZWxpZXZlIHRoZXJlIGlzIG9ubHkg4oCcSW50ZXJuZXTi gJ0gaWYgdGhlcmUgaXMgYSBESENQIHNlcnZlcg0KPiByZXNwb25kaW5nLCBldmVuIGlmIHRoZXkg aGF2ZSBJUHY2IGNvbm5lY3Rpdml0eSwgZXRjLiwgYnV0IHRoaXMgY2FuIGJlIHNvcnRlZA0KPiBv dXQgaW4gdGhlIGFjdHVhbCBSRkM3MDg0IGlmIHRoZXJlIGlzIElQdjQgc3RhY2ssIGFuZCB0aGVy ZSBpcyBubyB0cmFuc2l0aW9uDQo+IHN1cHBvcnQgYW5kIHRoZXJlIGlzIG5vdCBJUHY0IHN1cHBv cnQsIGJ5IG1ha2luZyBzdXJlIHRoYXQgdGhlIERIQ1B2NA0KPiBzZXJ2ZXIgaW4gdGhlIENFIGlz IG5vdCB0dXJuZWQgb24gaW4gdGhhdCBjYXNlIOKApg0KDQpUaGF0J3MgYSBiYWQgaWRlYS4gSSBl eHBlY3QgbXkgaG9tZSBuZXR3b3JrIHRvIG9wZXJhdGUgaW4gdGhlIGFic2VuY2Ugb2YgYW55IGFu ZCBhbGwgV0FOIElQIGNvbm5lY3Rpb25zLiBJIHJlZnVzZSB0byBidXkgKG9yIHNlbGwgb3IgcmVj b21tZW5kKSBhIENFIHJvdXRlciB0aGF0IGRvZXMgbm90IGNvbnRpbnVlIHRvIG9wZXJhdGUgaXRz IERIQ1B2NCBzZXJ2ZXIgaW4gdGhlIGFic2VuY2Ugb2YgSVB2NCBXQU4gY29ubmVjdGl2aXR5LiBB bHNvLCBJIGRpc2FncmVlIHdpdGggcHV0dGluZyBhbnkgTEFOLXNpZGUgSVB2NCBwcm90b2NvbCBy ZXF1aXJlbWVudHMgaW50byBhIDcwODRiaXMuIA0KIA0KPiBPZiBjb3Vyc2UsIGl0IGNhbiBwcm9i YWJseSBiZSBkb25lIGluIG9uZSBtb3JlIGRvY3VtZW50IHRvIOKAnGNvbXBsZW1lbnQNCj4gUkZD NzA4NOKAnS4NCj4gDQo+IFRoaW5raW5nIHR3aWNlLCBJIGNvdWxkLCBhcyB3ZWxsLCBmb3IgbWF5 YmUgMSBvciAyIG9mIHRoZSBwcm9ibGVtcywgaGF2ZSBzb21lDQo+IHRleHQgaW4gdGhlIHRyYW5z aXRpb24gZG9jLCBidXQgSSBkb27igJl0IHRoaW5rIGFsbCB0aGVtIGNhbiBiZSByZXNvbHZlZCBp biB0aGF0DQo+IGRvYy4NCj4gDQo+IFNvLCB0byBkbyBpdCBjb3JyZWN0bHkgSSB0aGluayBSRkM3 MDg0IG5lZWRzIHRvIGJlIHVwZGF0ZWQgKGFuZCBtYXliZSB0aGVuDQo+IHJlbW92ZSB0aGUgdHJh bnNpdGlvbiBzdHVmZiB0aGVyZSwgc28gYWxsIHRoZSB0cmFuc2l0aW9uIGdvZXMgdG8gdGhlIHRy YW5zaXRpb24NCj4gb25lKS4NCj4gDQo+IEnigJltIGp1c3QgdGhpbmtpbmcgbG91ZCBhbmQgdHJ5 aW5nIHRvIGhlYXJkIHRoZSBXRy4NCj4gDQo+IFJlZ2FyZHMsDQo+IEpvcmRpDQo+IA0KPiANCj4g LS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6ICJTVEFSSywgQkFSQkFSQSBIIiA8YnM3 NjUyQGF0dC5jb20+DQo+IFJlc3BvbmRlciBhOiA8YnM3NjUyQGF0dC5jb20+DQo+IEZlY2hhOiBt acOpcmNvbGVzLCAxNiBkZSBhZ29zdG8gZGUgMjAxNywgMjA6NTANCj4gUGFyYTogImpvcmRpLnBh bGV0QGNvbnN1bGludGVsLmVzIiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+LA0KPiAidjZv cHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NCj4gQXN1bnRvOiBSRTogW3Y2b3BzXSBTdW5z ZXQ0IGdhcCBhbmFseXNpczogcmZjNjU1NWJpcywgaXB2NnJ0ci1yZXFzLCByZmM3MDg0LWJpcw0K PiANCj4gICAgID4gSG93ZXZlciwgaWYgd2UgZG9u4oCZdCB3YW50IHRvIHRvdWNoIFJGQzcwODQs IHNlZW1zIHRvIG1lIGRpZmZpY3VsdCB0aGF0DQo+IHdlDQo+ICAgICA+IGNhbiBkbyBpdCBpbiBh IOKAnHRyYW5zaXRpb27igJ0gb25seSBkb2N1bWVudC4NCj4gDQo+ICAgICA8YmhzPiBJIGRpc2Fn cmVlLiBJIHRoaW5rIGl0IHdvdWxkIGFjdHVhbGx5IGJlIGVhc2llciBpbiBhICJ0cmFuc2l0aW9u IiBvbmx5DQo+IGRvY3VtZW50LiBTdWNoIGEgZG9jdW1lbnQgY291bGQgZWFzaWx5IGhhdmUgYSBy ZXF1aXJlbWVudCBhbG9uZyB0aGUgbGluZXMNCj4gb2Y6DQo+ICAgICBJZiBubyBXQU4gSVB2NCBj b25uZWN0aXZpdHkgaXMgcHJlc2VudCAobmF0aXZlIG9yIHRocm91Z2ggb25lIG9mIHRoZQ0KPiB0 ZWNobm9sb2dpZXMgaW4gdGhpcyBkb2N1bWVudCksIHRoZSBDRSBSb3V0ZXIgTVVTVCAuLi4NCj4g ICAgIEknbSBub3Qgc3VyZSB3aGF0IGl0IG11c3QgZG8sIHRob3VnaC4NCj4gICAgIEkgZG9uJ3Qg dGhpbmsgdGhlIHNvbHV0aW9uIGludm9sdmVzIElQdjYgc2lnbmFsaW5nLCBhbmQgcHV0dGluZyBM QU4tZmFjaW5nDQo+IElQdjQgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGluIFJGQzcwODRiaXMgd291 bGQgYmUgcHJvYmxlbWF0aWMuIEJ1dCBpdCB3b3VsZA0KPiBub3QgYmUgYSBwcm9ibGVtIGluIGEg InRyYW5zaXRpb24iIGRvYy4gLSBCYXJiYXJhPC9iaHM+DQo+IA0KPiAgICAgPiBTbywgZG8gd2Ug d2FudCB0byByZS1jb25zaWRlciB0aGlzIGRlY2lzaW9uIGFnYWluPw0KPiAgICAgPg0KPiAgICAg PiBNeSBwbGFuLCBpZiB0aW1lIHBlcm1pdHMsIGlzIHRvIHVwZGF0ZSBlaXRoZXIgb25lIG9yIHRo ZSBvdGhlciBkb2N1bWVudA0KPiBuZXh0DQo+ICAgICA+IHdlZWsuDQo+ICAgICA+DQo+ICAgICA+ IFJlZ2FyZGluZyA2JjcsIEkgYWN0dWFsbHkgcHJvdmlkZWQgdGV4dCBvbiB0aGF0IHRvIHRoZSBh dXRob3JzLCBhbmQgb25lIG9mDQo+IG15DQo+ICAgICA+IGNvbW1lbnRzIHdhcyBpbiB0aGUgZGly ZWN0aW9uIG9mIFJGQzY1NTUtYmlzIGNhbiBzb21laG93IHNvcnQgb3V0DQo+IHRob3NlLA0KPiAg ICAgPiBidXQgdGhlIGFjdHVhbCB0ZXh0IGlzIHN0aWxsIGJhc2VkIGluIFJGQzY1NTUgdW50aWwg UkZDNjU1NS1iaXMgYmVjb21lIGFuDQo+IFJGQywNCj4gICAgID4gaW4gb3JkZXIgdG8gYXZvaWQg 4oCcaG9sZGluZ+KAnSBkcmFmdC1pZXRmLXN1bnNldDQtZ2FwYW5hbHlzaXMtMDksIHNvIGFsbA0K PiBkZXBlbmRzDQo+ICAgICA+IG9uIGhvdyBmYXN0IHdlIG1vdmUgd2l0aCBvbmUgb3IgdGhlIG90 aGVyIOKApg0KPiAgICAgPg0KPiAgICAgPiBSZWdhcmRzLA0KPiAgICAgPiBKb3JkaQ0KPiAgICAg Pg0KPiAgICAgPg0KPiAgICAgPiAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiAgICAgPiBE ZTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSBMZWUgSG93YXJk DQo+ICAgICA+IDxsZWVAYXNnYXJkLm9yZz4gUmVzcG9uZGVyIGE6IDxsZWVAYXNnYXJkLm9yZz4N Cj4gICAgID4gRmVjaGE6IG1pw6lyY29sZXMsIDE2IGRlIGFnb3N0byBkZSAyMDE3LCAxODoyOA0K PiAgICAgPiBQYXJhOiA8djZvcHNAaWV0Zi5vcmc+DQo+ICAgICA+IEFzdW50bzogW3Y2b3BzXSBT dW5zZXQ0IGdhcCBhbmFseXNpczogcmZjNjU1NWJpcywgaXB2NnJ0ci1yZXFzLCByZmM3MDg0LWJp cw0KPiAgICAgPg0KPiAgICAgPiAgICAgUmVhZGluZyB0aHJvdWdoIGRyYWZ0LWlldGYtc3Vuc2V0 NC1nYXBhbmFseXNpcy0wOSBpdCBzZWVtZWQgdG8gbWUNCj4gdGhhdA0KPiAgICAgPiBzZXZlcmFs IHByb2JsZW1zIG1pZ2h0IGJlIHJlc29sdmFibGUgaW4gZG9jdW1lbnRzIHdlIGN1cnJlbnRseSBo YXZlDQo+IG9wZW46DQo+ICAgICA+DQo+ICAgICA+ICAgICBDYW4gcHJvYmxlbXMgMS01IChpbmRp Y2F0aW5nIHRoYXQgSVB2NCBpcyB1bmF2YWlsYWJsZSwgZGlzYWJsaW5nIElQdjQgaW4NCj4gdGhl DQo+ICAgICA+IExBTikgYmUgYWRkcmVzc2VkIHdpdGggcmVjb21tZW5kYXRpb25zIGluIGFueSwg c29tZSwgb3IgYWxsIG9mOg0KPiAgICAgPiAgICAgZHJhZnQtaWV0Zi12Nm9wcy1pcHY2cnRyLXJl cXMtMDAgIlJlcXVpcmVtZW50cyBmb3IgSVB2NiBSb3V0ZXJzIg0KPiAgICAgPiAgICAgZHJhZnQt aWV0Zi12Nm9wcy1yZmM3MDg0LWJpcy0wNCAg4oCcQmFzaWMgUmVxdWlyZW1lbnRzIGZvciBJUHY2 IEN1c3RvbWVyDQo+ICAgICA+IEVkZ2UgUm91dGVycyINCj4gICAgID4gICAgIE9yIG90aGVyIGRy YWZ0cyB1bmRlciBkaXNjdXNzaW9uIGluIHY2b3BzIG5vdz8NCj4gICAgID4gICAgIE9yIGRvIHdl IG5lZWQgbmV3IElQdjYgc2lnbmFsbGluZyAoUkE/KSB0aGF0IElQdjQgaXMgdW5hdmFpbGFibGU/ IFRoYXQNCj4gICAgID4gd291bGQgaGF2ZSB0byBnbyB0byA2bWFuLiBPciBkaWQgd2UgZG8gdGhp cywgYW5kIEnigJl2ZSBmb3Jnb3R0ZW4gaW4gbXkgb2xkDQo+ICAgICA+IGFnZT8NCj4gICAgID4N Cj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgIEFyZSBwcm9ibGVtcyA2ICYgNyAoSGFwcHkg RXllYmFsbHMgYW5kIGdldGFkZHJpbmZvKCkpIGFkZHJlc3NlZCB3aXRoDQo+ICAgICA+IGRyYWZ0 LWlldGYtdjZvcHMtcmZjNjU1NWJpcy0wMywgICJIYXBweSBFeWViYWxscyBWZXJzaW9uIDI6IEJl dHRlcg0KPiAgICAgPiBDb25uZWN0aXZpdHkgVXNpbmcgQ29uY3VycmVuY3nigJ0/DQo+ICAgICA+ ICAgICBDYW4gcHJvYmxlbSAxMCBiZSBhZGRyZXNzZWQgaW4gcmZjNjU1NS1iaXM/DQo+ICAgICA+ DQo+ICAgICA+ICAgICBUaGFua3MsDQo+ICAgICA+DQo+ICAgICA+ICAgICBMZWUNCj4gICAgID4N Cj4gICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAgIHY2b3BzQGll dGYub3JnDQo+ICAgICA+ICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtDQo+ICAgICA+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192 Nm9wcyZkPUR3SUdhUSZjPUxGWVotDQo+ICAgICA+IG85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhD LQ0KPiAgICAgPiA4c2M4U1k4VHE0dnJmb2cmbT11emNjVkUzWGdXcGNwRkdNUTlxakYtSUdpNlpn N3dwT20xVDFvTi0NCj4gICAgID4gUlVacyZzPWRBbnFGMElXQUliejNfd3ZaU201U0JKcXZHR1Jz d0lqNG5wR3RKYVAtN00mZT0NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4g ICAgID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAg ICAgPiBJUHY0IGlzIG92ZXINCj4gICAgID4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRl cm5ldCA/DQo+ICAgICA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLQ0KPiAgICAgPiAzQV9fd3d3LmNvbnN1bGludGVsLmVzJmQ9RHdJR2FRJmM9TEZZWi0N Cj4gICAgID4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+ICAgICA+IDhzYzhTWThUcTR2 cmZvZyZtPXV6Y2NWRTNYZ1dwY3BGR01ROXFqRi1JR2k2Wmc3d3BPbTFUMW9OLQ0KPiAgICAgPiBS VVpzJnM9Tkh4MWxGUGVaUTEzWkZRS1JIcHZOZngxdlRianVtYXFLdmJodXpOZWJFMCZlPQ0KPiAg ICAgPiBUaGUgSVB2NiBDb21wYW55DQo+ICAgICA+DQo+ICAgICA+IFRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+ ICAgICA+IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZv ciB0aGUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpDQo+ICAgICA+IG5hbWVkIGFib3ZlLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+ ICAgICA+IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNv bnRlbnRzIG9mIHRoaXMNCj4gaW5mb3JtYXRpb24sDQo+ICAgICA+IGluY2x1ZGluZyBhdHRhY2hl ZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAg ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAg ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ICAgICA+IHY2b3BzQGlldGYub3JnDQo+ICAgICA+IGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gICAgID4g M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9TEZZWi0N Cj4gICAgID4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+ICAgICA+IDhzYzhTWThUcTR2 cmZvZyZtPXV6Y2NWRTNYZ1dwY3BGR01ROXFqRi1JR2k2Wmc3d3BPbTFUMW9OLQ0KPiAgICAgPiBS VVpzJnM9ZEFucUYwSVdBSWJ6M193dlpTbTVTQkpxdkdHUnN3SWo0bnBHdEphUC03TSZlPQ0KPiAN Cj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5l dCA/DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLQ0K PiAzQV9fd3d3LmNvbnN1bGludGVsLmVzJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1Fp Y3ZqSWcmcj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJm09YmRmalktDQo+IDRCcHZwRzVyeFV0VzZs alc3dVhjVGIwNkotDQo+IHdheWRDS3NoMzBjJnM9dUFTaHR2eVk4RnFMY2ozcTgydU1qWVpYV0c2 N19iUmtqUTdBM1ZxZU84OCZlPQ0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0 cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdl ZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKQ0KPiBuYW1lZCBhYm92ZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueQ0KPiBkaXNjbG9z dXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz IGluZm9ybWF0aW9uLA0KPiBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHByb2hpYml0ZWQu DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUdhUSZjPUxGWVotDQo+IG85X0hVTWVN VFNRaWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPWJkZmpZLQ0KPiA0QnB2cEc1cnhV dFc2bGpXN3VYY1RiMDZKLXdheWRDS3NoMzBjJnM9Umo3Qy0NCj4gSl9XbXo4STJTV29USm5IMGFp aWsxa0NuQ2JSUlVsdEc2OUdIUmsmZT0NCg== From nobody Wed Aug 16 14:48:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0013271A; Wed, 16 Aug 2017 14:48:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292010454.15048.16601305330115893059.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 14:48:24 -0700 Archived-At: Subject: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:48:25 -0000 Ben Campbell has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no technical comments, but a number of editorial comments: - General: I think this could use another proofreading and/or editing pass for the following issues: -- Inconsistent tense--especially use of future or present continuous. -- Wordy and convoluted sentences -- Use of "/" as a conjunction. - Abstract: The abstract is longer and more detailed than is useful. The last paragraph could have stood alone as the abstract. It's not clear to me if "hosts (subscribers)" means something different than "hosts" in context. -1: Please expand "IA_NA" on first use. s/"This document will focus..."/"This document focuses..." "As such the use of IPv6 SLAAC based subscriber and address management for provider managed shared network services is the recommended technology of choice, as it does not exclude any known IPv6 implementation." Does this document make that recommendation, or is that some pre-existing recommendation? -3: "The Best Current Practice documented in this note is to provide a unique IPv6 prefix to hosts/subscribers devices connected to the provider managed shared network." The sentence hard to follow. Consider "This document recommends...". I'm not sure how to interpret "hosts/subscribers devices" "Each unique IPv6 prefix can function as control-plane anchor point to make sure that each subscriber is receiving" s/"... subscriber is receiving ..."/"... subscriber receives..." -4: Is "First Hop Provider Router" different than "First Hop Router"? In the last bullet (L-flag=0), are NEVER and ALWAYS in all-caps expected to have different meaning than if they had normal capitalization? The sentence starting with "The architected result of designing the RA as documented above..." is convoluted and hard to follow. "... however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address": Is that really a normative requirement, or is it a statement of fact about existing requirements? "it SHOULD send this traffic to the First Hop Provider Router." : statement of fact? - 5: "To reduce undesired resource consumption on the First Hop Router the desire is to remove UE/subscriber context in the case of non-permanent UE, such as in the case of WiFi hotspots as quickly as possible. " Convoluted sentence. "A possible solution is to use a subscriber inactivity timer which, after tracking a pre-defined (currently unspecified) number of minutes, deletes the subscriber context on the First Hop Router." s/which/that (Consider " ... timer that deletes...after a predetermined number of minutes" -7: "The combination of both IPv6 privacy extensions and operator based assignment of a Unique IPv6 Prefix per Host provides each implementing operator a tool to manage and provide subscriber services and hence reduces the experienced privacy within each operator controlled domain." I have trouble following that sentence. Is the point to say that providing tools to manage and provide services reduces privacy in general? As worded, it almost sounds like this is meant as a feature, which I assume is not the case. From nobody Wed Aug 16 14:50:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9F13274E for ; Wed, 16 Aug 2017 14:50:15 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hpocpi9kp_eM for ; Wed, 16 Aug 2017 14:50:11 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA09132743 for ; Wed, 16 Aug 2017 14:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502920207; x=1503525007; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=33E0xQ88UWIHwP7Iy8zv6ZDLG G/sL76E2xdAc1uduVo=; b=p6e9wEGglOU2/Y9o6tbYpC4RG0DY01h1FX0B4wXA8 RwVyNXO2T0Fjqn8LgI2IdM9cdd3VZDHnKBVs3YokQTy/ofdl5lpiVPHnxqSYEovh GtMYIr33/XDPdcvmBGKIin4VJKZLRLpbm9y/nr4L+AMK9xEslQ7lSGx3CghaVrB4 Go= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=FNyQke2lxRszd1tBB1gojuF1+fPnwtHFbrsl72u5Fp1RlrIbv82RLZutw8Ik JM9PVB9lkpdQng661X2XybTWdqyfRZHCEd17fYJ7JogOvbeAyvYweL2MD mZKga8Fo8yIGABTyBikX9QQSDpbZHlnnhIaqIAJIOtZ4byG+EY10pk=; X-MDAV-Processed: mail.consulintel.es, Wed, 16 Aug 2017 23:50:07 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 16 Aug 2017 23:50:06 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005507540.msg for ; Wed, 16 Aug 2017 23:50:05 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170816:md50005507540::J8qlRgMGkQCAnaAW:00004cA6 X-Return-Path: prvs=1401d3a9dd=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Wed, 16 Aug 2017 23:50:03 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <37255BC1-F7CF-4F04-B081-9FA32631F185@consulintel.es> Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis References: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:50:16 -0000 Below, in-line. Regards, Jordi =20 -----Mensaje original----- De: "STARK, BARBARA H" Responder a: Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 23:33 Para: "jordi.palet@consulintel.es" , "v6ops@iet= f.org" Asunto: RE: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084= -bis Inline... Barbara =20 > draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case wh= en IPv4 > is no longer available. =20 Yes: Not available (through any means) on the WAN. But still used on th= e LAN. [Jordi] The goal of the document, if I read it correctly is to turn off IPv= 4 =E2=80=9Ccompletely=E2=80=9D LAN and WAN. =20 > So, if RFC7084 is an IPv6 only-CE (even if the CE can have an IPv4 st= ack), then > we have those problems when there is no IPv4 connectivity. =20 Yes: We will have the described problems if there is no IPv4 available = on the WAN (through any means). =20 > If the IPv6-CE supports transition, then you never have those problem= s, > because the goal of the transition support is precisely to avoid them= . It is not > a matter of IPv4 in the WAN. You can have IPv6-only WAN, but transiti= on can > resolve that. >=20 > Or I=E2=80=99m missing anything in your opinion? =20 Please correct me if I'm wrong, but I thought all the described mechani= sms require a correlated capability in the WAN. Just because a CE router su= pports all of these doesn't mean any of them necessarily exist in the WAN, = or that configuration of any of them via DHCPv6 is supported by the ISP (WA= N may have capability but requires manual CE Router config which many end u= sers won't know how to do). So I think support in the CE Router, by itself,= is insufficient to ensure IPv4 WAN availability. Therefore, even if a CE R= outer supports all of these, it is still possible for there to be no IPv4 W= AN connection. IMO, CE Router requirements that explicitly target IPv6-only= operation would be a very logical place to include requirements for "what = to do when there is no IPv4 in the WAN". [Jordi] Not really, may depend on the transition mechanism. Let me give you= one example. You can have an operator with a completely IPv6-ONLY network.= The customer CE can have CLAT (or the OSs), and the NAT64 service and even= the DNS64 service can be somewhere else, not necessarily in the operator n= etwork (may be a free service, actually there are already some), and it may= be automatically configured by the operator even if doesn=E2=80=99t have I= Pv4 at all, pointing the CEs to the =E2=80=9CNAT64 external=E2=80=9D provid= er. Just consider this as the =E2=80=9Creverse=E2=80=9D situation to the ac= tual IPv6-tunnel-brokers. =20 > The problem here, in my opinion is that in the actual RFC7084 you =E2= =80=9Callow=E2=80=9D the > support of IPv4, so is in that case when, if there is no transition s= upport, the > problems 1-5 may be presented in the LANs. >=20 > So, one alternative is again considering my proposal of making an RFC= 7084 > with is =E2=80=9Creally=E2=80=9D only-IPv6 (removing ALL the IPv4 sup= port in that document), > and then it make sense to have other documents with the transition su= pport, > etc., and then finding the right one for resolving the problems above= . =20 Because of the existence of the CE Router IPv6 Ready certification prog= ram, the many references to RFC 7084 made by external orgs, etc. I continue= to be opposed to changing it. That would almost certainly cause confusion,= and is unnecessary. Requirements related to IPv6-only WAN connections (wit= h or without the WAN supporting configuration or termination of an IPv4 tun= neling mechanism) can all logically go in a single new doc. [Jordi] I understand that =E2=80=A6 =20 > Actually, some of the problems, in my opinion, can be resolved just i= n the OS, > but is not a matter here to discuss one by one. For example, problem = 1, > some OS may believe there is only =E2=80=9CInternet=E2=80=9D if there= is a DHCP server > responding, even if they have IPv6 connectivity, etc., but this can b= e sorted > out in the actual RFC7084 if there is IPv4 stack, and there is no tra= nsition > support and there is not IPv4 support, by making sure that the DHCPv4 > server in the CE is not turned on in that case =E2=80=A6 =20 That's a bad idea. I expect my home network to operate in the absence o= f any and all WAN IP connections. I refuse to buy (or sell or recommend) a = CE router that does not continue to operate its DHCPv4 server in the absenc= e of IPv4 WAN connectivity. Also, I disagree with putting any LAN-side IPv4= protocol requirements into a 7084bis.=20 [Jordi] and I agree with you here, was an example, not really my intend =E2= =80=A6 But as you follow your own rationale, it is very clear that even if = we have IPv6-only CEs, we need during many years to go, many IPv4 =E2=80=9C= functions=E2=80=9D support, there are many devices in almost every home/off= ice that will not be replaced in 3-5, maybe 10 years, so we need to offer t= he IPv4 transition support =E2=80=A6 to allow operators to go to =E2=80=9CI= Pv6-only=E2=80=9D WANs (or complete networks). =20 > Of course, it can probably be done in one more document to =E2=80=9Cc= omplement > RFC7084=E2=80=9D. >=20 > Thinking twice, I could, as well, for maybe 1 or 2 of the problems, h= ave some > text in the transition doc, but I don=E2=80=99t think all them can be= resolved in that > doc. >=20 > So, to do it correctly I think RFC7084 needs to be updated (and maybe= then > remove the transition stuff there, so all the transition goes to the = transition > one). >=20 > I=E2=80=99m just thinking loud and trying to heard the WG. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: "STARK, BARBARA H" > Responder a: > Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 20:50 > Para: "jordi.palet@consulintel.es" , > "v6ops@ietf.org" > Asunto: RE: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, r= fc7084-bis >=20 > > However, if we don=E2=80=99t want to touch RFC7084, seems to me= difficult that > we > > can do it in a =E2=80=9Ctransition=E2=80=9D only document. >=20 > I disagree. I think it would actually be easier in a "trans= ition" only > document. Such a document could easily have a requirement along the l= ines > of: > If no WAN IPv4 connectivity is present (native or through one of = the > technologies in this document), the CE Router MUST ... > I'm not sure what it must do, though. > I don't think the solution involves IPv6 signaling, and putting L= AN-facing > IPv4 protocol requirements in RFC7084bis would be problematic. But it= would > not be a problem in a "transition" doc. - Barbara >=20 > > So, do we want to re-consider this decision again? > > > > My plan, if time permits, is to update either one or the other = document > next > > week. > > > > Regarding 6&7, I actually provided text on that to the authors,= and one of > my > > comments was in the direction of RFC6555-bis can somehow sort o= ut > those, > > but the actual text is still based in RFC6555 until RFC6555-bis= become an > RFC, > > in order to avoid =E2=80=9Cholding=E2=80=9D draft-ietf-sunset4-= gapanalysis-09, so all > depends > > on how fast we move with one or the other =E2=80=A6 > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: v6ops en nombre de Lee Howard > > Responder a: > > Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:28 > > Para: > > Asunto: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs,= rfc7084-bis > > > > Reading through draft-ietf-sunset4-gapanalysis-09 it seemed= to me > that > > several problems might be resolvable in documents we currently = have > open: > > > > Can problems 1-5 (indicating that IPv4 is unavailable, disa= bling IPv4 in > the > > LAN) be addressed with recommendations in any, some, or all of: > > draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Rou= ters" > > draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirement= s for IPv6 Customer > > Edge Routers" > > Or other drafts under discussion in v6ops now? > > Or do we need new IPv6 signalling (RA?) that IPv4 is unavai= lable? That > > would have to go to 6man. Or did we do this, and I=E2=80=99ve f= orgotten in my old > > age? > > > > > > > > Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addre= ssed with > > draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Bet= ter > > Connectivity Using Concurrency=E2=80=9D? > > Can problem 10 be addressed in rfc6555-bis? > > > > Thanks, > > > > Lee > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > > RUZs&s=3DdAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=3D > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > 3A__www.consulintel.es&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > > RUZs&s=3DNHx1lFPeZQ13ZFQKRHpvNfx1vTbjumaqKvbhuzNebE0&e=3D > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged or > > confidential. The information is intended to be for the use of = the > individual(s) > > named above. If you are not the intended recipient be aware tha= t any > > disclosure, copying, distribution or use of the contents of thi= s > information, > > including attached files, is prohibited. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DuzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN- > > RUZs&s=3DdAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=3D >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.consulintel.es&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DbdfjY- > 4BpvpG5rxUtW6ljW7uXcTb06J- > waydCKsh30c&s=3DuAShtvyY8FqLcj3q82uMjYZXWG67_bRkjQ7A3VqeO88&e=3D > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the in= dividual(s) > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this info= rmation, > including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DbdfjY- > 4BpvpG5rxUtW6ljW7uXcTb06J-waydCKsh30c&s=3DRj7C- > J_Wmz8I2SWoTJnH0aiik1kCnCbRRUltG69GHRk&e=3D =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Aug 16 15:54:16 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACA126DD9; Wed, 16 Aug 2017 15:54:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 15:54:15 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 22:54:15 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 4 It is not clear what you intend here "IPv6 Router Advertisement Interval = 300s" The router advertisement interval is not configured as an absolute value but as minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) which are used to calculate the actual advertisement interval. When the RA is sent from an interface, the actual interval is an uniformly distributed random value between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need to clarify if you would like to have this as a lower bound or as an upper bound. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4 -> I think text is needed here to handle the case where the DNS server is provided in the RA itself (RFC8106) "In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server" -> I am not sure what is the motivation for this text. "however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address" -> This text seems incorrect "due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router" I think it should be the exact opposite. i.e. say *unset* instead of set "due to the L-bit being unset, it SHOULD send this traffic to the First Hop Provider Router" From nobody Wed Aug 16 16:15:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9243613235E for ; Wed, 16 Aug 2017 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 6cd6syzwv9XY for ; Wed, 16 Aug 2017 16:15:35 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEF813235A for ; Wed, 16 Aug 2017 16:15:35 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76so23856617ith.0 for ; Wed, 16 Aug 2017 16:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hr80kntUXvU4ElbqLpjfDR8HObOk7+RDkc0mYnf+d0U=; b=d6abCgg6lZoso3IrKomVA/FImZTekrZ/aeuMhLsiEEn3m6HiIYEN1X6P5p+AvQSGWE W1bWMPUffb7jDGR+vdd3PS7l9YHEUjqlPWJyTPnV3gEUY5dx03nMwENzaJEaw6PyT1sN 4V49lORs7Zt/1UVqECtLlcUSLiT5BxxL/rAxPSqs7JspfUfSkafrDOBOGhab6rZMsUrc fzNkGjyXUfWMDzlMKu8TqjbBvpjIl6XJJ1F14AVGOEonLB27xABB0j5HtHJ1fID28oQo /AgTRbasr0xfQ3YzDHiFrvzs1A/ECg1xUeh0x4PBC3Ty0Xyqq8MJbrNxPuYgAkx+mrhq 5MTQ== 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=Hr80kntUXvU4ElbqLpjfDR8HObOk7+RDkc0mYnf+d0U=; b=bh6KACFrbaZEhjoJj4CfO8hjqhBj6vtBNAB9yp14xyF/RkQzO+A8rCNyNrTNyMPd4y 05U4klYTJW0+Q0oCOsikOzHDP59rDeqHfE0NUDBo5GYvPg2j0JD1740V8yDfdICuAxjz av9EKe7LrMIRdtCZ+/C572vS/hKYMTnbELvPrQJ0+/URZYhJVbQ3QPLhiXk+8tMUAVN1 OVEhrolST6VCXLcbuFmRwSSM98BZMz+D885O3rzcovD0NcRB6ew0skR+8LXG9fy9pkBF 7m05ywXviCMbTZJKrEPa3B2nPJSIBquOQFZXmzJUaK0FWHE1gCfEBQqYbxNwipjBDoKL nAEg== X-Gm-Message-State: AHYfb5hHSP+RfPALZcKcYqe1oFNzRKF3+68Z0/lUb4oWYSB5mFKOJ62v I0sAjL3GGMTKV4vnfGG0WczJ+LBIRLfR X-Received: by 10.36.25.70 with SMTP id b67mr110742itb.72.1502925334743; Wed, 16 Aug 2017 16:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 16:15:14 -0700 (PDT) In-Reply-To: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 08:15:14 +0900 Message-ID: To: Suresh Krishnan Cc: The IESG , draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1143d716b4251f0556e71296" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:15:38 -0000 --001a1143d716b4251f0556e71296 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 7:54 AM, Suresh Krishnan wrote: > It is not clear what you intend here > > "IPv6 Router Advertisement Interval = 300s" I'll also point out yet again that this value is in conflict with RFC 7772 in the case of networks that are provide service for battery-powered devices. The text should either be changed to follow that RFC or to explain the reason for the conflict. --001a1143d716b4251f0556e71296 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 7:54 AM, Suresh Krishnan <suresh.krishnan@gma= il.com> wrote:
It is not cl= ear what you intend here

"IPv6 Router Advertisement Interval =3D 300s"
I'll also point out yet again that this value is in confli= ct with RFC 7772 in the case of networks that are provide service for batte= ry-powered devices. The text should either be changed to follow that RFC or= to explain the reason for the conflict.
--001a1143d716b4251f0556e71296-- From nobody Wed Aug 16 16:29:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3EB132143; Wed, 16 Aug 2017 16:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNErCt7uOJQK; Wed, 16 Aug 2017 16:29:06 -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 02FFA132335; Wed, 16 Aug 2017 16:29:06 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id f11so51436680oic.0; Wed, 16 Aug 2017 16:29:05 -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=IPWajDGPZnY9uheKwsMF1u21mX8tfVR+EcCPjDnQWMY=; b=F0uXRMy3R2Xt8BzkqTETsb7u0b8ZbkdJtCYQwgCbGdY6Iz0WfVj0CSpGzBwD81KEn+ SO1S+/Qg1vhktLVc4cYRddy1mjtqX2y/Q7Og6DcerSZcFQ3RE5VvSrv1iol2ImTHM/Ut Kd4v1oZo8JBmiI4KqDCyWwA1V+mQ/LJ2u/xNvy1bo8tkOYT9fPBUe/J7ZXNu+nSTy+eO rmSDSI+dJsp9MeaFE4snPL2S9/uInRWx/r2vkt+Zhne8Hm4YF3hokZcTcbGQIGRPtB7u IpwmtWChBtGQSPHdJK6eVdSqx4A0B+OIsvk6N0mvcUJ96U6xq9JHjBFWFmu/s59bn+mB 1lqw== 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=IPWajDGPZnY9uheKwsMF1u21mX8tfVR+EcCPjDnQWMY=; b=NeL94FKuiYvtTCpHLlmJO3wVFhAHqjtHyu4ZZGNUkBGKdeidTlEvmj/syfpATuyVHM rczUl1ElBYG1SDOAVp15hg/d18ptnLRrp0XIfy9LcLUBjuTFz7Kn4kdOoBj4uH8OgTno GqobT726MR/eTmWWjfYg6ANV6NbzZziKBqPxlJxagatEGKMNQ5D0Jw3MZ4ibt+jBA4S0 zUfV8SGpIb4ouJEm3Xh0ok1oOKTB4oPrtQVk0GZZZNasNuzllu1AHKdVzjpYW/7MaL1A Awp36Se1h1uLLTp0Uo9PuJPNQcupIB/mjcXvZjyFfFRqAul8jzGGhwXHByeLYLwXO5/f ADVA== X-Gm-Message-State: AHYfb5g99nROc9Th1DEutVeOMMPTcJr9VLr+zgdjDb8Q94Vv8mvCxt3S WVL16iCwb8J39xKTmmU= X-Received: by 10.202.195.77 with SMTP id t74mr4533027oif.102.1502926145215; Wed, 16 Aug 2017 16:29:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1281? ([2600:8802:5600:1e::1281]) by smtp.gmail.com with ESMTPSA id t70sm2577685oif.38.2017.08.16.16.29.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 16:29:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.3\)) From: Fred Baker In-Reply-To: Date: Wed, 16 Aug 2017 16:29:02 -0700 Cc: "sunset4@ietf.org" , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.1.3) Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:29:09 -0000 Hatless... The question I would ask is whether on-demand IPv4 makes sense. To my = way of thinking, it amounts to deploying a new kind of network. We are = asking people to deploy IPv6 in their IPv4 networks, or to deploy = IPv6-only networks. That requires some portion of the money and time = they have available for such issues. Deploying an IPv4-on-demand network = is another thing competing for those same resources - it doesn't create = new resources or reduce the matters pertaining to IPv6 deployment - it = creates another demand for the same resources. I don't see the point. I suspect that the network actually routes IPv4 no matter what; what is = being handed out on demand is an IPv4 address to an edge device. Hosts = right now get IPv4 (and IPv6) addresses when they don't need them so = they can use them when they do. They would need a different mode of = operation, perhaps triggered by the resolver noticing that an = application wants to access some name and the name only has an A record. = In that mode of operation, the host only asks for (DHCP) an IPv4 address = when it needs it, and routing in the network is to the granted address = for the lifetime of the address. Do I believe we can describe and solve that? Yes. Do I think we can do = it more cheaply and simply than moving folks and their applications to = IPv6, and convince operators to change their operational practices = accordingly? Not even close. I think it is a diversion from IPv6 = deployment. > On Aug 16, 2017, at 2:08 PM, JORDI PALET MARTINEZ = wrote: >=20 > (copying v6ops) >=20 > Forgot something here regarding: >=20 > 4. Write a guidance document for IPv4-on-demand, covering problems = 10-14. >=20 > I think this can be done in = draft-palet-v6ops-rfc7084-bis-transition-00, which I plan to review next = week (in this case I believe it belongs to v6ops), otherwise, I will = draft something else (need to identify then if v6ops, sunset4 or some = other WG). >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: sunset4 en nombre de Lee Howard = > Responder a: > Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:27 > Para: "Liushucheng (Will Liu)" , = "sunset4@ietf.org" > Asunto: Re: [sunset4] I-D Action: = draft-ietf-sunset4-gapanalysis-09.txt >=20 > I admit, it=E2=80=99s been a long time since I=E2=80=99ve read this = draft. >=20 > One capability gap we still have: there=E2=80=99s no IPv6 version = of FlowSpec. > There is an idr WG draft, but it hasn=E2=80=99t had a lot of = discussion in recent > months:=20 > = https://datatracker.ietf.org/doc/html/draft-ietf-idr-flow-spec-v6-08 >=20 > Review of the gap-analysis draft: (summary at the bottom) > There are 16 specific problems identified. Some solutions are = proposed in > Annex A; I=E2=80=99d rather see those incorporated into the text. >=20 > Can problems 1-5 (indicating that IPv4 is unavailable, disabling = IPv4 in > the LAN) be addressed with recommendations in any, some, or all of: > draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" > draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for = IPv6 Customer > Edge Routers" >=20 > Or other drafts under discussion in v6ops now? > Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable = (as in > A.1.1 and A.1.2)? >=20 > Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed = with > draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better > Connectivity Using Concurrency=E2=80=9D? >=20 >=20 >=20 > Problems 8 and 9 are about surprises when IPv4 support is removed = from the > kernel. I remember reading about this several years ago; should we = have a > hackathon to repeat the experiment? >=20 > I=E2=80=99m not very clear on the IPv4-on-demand scenario described = in Section 6 > (and I don=E2=80=99t understand the solution in A.4). But we should = probably write > a guidance document on how to handle problems 10-14, don=E2=80=99t = you think? > Anyone want to volunteer for that? > Could Problem 10 be addressed in Happy Eyeballs v2, rfc6555bis? >=20 > Problem 15 (IPv4 address literals) is mitigated with most = transition > technologies, isn=E2=80=99t it? Not NAT64 (requiring DNS64), but = 464xlat, DS-Lite, > MAP. >=20 > I like the solutions proposed for Problem 16 (Router IDs): Just = pick a > 32-bit number and use it as the last 32 bits of the IPv6 address. = If you > try, you could use it in multiple prefixes on the same router, = including > Loopback, Link Local, and even GUAs. I=E2=80=99m not entirely sure = this problem > qualifies as a gap, so much as an operational consideration. >=20 >=20 > Summary of proposed actions: > 1. Ask authors of draft-ietf-v6ops-ipv6rtr-reqs-00 and > draft-ietf-v6ops-rfc7084-bis-04 to consider whether they can = respond to > problems 1-5. > 2. Confirm that problems 6-7 are resolved in rfc6555bis, and ask = whether > problem 10 can be. > 3. Hackathon removing IPv6 support from the kernel. If it=E2=80=99s = an IETF > Hackathon, need a Champion who is comfortable hacking the kernel. = Would be > great to include people from Windows, Apple, Android. > 4. Write a guidance document for IPv4-on-demand, covering problems = 10-14. >=20 >=20 > I will do the first two things. > Do people agree with the other two things? Anyone want to = volunteer? >=20 > Lee >=20 >=20 >=20 >=20 > On 8/3/17, 7:08 AM, "sunset4 on behalf of Liushucheng (Will Liu)" > = wrote: >=20 >> Hi all, >>=20 >> We've updated the draft according to the comments we received online = and >> offline. Please take a look and let us know your thought. >>=20 >> Thanks! >>=20 >> Will >>=20 >> -----Original Message----- >> From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Tuesday, August 01, 2017 7:32 PM >> To: i-d-announce@ietf.org >> Cc: sunset4@ietf.org >> Subject: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Sunsetting IPv4 WG of the IETF. >>=20 >> Title : Gap Analysis for IPv4 Sunset >> Authors : Will(Shucheng) Liu >> Weiping Xu >> Cathy Zhou >> Tina Tsou >> Simon Perreault >> Peng Fan >> Rong Gu >> Chongfeng Xie >> Ying Cheng >> Filename : draft-ietf-sunset4-gapanalysis-09.txt >> Pages : 11 >> Date : 2017-08-01 >>=20 >> Abstract: >> Sunsetting IPv4 refers to the process of turning off IPv4 >> definitively. It can be seen as the final phase of the transition = to >> IPv6. This memo enumerates difficulties arising when sunsetting >> IPv4, and identifies the gaps requiring additional work. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09 >> = https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-gapanalysis-09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sunset4-gapanalysis-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 >=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 16 17:13:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008A13242B for ; Wed, 16 Aug 2017 17:13: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAOLIMkRVBI1 for ; Wed, 16 Aug 2017 17:13:15 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 E01B5126BF0 for ; Wed, 16 Aug 2017 17:13:14 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m34so24267082iti.1 for ; Wed, 16 Aug 2017 17:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qg1eTbqms1NGg+aQK9jQiwyvpJT4BRxAYbRMyp1bytg=; b=s16Y4NMNA7qWdc82w6L17P9mhkmW9ZbdcgLOdP7k5uUhdkfKmxgaZKPlR5PIcjljc+ U80t2LUpEVfnhH0IeJaCL/QqtCTcl5F3jtpxe2w5G7GLVRs7wpP4bEuHqmCBpn242y1B Jbc/T/Ml4rLPsjZhpMb9Gx7Jce3djsQx5bkXZevi09HWjTilfspuxVDioXabpz/9IKw+ 8ds8Ks2EcfFPM+34T92AcmiKJeQNM1+MttvRwFRasOXSgvqMSIlfRBwLqaDLjhb0KUWP PMhSLxddTUmPDjSSrCA066ETDo2zikJtcy7xVLFjQRiLUuvt/5y4bfu52DYnYDgQkqZ5 OzoA== 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=Qg1eTbqms1NGg+aQK9jQiwyvpJT4BRxAYbRMyp1bytg=; b=On3c817i/zYpBC0zGEL/Hl326LQSk27gLIbylN4TExuclApiEaF7wYZuM66yKuNhi/ stsG04RLn/ExFqVaaUATNFPj4ItS2AnKXNXSEJF+TBQW7hMQ0Rol8DQFqFbeEm4E2wlU GBdYOnS0RBII/0Xuof32bXVvk7Wfs6ugSGDqn9A8xblmT9Ps1ueC0X1aUaIbCYL6eK4/ tXW9VOPyVUo/W/hw2FfarphHf5Rdwe5JxKHdw2NCKQ11JkZq+WtHe0nGs576sRf3TGa5 7a6fnP2yqjV5Lbg6/2cl6YaEXbvX0NcfLuQS3y0jMRLc8RQG8q52jqNknEQXIjxmnmoG BUqw== X-Gm-Message-State: AHYfb5gczUzmFxD6jrUFoiovjGVtVxFm4L9UVOGUwK48Pduuj+/fx76A lwgZQ04okQll6XEYtWY30XjfmnY/tQ81 X-Received: by 10.36.25.70 with SMTP id b67mr221500itb.72.1502928793703; Wed, 16 Aug 2017 17:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 17:12:52 -0700 (PDT) In-Reply-To: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 09:12:52 +0900 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: multipart/alternative; boundary="001a1143d716dfd7db0556e7e0c3" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 00:13:18 -0000 --001a1143d716dfd7db0556e7e0c3 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 4:47 AM, Simon Hobson wrote: > > /64 gives you something that no longer prefix does: the ability to run > SLAAC and connect unlimited devices behind the host. > > From previous discussions, I am led to believe that SLAAC will work with > other (longer or shorter) prefixes. It is only the deprecated EUI64 method > that *needs* 64 bits. > In practice it does not because every link layer specifies 64-bit IIDs. > > No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly > announces it in an RA. > > Are you suggesting that someone who realises that not everything is a /64 > would do that ? You've not really done anything to counter this being a > case of "everything is /64" thinking and thus ignoring the potential for > anything else. It may be a simple case of blindly re-announcing the prefix > you got delegated - but it still comes down to not understanding that the > prefix may be other than /64. > You could just as well answer that if someone thought that everything was /64 they'd just reject non-/64 prefixes. > > Already? 64 everywhere has been the standard for 20 almost years now. It > predates pretty much every IPv6 network and every IPv6 implementation out > there today. > > And that hardcodes in a restriction which IN THE REAL WORLD is known to > cause issues. For example, you (incorrectly) only get a single /64 from > upstream, but want to something other than a single host or very simple > network. I agree that it shouldn't happen, but in the real world it does - > you either stick with a simple basic network, or you run prefixes smaller > than a /64. If the ISP is well-intentioned, it will give you a /64. If the ISP not well-intentioned, they will give you an allocation that is the minimum size that clients are prepared to accept. So you will never be able to subnet anyway - as soon as your device is willing to do SLAAC on a /80, that's what your ISP will hand you. There's no point starting that arms race. --001a1143d716dfd7db0556e7e0c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 4:47 AM, Simon Hobson <linux@thehobsons.co.uk= > wrote:
> = /64 gives you something that no longer prefix does: the ability to run SLAA= C and connect unlimited devices behind the host.

From previous discussions, I am led to believe that SLAAC will work = with other (longer or shorter) prefixes. It is only the deprecated EUI64 me= thod that *needs* 64 bits.

In practice = it does not because every link layer specifies 64-bit IIDs.
=C2= =A0
> No. Someone w= rote code that gets a prefix via DHCPv6 PD, and blindly announces it in an = RA.

Are you suggesting that someone who realises that not everything is = a /64 would do that ? You've not really done anything to counter this b= eing a case of "everything is /64" thinking and thus ignoring the= potential for anything else. It may be a simple case of blindly re-announc= ing the prefix you got delegated - but it still comes down to not understan= ding that the prefix may be other than /64.

=
You could just as well answer that if someone thought that everything = was /64 they'd just reject non-/64 prefixes.
=C2=A0
> Already? 64 everywhere has= been the standard for 20 almost years now. It predates pretty much every I= Pv6 network and every IPv6 implementation out there today.

And that hardcodes in a restriction which IN THE REAL WORLD is known= to cause issues. For example, you (incorrectly) only get a single /64 from= upstream, but want to something other than a single host or very simple ne= twork. I agree that it shouldn't happen, but in the real world it does = - you either stick with a simple basic network, or you run prefixes smaller= than a /64.

If the ISP is well-intentioned= , it will give you a /64. If the ISP not well-intentioned, they will give y= ou an allocation that is the minimum size that clients are prepared to acce= pt. So you will never be able to subnet anyway - as soon as your device is = willing to do SLAAC on a /80, that's what your ISP will hand you. There= 's no point starting that arms race.
--001a1143d716dfd7db0556e7e0c3-- From nobody Wed Aug 16 17:24:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8528413217D for ; Wed, 16 Aug 2017 17:24: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 Rd0LC2Hgxl_a for ; Wed, 16 Aug 2017 17:24:06 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F5B132143 for ; Wed, 16 Aug 2017 17:24:06 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y129so6985973pgy.3 for ; Wed, 16 Aug 2017 17:24:05 -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=YTKWSXAFjAzyfHP3zdTmNP6RZ5xkQF6SvrfPWt7hEC0=; b=HX6BEy7/CjhCyFs1nHoIQ5wLpudaynWA+uNHJ59Uy2VzX+Z5X+6Bezrm15eskmIgRT gMIa0dPXU7QWVkBLiyPZ9+/ojIUDn9y8n8W118/hTQOc3DMM7NzDAukfHf/CRH+8FPtH 8A0mEhmxznrF7SawmdfcgI0VrvCFQ1lMmaPodIgtqIn43UXCtFgsWwqefuh+dCdM5nR2 nmrk0EcRTSoSFg9KUWjnSzBk42rRo2f2ZcI0uZebZR2thI/atahVrXs8MQqi5ifgveWG rYONciYQu5JngNZaKkHPX8Gr9ptTStHm16V2X6o/KiH2Iqw6tJAhH6aWHBnS8y18G2MI FnsQ== 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=YTKWSXAFjAzyfHP3zdTmNP6RZ5xkQF6SvrfPWt7hEC0=; b=lRn2KwRxWYn45eqJkGxg/VCYk/nZRD2GRd9k5atNBiQSnKmqVk1CjTVWOQkRXMXfeo HXga7+oKQCsTVfCEJ3ZqZBQ43q62+4trB2KqVvN9bm6z1SsYpuDLCzxART8p2HsrLw3r VxpKv04glwujcPSLJEblg9i530mkoOtfuO1eFowUwtRZJn5Ba6F7n6tWoU18weJ+UOU5 iIp23rs8bFPtj8bYqUU7RE1HbAHdCnD/w6fRORPqyKDhuzXIyKl/apONOQTlQ60o39so QWg05UdjSNH0zrMNUdMVh2eTKqmHUmF1tVNfCoJRjdXwzLXtH+SpexyWOXdl4aWwTV5x 1hyw== X-Gm-Message-State: AHYfb5h2PZ2Xy2NOq6xQlT02G2wRJ62IiqPwZmKKvd7Lso4/8k4CeK+3 u6uHn4lPAIOgcg== X-Received: by 10.84.224.203 with SMTP id k11mr3642169pln.1.1502929445301; Wed, 16 Aug 2017 17:24:05 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id d5sm3955222pfc.110.2017.08.16.17.24.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 17:24:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Thu, 17 Aug 2017 09:24:00 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 00:24:07 -0000 Does this =E2=80=98unlimited devices behind the host=E2=80=99 include = the following case? - A host gets a /64 prefix. - The host runs for itself an internal = =E2=80=98Unique-IPv6-Prefix-per-Host=E2=80=99 so that it hands out a /96 = prefix to each internal device. - In effect, this comes down to /96 prefixes and 32-bit IIDs. Technically, there=E2=80=99s no reason why this cannot be done, I=E2=80=99= d assume. However, would this be forbidden in the sense of the current = and related std track documents? --- DY > On 16 Aug 2017, at 23:00, Lorenzo Colitti wrote: >=20 > /64 gives you something that no longer prefix does: the ability to run = SLAAC and connect unlimited devices behind the host.=20 From nobody Wed Aug 16 18:32:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D54126BF0 for ; Wed, 16 Aug 2017 18:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8DjZ0-CUqnN for ; Wed, 16 Aug 2017 18:32:00 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA3013226B for ; Wed, 16 Aug 2017 18:32:00 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id y129so32111225pgy.4 for ; Wed, 16 Aug 2017 18:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gxi4jDHgmXvB357VwcJXXm/El0ZsCfWf0aIbzzsf1E0=; b=s6lAAJgJLw7jU/6VzJKXdtLeUy0WuHcUP22+/BWS5njsYZVIY4ru0Z8GyxRFFoICFH BUEX0mozaAJYn4TQFNOn6btwgKjsFP7cQv9ukToOa78osA+1GNttRiWkuxkGrUxu80dm SIPDdohctgylJLYxPDU6upX5mnZSyKLxIBxA4uP5dTnpCmMExuhizzVg8z6voyw/BaBc 7gC+8Jiijn3d/8U51BscG9kjztRcnvRSnxZkzwRDZIg7ylpLINQyN+i7+ECdF4J3h7aX ed8ndPT4EZkq0LR3mZkkBgV+DWPkPFfUZvjUzg1DFLnWRP4e+ZX9u3zbX6IS7otY9Ht8 zwvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gxi4jDHgmXvB357VwcJXXm/El0ZsCfWf0aIbzzsf1E0=; b=n3GCGx9C0F7B6SalgDLPcnbgFP4/hn432syd6ET/3/lfDvpFyqqCK6YpVJ0iIi/+dx lyebtik0VBkO4t4Ph1rjEYffDNPZ9RYWerM73UDx584RbcN3YogBqc9v5UsvAAilJMOa PZPHjFvIiKy74lCUmVS8Q3ieruU//pIGYo7YE8isHWWsYjWo3xrZTKyYHoiXhtE8lLh5 rlgs5M7Cn8gjERKQAXm4mhucsQqrG9EqNAhG68x18PjcZml1FARx28c4g7zLri5rl8Rp bZX022x3f8PAGwgZEHPg2Z6qwQ91fvrDoinEdtZCXRzhghe69CEVNitBvZHQTlmsWQKo 8L0A== X-Gm-Message-State: AHYfb5jZpKBpKd2VlJ9+pj6jEwXiqmyOvuVwZh0s0/pn+meBwICCUWAW is+UIImmEsz89oht X-Received: by 10.84.132.76 with SMTP id 70mr3917229ple.7.1502933519771; Wed, 16 Aug 2017 18:31:59 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h20sm3838465pfk.175.2017.08.16.18.31.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 18:31:59 -0700 (PDT) To: DY Kim , Lorenzo Colitti Cc: Simon Hobson , v6ops list References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 17 Aug 2017 13:32:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:32:02 -0000 On 17/08/2017 12:24, DY Kim wrote: > Does this =E2=80=98unlimited devices behind the host=E2=80=99 include t= he following case? >=20 > - A host gets a /64 prefix. >=20 > - The host runs for itself an internal =E2=80=98Unique-IPv6-Prefix-pe= r-Host=E2=80=99 so that it hands out a /96 prefix to each internal device= =2E >=20 > - In effect, this comes down to /96 prefixes and 32-bit IIDs. >=20 > Technically, there=E2=80=99s no reason why this cannot be done, I=E2=80= =99d assume. However, would this be forbidden in the sense of the current= and related std track documents? It's forbidden by the fact that RFC4291 states that the IID length is 64.= Clearly that applies to SLAAC; it's a bit less clear whether it applies = to DHCPv6. But the privacy related RFCs make it pretty clear that 32 bits= is too small. Brian From nobody Wed Aug 16 19:33:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE45132359 for ; Wed, 16 Aug 2017 19:33:54 -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 0s_Xje8dfUeV for ; Wed, 16 Aug 2017 19:33:53 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 6646413217D for ; Wed, 16 Aug 2017 19:33:53 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id z91so21800118wrc.4 for ; Wed, 16 Aug 2017 19:33:53 -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=MB8z+Q4KvuUKnIpCaA6x0oToQLmZN6ZauKFEZZfTOfk=; b=d0qeN6VpkNaGCX7EXnJP/ar8t31MD76jDtW3/HQSEQ+Ybb/MGS/XGXaT+Y+mxGBPt8 1tx+s3Kw9ydKYphlvITT+D7uJ083UFHA7oDuK7kE+0IW4GfARAyvUzWNWjBU/8MlxvXZ Ch7DBpJ1/1AYCypmFLPS6TDcYmxOER19iRVBkgZqMRHZF5jpGg7/SzG29gxx/BMvoEVh tH0WHRbcbV7RnQLqmCiApZj7gj6mR3FR0IQxfaCrEgMNxEEqLJfdNLp6NnNaM332Dpyg NHz7FatcbUQsA5FZTTHMqxJn6hnWH/eB2mkhnfDI8NXMDZm7JlWyPAWcV6rOg69DcWXx TADQ== 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=MB8z+Q4KvuUKnIpCaA6x0oToQLmZN6ZauKFEZZfTOfk=; b=kKeyzxM04cDhTMyDQECcgBh6bXdu3mOwYQVlH+HFKZz/Q8DY7j09YraCFQSqSw8XOl bF0c8tALMM3Bcjf/O9vDXAUbpmk4czh3vOq8ffTzFy7J6j1IZcHki2XI3mTBMiy+opXR 5Lu6rHO2/8n+GGvBcNjdfC/Iv3YIEUQQdSxtgqEdI+nYNz9eCXn2cUU3D3Wxx8SPXNpa AIOxMXM/IDt6binXIMqMRTDDg436VfZ7zmjH6X0a1Zq4acu0QADywbMvih6wVDmzTGQC TVqpOrJYsO/337mPZ1aDvfhNsa5x3xkjQYM+qk1IOXXgxbNaAobyCL7Axn1l8zuFLHHi VD4A== X-Gm-Message-State: AHYfb5hKIzAJ2Fj8MQrCGwgIhUNWuOeF7655k0cp96ZkR8VlNg+uEo4V BUeFUPDoi0Ok+t+lIQADqf4GaaOKpA== X-Received: by 10.223.142.168 with SMTP id q37mr275971wrb.254.1502937231818; Wed, 16 Aug 2017 19:33:51 -0700 (PDT) MIME-Version: 1.0 References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> In-Reply-To: From: DY Kim Date: Thu, 17 Aug 2017 02:33:39 +0000 Message-ID: To: Brian E Carpenter , Lorenzo Colitti Cc: Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="f403045f5786d283d70556e9d715" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:33:55 -0000 --f403045f5786d283d70556e9d715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In 'Unique-IPv6-Prefix-per-Host', IIDs given by a host are given to its own interfaces. Should there be any privacy concern about the IIDs which are confined to a single host? As I think, privacy concerns might be more related to /64 prefixes rather than IIDs. Therefore, the IID length might not bear much implication in regard to privacy. SLAAC by itself does not put any restrictions on the IID length. Unless the SLAAC software is hard-coded to 64-bit IIDs, it should be able to process configure 32-bit IIDs. If the available SLAAC is really hard-coded to 64-bit, then I mght write and enforce, onto the internal devices (behind my host), a simple code to assign 32-bit (or whatever bits shorter than 64) IIDs, since the devices might be under my control. Would this be policed not ever to happen? On Thu, 17 Aug 2017 at 10:32 Brian E Carpenter wrote: > On 17/08/2017 12:24, DY Kim wrote: > > Does this =E2=80=98unlimited devices behind the host=E2=80=99 include t= he following case? > > > > - A host gets a /64 prefix. > > > > - The host runs for itself an internal =E2=80=98Unique-IPv6-Prefix-pe= r-Host=E2=80=99 > so that it hands out a /96 prefix to each internal device. > > > > - In effect, this comes down to /96 prefixes and 32-bit IIDs. > > > > Technically, there=E2=80=99s no reason why this cannot be done, I=E2=80= =99d assume. > However, would this be forbidden in the sense of the current and related > std track documents? > > It's forbidden by the fact that RFC4291 states that the IID length is 64. > Clearly that applies to SLAAC; it's a bit less clear whether it applies t= o > DHCPv6. But the privacy related RFCs make it pretty clear that 32 bits is > too small. > > Brian > > -- ---- DY --f403045f5786d283d70556e9d715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In 'Unique-IPv6-Prefix-per-Host', IIDs given= by a host are given to its own interfaces. Should there be any privacy con= cern about the IIDs which are confined to a single host?

As I think, privacy concerns might be more= related to /64 prefixes rather than IIDs. Therefore, the IID length might = not bear much implication in regard to privacy.

=
SLAAC by itself does not put any restrictions on th= e IID length. Unless the SLAAC software is hard-coded to 64-bit IIDs, it sh= ould be able to process configure 32-bit IIDs.

<= /div>
If the available SLAAC is really hard-coded to 64-bi= t, then I mght write and enforce, onto the internal devices (behind my host= ), a simple code to assign 32-bit (or whatever bits shorter than 64) IIDs, = since the devices might be under my control.

Would this be policed not ever to happen?

On Thu, 17 Aug 2017 at 10:32 Brian E Carpenter= <brian.e.carpenter@gmail= .com> wrote:
On 17/08/2017 1= 2:24, DY Kim wrote:
> Does this =E2=80=98unlimited devices behind the host=E2=80=99 include = the following case?
>
>=C2=A0 =C2=A0- A host gets a /64 prefix.
>
>=C2=A0 =C2=A0- The host runs for itself an internal =E2=80=98Unique-IPv= 6-Prefix-per-Host=E2=80=99 so that it hands out a /96 prefix to each intern= al device.
>
>=C2=A0 =C2=A0- In effect, this comes down to /96 prefixes and 32-bit II= Ds.
>
> Technically, there=E2=80=99s no reason why this cannot be done, I=E2= =80=99d assume. However, would this be forbidden in the sense of the curren= t and related std track documents?

It's forbidden by the fact that RFC4291 states that the IID length is 6= 4. Clearly that applies to SLAAC; it's a bit less clear whether it appl= ies to DHCPv6. But the privacy related RFCs make it pretty clear that 32 bi= ts is too small.

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

--
----
DY
--f403045f5786d283d70556e9d715-- From nobody Wed Aug 16 19:48:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669F61323D7 for ; Wed, 16 Aug 2017 19:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGAlBTYRXk5U for ; Wed, 16 Aug 2017 19:48:39 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F851323BD for ; Wed, 16 Aug 2017 19:48:39 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id y36so20637715uac.5 for ; Wed, 16 Aug 2017 19:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UwPatbb9xCNjkZy9mMA4C1Rad3Vi1ZT03mbVU89DNsc=; b=UrhcHQYNdst7WLLe1VYL01H5hGMgL8EHbadm1/XLyYz8tLJl3doho8c9rpAaJy9RkH BN1V82Z3R1QMxXFYVPBDgxW8q5QfNTP3daUvf/CuBJ0hhi4HaeKhueGFuYekbRQaGF2u H+1W2P8C6cMRxvi0ZxbqXAd/typKqIAvgF+4MjMGGL5Z7BK5hdUNXHYCgly+SrX7INhw TZS81rmC4adsQE6FUtRdaVBuf3SQVFVch81TCTJybfvvFWNpzDqmp6yGhTzagpl2IPcG 3h09NJVISF+rW/vlN6K3Nwwo6u6QiJ14tc63zevsqLm778Gch6BEM2Lc2yUZV7OqfoI+ S1ZA== 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=UwPatbb9xCNjkZy9mMA4C1Rad3Vi1ZT03mbVU89DNsc=; b=U6jkiplFGX423BunwJethPFxOXn4wSrXDYoN3VDn90+IX/iiPs1JFmARV0tPFKeNxY B+SW11lO24v1kab7cmMqBUDn0tuLfMZVTr91gtNcTpJ6E5VbsID5VJm12AV+qbu1j3KA ryZMw/IHFtfVZG5UGhG3BcdWyHLQ1m/KyPa0bjpDj3O4vOAngmO3qBmJE2tB3UYdkldg BqBTC6vjyNSpWZGBCTxf2qy276nwZdThr2w3wMEYH9F8ZMGOXV7a4x2QS/nCr465szkl UoS5kBcubqPCcMJnSdtG+j2Bzw/95ISds8H59nwLgm61vBUbBj6gp2fDoEM6nkHT+ope DH1A== X-Gm-Message-State: AHYfb5ic2ZxI2Wcg2AluaGCZ1WP7aQx/XTeRV8v9Q/BIzRQs25iRVlZ1 JK9oO9+NP/Rc0L7yjNEadJymxR3L/Q== X-Received: by 10.176.25.197 with SMTP id r5mr2573098uai.22.1502938118307; Wed, 16 Aug 2017 19:48:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Wed, 16 Aug 2017 19:48:06 -0700 (PDT) In-Reply-To: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> From: Mark Smith Date: Thu, 17 Aug 2017 12:48:06 +1000 Message-ID: To: DY Kim Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:48:41 -0000 On 17 August 2017 at 12:33, DY Kim wrote: > In 'Unique-IPv6-Prefix-per-Host', IIDs given by a host are given to its o= wn > interfaces. Should there be any privacy concern about the IIDs which are > confined to a single host? > > As I think, privacy concerns might be more related to /64 prefixes rather > than IIDs. Externally, it is not possible to determine whether a /64 is assigned to a link or a host - consequently, it isn't possible to know if source addresses from with a /64 represent a single device's traffic (the /64 is assigned to a single device) or traffic from a range of devices (a /64 is shared by many devices attached to a link.) >Therefore, the IID length might not bear much implication in > regard to privacy. > Individual source addresses however always represent traffic from a single device. "Security and Privacy Considerations for IPv6 Address Generation Mechanisms= " https://tools.ietf.org/html/rfc7721 > SLAAC by itself does not put any restrictions on the IID length. Unless t= he > SLAAC software is hard-coded to 64-bit IIDs, it should be able to process > configure 32-bit IIDs. > > If the available SLAAC is really hard-coded to 64-bit, then I mght write = and > enforce, onto the internal devices (behind my host), a simple code to ass= ign > 32-bit (or whatever bits shorter than 64) IIDs, since the devices might b= e > under my control. > > Would this be policed not ever to happen? > > On Thu, 17 Aug 2017 at 10:32 Brian E Carpenter > wrote: >> >> On 17/08/2017 12:24, DY Kim wrote: >> > Does this =E2=80=98unlimited devices behind the host=E2=80=99 include = the following >> > case? >> > >> > - A host gets a /64 prefix. >> > >> > - The host runs for itself an internal =E2=80=98Unique-IPv6-Prefix-p= er-Host=E2=80=99 >> > so that it hands out a /96 prefix to each internal device. >> > >> > - In effect, this comes down to /96 prefixes and 32-bit IIDs. >> > >> > Technically, there=E2=80=99s no reason why this cannot be done, I=E2= =80=99d assume. >> > However, would this be forbidden in the sense of the current and relat= ed std >> > track documents? >> >> It's forbidden by the fact that RFC4291 states that the IID length is 64= . >> Clearly that applies to SLAAC; it's a bit less clear whether it applies = to >> DHCPv6. But the privacy related RFCs make it pretty clear that 32 bits i= s >> too small. >> >> Brian >> > -- > ---- > DY > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Aug 16 19:50:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B271323A8 for ; Wed, 16 Aug 2017 19:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts4YmJTUwWqc for ; Wed, 16 Aug 2017 19:50:35 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C57B13217D for ; Wed, 16 Aug 2017 19:50:35 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id j32so19168303iod.0 for ; Wed, 16 Aug 2017 19:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=voOl3oBQPa4EcugCZSLHHwkUdLGU1HGN6EFfjt+Jj5U=; b=CR2nu06q3nnpd9D2yvlyjkrHedk6M9N+YxBpo3ZJpqzmwvXZrM/Au603B5BrwbTuxp hVO7WGMpU+jkAbKdYWDtCIsZfbsPH7p28bto2lb4z/+urBYA59+CFq0nvdIE7FBpruCm jGLIr9YTMIYeNmZIpBdmlXwkcVzc+7wBvWDnFURW5HfSUBfP9jk4o8hqXG4L8h8jJUhB 5o9faoxgcsSK0IXf2HDZadQeyOk2wFf6ABGP+YKO8B6w+ZjRWk1uWZ7+rryOEnpNBSn2 lveWLL+nwPUsF4ULXN0BFt8O+JojQJrvPAEUbR7axttHxRuTpfkUV2VpYPDpMLBeH3OV VNyQ== 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=voOl3oBQPa4EcugCZSLHHwkUdLGU1HGN6EFfjt+Jj5U=; b=AeUnXzg1sMASLg/POP+4fJ8PftIDaoDEFecHkIFQAEmxagjduEoS0zHrttfg9Yv+Rh Dnlk5kwezULSdMI0hbepNEs9LDPrYm4QW5ec30FQCWU5076Pis8GXLRoWK4CMEtaJItD 2RoZ01rcAsrl3ffcPcHKEwdnhhbSq4XSu8piyu1Rj8AM8KDYE8/0jCoBOFj24f6SYzU2 1rzQx8Jf167gr6neMk5lpZdoeapoekYq+U8pw5wFCMtY6eO4m0cKXwWrlJVK4ayg1k77 ajwj/1n2cmNfCxBZE+6vbdal7sy7UIYVax4i5db0fYSrmcE8iDlo79IhMjoRpUXMKXYK mF7A== X-Gm-Message-State: AHYfb5j4NI6BLZUQNAJXM6z1WtbU7MdRyZt26Obq2WWt4XD4nypg/UzB XqWSglYcDNFcp70G7ISl/WVb9l8cqspl X-Received: by 10.107.201.150 with SMTP id z144mr3215609iof.132.1502938234496; Wed, 16 Aug 2017 19:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 19:50:13 -0700 (PDT) In-Reply-To: <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 11:50:13 +0900 Message-ID: To: DY Kim Cc: Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="94eb2c0b951a9695eb0556ea133a" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:50:37 -0000 --94eb2c0b951a9695eb0556ea133a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, that doesn't work for two reasons: 1. The "internal" hosts now have sub-par network connectivity that they cannot share any further with hosts behind them. 2. As soon as enough hosts accept a /96 prefix length, a network operator that wants to limit address space can simply assign a /96 to th= e main host. That makes it impossible for these internal hosts to share th= eir own connectivity without NAT. On Thu, Aug 17, 2017 at 9:24 AM, DY Kim wrote: > Does this =E2=80=98unlimited devices behind the host=E2=80=99 include the= following case? > > - A host gets a /64 prefix. > > - The host runs for itself an internal =E2=80=98Unique-IPv6-Prefix-per-= Host=E2=80=99 so > that it hands out a /96 prefix to each internal device. > > - In effect, this comes down to /96 prefixes and 32-bit IIDs. > > Technically, there=E2=80=99s no reason why this cannot be done, I=E2=80= =99d assume. > However, would this be forbidden in the sense of the current and related > std track documents? > > --- > DY > > > > On 16 Aug 2017, at 23:00, Lorenzo Colitti wrote: > > > > /64 gives you something that no longer prefix does: the ability to run > SLAAC and connect unlimited devices behind the host. > > --94eb2c0b951a9695eb0556ea133a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, = that doesn't work for two reasons:
    =
  1. The "internal" hosts now have sub-par network connectivity th= at they cannot share any further with hosts behind them.
  2. As soon as= enough hosts accept a /96 prefix length, a network operator that wants to = limit address space can simply assign a /96 to the main host. That makes it= impossible for these internal hosts to share their own connectivity withou= t NAT.
On Thu, Aug 17, 2017 at 9:= 24 AM, DY Kim <dykim6@gmail.com> wrote:
Does this =E2=80=98unlimited devices behind the host=E2=80=99= include the following case?

=C2=A0 - A host gets a /64 prefix.

=C2=A0 - The host runs for itself an internal =E2=80=98Unique-IPv6-Prefix-p= er-Host=E2=80=99 so that it hands out a /96 prefix to each internal device.=

=C2=A0 - In effect, this comes down to /96 prefixes and 32-bit IIDs.

Technically, there=E2=80=99s no reason why this cannot be done, I=E2=80=99d= assume. However, would this be forbidden in the sense of the current and r= elated std track documents?

---
DY


> On 16 Aug 2017, at 23:00, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> /64 gives you something that no longer prefix does: the ability to run= SLAAC and connect unlimited devices behind the host.


--94eb2c0b951a9695eb0556ea133a-- From nobody Wed Aug 16 19:52:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93DB132449 for ; Wed, 16 Aug 2017 19:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uD4Ybkw0OQN for ; Wed, 16 Aug 2017 19:52:10 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675A313217D for ; Wed, 16 Aug 2017 19:52:10 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id r199so18317207vke.4 for ; Wed, 16 Aug 2017 19:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=hAPAplaHwKAYwWsobt98+YCwo/ZIiEkHWkqB/VOmpHc=; b=SR9DXQcaAa2tPj5XyU4FFNGONYvmfqiZWwItwTMVQYhC5MIxS2vwS+pIh2JMUCeJRs 4BS2bp/tHXGo+gT4I6ccZHQpPPP3cKAocHXpWBUPPQAAGO8fG8XuDhT1W+cVIRWD0cxH OogY86kPKlX6p71p+otHkQItaxr8t+EyoQFshsBj+RvzqXTP5MeIXFGfrQFba2QN2KwI 8YNOr5KV+FRXFGVIYpjtgvAuYJ9er6s8tsf/A9DNQTr4YFN14L6H9LBfECLywVJzjRf7 n6PSxilun2nnrfjWutzvDja0QBS9I4cq7NKPZGv6b41OTQHY01sI5elQfBn+H+YaxUJR 5w8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=hAPAplaHwKAYwWsobt98+YCwo/ZIiEkHWkqB/VOmpHc=; b=pW+WrkoJYnMLhYHQ0BrWRe4Bu2X8O9Xa6c+nuc2TxdMEt2OBqyN8qe3Kz5/64XttuK 4N1YbE0b3+p28EqxZuAaPze6WSOGBo5JIUWGpXekC3+/XsEjOP4g7nSpdS4tg0p8YjZ7 UXjCMWLtehpqjk6kqq5YxqGL8KU9UTvrSH8j8dkq5fSQ8Ma36NIkDv/f5zKOaVLAXD1M GZIUtoy2lPQDYcsRI3xAbo/awL7PG/ZsMev0MZhjDkX3nfwA9q4yEvUchZar2rChZGyh Cao5yGx6dSxMKbQlKm0uZfosgxnNIqNHqA+LTSoWtKcrjNHCbQJwp4ZoGsxWZ6lK9Buo 7/BQ== X-Gm-Message-State: AHYfb5gGnk5SJ7a07wg//xThf/ZJs12DCn6jEtNo/nUKh+DYqb9BBDlz SaTxUvh4p8DivjSg/DDQ8TBHEn8gHA== X-Received: by 10.31.6.205 with SMTP id 196mr2576437vkg.10.1502938329507; Wed, 16 Aug 2017 19:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Wed, 16 Aug 2017 19:51:39 -0700 (PDT) From: Mark Smith Date: Thu, 17 Aug 2017 12:51:39 +1000 Message-ID: To: Brian E Carpenter Cc: DY Kim , Lorenzo Colitti , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:52:13 -0000 So how do we evaluate what is the best solution? What are the criteria to use? This discussion is going in circles because I think people have different opinions on what the criteria are. Mark Nottingham has been working on the following draft, "The Internet is for End Users" https://tools.ietf.org/id/draft-nottingham-for-the-users-05.txt which says that what is best for the end-user needs should trump any other parties' needs. I entirely agree. What is best for end-users is the fundamental goal. I've thought it would be useful to have a set of high level and end-user oriented criteria to use to evaluate various technical choices, in particular when there are situations such as this one. I've thought there are the following 3 high level end-user criteria to use for evaluation: * Available and Reliable * Secure and Private * Cost Effective It seems to me that all IETF solutions should meet all of these criteria, ensuring they are prioritising end-user needs. I've suggested these to Mark for his ID, and to demonstrate their use, I used the 64 bit IID example. My evaluation was rushed for the purposes of example in the email. There are other Secure and Private impacts other than just being able to successfully scan a 32 bit address space. Another example is that reducing shrinking IIDs to increase the number of prefixes available within an assignment e.g. a /32 doesn't improve Cost Effectiveness because their RIR cost is trivial (a /48 is 1 or 2 cents per annum), and route table slot use doesn't change. "If IPv6 IIDs were reduced to something like 32 bits, would any of the above be impacted: - Available and Reliable: No. May have a positive influence, as availability and reliability possibly could be increased, as ND cache resource exhaustion attacks effectiveness would be reduced. - Secure and Private: Yes, negatively. It is practical to scan 32 bit address spaces e.g., shodan.io. 64 bit random addresses are effective at mitigating device discovery via unsolicited packet probing, 32 bit random addresses would not be. - Cost Effective: Yes, negatively. 64 bit IIDs have been the standard since July 1998 per RFC2373, meaning many protocols and implementations assume them. Code would have to be audited and possibly modified, and that code update distributed; there would be a population of devices that won't receive the update etc. End-user services outages could result due to incompatibility." As smaller IIDs have more negative than positive Secure and Private, and Cost Effective impacts compared to what we have today, it seems to me that they should be left alone, as the drawbacks of changing them outweigh the benefits. Regards, Mark. From nobody Wed Aug 16 20:01:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D8F132391 for ; Wed, 16 Aug 2017 20:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa80r0d_15f0 for ; Wed, 16 Aug 2017 20:01:42 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EEA13217D for ; Wed, 16 Aug 2017 20:01:42 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m34so25397045iti.1 for ; Wed, 16 Aug 2017 20:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xQse3393VTc2HWpOrcm+n5DmLH7Ts4LOTCoxG/j5N1I=; b=tBTH5k9mCnqTCzU0byqumtzk4WKbiLRt63dfJ1ZTz8G2Q7Y8PTBRG2sGSDiVYe7GPX q0zGNhTpoSSw+9oMT2B3IwrC9xEz9pRr5+EI86p+Zc89VNIW8tlGnGo4CcRY60xYEUF7 GGtzuMAM5YhaerRsA7cFDhnZnW/X9J9aTlEs1wosjGaFSNims1/Jim6SEOP4MOhKambV 4KUbgmSP3SLrOmtOfdHMeDjP0XH3LctfXYfb0BK9FUYT1OVoqFqajrJ+MC/Qi2o15nkN D2oGFUpJqqV2+9uVF5GRVp0gsfVlzQkXmdZpa2nn6ghK9Fv4ezKqFu7cwFqL8ppFftdg LjnA== 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=xQse3393VTc2HWpOrcm+n5DmLH7Ts4LOTCoxG/j5N1I=; b=WiZbnkcZczi0CUGEQbeHVlKwdnlsfZYXLUkqZnJ7lryfaC3lGviXnSJMzPu9Bguhz8 LFr/Gx+xhaozVsDfvq3KFYaaoKagOjr73xJCedYPdqm+yquoSLpks9+AspYQtC58F4B7 9GNBahmi917vjkE5h4uNIJYxusZj9XdqfD/4zBVGj8GiHjCi1vV3ebf2YrdgjL7IcH+c krbWewrO8zRYwBWQ+oojCQqBboz3vxVCxu9/Mm2A46q2gjxqOdIYb7U9CXZir45KzRtz DF/0uzfZCUHq6piJN4JQojUn8raeKebLPafCqVlzAxhDgGBToYVPfihkNFqP2iFPBIAg 4auQ== X-Gm-Message-State: AHYfb5jv1IhBORAQ3voY0JwbxiIDBJ5hSeDFOj5M14YAJaLreZA89sLA rV4EIdU3cJu1cUvLUSqEiBlKZC8GWTx8 X-Received: by 10.36.25.70 with SMTP id b67mr490077itb.72.1502938901812; Wed, 16 Aug 2017 20:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 20:01:21 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 17 Aug 2017 12:01:21 +0900 Message-ID: To: Mark Smith Cc: Brian E Carpenter , DY Kim , Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a1143d7165d09d80556ea3bd0" Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:01:44 -0000 --001a1143d7165d09d80556ea3bd0 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith wrote: > "If IPv6 IIDs were reduced to something like 32 bits, would any of the > above be impacted: > > - Available and Reliable: No. May have a positive influence, as > availability and reliability possibly could be increased, as ND cache > resource exhaustion attacks effectiveness would be reduced. > Actually the answer here is also "yes, negatively". It means that networks with large numbers of users would become unreliable because of IID collisions. There are networks that run 10k or 20k nodes on a single subnet. Large corporate networks are an example, or large conferences such as MWC. --001a1143d7165d09d80556ea3bd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 11:51 AM, Mark Smith <markzzzsmith@gmail.com&= gt; wrote:
"If IPv6 IIDs were= reduced to something like 32 bits, would any of the
above be impacted:

- Available and Reliable: No. May have a positive influence, as
availability and reliability possibly could be increased, as ND cache
resource exhaustion attacks effectiveness would be reduced.

Actually the answer here is also "yes, negatively= ". It means that networks with large numbers of users would become unr= eliable because of IID collisions. There are networks that run 10k or 20k n= odes on a single subnet. Large corporate networks are an example, or large = conferences such as MWC.
--001a1143d7165d09d80556ea3bd0-- From nobody Wed Aug 16 21:55:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F234B13235B for ; Wed, 16 Aug 2017 21:55:04 -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 lt_W32V8oH9p for ; Wed, 16 Aug 2017 21:55:03 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AF0124E15 for ; Wed, 16 Aug 2017 21:55:03 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id t80so1752967pgb.2 for ; Wed, 16 Aug 2017 21:55: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=zG2xAEaS2PAoT084maePhqRd+oBrh7ErYphzJJPTEFw=; b=nzVNY8J04PsUD+8YX7lsOV3YxTH2H8q+BkZ1AgG/M2pw44rZ4H9Iogq9cKm9srMnkw K3SbPRL1D4dg33t5zF6OWWAF7wrCfC7AQvOwssmCl2MdPyLSbqHn1Mq1q1JOtS/IdxU7 2xU/jJ7QClh5n5DE9IWiJBT+xuA8rx+Gg16kmei1Th0DNJgzMs/bDEP25nrrkOLupKir ISUzuJe+8YLDdR8HioYeSmiwEd1Yl7svR6Ofm1o5mgbhel/zO5LobL5CSLar3nqtwvuG NJTtzh2X2AZjiAJNBi9nPrjIbS11Qx35vMfOnRqWSi3xOaa/2efaKFSa71PbEj6iSGLL 8iCw== 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=zG2xAEaS2PAoT084maePhqRd+oBrh7ErYphzJJPTEFw=; b=YmCbm9VEHOFmqNKNq+lCcmtP51HKWNOSXopMWfu+6Gfbm7fDlhDv9/9DlQ8WexwyPz JOH172VML/rJ5bm3utU322QIGyYMTKFeSvoJyvVTcfbrWwTGgEibrRDWemAG+eoVkG7/ 7uXjlZK84FczCFXYCGSWP2AsT6T+JnoIMup1cD2lANjD9bfufhbxAH5IUr8nElOXoBZ8 j/FwfWP84C4Crzz9zqKUpGVtmGUjWEStBZynjmYTsSwyTuLM70c23dRcofJeY21pnGZt m2Xn5luTaK+cq3p0HmU1Cc7RQkpu5f3B5nNlVDKj5DwPaQWGfV4Mz9vt2saW6B1WDbqR ++3g== X-Gm-Message-State: AHYfb5goApHUIXDDf+gIK0BsLHSxi4wWfCq/fS02y+yBDmh2vu1ABPVC kDpFVNIlKNsrz06e78Q= X-Received: by 10.98.33.84 with SMTP id h81mr3957726pfh.302.1502945702959; Wed, 16 Aug 2017 21:55:02 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id c14sm5281677pfl.160.2017.08.16.21.55.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 21:55:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 13:54:59 +0900 Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:55:05 -0000 Sent from my iPhone > On 17 Aug 2017, at 11:48, Mark Smith wrote: >=20 > Externally, it is not possible to determine whether a /64 is assigned > to a link or a host - consequently, it isn't possible to know if > source addresses from with a /64 represent a single device's traffic > (the /64 is assigned to a single device) or traffic from a range of > devices (a /64 is shared by many devices attached to a link.) Exactly. So, why would it bother you - if a host given a /64 prefix assigns a 64-bit IID to each of its interf= aces, or=20 - if the same host subdivides the /64 prefix into multiple /96 prefixes e= ach of which be given to internal devices behind, wherein each device then a= ssigns 32-bit IIDs to its own interfaces. Such domestic behaviors are not observable from outside, so why would you en= force 64 bits for whatever is classified as an IID? > Individual source addresses however always represent traffic from a > single device. Of course. =20 The original question was about the feasibility of 32-bit length of IIDs for= internal devices behind a /64 host, in regards to privacy. In a legacy IPv6 networking, the pool of 64-bit IIDs would be shared by host= s inside a subnet which may contain arbitrarily many hosts, whereas in my scenario of internal /96 devices behind a /64 host, the pool o= f 32-bit IIDs would be shared by interfaces of a single device. If obfuscation should be a measure of merit, the obfuscation of 32-bit IIDs a= cross interfaces of a /96 device should not be terribly inferior to that of 6= 4-bit IIDs across all interfaces of all hosts inside a /64 subnet. My question then goes back to - What's the point of mandating 64 bits for IIDs when behaviors internal t= o or behind a /64 are not observable from outside anyhow? - Are there any practical ways to police them and return penalties to ill= -behaving hosts? From nobody Wed Aug 16 22:07:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B1413234B for ; Wed, 16 Aug 2017 22:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mesi9CLMvIi for ; Wed, 16 Aug 2017 22:07:32 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3CE124E15 for ; Wed, 16 Aug 2017 22:07:32 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id u133so18888909vke.3 for ; Wed, 16 Aug 2017 22:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U12NkM9HXY1Xfe+uAlba/RF9qjaf68hhY5/PPJjwQy4=; b=Y9NnCaVFKMLEhlCIi7UIo2ygoRvEZ3LNiRdzIBLElMFAS/pNJu0pns5HiOjGfJgiYF OKP4g+IICpLIfgv814BTF0w6wPsIpwq/hUlDl6x36OmUzRVdc1A/2LwZD0hD58UvXNu5 vNZq5i1o760czadMB9LPScKjofFKjhiEPf+Doi5djkQJNPkYJsdVbDKHUZ1yqGpTygtR ynDcaxPSYlHXi9v7thYhspcOdpbSNl6ZN/ES1Q9kuPykUtu8k7AEDqBpnXnFiU5rN8N2 Fly8Z6VJ2ho6ek7gZglGEvvzaAUgvCmXkJvQag5ZrvbuE3GyoBx7yqVV9ZGeUjgF8m39 B5Sg== 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=U12NkM9HXY1Xfe+uAlba/RF9qjaf68hhY5/PPJjwQy4=; b=HlH1kt57RoVGxQgNypiCq1/z+2iVZTDVowtDAcbKYt5TvAD3C0+jh9Bjd1f699iKVD uqyBypal49zF/WX5bt2vS9jgU5NgajfX5eJM3NjBsRJ8eH/sTLcHophd7OQNipIKRG7b j0McrOemWbtwwPBzyMV81RqwqWDK1CiKrxRqRbBjzqPPHiQmBwv6vzMsBFc2buiPxF6B DlZjckAXxM8QhtgrEyG8G+v/t/Msf/3DsU4My91XZqy83kKa0ojg11uhgfK42j8qVkGB kSvNdz9B/tIn7r/EpH2XpYOmzQXLp8jHTAhvLH0dEBNtFUlATFxu23D5tpT+RoisX4lQ kWmg== X-Gm-Message-State: AHYfb5j9qAAeeq3ZmouLSUfoXeLpKZZBfw/zEa9Lc0rVJ4biH6CwuNwS FwIcRKL3RO1HmJWxCgkAqQohcMPBvg== X-Received: by 10.31.155.88 with SMTP id d85mr2513134vke.88.1502946451796; Wed, 16 Aug 2017 22:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Wed, 16 Aug 2017 22:07:00 -0700 (PDT) In-Reply-To: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> From: Mark Smith Date: Thu, 17 Aug 2017 15:07:00 +1000 Message-ID: To: DaeYoung KIM Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:07:35 -0000 On 17 August 2017 at 14:54, DaeYoung KIM wrote: > > > Sent from my iPhone > >> On 17 Aug 2017, at 11:48, Mark Smith wrote: >> >> Externally, it is not possible to determine whether a /64 is assigned >> to a link or a host - consequently, it isn't possible to know if >> source addresses from with a /64 represent a single device's traffic >> (the /64 is assigned to a single device) or traffic from a range of >> devices (a /64 is shared by many devices attached to a link.) > > Exactly. > > So, why would it bother you > > - if a host given a /64 prefix assigns a 64-bit IID to each of its interfaces, or > > - if the same host subdivides the /64 prefix into multiple /96 prefixes each of which be given to internal devices behind, wherein each device then assigns 32-bit IIDs to its own interfaces. > > Such domestic behaviors are not observable from outside, so why would you enforce 64 bits for whatever is classified as an IID? > >> Individual source addresses however always represent traffic from a >> single device. > > Of course. > That is exactly why IID values matter. There is no hiding what they are referring to. They're always referring to a individual end point, there is no ambiguity. Externally you cannot really tell if /64s are being used. If you assume they are, you still cannot tell whether the /64 is assigned to a link shared between a set of hosts, or assigned to an individual host. There is no such ambiguity with a single 128 bit IPv6 address. It's an end-point identifier. > The original question was about the feasibility of 32-bit length of IIDs for internal devices behind a /64 host, in regards to privacy. > > In a legacy IPv6 networking, the pool of 64-bit IIDs would be shared by hosts inside a subnet which may contain arbitrarily many hosts, > > whereas in my scenario of internal /96 devices behind a /64 host, the pool of 32-bit IIDs would be shared by interfaces of a single device. > > If obfuscation should be a measure of merit, the obfuscation of 32-bit IIDs across interfaces of a /96 device should not be terribly inferior to that of 64-bit IIDs across all interfaces of all hosts inside a /64 subnet. > Have you read "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" https://tools.ietf.org/html/rfc7721 ? > My question then goes back to > > - What's the point of mandating 64 bits for IIDs when behaviors internal to or behind a /64 are not observable from outside anyhow? > Urm, are you assuming NAT? Source addresses are visible to the outside, because there isn't > - Are there any practical ways to police them and return penalties to ill-behaving hosts? > From nobody Wed Aug 16 22:08:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F61D132454 for ; Wed, 16 Aug 2017 22:08:21 -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 4F96qKhvhkl8 for ; Wed, 16 Aug 2017 22:08:19 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7F21201F8 for ; Wed, 16 Aug 2017 22:08:19 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y129so7945908pgy.3 for ; Wed, 16 Aug 2017 22:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a0nub0LowuPZBBtfRUkp+8D+ZaftBLK0T0QrZ2IRXIM=; b=XZaIBZ4Xkm1pQuoxM3LC/pXhaYJvQ8kN+xy2X4Ov0aPEoENUewFMfq0npQXEI/lyTL 6wOA1w7aSsemf/3HRO6r5QlkWnUUfL2YbapIYdBctfc+N8Pozfox2do3krUULknuDLyt mNy751T8VOR+l/3Hj/qGLBfKPU+MTf0AMBxuqTXdPY6+S3b6qgjPb0Tp5Tw0hwM0pERl qi8yNtHytGC7iO7o0sGUm2I6dO4iCeaxZmPjEQPMDQ+LEdgEpxy4R3YOkOI0hq68oxQW jYhvjm4onbU3HE6UCRyzA2vys0ZC/i61QUNlDLI3V0Nei5d5GQ+t9aWf2ULTqT7BGLP3 TsTA== 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=a0nub0LowuPZBBtfRUkp+8D+ZaftBLK0T0QrZ2IRXIM=; b=kqWaFKP8tKRYCLaiQSOxfSHRBVTDF7jGV51LKr5mhR9dHUG6oZcie4EF6c1puOX0dT FdnsGgEa2gU7cXlscoqStQN+2kknZXj9H9gSbIs+onP+qc/GjHz+tylrjK7cBi73ZtBs 6K2VJYnSlz468dYIatXKPaT9csUTnsEW58kBd4PL9mKcvl2ctJJniKVv97WY8xGogoa/ eoiFR8V8TaAv26/FCMJYubBYXVgDyP4LMnu1gH+TzU/b+bD7cn9NcDqn0XdHvxM1ToGX 2CRFdhIvaACRsv/5iuxSQDLRwYwwRoPnTun3SEkRhSVvjAgHDqtn2jxVDZz/rrrfeOSg kJTQ== X-Gm-Message-State: AHYfb5gFVjDKqYX5XH2qyFXuxOPcVrAeMn/PGJphzyQrAoJPpoI0GEfM cOd1LPXc7qJrcA== X-Received: by 10.99.160.25 with SMTP id r25mr3752089pge.6.1502946499364; Wed, 16 Aug 2017 22:08:19 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id a125sm4078162pgc.37.2017.08.16.22.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 22:08:18 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-37666411-AB96-4B32-AF9E-690A2EDCE828 Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 14:08:15 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: 7bit Message-Id: <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> To: Lorenzo Colitti Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:08:21 -0000 --Apple-Mail-37666411-AB96-4B32-AF9E-690A2EDCE828 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm afraid I don't get you exactly here, but I'll try inline... Sent from my iPhone > On 17 Aug 2017, at 11:50, Lorenzo Colitti wrote: >=20 > No, that doesn't work for two reasons: > The "internal" hosts now have sub-par network connectivity that they canno= t share any further with hosts behind them. The /64 host in my scenario in fact now behaves as a router and distributes /= 96 prefixes to internal devices. E2E connections don't terminate at the /64 n= ode but at /96 devices. No NAT at the /64 node for e2e connections for /96 devices. > As soon as enough hosts accept a /96 prefix length, a network operator tha= t wants to limit address space can simply assign a /96 to the main host. Confused. /96 prefixes are handed out by a /64 host, not by a network operator. > That makes it impossible for these internal hosts to share their own conne= ctivity without NAT. No NAT necessary as I described above. --Apple-Mail-37666411-AB96-4B32-AF9E-690A2EDCE828 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm afraid I don't get you exactly her= e, but I'll try inline...

Sent from my iPhone

On 17 Aug= 2017, at 11:50, Lorenzo Colitti <l= orenzo@google.com> wrote:

No, t= hat doesn't work for two reasons:
  1. Th= e "internal" hosts now have sub-par network connectivity that they cannot sh= are any further with hosts behind them.
The /64 host in my scenario in fact now behaves as a router a= nd distributes /96 prefixes to internal devices. E2E connections don't termi= nate at the /64 node but at /96 devices.

No NAT at t= he /64 node for e2e connections for /96 devices.
  1. As soon as enough hosts accept a /96 prefix length, a= network operator that wants to limit address space can simply assign a /96 t= o the main host.
Confused.
/96 prefixes are handed out by a /64 host, not by a network o= perator.
  1. That makes i= t impossible for these internal hosts to share their own connectivity withou= t NAT.
No NAT necessary as I described above.

= --Apple-Mail-37666411-AB96-4B32-AF9E-690A2EDCE828-- From nobody Wed Aug 16 22:17:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6D11321B0 for ; Wed, 16 Aug 2017 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZHNus7IeQg7 for ; Wed, 16 Aug 2017 22:17:49 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 E98EA12EC06 for ; Wed, 16 Aug 2017 22:17:48 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m34so26192551iti.1 for ; Wed, 16 Aug 2017 22:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ma+sv1yir/OI7ozKGch3n6yW5lVPUBYjHmZs9mKiauU=; b=q/LD82F2TE6fg8VEvCL0zHsR0qm/M93QpOtICWXpIoWEg+/or71YQYav5+R2toTqUZ shTdEY7bPAN/negKEvBHwEHk03odNN6ELPk6+zaXKOtbovMcxv8oj7GdBR8xcBoXWhe2 n99xHC7AbGPN/jMLJk9XoKPy/GpDb0DZBb0jmaGCnw8ZxkJheBehegFeHoUomxUPXcEI 1N48LZmcbsSNQYO+ANhiiBEqKfHj9ZR1wiVNRWAjAL8W2ujuXCwJK7p9cp/f0Q7O5F6j dQs9QKTgmJ+4zmOQ8t6Z8OrjQujjNDQ5QGg/8cHG2rMZ+0UUNYZuHwZQwEy9yqpXTGHw 9VcQ== 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=Ma+sv1yir/OI7ozKGch3n6yW5lVPUBYjHmZs9mKiauU=; b=lKP2rqyYYSQS81dKfl+EAEWCVTT8JOWtH+dFCPDx9qBIbnQ6C9cY5VInMnuJmswUJS PXxs8eT4GmRE1s7nhHNOcHcCxlTRd1fR8tr7/fmyEuCtTy7fQl2QTz6OLChFNpUsjUc1 ftjg+aoNjrP8eFEfoQY37eDMeer4+yO6hiW0LTaxAlWLbauidUGRzs+xJOm5Iuf0JrNP fa/W5uUgtJAZSjt/Hreb3GS6awR4+23l2/VYlmxuQ8+BEuxjLiaXzb8PoSX0Y8q2JTx1 p0krhPKY+h8dvNrSilA4C7SqfzWGwR33nPGY+F+XPCAHg4/o72hPc7r2s22VDsg4dz75 1+cw== X-Gm-Message-State: AHYfb5gf2cFG4IfYmXaajmLhha+5XV9kYT+DZ9I6LtpK3nkKe09EySGi iiGrrxrUJ2SZA1NOmkZIbvFg9L3Wqaqc X-Received: by 10.36.25.70 with SMTP id b67mr684488itb.72.1502947067991; Wed, 16 Aug 2017 22:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 22:17:46 -0700 (PDT) Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 22:17:46 -0700 (PDT) In-Reply-To: <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 14:17:46 +0900 Message-ID: To: Dae Young Kim Cc: "v6ops@ietf.org WG" , Simon Hobson Content-Type: multipart/alternative; boundary="001a1143d7161b11d20556ec2273" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:17:51 -0000 --001a1143d7161b11d20556ec2273 Content-Type: text/plain; charset="UTF-8" On 17 Aug 2017 14:08, "DaeYoung KIM" wrote: 1. The "internal" hosts now have sub-par network connectivity that they cannot share any further with hosts behind them. The /64 host in my scenario in fact now behaves as a router and distributes /96 prefixes to internal devices. E2E connections don't terminate at the /64 node but at /96 devices. You said that, yes. the host gets a /64. The hosts behind it get a /96 each. Which means that the hosts behind it have worse connectivity than it does, because they can't further extend the network (without NAT). 1. As soon as enough hosts accept a /96 prefix length, a network operator that wants to limit address space can simply assign a /96 to the main host. Confused. /96 prefixes are handed out by a /64 host, not by a network operator. This requires that hosts will accept a /96 if the network gives them one. Thus, a network operator that wants to limit address space can simply assign a /96 to a host. Then the host will not be able to give other hosts behind it any /96 prefixes. So if the host wants to extend the network to other hosts it has to use NAT. --001a1143d7161b11d20556ec2273 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 17 Aug 2017 14:08, "DaeYoung KIM" <dykim6@gmail.com> wrote:
<= div>
=
  1. The "internal" hosts now have sub-par network connectivit= y that they cannot share any further with hosts behind them.
The /64 host in my scenario in f= act now behaves as a router and distributes /96 prefixes to internal device= s. E2E connections don't terminate at the /64 node but at /96 devices.<= /div>

You said that, yes. the host gets a /64. The hosts behind it get a /= 96 each. Which means that the hosts behind it have worse connectivity than = it does, because they can't further extend the network (without NAT).

  1. As soon a= s enough hosts accept a /96 prefix length, a network operator that wants to= limit address space can simply assign a /96 to the main host.
Confused.

/96 pr= efixes are handed out by a /64 host, not by a network operator.
=

This= requires that hosts will accept a /96 if the network gives them one. Thus,= =C2=A0a network operator that wants = to limit address space can simply assign a /96 to a host. Then the host wil= l not be able to give other hosts behind it any /96 prefixes. So if the hos= t wants to extend the network to other hosts it has to use NAT.

--001a1143d7161b11d20556ec2273-- From nobody Wed Aug 16 22:31:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B180131D19 for ; Wed, 16 Aug 2017 22:31:25 -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 5T8N1l1XEwWk for ; Wed, 16 Aug 2017 22:31:23 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01B112EC06 for ; Wed, 16 Aug 2017 22:31:23 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so8050362pgd.1 for ; Wed, 16 Aug 2017 22:31:23 -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=7CDPNUfakrPiEHF2ltfpRw/agT4mjbQCLTpL6d9f/es=; b=Pp3nfk24U7LPmAMmk7Oscf7ocS3Mwja7TMFAJJTJaF+lV00ntPMppJcaoEw3C8DZID G7i65XqZMbaLAI+LuqTBT+7wy/zlb9dkf7dIlFCksLs75gpcuhvGSyNSTN8sdXoSCTlM 90L1nPSbRGq2b0k4Xiv6+3jjoOiBKxPaYDNDD2walL+xoaKuoDtDLhbqzFMf2WYTpGQD h+8NaXz9WsRi2qqKaeWaEM/WPoT1axJSemJqG2rgdRo0v4oSF4BlYqnbXjkg7L900diS 8rLXZ8zgeBKCKPhYcai8Dnb/OK9wta5tg1HPPvJaVO7AtntvwdFlYbhopzy2K3wL0h9u Epwg== 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=7CDPNUfakrPiEHF2ltfpRw/agT4mjbQCLTpL6d9f/es=; b=HZJLQBUW60PlXTBjvyCj//7YwaU3rGNj+QjcgLTcRv9Az/L+G2T2jnPVTmtea+Zfu5 Cbjsv5MrRihoBSB0nNWgFquYgYgXMlMryW0oMH9Jjvvvf0xB0xk7QTniF1j/93FsMo2F +ChTJXolci26cjn76ldoQ8/s9DYM7ZCcroJXxiUab8ExCvypX8/vxi5wCY3i12C1Kdaa srG0i1L/K22u5Bne8TXoau8FbeonSIJHjQuv/OJMjaFKgYPDw6Nb8PaCuH7PfscHzi+K pQGyyjctlmodH5/ON07eu4nmlXFQnpO9lKFJwR0DJWGYeP6358N3E7YmF3d9gjNqrD9I plBg== X-Gm-Message-State: AHYfb5jgQ8X1bYVTF1uaSBLJtcQpu4y6nTsoEgHw3G4M8mmQ02aspvi7 Kbm9T+6t6fwVXg== X-Received: by 10.99.39.135 with SMTP id n129mr4002743pgn.36.1502947883395; Wed, 16 Aug 2017 22:31:23 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id q185sm4761894pfb.119.2017.08.16.22.31.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 22:31:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 14:31:19 +0900 Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:31:25 -0000 Yes, I did. What do I miss? Sent from my iPhone > On 17 Aug 2017, at 14:07, Mark Smith wrote: >=20 > "Security and Privacy Considerations for IPv6 Address Generation Mechanism= s" > https://tools.ietf.org/html/rfc7721 From nobody Wed Aug 16 22:37:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525F11323FD for ; Wed, 16 Aug 2017 22:37:25 -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 VcboFFY0Zpz8 for ; Wed, 16 Aug 2017 22:37:23 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8378C124E15 for ; Wed, 16 Aug 2017 22:37:23 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id u185so8090013pgb.0 for ; Wed, 16 Aug 2017 22:37:23 -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=MH09ELZNP1eiJnNF/mY07JxJUQ9MocvD+u1AdT8OF3Y=; b=YgwbORYAgE2nQ56AXo5GtmG4GFOS1rNCYOpRSl5cibtb2zGn7UbTGXx8A8VJEViw1+ ECNem9PmTWNBhv96kU54MOPLbvtNVbv/11Hn/nd41aNIVtjXuksVRebbVhkwfi7yGg4m uq3FZxFYSna/GVeNmzXdaO8HlLOTOq9ljxRG/VuuIzkf8nf8ceKaszpuPByM8LGCK5tw 1hxh65/AqzZ31OTYjIbtlK7jv2iRZBNWnZoie2JN6Wo+ZFyz0wo4yUuau16XsM8J/D+W UolGq3KBeSWb67+9GL4UDfFABCkrqDYfkqEZ1oYbOaXpx57URNFZ//viJy3Slq97YSP5 CiLw== 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=MH09ELZNP1eiJnNF/mY07JxJUQ9MocvD+u1AdT8OF3Y=; b=pLtX61ljXW5vj59NMn08E9Yh4T6I+nxAZM97eAshjgy9vkKfuH6gdHfgwNwtkIUvAv t5wlQKWHDAQZfdXUuZXewuirj00XfzxlahGWl5QWrwRIuy9tjSBMO77MITS15w/21fgo kigJR8aNJtosEtrU3TgnAJSLnB4Tw78VQHUdP5aqn9qVV37+WMwJQmiIX5u7RFPLl1sh W7TwhFhwwVuU4u0S4c9Pq5JtMskmevYQeWo13SPe1CgkppTulabqcbS7rH7YznWRyGzp tXbl57hXw0rHpDX4AVU++Y2sJ7o8FioK4Qqfo07eIXnV0KS5TyibaWil4cX+AnVQ10xA GL7g== X-Gm-Message-State: AHYfb5hGPMCBjHGN6IUOGxqa5G1KDOLBsvv6XyMSuRGFt9A05usaC02J +K4rgqAkXxDr1Q== X-Received: by 10.99.121.1 with SMTP id u1mr3805468pgc.217.1502948242935; Wed, 16 Aug 2017 22:37:22 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id f88sm4810010pff.74.2017.08.16.22.37.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 22:37:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 14:37:19 +0900 Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <8630F222-BEE1-4F68-8C1F-7941C5901F3D@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:37:25 -0000 Sent from my iPhone > On 17 Aug 2017, at 14:07, Mark Smith wrote: > That is exactly why IID values matter. There is no hiding what they > are referring to. They're always referring to a individual end point, > there is no ambiguity. Yes, > Externally you cannot really tell if /64s are being used. If you > assume they are, you still cannot tell whether the /64 is assigned to > a link shared between a set of hosts, or assigned to an individual > host. No, I cannot, > There is no such ambiguity with a single 128 bit IPv6 address. It's an > end-point identifier. Yes. > Have you read >=20 > "Security and Privacy Considerations for IPv6 Address Generation Mechanism= s" > https://tools.ietf.org/html/rfc7721 >=20 > ? >=20 Yes. What do I miss? >> - What's the point of mandating 64 bits for IIDs when behaviors interna= l to or behind a /64 are not observable from outside anyhow? >>=20 >=20 > Urm, are you assuming NAT? No, I'm not. > Source addresses are visible to the > outside, because there isn't ?? From nobody Wed Aug 16 23:03:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED81323B2 for ; Wed, 16 Aug 2017 23:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyMAqa98vSzr for ; Wed, 16 Aug 2017 23:03:16 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891661323B1 for ; Wed, 16 Aug 2017 23:03:16 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k43so21417262uaf.3 for ; Wed, 16 Aug 2017 23:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mjy37By/QhTd69XB4DzBdXLNT7vyrcG/7MWwZ4pFtGo=; b=BqHesgFOc8wGoAdXmdYFFUaEb5z+UFH3nf+cRlNzyVM0DCAaIkS2+hHXZgWOfUIzWe v1CFC5pfRw4A9wndg0l+dEXRcOREpS2BLLIMopmeJErh7Ot+tItS1DVh31ODvKrAR0BP eZS5obS8EgbxCi7aoNmd/mqyzdTKBOeNGt/WJRxgx/0TNnrWAa1i1J8ZFZvExr3c18t4 DmkuPzuOzYsiD5/OujiRu0SpoDV7wKR7WveArGxWcJ/tyROdXNXP0gYkbozIVEhNWGYu pVFlN6g7hGfivC+JPrVVCl54/eJ9D7qnR1ZLJLBnEj/PnpCADb2ut3uyASD831gq0RtI AUNg== 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=Mjy37By/QhTd69XB4DzBdXLNT7vyrcG/7MWwZ4pFtGo=; b=T+zG1OYdCGH82aI91Hn1LKsqSl4T53DPD1XSYTL/o+jjBiiVLgx3EWP9t3tqgCYY35 dyv8pohqma47tFsiosBI+MR2IfTJx19bPzuaMlz1ohZ95MFlSoIwWueiCDeSL1yfg7tO wvcaJjh9ekytzk3mpPxJM/tVHdWQIT2WGm5ePwBqecDOB8JafSBpI76mJcljMGubiChh mI/arbfP25EHoK4AlSE3yi7Z3+xh7ib1RHaWOjShbaNznOlbKqwKZ3zvKc5SkKAO5IL2 DBFMa9ErRjTbG4wLZa/O41WdpNcaC+YcxqoBxp/bcELAdAnCkZkFvUN9OPgQpN5QWpSe UWgA== X-Gm-Message-State: AHYfb5g/xVNcywlxWY/JFzEmCDzVuHjFZqyvU2FNql3vgIVXHJXg71/O LKTd6BeaBrqTKMzsSHfmeDxcTBAg9g== X-Received: by 10.176.22.204 with SMTP id g12mr2615094uaf.120.1502949795519; Wed, 16 Aug 2017 23:03:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Wed, 16 Aug 2017 23:02:44 -0700 (PDT) In-Reply-To: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> From: Mark Smith Date: Thu, 17 Aug 2017 16:02:44 +1000 Message-ID: To: DaeYoung KIM Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:03:18 -0000 Hi, On 17 August 2017 at 15:31, DaeYoung KIM wrote: > Yes, I did. What do I miss? It seemed that you might have missed that there are security issues IIDs with low entropy e.g., the MAC address derived ones, e.g., being vulnerable to address scanning. Regards, Mark. > > Sent from my iPhone > >> On 17 Aug 2017, at 14:07, Mark Smith wrote: >> >> "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" >> https://tools.ietf.org/html/rfc7721 From nobody Wed Aug 16 23:17:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B116124E15 for ; Wed, 16 Aug 2017 23:17:13 -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 LmXg50WsEpMP for ; Wed, 16 Aug 2017 23:17:11 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA531323B1 for ; Wed, 16 Aug 2017 23:17:10 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so8241829pgd.1 for ; Wed, 16 Aug 2017 23:17:10 -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=+D6VCks3BeavVtvUpqU0E3qANmfDBBZET3tITqlE70E=; b=tjMALLJiXy7zPOvLM5OLnOWSUomohv1qhFCbCqEjdINxlpv4DCCieTJ9yvfBcd0QYf S85yDsu0W8tP4zeGwUSOpFeQn+2BhEgpR8gjOTefTMy1rVL2dyv94hCQKshgIaPypM7u jda8SRatDYY/J4ent1NdNLEu9gkvl6fydpl/HCcBJICyHw68HV8ZuV0Invu3C25AkH87 vrDkywJZkXkGmEq1gKimlVmxPzApd7oulBXM4bvuTb9n5hf979V4cljQQviiSd4ysY55 s/RWiDHtK8IjWQBCE4OIFlY3cHB1BtIbmTt9NbhBKGxTsNT7A5lbXPfCEWHqY1rkzg+p GyEQ== 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=+D6VCks3BeavVtvUpqU0E3qANmfDBBZET3tITqlE70E=; b=Cd/+LZDzrvpEBmuTZPMnt4/ZvbKU5cIRq1agH+5YaNw5S6Qt3JUH6PUWjt6Rkv36nc VDqhZWoANog8PYYzUnyvLze9v8m1pdo94q7i68K0xq4qpn3aaUsYbNTJ2Btvj68gOZ6V LEOojSEGDYTsfUgFd4NM4KEfsRdYktADjFa7J7aRG+dggrCdLAeFonGWTr57OBTH8zHe fI+mfvyLJLSK+iNArHJ4qjjeh3Wz9V9qkKhuiZq/SGSv7ylVmrjPYk9GM8UZKH5QmI25 dRKuRLYsqiZOwEIcOdPrcQJNxq/gJrfTRxc0Wj0IRRcN/uElGFBge9h3Yjcsu8JcdiIv vdgg== X-Gm-Message-State: AHYfb5j8opIUGGZ6TnLaaf+6+xjV7L3fjeACosB6mrcuE1b7OVRxyIjx hNsYlZ8onVEVtg== X-Received: by 10.98.160.76 with SMTP id r73mr4184218pfe.26.1502950630567; Wed, 16 Aug 2017 23:17:10 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id 5sm3911380pgx.56.2017.08.16.23.17.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 23:17:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-210EE143-6560-4DD9-AF84-C94FFACDB018 Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 15:17:06 +0900 Cc: "v6ops@ietf.org WG" , Simon Hobson Content-Transfer-Encoding: 7bit Message-Id: <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> To: Lorenzo Colitti Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:17:13 -0000 --Apple-Mail-210EE143-6560-4DD9-AF84-C94FFACDB018 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On 17 Aug 2017, at 14:17, Lorenzo Colitti wrote: > The /64 host in my scenario in fact now behaves as a router and distribute= s /96 prefixes to internal devices. E2E connections don't terminate at the /= 64 node but at /96 devices. >=20 > You said that, yes. the host gets a /64. The hosts behind it get a /96 eac= h. Which means that the hosts behind it have worse connectivity than it does= , because they can't further extend the network (without NAT). I would' mind that. I'm not a manager of s whole site (of /48 typically), an= d that's neither my interest nor purview. All I'm interested would be whether I could recursively apply the same mecha= nism of 'Unique-IPv6-Prefix-per-Host' internally to my node (perhaps a sophi= sticated robot or a small IoT island). (At this point, I'd like to see the draft read '-per-Node' rather than '-per= -Host'. If the node terminates connections, then it's a host whereas it's a r= outer if it doesn't only to relay packets to connection-teminating internal d= evices.) So, I'm not interested in network connectivity the size of a whole (typicall= y /48) site up to theoretically as many as 2^80 (=3D 128 - 48) nodes. The ap= plication area I'd be interested with my scenario would be in an internal ne= twork of tens or hundreds nodes if not thousands. Within my /64 prefix, I ca= n in fact give birth to theoretically as many as 2^32 internal devices (each= of a /96 prefix), effectively the size of the whole IPv4 Internet which wou= ld be way way more than I'd need. > /96 prefixes are handed out by a /64 host, not by a network operator. >=20 > This requires that hosts will accept a /96 if the network gives them one. T= hus, a network operator that wants to limit address space can simply assign a= /96 to a host. Then the host will not be able to give other hosts behind it= any /96 prefixes. So if the host wants to extend the network to other hosts= it has to use NAT. Let's make this clear before going any further: I'm not at all against princ= ipally distributing /64 prefixes to hosts up to this draft. That far, fine. All I'm asking is whether I could recursively apply the same (or equivalent)= mechanism to my /64 host to incarnate a child network behind my host. My in= ternal devices don't get prefixes directly from a network operator upstream t= o me, but exclusively from my /64 host. No worry about malicious upstream ne= twork operators.= --Apple-Mail-210EE143-6560-4DD9-AF84-C94FFACDB018 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On 17 Aug 2017, at 14:17, Lorenzo Colitti <lorenzo@google.com> wrote:

The /64 host in= my scenario in fact now behaves as a router and distributes /96 prefixes to= internal devices. E2E connections don't terminate at the /64 node but at /9= 6 devices.

<= div dir=3D"auto">You said that, yes. the host gets a /64. The hosts behind i= t get a /96 each. Which means that the hosts behind it have worse connectivi= ty than it does, because they can't further extend the network (without NAT)= .

I would' mind that. I'm not a manag= er of s whole site (of /48 typically), and that's neither my interest nor pu= rview.

All I'm interested would be whether I could recurs= ively apply the same mechanism of 'Unique-IPv6-Prefix-per-Host' internally t= o my node (perhaps a sophisticated robot or a small IoT island).
<= br>
(At this point, I'd like to see the draft read '-per-Node' rat= her than '-per-Host'. If the node terminates connections, then it's a host w= hereas it's a router if it doesn't only to relay packets to connection-temin= ating internal devices.)

So, I'm not interested in n= etwork connectivity the size of a whole (typically /48) site up to theoretic= ally as many as 2^80 (=3D 128 - 48) nodes. The application area I'd be inter= ested with my scenario would be in an internal network of tens or hundreds n= odes if not thousands. Within my /64 prefix, I can in fact give birth to the= oretically as many as 2^32 internal devices (each of a /96 prefix), effectiv= ely the size of the whole IPv4 Internet which would be way way more than I'd= need.




/96 p= refixes are handed out by a /64 host, not by a network operator.
=

This r= equires that hosts will accept a /96 if the network gives them one. Thus,&nb= sp;a network operator that wants to l= imit address space can simply assign a /96 to a host. Then the host will not= be able to give other hosts behind it any /96 prefixes. So if the host want= s to extend the network to other hosts it has to use NAT.
=
Let's make this clear before going any further: I= 'm not at all against principally distributing /64 prefixes to hosts up to t= his draft. That far, fine.

All I'm asking is whethe= r I could recursively apply the same (or equivalent) mechanism to my /64 hos= t to incarnate a child network behind my host. My internal devices don't get= prefixes directly from a network operator upstream to me, but exclusively f= rom my /64 host. No worry about malicious upstream network operators.
<= /body>= --Apple-Mail-210EE143-6560-4DD9-AF84-C94FFACDB018-- From nobody Wed Aug 16 23:27:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC6126C2F for ; Wed, 16 Aug 2017 23:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ko9AQei3J0DE for ; Wed, 16 Aug 2017 23:27:19 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E206124E15 for ; Wed, 16 Aug 2017 23:27:19 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m88so20048312iod.2 for ; Wed, 16 Aug 2017 23:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dp5ThIlUHImw1BfTQ2l86++05aushnQ/y9IKBGD8SMY=; b=vKwYiWGDioXO2Eo4MKC7OhATzafQ7W86anOwB1/fBilx0sMnwIgrKFa6cmz9iSc3WC x7YVKArj6BcEXoOw9JyZDKG5b5BXLqIn/+XbMuSp/87Lq+UughML14eZBTR6/KeAR/iw Ok093XQEWyQ8stUjOwp8KWrcG8NPma4rNZtlz+HdmVJ3puh0Pz0NCnPPOpaqFoEHI0Zx 619BfTe8LMJyy1vrXzpXDEZGkSrO0ngiqzo+t/5EFnXIZRVG7XQocP4JCxGotmwzszsn zCeWcz6XUxMfdV9GV4uWJRTbxBVOENJGazCri74JAvqOpcuD6AdgVkxRE2kg3Cs2fAxe GM7w== 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=dp5ThIlUHImw1BfTQ2l86++05aushnQ/y9IKBGD8SMY=; b=e0RveM9RsjTjO+D+6r/Hhmi6eLyRdIY7eKkLu1kJKRchd+ltqM0A9d+DLVUOi4kJpL oBSqeWWbfQaXBzGV3/lRX9tl6Ex+rSFREKCgVNSTefF4KIaJ4ef4uTHz2c7NwgoHeG3e nMH2LlYpKQ5KOAbhz/LWe0QWgC7BcqA6dB5xTP0sj+sHTq9k6cUVQ8FcOIGadd0XCIzt y6PVNJ5ZVP1CyFuTlbQkJz+XiWPIUs9Q+67o4meOZEZDFE+V3tUP42+Og116/oJhnV2D RR0xnOKHYHmYI++KIzrezsc3M0p985N33/mmKZQqMwSXVR/87LctL9KnvNvIZQ/fBH3h OCtQ== X-Gm-Message-State: AHYfb5jPrNh0TiKMlI5sziMx3qBV4sogdF9ZhPvShTdQHPYo/rpC1PDe 1qDsZNuDeZ6T73SeOKWgI5u0ZszSsNEf X-Received: by 10.107.201.150 with SMTP id z144mr3534228iof.132.1502951238524; Wed, 16 Aug 2017 23:27:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 23:26:57 -0700 (PDT) In-Reply-To: <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 15:26:57 +0900 Message-ID: To: DaeYoung KIM Cc: "v6ops@ietf.org WG" , Simon Hobson Content-Type: multipart/alternative; boundary="94eb2c0b951ab06db50556ed1a50" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:27:22 -0000 --94eb2c0b951ab06db50556ed1a50 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 3:17 PM, DaeYoung KIM wrote: > The /64 host in my scenario in fact now behaves as a router and > distributes /96 prefixes to internal devices. E2E connections don't > terminate at the /64 node but at /96 devices. > > > You said that, yes. the host gets a /64. The hosts behind it get a /96 > each. Which means that the hosts behind it have worse connectivity than it > does, because they can't further extend the network (without NAT). > > > I would' mind that. I'm not a manager of s whole site (of /48 typically), > and that's neither my interest nor purview. > > All I'm interested would be whether I could recursively apply the same > mechanism of 'Unique-IPv6-Prefix-per-Host' internally to my node (perhaps a > sophisticated robot or a small IoT island). > Ah, I see. If you're asking whether you can use this technique to hand out a /96 per host, then the answer is no. You can't use this technique because this technique presumes the use of SLAAC, and SLAAC only works with 64-bit prefixes (except for addresses in ::/3, which aren't routable on the Internet). If you're suggesting that SLAAC be changed to support non-64 bit prefixes, that topic is out of scope for this document and this working group. If you're willing to use something other than SLAAC, such as DHCPv6, then all you need is one /64 for your whole network and you can number as many devices as you want. --94eb2c0b951ab06db50556ed1a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 3:17 PM, DaeYoung KIM <dykim6@gmail.com> = wrote:
The /64 host in my scenario in fact= now behaves as a router and distributes /96 prefixes to internal devices. = E2E connections don't terminate at the /64 node but at /96 devices.

You said that, yes. the host gets a /64. The hosts behind it get a /96 = each. Which means that the hosts behind it have worse connectivity than it = does, because they can't further extend the network (without NAT).

I would' mind that. I'm n= ot a manager of s whole site (of /48 typically), and that's neither my = interest nor purview.

All I'm interested would be wh= ether I could recursively apply the same mechanism of 'Unique-IPv6-Pref= ix-per-Host' internally to my node (perhaps a sophisticated robot or a = small IoT island).

Ah, I s= ee. If you're asking whether you can use this technique to hand out a /= 96 per host, then the answer is no. You can't use this technique becaus= e this technique presumes the use of SLAAC, and SLAAC only works with 64-bi= t prefixes (except for addresses in ::/3, which aren't routable on the = Internet).

If you're suggesting that SLAAC be = changed to support non-64 bit prefixes, that topic is out of scope for this= document and this working group.

If you'= ;re willing to use something other than SLAAC, such as DHCPv6, then all you= need is one /64 for your whole network and you can number as many devices = as you want.
--94eb2c0b951ab06db50556ed1a50-- From nobody Wed Aug 16 23:36:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1813267F for ; Wed, 16 Aug 2017 23:36:56 -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 Bo4a7kGC_eQW for ; Wed, 16 Aug 2017 23:36:50 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456021326D7 for ; Wed, 16 Aug 2017 23:36:46 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id t80so2168726pgb.2 for ; Wed, 16 Aug 2017 23:36:46 -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=9qA1YSUZW0JFNodUCAU30wcF35UzHJ3AIhq3pTF05M0=; b=BcOrNel6174VqsQ767ja4yBZ3bPmCkfeTrkPaNl7W661kZAatGcGvCz4a6LFxoKXE8 LSdMANjN4aFQVTKX3pJFqp/mpYi1VcwteP4/XO6EQeNLWO27lrKxMlN80k0Iz0GiNYG0 mvNsSrqZmWQlrqrC28ni6HetWdOE2Ih93itWkhHmScwh9a9xsF16detxGVt4aV+3S6x3 jeBvZm/NosjdMRnA9kQhs3Xx72gAwpc9kxRGO1LtQBb7e2CgP8adUvor2GHhQun7vd/N cTUiULGBQJGzg7qRt6kUkjKj05eNZVGLrPkvrHq4WFaUAzfNAb8arvGrOOUhila9jNYn 5+vQ== 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=9qA1YSUZW0JFNodUCAU30wcF35UzHJ3AIhq3pTF05M0=; b=QKSuthI4dtuz8yA7cLOZJb+iJAYvgM+75qzgwaoSx6OkB2gtE5CJmxSG+jTtlD900e SxkYmbPPR4haiaFZOYGCgYPiuIZzMrUjmwXiXFnTJGO51ojzX8jZGEVLPS51WqNa/x6+ R89Zc6q0gOLF4xcU07T9H2sKexdSatRqKdD6NjG9/47Y5BRX7l92vJ7jn6lgANS4jVeb 787OwPg1JWR6+vKGIgmQNMbPHNK5DuoPPutAx6I32EyLUpB+N2l7TBOwW4wOKec85m1/ lgpsEHY+q5Xf534WA5Haw9dWfT4vip0fLnaMaRCgKwx6m4v08AgtibUVl4tc56N9XAkd Oltw== X-Gm-Message-State: AHYfb5gW2SGv7t93SJiSt3wFG7N+cmqLeGw+nOfGALDyKLMVn0LaLx90 W4IpUT2CikLO3A== X-Received: by 10.99.119.12 with SMTP id s12mr2100263pgc.374.1502951805845; Wed, 16 Aug 2017 23:36:45 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id p10sm4785077pfk.103.2017.08.16.23.36.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 23:36:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 15:36:42 +0900 Cc: Brian E Carpenter , Lorenzo Colitti , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <1EFE4702-B7E2-4672-BAE2-AE1C0200462E@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:36:56 -0000 Sent from my iPhone > On 17 Aug 2017, at 15:02, Mark Smith wrote: >=20 > Hi, >=20 >> On 17 August 2017 at 15:31, DaeYoung KIM wrote: >> Yes, I did. What do I miss? >=20 > It seemed that you might have missed that there are security issues > IIDs with low entropy e.g., the MAC address derived ones, e.g., being > vulnerable to address scanning. Discussions in that privacy doc are mainly based on a typical legacy network= of /64 subsets of an arbitrary size whereas mine example is with a single /= 96 device. On the other hand, I'd be more concerned about the entropy of /64 hosts in a= /48 site. Scanning would be over 2^32 /64 hosts. Back to 32 bits for my device IIDs, if there be insists, I could switch to 4= 8 bit IIDs with /56 prefixes for my internal devices. I remember I read some= where that bits around 40 would secure enough entropy for privacy (or was it= for collision avoidance?). From nobody Wed Aug 16 23:50:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFE132457 for ; Wed, 16 Aug 2017 23:50:01 -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 5Pf2wQp7IIEy for ; Wed, 16 Aug 2017 23:50:00 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00BF126B7E for ; Wed, 16 Aug 2017 23:49:59 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u185so36641776pgb.1 for ; Wed, 16 Aug 2017 23:49: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=zhIKkAh0dbt4DAMmDjgVwNcASgPC+7F1hqBXvoRlaM4=; b=CbuMIjXWmnkLeMnhx7YeTnpzEnQ4XyDeGJgsHAq+cfvtURltAoMp+QE1gUmvFN4pKz f499PXbAGOa7HHZ3DQeCjK6/kwIBDDKUQbOKNoFtQ6AYkrosFEUWClm1qQPPjzJpHUir Pc0QNVIJKkalIEw4vQrgeJ7wuffT1ikKDCQXctpHLyh/qqyL+g8rVtesYpe7BEpKGIII OdbZPZ381jqRHvnlAC9OBZsrLW7TH+AtVka10cN44vOZK8cAyWFuUDdJJNiv3b0DT8SD xD+CZY+2DughBARlsQG67SrqTMiGeHrval3/x8PFE4gG70nAQPTnkXqjJWFjhn5cgHu0 +DIQ== 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=zhIKkAh0dbt4DAMmDjgVwNcASgPC+7F1hqBXvoRlaM4=; b=R4Z3weLVHnASDjMF+GG27HWpV6M2kthyxUcCpEdunYwt+uzCnfJZA/vHlw41LDsXh6 6HM7FNm4GEDCwwZLj0QXrLn0zvhq1tBIZUHrrAT+CEjVySiHEREWadv3VLa0DADlyMn8 3FbhupoJL0iehgmWGzOpzl4g7FyN39teOeof7gJm9C1GORvmQvfKguMpqOoHGNLCM4Ez cmVtUOcB5UGSrlFrhAumTtVDe/cH2/FBmFjCmY38Y/lkh/uYAlYvCP7vRl5696tHVz+b fbcxYeDd2fIKqpUuCXWFSFk91f6XtLcJhq7K7/DDEDLRerdqX/lXfPHjri/xBYjI+SLS mHOA== X-Gm-Message-State: AHYfb5giSNRtnPQ24a5F7AsxbT9D0umocbhWy37bPP4frKUhMlmQgZa9 tmrOY+8q35M8Kw== X-Received: by 10.84.215.205 with SMTP id g13mr4705350plj.8.1502952598113; Wed, 16 Aug 2017 23:49:58 -0700 (PDT) Received: from [100.68.118.228] ([39.7.58.87]) by smtp.gmail.com with ESMTPSA id h14sm5457965pgn.34.2017.08.16.23.49.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 23:49:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: DaeYoung KIM X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 17 Aug 2017 15:49:53 +0900 Cc: "v6ops@ietf.org WG" , Simon Hobson Content-Transfer-Encoding: quoted-printable Message-Id: <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> To: Lorenzo Colitti Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 06:50:01 -0000 Sent from my iPhone > Ah, I see. If you're asking whether you can use this technique to hand out= a /96 per host, then the answer is no. You can't use this technique because= this technique presumes the use of SLAAC, and SLAAC only works with 64-bit p= refixes (except for addresses in ::/3, which aren't routable on the Internet= ). >=20 > If you're suggesting that SLAAC be changed to support non-64 bit prefixes,= that topic is out of scope for this document and this working group As I know, SLAAC by itself doesn't impose restrictions on the IID length. It= 's Addr Arch (4291bis) that imposes it. Then, are all deployed SLLAC software hard-coded to 64 bits? If properly imp= lemented, the IID length should remain a parameter that can be set by an adm= in. Should the latter be the case, my life would get easiest. > If you're willing to use something other than SLAAC, such as DHCPv6, then a= ll you need is one /64 for your whole network and you can number as many dev= ices as you want. If not for SLAAC, this would certainly be my last option.= From nobody Thu Aug 17 00:00:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4755D13235E for ; Thu, 17 Aug 2017 00:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlPTIp5NirPu for ; Thu, 17 Aug 2017 00:00:00 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 4BBAB124BAC for ; Thu, 17 Aug 2017 00:00:00 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id c74so20301645iod.4 for ; Thu, 17 Aug 2017 00:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vzub0v8YBMWIjUA+TrIWwFKjm6JnPjsHE4pv3SbfrV0=; b=s0nf+h0bkXCpRRemS9/UNkv4Z256YQsBWpUmgn1/WR6JMYw9INBUWXlPr3WJGLzPzh zHd+euEuV3zB47GeBS0ZUAqyS0sj9oY5HYY63m1Bt4chZLeLxX3BTFVXzkAq+WmeYUr4 k2npAeagpteqB4CPOsmyrNA9eNqXAARw/jT37f1MK4SLG5yOI2wYN27h6YK34Jow4Y9o 278JcY0w/7poDb4CyptTm3HypzYnPFU/Dmi3pHCPmDrXMxIp2JX9FI1ZpgkMTvpRQT9H LIDW2G0E7dmbzTo/tDz1eUxM2P1NlNGyyHARoPy1VFMDTLxlyfU0JwCR1AkUxGtS/V9O ghbw== 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=Vzub0v8YBMWIjUA+TrIWwFKjm6JnPjsHE4pv3SbfrV0=; b=BqAPlsLSgAgbp+TcmManhJ2zFONZ2+RptRGWfeG1E3LNUZKmNv97bqPypQJk9FjThJ Z92ZrQkwWYp5iUc1Guf6C/AHWoneOYaz4AF+nx59q2QN2Q9Zjq2ss968Km31GzQEmXYu qURHjrFAILglxYwRExB/NtI2BXLaJKC4dTl871ReKvVB3bhEBHpgu9El/ou3uZOhePMa jTQoRW+sFpr5Zjv68gNGmiB+42Dr/egoh+WVPh93qXcloFfqe6NWsr+ur9zhx6pu2wV6 A7AjkoSuqr/xmjs4Lm+ZZV0QpE6r55OitHqzq+ysNytMuAtRcsbYHmbeACmdrF1TEU7T 51rQ== X-Gm-Message-State: AHYfb5i+4COHP3KFJMNaxBwK4v2PFNL8jpnZoWS/aRfjF71JMS7C5fTr qn91FMTtOCEsbpWVqO+Q3nyKTybDAmqK X-Received: by 10.107.201.150 with SMTP id z144mr3586744iof.132.1502953199361; Wed, 16 Aug 2017 23:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 23:59:38 -0700 (PDT) In-Reply-To: <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Aug 2017 15:59:38 +0900 Message-ID: To: DaeYoung KIM Cc: "v6ops@ietf.org WG" , Simon Hobson Content-Type: multipart/alternative; boundary="94eb2c0b951a9038300556ed8f10" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:00:02 -0000 --94eb2c0b951a9038300556ed8f10 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 3:49 PM, DaeYoung KIM wrote: > > Ah, I see. If you're asking whether you can use this technique to hand > out a /96 per host, then the answer is no. You can't use this technique > because this technique presumes the use of SLAAC, and SLAAC only works with > 64-bit prefixes (except for addresses in ::/3, which aren't routable on the > Internet). > > > > If you're suggesting that SLAAC be changed to support non-64 bit > prefixes, that topic is out of scope for this document and this working > group > > As I know, SLAAC by itself doesn't impose restrictions on the IID length. > It's Addr Arch (4291bis) that imposes it. > > Then, are all deployed SLLAC software hard-coded to 64 bits? If properly > implemented, the IID length should remain a parameter that can be set by an > admin. > > Should the latter be the case, my life would get easiest. > Again, that topic is out of scope for this document and this working group. --94eb2c0b951a9038300556ed8f10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 3:49 PM, DaeYoung KIM <dykim6@gmail.com> = wrote:
> Ah, I see. I= f you're asking whether you can use this technique to hand out a /96 pe= r host, then the answer is no. You can't use this technique because thi= s technique presumes the use of SLAAC, and SLAAC only works with 64-bit pre= fixes (except for addresses in ::/3, which aren't routable on the Inter= net).
>
> If you're suggesting that SLAAC be changed to support non-64 bit p= refixes, that topic is out of scope for this document and this working grou= p

As I know, SLAAC by itself doesn't impose restrictions on the II= D length. It's Addr Arch (4291bis) that imposes it.

Then, are all deployed SLLAC software hard-coded to 64 bits? If properly im= plemented, the IID length should remain a parameter that can be set by an a= dmin.

Should the latter be the case, my life would get easiest.
<= div>
Again, that topic is out of scope for this document and = this working group.
--94eb2c0b951a9038300556ed8f10-- From nobody Thu Aug 17 00:05:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA621326F7 for ; Thu, 17 Aug 2017 00:05:09 -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 odJnDHiKFyVf for ; Thu, 17 Aug 2017 00:05:08 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 5034D124BAC for ; Thu, 17 Aug 2017 00:05:07 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 5so9228657wrz.5 for ; Thu, 17 Aug 2017 00:05:07 -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=QtiGQEvZE3mcDuSDJoqU0z86IvnyYy6gVkQKX+w0HLY=; b=rl0bAiC1qsGOI1W5MTV/BCwSv9rMP8hoi+YbMYJC49BFYonBMCbP/xL5GWcFQa0hto bY5/o4vV/B83XHHLI94A+xjbrgSue8OFW3ZdD0FmE+PPXzFS5aPd3tlB9rqATqrvEPg6 EcK7zE6ywpNF8lgMo6Ut/+WKRwcHtmoDZ16HJFYa0arplnpbAfHnLMqPoKtIKp9kdQlU 4ZKEC/yrHe3f10LV20YPcxeZ5YwjTPmbva3NXvn9YLg38PRZKwDAz88CdSF1cmNxteTz ekfpXF6u8GQJbYoioDyn7ufEh9EZRxilXMrgUPciowFd4uGL/KFADoACrkLz5bTmm7Ae fyrg== 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=QtiGQEvZE3mcDuSDJoqU0z86IvnyYy6gVkQKX+w0HLY=; b=rbJXUy/MLhelCRn79WZIrTXzH7DuJ64SYeebusiZmMsp89jC4jiG63T5iHolgXJtDY VUOd0udrSfrjap5Fmb80itSKPmGeuIRohU6SrhKdDtMJGNKXVb+CqhJShCfr43pdAmBb 6g51eqRlEYuQDfA2GOaQtWSh0uGYj2h8luOYEe2SbpELu7o+dPYeiMdHYNdCihm+8bkU 8q/g/y1ly8N1e3YXzKcWDIhr6mgQhpBlNULG9fwr1s0CFFgOqyy5KeYyiEz/Rjl8qIkq 6Xz+uUowitQ+mlZOxlcZHozKvugYBSE5/2mPRlJTXN1rKMRNpiR72klELZyW31pn+r8v h78g== X-Gm-Message-State: AHYfb5gSP97UZcL9QpLcliulHFZOlHOPH6nwiYRKsej+JJ3ZGfFm/Cfm ycXVtGvUKBy7PaPW3cLproYditfcEQ== X-Received: by 10.28.165.145 with SMTP id o139mr184150wme.49.1502953505845; Thu, 17 Aug 2017 00:05:05 -0700 (PDT) MIME-Version: 1.0 References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> In-Reply-To: From: DY Kim Date: Thu, 17 Aug 2017 07:04:53 +0000 Message-ID: To: Lorenzo Colitti Cc: Simon Hobson , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114b4108d478c70556eda1b8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:05:09 -0000 --001a114b4108d478c70556eda1b8 Content-Type: text/plain; charset="UTF-8" On Thu, 17 Aug 2017 at 16:00 Lorenzo Colitti wrote: Again, that topic is out of scope for this document and this working group. > Suffices to know at this moment that I could recursively apply the mechanism to my /64 node, albeit perhaps not with SLAAC. -- ---- DY --001a114b4108d478c70556eda1b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, 17 Aug 2017 at 16:00 Loren= zo Colitti <lorenzo@google.com= > wrote:

Again, tha= t topic is out of scope for this document and this working group.
Suffices to know at this moment = that I could recursively apply the mechanism to my /64 node, albeit perhaps= not with SLAAC.
--
----
DY
--001a114b4108d478c70556eda1b8-- From nobody Thu Aug 17 00:36:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61461327EB for ; Thu, 17 Aug 2017 00:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wbp8CxXV2kYm for ; Thu, 17 Aug 2017 00:36:48 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5AD132436 for ; Thu, 17 Aug 2017 00:36:48 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 540AE2D4FD1; Thu, 17 Aug 2017 07:36:45 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 356AFF8FF3DD; Thu, 17 Aug 2017 09:36:44 +0200 (CEST) From: Ole Troan Message-Id: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_108A4CBD-5F2A-4A23-9F56-7804BBD61BF0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 09:36:43 +0200 In-Reply-To: Cc: v6ops list To: Simon Hobson References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:36:51 -0000 --Apple-Mail=_108A4CBD-5F2A-4A23-9F56-7804BBD61BF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simson, >> /64 gives you something that no longer prefix does: the ability to = run SLAAC and connect unlimited devices behind the host. >=20 > =46rom previous discussions, I am led to believe that SLAAC will work = with other (longer or shorter) prefixes. It is only the deprecated EUI64 = method that *needs* 64 bits. That's not quite correct, at least not in a historical context. While the term "Modified EUI-64" was most commonly derived from a MAC = address it was also used for interface identifiers derived by any other = means. Be it serial numbers, random tokens or manually configured. By = that definition an interface-id generated with the method in 7217 is = still a Modified EUI-64. With regards to your "will work" comment. Sure, it is just software, we = can make anything work. I am not aware of any implementation supporting that though. Certainly = the ones I am involved with do not. Someone pointed me at this paper which is quite relevant for this = discussion. = https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/State-= the-Problem-Before-Describing-the-Solution.pdf Best regards, Ole --Apple-Mail=_108A4CBD-5F2A-4A23-9F56-7804BBD61BF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZlUeLAAoJEL7aWKiYQt921qMQAJiWuEAXYPuBJychGnbZPw3s TgiDOn9GNr5Ayx91wPfoohaedM6+HPLmeU6XB+ocvDQJDZsEHRt8qB10dMmkqfnG N1qv9PRAe69IHCnaCEdZqIhpKNC46ddi0u3T8Zysn0qBmCmG+1UBUSZqTBRI2zUQ b+NH7P7ijYdbsvsQVK1f5ELq+nHssYhfzjQ4lSF6nYH9zq4NyIXoFsM1VAnZMM9x 1+6nTUDMLV+qDisLU77MOJ7T7hXTRsUn0O7eZlP8VDbaWHpo0SncIg+WNca3mQLA 4lQmU3Lc6sn5vO7Qk2yd8UYntSbXJOWpscoXfwx7BrwpxhDXS2n8gj6plMS/IqQU rX5b5QNkL2S0EGNovo+0ahjNSLtWfCpcMQGV6QJLcSmzLLGI4CDDZMF/w+6Jfcy0 kx7cDZc+4lVJrJHdLhyPc39D/4yk5iNXkEEYAgkvNk3k3b+nZ0clgFA0bCuCsOxc QmzUT5Liw4JCTAhFOT1Qj3z733Fv3DtFdZ4snIPXK7KfXkoWuquXhP46kVg+4nC+ b4Vb5H3y2SNMKg2xORzE0R3pQJ8fTi1Zi7XYNQqMq1HxH727AFE10UKKr4ILM5wJ RAok0b0lyJJOBNJ0UaY41g+NkyT0pwoRKeqfIQzYKoiIQaerL/95hp/p5Vua/ZkP tMpzz3af2MLjGsRbKkgI =AOo+ -----END PGP SIGNATURE----- --Apple-Mail=_108A4CBD-5F2A-4A23-9F56-7804BBD61BF0-- From nobody Thu Aug 17 00:37:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D21327FF for ; Thu, 17 Aug 2017 00:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7JkdTl1jd5hA for ; Thu, 17 Aug 2017 00:37:48 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C759C132436 for ; Thu, 17 Aug 2017 00:37:48 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4C0A02D4FD7; Thu, 17 Aug 2017 07:37:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 30986F8FF53F; Thu, 17 Aug 2017 09:37:50 +0200 (CEST) From: Ole Troan Message-Id: <33706CF4-26EC-4C30-98AD-8939C9CA9DB6@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_BBA4662A-AA89-44B5-BAB7-A785A9567BE8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 09:37:49 +0200 In-Reply-To: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> Cc: v6ops list To: Simon Hobson References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:37:50 -0000 --Apple-Mail=_BBA4662A-AA89-44B5-BAB7-A785A9567BE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Simson, Stumbling fingers, apologies, that should of course be "Simon". /ot >=20 >>> /64 gives you something that no longer prefix does: the ability to = run SLAAC and connect unlimited devices behind the host. >>=20 >> =46rom previous discussions, I am led to believe that SLAAC will work = with other (longer or shorter) prefixes. It is only the deprecated EUI64 = method that *needs* 64 bits. >=20 > That's not quite correct, at least not in a historical context. > While the term "Modified EUI-64" was most commonly derived from a MAC = address it was also used for interface identifiers derived by any other = means. Be it serial numbers, random tokens or manually configured. By = that definition an interface-id generated with the method in 7217 is = still a Modified EUI-64. >=20 > With regards to your "will work" comment. Sure, it is just software, = we can make anything work. > I am not aware of any implementation supporting that though. Certainly = the ones I am involved with do not. >=20 > Someone pointed me at this paper which is quite relevant for this = discussion. > = https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/State-= the-Problem-Before-Describing-the-Solution.pdf >=20 > Best regards, > Ole >=20 --Apple-Mail=_BBA4662A-AA89-44B5-BAB7-A785A9567BE8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZlUfOAAoJEL7aWKiYQt92ZuQQAJGBzFpnKm0/c6QtVY+/ycnF qXMUp8ArdiKdDaqzHXsYaHTwBPEFfNszm4OMs+svGJ9x3OFdm/ghhjlW39/4c8DL iC9lbLyA6trTujLk3yNyucbxqZOirzVgQfzPPuxiqzA6pGwqbWJZfdrrQ9fbYKjr 1jqx4A1zFd24wrC6L4BlsYEKs6GNJt/D56SWWJInvg+HM5vOTbAbigJBy2ZhYh2N Oj9rxvylZtqm+0MXI55kDoiwT4MmkTlrJaUcl2KCVdazA9mbjAgRhMR8sPdBeDys bVcH/Bc7k1T00SFNOaHv1KLrM+gn7wSiHHwtotBGZu4xtxavDvtHIufmybI+QQcO 6Q82DhH6S1o01AM1VhZKWOEvQoBDgknyIWCnVQVv0X02mdDrz3ON+oNpDofcMQQO +pf1k6ywJBSekH9dDitpW0glU4fqG26jdh1U6lYscddrY5h6JIV2qO6ATNXV2oT+ cASuYL9ZFBmQkLXNccx+AfzoT7LigUGzDBPt17qSydIAvZekbW1D6lN5qgw7TQU1 h0kQH3/Z7+O9JlNsRLi7Y5gEmH3jseVWvS4jO23CkcvxbEXlsu5gupCWbZf44Zct Y9PdKPOcZeDObkU/pAVhJQVdtIxVTnduN8OrvhTBQMz1FZq8BU6ze6+FM50kbcNA HVlj4G0e6sm3+TnfVL1b =F2PE -----END PGP SIGNATURE----- --Apple-Mail=_BBA4662A-AA89-44B5-BAB7-A785A9567BE8-- From nobody Thu Aug 17 00:43:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C749132815 for ; Thu, 17 Aug 2017 00:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YBWoDHetOIH for ; Thu, 17 Aug 2017 00:42:57 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9254B132719 for ; Thu, 17 Aug 2017 00:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1502955775; x=1503560575; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=HfdV1Xx2VJr55nWTKSlzZrzyT E+9if3xgOzPkPvQmW0=; b=t2KfAliGDCHg5Knu0PKnAszxBJvQI83G/X0WJ8k9P HP2ZbmRcefW+MyL2w92kIfNZpGMN/cJVuTv9K4UkiVtdN7D4SmrVc/lMpgyJirnJ DGZUVvHokQFbI63FqCXTobKQ3vaXXIHwIH1FEUFFop++OkDkMWYcYoobg/oyhGCn YE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=E7wr0hCQ7uK7oGs/nVBkiRt9ZdbDR6QXbI0t4+La5gb8bn1zCOYhTNcl6mVc 7lerT5GtzkfH7JfHWuKQYL528HTf3ImQBhDAGbV4lqmclyU6X5mRUmxHi tGVZUY8ql2wOi5qjmS9vATxBLkZec5MKAyT6KkbYoY2Pr62MgORu7E=; X-MDAV-Processed: mail.consulintel.es, Thu, 17 Aug 2017 09:42:55 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 17 Aug 2017 09:42:54 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005508814.msg for ; Thu, 17 Aug 2017 09:42:52 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170817:md50005508814::B5K7/rFOBFjGGteC:000006US X-Return-Path: prvs=140296a35d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Thu, 17 Aug 2017 09:42:52 +0200 From: JORDI PALET MARTINEZ To: "sunset4@ietf.org" , Message-ID: <017613CE-A9E0-4B2E-B84A-F76C8B3A4201@consulintel.es> Thread-Topic: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> In-Reply-To: <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:43:00 -0000 My initial perspective on this, and that=E2=80=99s why I think it can be pa= rt of the 7084-transtition document, is that it only makes sense if it can = be done by means of a transition mechanism in the CE, so not requiring an e= xisting operator to deploy anything new. For example, let=E2=80=99s assume an operator has already NAT64, deployed d= uring the transition from an IPv4-only network to an IPv6-only one. They de= ployed a few NAT64 and DNS64 boxes, together with CEs that were configured = for doing 464XLAT. Now after a few years, they can probably have =E2=80=9Cless=E2=80=9D NAT64 = boxes, as there is less and less IPv4 traffic, however, new customers in th= e network (may be coming from IPv4-only operators), still require some IPv4= service. So, if the operator kept =E2=80=9Csome=E2=80=9D NAT64 boxes, they= can still offer =E2=80=9Con-demand=E2=80=9D IPv4, because the CLAT in the = CE is automatically taking care of this. I=E2=80=99m not actually sure (need to work on that), if there is =E2=80=9C= anything=E2=80=9D new to add to my existing document, or just some text to = clarify that this sort outs problems documented in draft-ietf-sunset4-gapan= alysis. Saludos, Jordi =20 -----Mensaje original----- De: Fred Baker Responder a: Fecha: jueves, 17 de agosto de 2017, 1:30 Para: JORDI PALET MARTINEZ CC: "sunset4@ietf.org" , Asunto: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09= .txt Hatless... =20 The question I would ask is whether on-demand IPv4 makes sense. To my w= ay of thinking, it amounts to deploying a new kind of network. We are askin= g people to deploy IPv6 in their IPv4 networks, or to deploy IPv6-only netw= orks. That requires some portion of the money and time they have available = for such issues. Deploying an IPv4-on-demand network is another thing compe= ting for those same resources - it doesn't create new resources or reduce t= he matters pertaining to IPv6 deployment - it creates another demand for th= e same resources. I don't see the point. =20 I suspect that the network actually routes IPv4 no matter what; what is= being handed out on demand is an IPv4 address to an edge device. Hosts rig= ht now get IPv4 (and IPv6) addresses when they don't need them so they can = use them when they do. They would need a different mode of operation, perha= ps triggered by the resolver noticing that an application wants to access s= ome name and the name only has an A record. In that mode of operation, the = host only asks for (DHCP) an IPv4 address when it needs it, and routing in = the network is to the granted address for the lifetime of the address. =20 Do I believe we can describe and solve that? Yes. Do I think we can do = it more cheaply and simply than moving folks and their applications to IPv6= , and convince operators to change their operational practices accordingly?= Not even close. I think it is a diversion from IPv6 deployment. =20 > On Aug 16, 2017, at 2:08 PM, JORDI PALET MARTINEZ wrote: >=20 > (copying v6ops) >=20 > Forgot something here regarding: >=20 > 4. Write a guidance document for IPv4-on-demand, covering problems 10= -14. >=20 > I think this can be done in draft-palet-v6ops-rfc7084-bis-transition-= 00, which I plan to review next week (in this case I believe it belongs to = v6ops), otherwise, I will draft something else (need to identify then if v6= ops, sunset4 or some other WG). >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: sunset4 en nombre de Lee Howard > Responder a: > Fecha: mi=C3=A9rcoles, 16 de agosto de 2017, 18:27 > Para: "Liushucheng (Will Liu)" , "sunset4@iet= f.org" > Asunto: Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.t= xt >=20 > I admit, it=E2=80=99s been a long time since I=E2=80=99ve read thi= s draft. >=20 > One capability gap we still have: there=E2=80=99s no IPv6 version = of FlowSpec. > There is an idr WG draft, but it hasn=E2=80=99t had a lot of discu= ssion in recent > months:=20 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-flow-spec-v6-= 08 >=20 > Review of the gap-analysis draft: (summary at the bottom) > There are 16 specific problems identified. Some solutions are prop= osed in > Annex A; I=E2=80=99d rather see those incorporated into the text. >=20 > Can problems 1-5 (indicating that IPv4 is unavailable, disabling I= Pv4 in > the LAN) be addressed with recommendations in any, some, or all of= : > draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers" > draft-ietf-v6ops-rfc7084-bis-04 =E2=80=9CBasic Requirements for I= Pv6 Customer > Edge Routers" >=20 > Or other drafts under discussion in v6ops now? > Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable (= as in > A.1.1 and A.1.2)? >=20 > Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed wi= th > draft-ietf-v6ops-rfc6555bis-03, "Happy Eyeballs Version 2: Better > Connectivity Using Concurrency=E2=80=9D? >=20 >=20 >=20 > Problems 8 and 9 are about surprises when IPv4 support is removed = from the > kernel. I remember reading about this several years ago; should we= have a > hackathon to repeat the experiment? >=20 > I=E2=80=99m not very clear on the IPv4-on-demand scenario describe= d in Section 6 > (and I don=E2=80=99t understand the solution in A.4). But we shoul= d probably write > a guidance document on how to handle problems 10-14, don=E2=80=99t= you think? > Anyone want to volunteer for that? > Could Problem 10 be addressed in Happy Eyeballs v2, rfc6555bis? >=20 > Problem 15 (IPv4 address literals) is mitigated with most transiti= on > technologies, isn=E2=80=99t it? Not NAT64 (requiring DNS64), but 4= 64xlat, DS-Lite, > MAP. >=20 > I like the solutions proposed for Problem 16 (Router IDs): Just pi= ck a > 32-bit number and use it as the last 32 bits of the IPv6 address. = If you > try, you could use it in multiple prefixes on the same router, inc= luding > Loopback, Link Local, and even GUAs. I=E2=80=99m not entirely sure= this problem > qualifies as a gap, so much as an operational consideration. >=20 >=20 > Summary of proposed actions: > 1. Ask authors of draft-ietf-v6ops-ipv6rtr-reqs-00 and > draft-ietf-v6ops-rfc7084-bis-04 to consider whether they can resp= ond to > problems 1-5. > 2. Confirm that problems 6-7 are resolved in rfc6555bis, and ask w= hether > problem 10 can be. > 3. Hackathon removing IPv6 support from the kernel. If it=E2=80=99= s an IETF > Hackathon, need a Champion who is comfortable hacking the kernel. = Would be > great to include people from Windows, Apple, Android. > 4. Write a guidance document for IPv4-on-demand, covering problems= 10-14. >=20 >=20 > I will do the first two things. > Do people agree with the other two things? Anyone want to voluntee= r? >=20 > Lee >=20 >=20 >=20 >=20 > On 8/3/17, 7:08 AM, "sunset4 on behalf of Liushucheng (Will Liu)" > wro= te: >=20 >> Hi all, >>=20 >> We've updated the draft according to the comments we received online= and >> offline. Please take a look and let us know your thought. >>=20 >> Thanks! >>=20 >> Will >>=20 >> -----Original Message----- >> From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Tuesday, August 01, 2017 7:32 PM >> To: i-d-announce@ietf.org >> Cc: sunset4@ietf.org >> Subject: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Sunsetting IPv4 WG of the IETF. >>=20 >> Title : Gap Analysis for IPv4 Sunset >> Authors : Will(Shucheng) Liu >> Weiping Xu >> Cathy Zhou >> Tina Tsou >> Simon Perreault >> Peng Fan >> Rong Gu >> Chongfeng Xie >> Ying Cheng >> Filename : draft-ietf-sunset4-gapanalysis-09.txt >> Pages : 11 >> Date : 2017-08-01 >>=20 >> Abstract: >> Sunsetting IPv4 refers to the process of turning off IPv4 >> definitively. It can be seen as the final phase of the transition = to >> IPv6. This memo enumerates difficulties arising when sunsetting >> IPv4, and identifies the gaps requiring additional work. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sunset4-gapanalysis/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09 >> https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-gapanalysis= -09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sunset4-gapanalysis-0= 9 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 >=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informa= tion, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Aug 17 00:55:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94029132813 for ; Thu, 17 Aug 2017 00:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qOaTZiBOOIa1 for ; Thu, 17 Aug 2017 00:55:22 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3821326E8 for ; Thu, 17 Aug 2017 00:55:21 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id j32so20671516iod.0 for ; Thu, 17 Aug 2017 00:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=zFgiaikx57a8+fin2aayqcyc5ADKGFfYWXo2GLdVmcM=; b=SNfD2Qo4g09W9vvP0v5uN2LzswLzkwbmrrY2xwQ0iuanCOhmbdzm9bS1RclXZ+Bf2u T9aGZeijQPZsWwmDLgZ/IPDfXk4SJvHl9RApby2NFw2RwTDz0BmrTRIpdUKVDlBFqP4a NDuYFasf20cYnwstyiSRPBI7uPTE0vUnagftEtwTta78TzAPYH08CTRg7NIgIdY/njH7 ZD2xIgoIdYPTFwU146gwmIDHV6CXhogybK1HDzSdxY4g4mLrnglP04uWDFvLdSau+vM5 vpHbeFMNYhylsUL4gU4arVNSQM8o72yPe60M24J2/S3itLoeYnBQF66XytI5QFF8wE3z DDSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zFgiaikx57a8+fin2aayqcyc5ADKGFfYWXo2GLdVmcM=; b=jqeDN+K3AoRLFEPQNP6T6r8ZMX6ayN4BdU9VutfW4F0pzBEs5RayWySPC4CMc+9kZ6 TVTzDONfnVSa1WDTRbugvurACV5hHLRVFPhSm7vxUmGL22o4PLPrRyazWFRrPdoH5DQB hiwYNeGsOsnLUn7WrIRGnhUik7u5bgP2vaU7Y1hsPnzRTBoSzjmnU0uWW9Eo8Fk3SmdL OQC3K7nR3LPGk66LPQaIn0n37YkJ+hgosSy2Bfz+YRCohS1aGI93v0VBGjrrGbmPlgxf VO76bIfKwoa4hothCwIB//Ue8yEJQHeY7lRrlET0XJxNGZx5whEjYw0BDoxbKwzTaBmF 4Qlg== X-Gm-Message-State: AHYfb5ggHZoUgHFHs7PH32ZeVoYOYYhgkowWgnlKVvveJA1wL/A00IRs 1c1OJz1EayEqaYbLwE28Vmoi9RVIsrs3 X-Received: by 10.107.201.150 with SMTP id z144mr3682739iof.132.1502956520871; Thu, 17 Aug 2017 00:55:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 17 Aug 2017 00:54:59 -0700 (PDT) From: Lorenzo Colitti Date: Thu, 17 Aug 2017 16:54:59 +0900 Message-ID: To: Ole Troan Cc: Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="94eb2c0b951a8aabe00556ee55bf" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 07:55:24 -0000 --94eb2c0b951a8aabe00556ee55bf Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 4:36 PM, Ole Troan wrote: > I am not aware of any implementation supporting that though. Certainly the > ones I am involved with do not. > The Linux implementation only does SLAAC on 64-bit prefixes. That is the correct behaviour, since that's what it says in RFC 4291. --94eb2c0b951a8aabe00556ee55bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 4:36 PM, Ole Troan <otroan@employees.org> wrote:
I am not aware of any impleme= ntation supporting that though. Certainly the ones I am involved with do no= t.

The Linux implementation only does S= LAAC on 64-bit prefixes. That is the correct behaviour, since that's wh= at it says in RFC 4291.
--94eb2c0b951a8aabe00556ee55bf-- From nobody Thu Aug 17 01:54:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED81321A8 for ; Thu, 17 Aug 2017 01:54:04 -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 zZtb3JfX6zHB for ; Thu, 17 Aug 2017 01:54:01 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 DB71F132420 for ; Thu, 17 Aug 2017 01:54:01 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id t80so2694696pgb.2 for ; Thu, 17 Aug 2017 01:54:01 -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=IlN8bA1An+e2Tdwfie8FgbdJ8B/b5x1CEo6j4J8i+ns=; b=Z+4jJWx6Dn3b42WHqxOEoKH8uktqTg+bAyom8vqIo4Ytb8Q9DDHOTXO511UmRkSQ2G CtOGG7AV1DKEGt6a3bzdksna7tkFhTHEpNj5kFcB2V1dEuELSEbxyMRfULZIzf0YEn0z hnKX9ZzXtz620iMywdvQcbK1QbXRS9uU49SsXIHa7DXcNjMLuu+uEE0qzvuP85mBrd6z kxX9KDxFe/djthPdgnCPssxcDarAs2IcGRboIa/4kImgN3877LQpQzB6pYeaHhV5cI4k Ppqz69/k2/f48FKkWrX8MOHlp0lCf9Iy/6rhI0UXQegKbEGcnaWz5LISufdqS5opIHyn 4EoA== 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=IlN8bA1An+e2Tdwfie8FgbdJ8B/b5x1CEo6j4J8i+ns=; b=bbR8HmZjaEGNXPV9s9AHj0xiF6kmZnsE6iuUmqrtCJf0TQUBM+amttjCpAEmIcEcuG wz75CCia6o34S+fiAXZFLihbQd7xhOtNlO9HLSE2FEtjbYMjb4FSUgs7W75GsW87TDHs RFoBxm577puYtU6bjyBZwxLuJbfSGG8NEo9q5NPqvAnlzNoc00Dsw6TC0K3wvHiFgHby HtJEkc6Tc6tgpChaAPqpMlUpYu3WG4y87qpAZC0jvHF8iMZwYK1YsKRzb5VUrxEy4UTB rsy4c91j1QMUqzFN380ttbqYi6ooh87I7THwDbsNQydFBQD3Xc5MKO+40xAvgfHDkz/q l0mQ== X-Gm-Message-State: AHYfb5jQTuF1dv6qzxOXICnF8wlOt9fb9y9iFCn0bdfJSaadJmJw9GUN bH/CTth4UCbQNg== X-Received: by 10.99.154.26 with SMTP id o26mr4272707pge.136.1502960041495; Thu, 17 Aug 2017 01:54:01 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id l2sm4868845pgc.27.2017.08.17.01.53.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 01:53:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> Date: Thu, 17 Aug 2017 17:53:56 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 08:54:04 -0000 I=E2=80=99d hope I=E2=80=99m not bothering busy people too much, but let = me recall the history as I remember: o 128 bits decided for the IPv6 address length, part of which being = prefix, part IID. o The next question arose about how to configure the addresses. o People noticed that 128 bits are large enough to hold the whole 802 = MAC addresses. o Soon, they also realized the length of the 802 MAC addresses are = going to be extended to 64 bits. o Each host interface would be associated with, typically, a 802 MAC, = so it should be the most convenient choice to identify an interface. o This then led to the possibility that the address can be = auto-configured once the hosts are given subnet prefixes, i.e., 64-bit = subnet prefix and 64-bit IID. o The practice has been over 20 years. o By now, IIDs are not to be configured with MAC addresses anymore, but = with (hashed) random numbers to provide privacy. o Hence, the historical link of the IID to the MAC address is now = broken, and so its link to 64 bits. Apparently, IID is now free from 64 = bits. o And yet, people would now pick the fallen broken branch of 64 bits, = and try to graft it back to the trunk IID. o As the history started out 20 years ago, the IID would be the master = and the 64-bit would be the slave. Now, the history is about to go = upside down so that the roles are overturned; the 64-bit is now the = master and the IID would be the slave. This flow of history looks a bit funny to me, I=E2=80=99m afraid. --- DY > On 17 Aug 2017, at 16:36, Ole Troan wrote: >=20 > That's not quite correct, at least not in a historical context. From nobody Thu Aug 17 01:58:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFDB1321A8 for ; Thu, 17 Aug 2017 01:58:49 -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 aHsO5WsGlfnA for ; Thu, 17 Aug 2017 01:58:46 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65CE132518 for ; Thu, 17 Aug 2017 01:58:45 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 1C5152D4FA1; Thu, 17 Aug 2017 08:58:44 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 922F6F9156CF; Thu, 17 Aug 2017 10:58:41 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7C44F362-77E5-4FB7-A91F-31026DF4B1B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 10:58:40 +0200 In-Reply-To: Cc: Simon Hobson , v6ops list To: DY Kim References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 08:58:49 -0000 --Apple-Mail=_7C44F362-77E5-4FB7-A91F-31026DF4B1B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Have you read RFC7421? What problem are you trying to solve? Ole > On 17 Aug 2017, at 10:53, DY Kim wrote: >=20 > I=E2=80=99d hope I=E2=80=99m not bothering busy people too much, but = let me recall the history as I remember: >=20 > o 128 bits decided for the IPv6 address length, part of which being = prefix, part IID. >=20 > o The next question arose about how to configure the addresses. >=20 > o People noticed that 128 bits are large enough to hold the whole 802 = MAC addresses. >=20 > o Soon, they also realized the length of the 802 MAC addresses are = going to be extended to 64 bits. >=20 > o Each host interface would be associated with, typically, a 802 MAC, = so it should be the most convenient choice to identify an interface. >=20 > o This then led to the possibility that the address can be = auto-configured once the hosts are given subnet prefixes, i.e., 64-bit = subnet prefix and 64-bit IID. >=20 > o The practice has been over 20 years. >=20 > o By now, IIDs are not to be configured with MAC addresses anymore, = but with (hashed) random numbers to provide privacy. >=20 > o Hence, the historical link of the IID to the MAC address is now = broken, and so its link to 64 bits. Apparently, IID is now free from 64 = bits. >=20 > o And yet, people would now pick the fallen broken branch of 64 bits, = and try to graft it back to the trunk IID. >=20 > o As the history started out 20 years ago, the IID would be the master = and the 64-bit would be the slave. Now, the history is about to go = upside down so that the roles are overturned; the 64-bit is now the = master and the IID would be the slave. >=20 > This flow of history looks a bit funny to me, I=E2=80=99m afraid. >=20 > --- > DY >=20 >=20 >> On 17 Aug 2017, at 16:36, Ole Troan wrote: >>=20 >> That's not quite correct, at least not in a historical context. >=20 --Apple-Mail=_7C44F362-77E5-4FB7-A91F-31026DF4B1B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZlVrBAAoJEL7aWKiYQt9267oP/0/XdjsTRx+p7ACrNzYepUAP qFNNIKC7/PuCOgEVJh8Mt52ZBeWmOaVkPfpMHFsAQuJkUR4fdWdUhQsjTt8DgUz1 3OLa2M3+bLkPIVeq1E0OJTxoQ804geYdw8FJ3vcPkmBNk0GCuJnXgkNpGLmX8iKE sbQCFQElPq0YUewB2nTVlPgEUNgryZ4LAwfukVEcbBuHoqwR66TfYHbLG6rjCZDx R8EsR1MdjkhSiNmxKFnOKGhYh/aMkqeU5kpxGy9tc68v1zHipG40P7oG2T7BpvYU d5uWjhaxmDxVl+9sHYkcXLNQrrVyePpQrzhmLVHtJTrGAF9TRg29lUNME1W6KRa+ 9ySQNagc+ra5yQVmzFGuoKbhPE1cZP6OVR5RHtNPc6UryH/gEeXAc38pXWDGOpEK tqnzUj2CoeIDkMcSeB95x2Xi1NdpnRR9N7SWG8NIiWYwQrR0LeUZLcJ9Q8LCryDm oPdqUaOySX4ThZEM6XgUMVV6jFPr4K36uKOWKMJHeE8jgaHoG2v/Sy0yvAhDCJOB iNoXjLJGhTSnEmCVmvbWxldHUJGjVe6OjVmPS8ESy66zcT/TEGcl6HDB1fVf2pEu KBRCVw+SJ1EbeobqsMEX6kM/YXDDzaRE3ffsnpLgIuhiT32Xy9T56d3nAsXR8DXl 3sQ2cRKCrpm9fOt7hK+8 =9ciR -----END PGP SIGNATURE----- --Apple-Mail=_7C44F362-77E5-4FB7-A91F-31026DF4B1B6-- From nobody Thu Aug 17 02:05:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C5A132452 for ; Thu, 17 Aug 2017 02:05:43 -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 arONiA5rHnLJ for ; Thu, 17 Aug 2017 02:05:41 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5DD132386 for ; Thu, 17 Aug 2017 02:05:41 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 123so8854979pga.5 for ; Thu, 17 Aug 2017 02:05:41 -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=l8oP8o6PoWoH1oyjNUZnnq3FLDzH4hNqgEZPZEW6bEI=; b=ReWTpKhZvJUmxlPSUaQ7lhigrGFfGXz9jvBQLf72Zib6xN/BIcK2n/PM8mzJF+SR8R Xb+pziuvNDu2obobFQ6rhcsKdN3G/7E2vGtl3Vr6sBeNUm2OKHf4+7eQ5ElDx+UhUubA qj793aMwWwIO/1H+HSBt5ES2njHHhB81b2BxXGJlDJKIyB9/C3euMd2nJLXTgO74TTZo z0rVrOqaAhWAmZAvUQuR5mq5oOIOHnCJlvTRm8xTNQ5r56MkGf1TgKryhG+Yoy+hpstx 701Uclji49GfyEK3Pk78GiK54oz9OJ7xaSJ+bSvzVmGzKDLLeBFtF2OYqSVrcBcjnw2F FqZg== 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=l8oP8o6PoWoH1oyjNUZnnq3FLDzH4hNqgEZPZEW6bEI=; b=oTfRh5qD1UCxQd0FrRBA/8NyJ55DJ6rDPHIIE2KQ8UpRrV0P0+TNntjJg+Of2CS3yl 6/xqp7Z62y7aZ3EH4ALEGAIX7liup0wRgUzWkotoKuwhnl+eKOaMpUUr+eAbOM0ahToC x39zinj4WWZz9rEnKn+YDfwvKTDy9H3EJU/sB1AxfU8NXM413GRqBcHEH7pL+B7DtVQy Lxs7SswX0LZZ2owYXUPdCWmt7ufbDeXtvRrzQvCLzmOu0cDyOlqHV0yql3siahTXyq4P 2QU+jcOy91CwLrJHMJp1iUBaQOShszCNjxeHKwjWmL5HZ1/DQyxCVmUadUg4jPfurr3P bDcw== X-Gm-Message-State: AHYfb5jg6qxtXYq0WA2i9Olt5RytXejnz/l5H6vb5HGufmqCxUSyUbMK 7Yfm5NmVhr8JEg== X-Received: by 10.98.56.71 with SMTP id f68mr4467142pfa.238.1502960740878; Thu, 17 Aug 2017 02:05:40 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id x8sm6666030pfi.174.2017.08.17.02.05.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 02:05:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Thu, 17 Aug 2017 18:05:37 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:05:43 -0000 --- DY > On 17 Aug 2017, at 17:58, Ole Troan wrote: >=20 > Have you read RFC7421? Yes, I did. With my own bias, the doc looks quite in the interest of = defending one school of thoughts. > What problem are you trying to solve? Not really. I find it a bit amusing that sometimes logics seem to be = overridden under the name of =E2=80=98rough consensus=E2=80=99.=20 And =E2=80=98recommend=E2=80=99 is one thing, and =E2=80=98mandate=E2=80=99= is another. From nobody Thu Aug 17 02:14:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D013264C for ; Thu, 17 Aug 2017 02:14: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, 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 IhTs608WvaIe for ; Thu, 17 Aug 2017 02:14:04 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31DC132386 for ; Thu, 17 Aug 2017 02:14:03 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 815A22D5037; Thu, 17 Aug 2017 09:14:03 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CD30FF919D16; Thu, 17 Aug 2017 11:14:01 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9CE22E53-76A3-42DC-A79B-A645A7333DE5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 11:14:01 +0200 In-Reply-To: <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> Cc: Simon Hobson , v6ops list To: DY Kim References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:14:06 -0000 --Apple-Mail=_9CE22E53-76A3-42DC-A79B-A645A7333DE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> Have you read RFC7421? >=20 > Yes, I did. With my own bias, the doc looks quite in the interest of = defending one school of thoughts. >=20 >> What problem are you trying to solve? >=20 > Not really. I find it a bit amusing that sometimes logics seem to be = overridden under the name of =E2=80=98rough consensus=E2=80=99. >=20 > And =E2=80=98recommend=E2=80=99 is one thing, and =E2=80=98mandate=E2=80= =99 is another. We're here to do engineering. We solve problems. Until we have real = problems to solve I think time would be better spent elsewhere... Ole --Apple-Mail=_9CE22E53-76A3-42DC-A79B-A645A7333DE5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZlV5ZAAoJEL7aWKiYQt92gbcP/2l+RNKbESOV1Z+jUjEoOf0I ArXv789zstH+JzFNZ92firVymqLx9s+5Qy7DW1vVoA95ilnqtubb20+EVhXQaRov hiBPL3DVX4izmoWNtoMGcNNKW7nZ/H8zHtgmzkp75KqvpZx4If+jCkvQDB47xaD9 b+VuIkrWvFxwVMndHaDRBYVfAh5KLMjp9o1UH7V2gE3vnSqQINsxPdKGs2L0R+0B TSxNaXvoMv/L/2cIIBuL1Bvpk0NCkzKRCmeSgCIfHtFtohLHtrkP+4KpULQfSBns 3ySA/+j/BXa6TFWqP1qERjClK5Co9LAHbgv71LmoCu3Hax7Za8VRj2frLRvovkNL ceqXcI1t8kRJixOdp/2z8Z8zW6birfmzvDlarAWv8cWJgKnVW9yqav9OWMwPF677 RfEsAWftu7NtM3MDsM1eNBifN8u+ZyVK8EwanRTstUH4/WHpbzVzkbJr52Cz2K0r kR0P21E5VuS/EM7laM98jWRLfC7hsmqWqwg9vJTZepJtytNvb+5jTA/RRtgZwFyP BixRF5V64d0MvSoUeqtY2YsqgBaWaejHRCuWBJwI0r0JGy7ugA6/w7ci349btsat LuP4IS8GumGE4lFS1REbj7OmfELgzzQecNLdyWmcdefNFA3dO+KFrhHbMrYs/BmN 7mQnyT7sZP8USQwuhdG6 =vdwW -----END PGP SIGNATURE----- --Apple-Mail=_9CE22E53-76A3-42DC-A79B-A645A7333DE5-- From nobody Thu Aug 17 02:29:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386FE132673 for ; Thu, 17 Aug 2017 02:29: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 rcczsLsoC8Ui for ; Thu, 17 Aug 2017 02:29:00 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D6313266F for ; Thu, 17 Aug 2017 02:29:00 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id t80so2834950pgb.2 for ; Thu, 17 Aug 2017 02:28: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=w/8NWFwbhSUoYuRekEixDVUr+056E3/51y5X+4VZfEQ=; b=bE/G9jSiayONtxo3Jbm3jhbUQE3+UV0JczWU1HOxZrGUlnvInDj094w8NR5henCBZg Ksf9GzTJOaW91mdQBUS7074IbPFIa5cO0eZPcwZdk0lQdoPFXblk+0eLNQzXskgpVFm0 X2KKsOWZUpChnz8TEqkThtx7FSN8RJzh5ADubhNTqQN33cQB+207Cg2/9CDgHKkuz91w 1q4M6YlLgMP+XjTWOIHXjRUrAVcWQ+YLFo0D0XMzZVPUPQHeG0Z2754I0cCHupmQdg9c Cb6pxAHvajYXSVJh7KKH9p4MaiQsvtg3ucfOSP/FLI29zVZGlzjJi02D577wisR+y+YR BEcw== 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=w/8NWFwbhSUoYuRekEixDVUr+056E3/51y5X+4VZfEQ=; b=Uv/XCNMNJ7v7jrx/SLCuLmnQkonHe2tPugnfdVRe1XIRYD60Z7+FogLGQKF5Cqp1BX FFEO6IxuWAFafuH+xV8Dq72kKLQUYHMiWOunx4KCiUy6rLNIwORV8KGwY1TgZ34uk0SD 5aVvARlRTX+ztVAuhUgUuFW+2E8znBhD03Qlm27Dpa88reAmXQL8BIEOzBXrCpQaxK/r Fk6y5yzrDu2sO8/GTMYMyaXFk5s09cZKqAcqc52AAlBNAPZjwUW5UAU3d9IWYQcI6Zua sSrCoVFlrJ5vRtFM1zM3yr4WbS7rRuca53kQGKGM0XmR9fslVmTLxYD9G4ACoywtBN7O ILlQ== X-Gm-Message-State: AHYfb5jn5x+KwL1yt9znzocRIe87oAIKBQ+ss+4CQg3EiUcKXMFFVOgH LmCxF0Y5FDvX4g== X-Received: by 10.84.133.11 with SMTP id 11mr5203699plf.77.1502962139626; Thu, 17 Aug 2017 02:28:59 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id i66sm6445781pfk.146.2017.08.17.02.28.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 02:28:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Thu, 17 Aug 2017 18:28:54 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> To: Ole Troan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:29:01 -0000 While you don=E2=80=99t see =E2=80=98the broken logic=E2=80=99 as a = problem while I do, all is fine with me what=E2=80=99s been proceeding = here. --- DY > On 17 Aug 2017, at 18:14, Ole Troan wrote: >=20 > We're here to do engineering. We solve problems. Until we have real = problems to solve I think time would be better spent elsewhere... >=20 > Ole From nobody Thu Aug 17 02:43:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7A1323B8 for ; Thu, 17 Aug 2017 02:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, 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 3LUNfOswEbag for ; Thu, 17 Aug 2017 02:43:01 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203311321A8 for ; Thu, 17 Aug 2017 02:43:01 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u133so20534787vke.3 for ; Thu, 17 Aug 2017 02:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FTNaTFYAHRA7ofj5fRKPgo4Wdv4sjimGP/fR/kWIy0s=; b=pOaeXR4jpV7v9RRRHRBdapAaC4/dsjCgZiX9j7UKdPC+NVZVV1yN5hue54fvWg8kaZ 6eKb8UtBlrHnSc7M4cGnO9hQM+l8WVaJ4lytn2bLSJmAP8cX0syiVsVXBCvdI0SQ9+IC pT+8iDCeaq8lHLxxOiImj1KjF4drC4DrzxjymvyYnNW9jsXN70BnwV3Mz0i6AFkqJm9y i+aoy5yAFfXwTYgSx9ZxtjqIPT0iKMuSarYI1r+L1rfDVd3dO458yj+XXN4Avw023qP+ Py8l2eEX/vw1guIvkos8qN+IHdKY+ROiT6Qlp9GsS24egWNtd88sc8rsUhMkpN+pM7p/ YNXA== 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=FTNaTFYAHRA7ofj5fRKPgo4Wdv4sjimGP/fR/kWIy0s=; b=NyLcAD+LrKFg14R96o5PFn10UFiREWVzEFSY3EpJXKz6GA6z31fkf760qWRFhqB1N5 Jjq2gUiS5wMOLdEYyn9YcQYXmcOOaXm9/fAu+KC7DnebH60neS8Ic7BJ2qH0XVDZFIR5 quU8ad9GyJtQYEV4rZMazjia+jv0/VAgJ25spwtlJ4+9M90lwaD5xn4pClOZ9Noevoxz 8gqic7kdsMtB19mu1l97wJca6nu9iNogwIGLHkaOcZEbLjzUAwREgcQLoz2tpek/shsk UFhAgnUjsLJ1bc5z6SNSpqmkGb/FAZJ3oWHgOyhuwACwojduYz3M48DHAeBv0MsU0Zew vyhg== X-Gm-Message-State: AHYfb5g4CKC7y+lztRGyk770p1SZii2WRMGjaAdCSjCa8BjkCO8zb1BC 1RxnL4uqJagwGhTcyILiAteLuzkFIg== X-Received: by 10.31.198.135 with SMTP id w129mr2966621vkf.169.1502962980106; Thu, 17 Aug 2017 02:43:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Thu, 17 Aug 2017 02:42:59 -0700 (PDT) Received: by 10.176.7.209 with HTTP; Thu, 17 Aug 2017 02:42:59 -0700 (PDT) In-Reply-To: <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> From: Mark Smith Date: Thu, 17 Aug 2017 19:42:59 +1000 Message-ID: To: DY Kim Cc: Simon Hobson , v6ops list , Ole Troan Content-Type: multipart/alternative; boundary="001a114d5b048a36820556efd61b" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:43:08 -0000 --001a114d5b048a36820556efd61b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have an installed base that numbers in the billions (i.e., at least the Android and iPhone implementations). Whether or not 64 bit IIDs really need to be 64 bits to suit all the requirements isn't really the question anymore. It is what are the consequences and costs of changing it now? They'd be high costs because of the installed base that assume 64 bits. The criticism of "tradition" or "religion" would be more valid if it was criticising something arbitrary that hadn't made it into production implementations for many years. Those changes could have easily been made in the mid 1990s, but not now when every IPhone, Android, Windows and probably all other IPv6 implementations in the hands of end-users that assume 64 bits. I started experimenting with the Linux implementation of IPv6 in 1998. 64 bit IIDs, SLAAC and RA PIOs from then are still the same today, so a 1998 implementation of IPv6 would still work today, nearly 20 years later. That's how long (at least) these working conventions have been in place. Change isn't cheap in IPv6. It's much cheaper to propose significant change for the next version of IP (IPv10 going by IANA). Regards, Mark. On 17 Aug. 2017 7:05 pm, "DY Kim" wrote: --- DY > On 17 Aug 2017, at 17:58, Ole Troan wrote: > > Have you read RFC7421? Yes, I did. With my own bias, the doc looks quite in the interest of defending one school of thoughts. > What problem are you trying to solve? Not really. I find it a bit amusing that sometimes logics seem to be overridden under the name of =E2=80=98rough consensus=E2=80=99. And =E2=80=98recommend=E2=80=99 is one thing, and =E2=80=98mandate=E2=80=99= is another. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --001a114d5b048a36820556efd61b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have an installed base that numbers in the billions (i= .e., at least the Android and iPhone implementations). Whether or not 64 bi= t IIDs really need to be 64 bits to suit all the requirements isn't rea= lly the question anymore. It is what are the consequences and costs of chan= ging it now? They'd be high costs because of the installed base that as= sume 64 bits.

The criticism of= "tradition" or "religion" would be more valid if it wa= s criticising something arbitrary that hadn't made it into production i= mplementations for many years. Those changes could have easily been made in= the mid 1990s, but not now when every IPhone, Android, Windows and probabl= y all other IPv6 implementations in the hands of end-users that assume 64 b= its.

I started experimen= ting with the Linux implementation of IPv6 in 1998. 64 bit IIDs, SLAAC and = RA PIOs from then are still the same today, so a 1998 implementation of IPv= 6 would still work today, nearly 20 years later. That's how long (at le= ast) these working conventions have been in place.
<= br>
Change isn't cheap in IPv6. It's much ch= eaper to propose significant change for the next version of IP (IPv10 going= by IANA).

Regards,
Mark.

<= br>
On 17 Aug. 2017 7:05 pm, "DY Kim" &= lt;dykim6@gmail.com> wrote:
---
DY


> On 17 Aug 2017, at 17:58, Ole Troan <otroan@employees.org> wrote:
>
> Have you read RFC7421?

Yes, I did. With my own bias, the doc looks quite in the interest of defend= ing one school of thoughts.

> What problem are you trying to solve?

Not really. I find it a bit amusing that sometimes logics seem to be = overridden under the name of =E2=80=98rough consensus=E2=80=99.

And =E2=80=98recommend=E2=80=99 is one thing, and =E2=80=98mandate=E2=80=99= is another.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--001a114d5b048a36820556efd61b-- From nobody Thu Aug 17 03:12:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2554E131D27 for ; Thu, 17 Aug 2017 03:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG4L7XhKguzN for ; Thu, 17 Aug 2017 03:12:22 -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 446C1126B71 for ; Thu, 17 Aug 2017 03:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502964740; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=f0v0meWymOvtMfV6STmTKITt4r9c2Tzxe+UJOTsYEO4=; b=ZZ+ddBjGYuIQx/sGmafjL5Wy+kr3OD729qmz1AcIBZHViju+lSExEJgGQbKypyv1nT2hvJCfkAwNMarPDQ27bSYHes94hspCe/9TjFGZoxFxBc3GEheKDV6GKrlgmlcgPvPm7H8U7xs42dlnk790ahEdTwY3s+fnyxAVcwaUHZM= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0118.outbound.protection.outlook.com [213.199.154.118]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-86-2MVZSe2JM2CHuR5PY_oAQw-1; Thu, 17 Aug 2017 11:12:17 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0614.eurprd07.prod.outlook.com (10.160.3.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Thu, 17 Aug 2017 10:12:16 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.01.1385.003; Thu, 17 Aug 2017 10:12:16 +0000 From: Tim Chown To: Lorenzo Colitti CC: Mark Smith , Simon Hobson , v6ops list Thread-Topic: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) Thread-Index: AQHTFwPkIR0hUkJRmUWLZheKIbsHcqKH3C2AgAB4YwA= Date: Thu, 17 Aug 2017 10:12:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0614; 20:Noiaf5MzYgkn2NzfsDno8h9OQYY1pcO/wziUOUYN4O1U9nfWMAg+EDu6LyZ27XWbaIUH2zPk0k94gg9+dZFl1HUXkWJ+VAaYAg5JVuxwK1s45D07jIwpKlUck1IeJMnVl/Rf1wiWXzOoSGZ1kB5Uemq/Cw2xmKoChIy3abRhOmM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 03cd4001-74d7-48df-d537-08d4e5587030 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0614; x-ms-traffictypediagnostic: AM3PR07MB0614: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(920507026)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0614; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0614; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(24454002)(377454003)(53546010)(34040400001)(6436002)(5250100002)(66066001)(86362001)(74482002)(97736004)(6246003)(110136004)(478600001)(105586002)(102836003)(6116002)(3846002)(106356001)(2906002)(4326008)(25786009)(83716003)(57306001)(2900100001)(230783001)(7736002)(6486002)(6512007)(82746002)(6506006)(101416001)(39060400002)(81156014)(33656002)(81166006)(76176999)(8676002)(3280700002)(305945005)(36756003)(68736007)(5660300001)(50986999)(14454004)(229853002)(189998001)(53936002)(72206003)(3660700001)(50226002)(54906002)(99286003)(8936002)(42882006)(6916009)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0614; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0BB3856F539EF64EAD0E6E0B5851FDAF@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 10:12:16.7588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0614 X-MC-Unique: 2MVZSe2JM2CHuR5PY_oAQw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:12:25 -0000 > On 17 Aug 2017, at 04:01, Lorenzo Colitti wrote: >=20 > On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith wro= te: > "If IPv6 IIDs were reduced to something like 32 bits, would any of the > above be impacted: >=20 > - Available and Reliable: No. May have a positive influence, as > availability and reliability possibly could be increased, as ND cache > resource exhaustion attacks effectiveness would be reduced. >=20 > Actually the answer here is also "yes, negatively". It means that network= s with large numbers of users would become unreliable because of IID collis= ions. There are networks that run 10k or 20k nodes on a single subnet. Larg= e corporate networks are an example, or large conferences such as MWC. Is there info anywhere on what the common OSes do when they encounter a DAD= failure - do they give up or try a new tentative address? =20 Tim From nobody Thu Aug 17 03:22:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865361323BB for ; Thu, 17 Aug 2017 03:22:28 -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, HTML_MESSAGE=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=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 0uRAFsBHHzJd for ; Thu, 17 Aug 2017 03:22:26 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2931321EB for ; Thu, 17 Aug 2017 03:22:26 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g71so21500165ioe.5 for ; Thu, 17 Aug 2017 03:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjxxgFhhf7azpYIiDDnL29x0VWBDs9e0DbA+Lsfg1aM=; b=HqP2BqPC34md/uV8Wl6+/PpJzU67u76ni28h0XT07FK6LZ+LUoS45Dl03WAe6bdDQ6 36VTe0jbpqvP8Elg4q05LlJwyUfWGSN60poiGmbhwkVNffz2XndFsml1EgWhG8/Y7kL2 q1kVzThxZ6soRYfkzINit80tqjRAkbseGYWUHbsaLXfSYwX7Sf5jmHw1RTyZk+naV10B HdOxg5HXC2p6agV7GV9UwYYVDBpXHjQY2PsfAYpBwTZwiDkHsJV55pFqHeJrfSMTfbzE J9XPTw/2p2CEtzNHf0/TuBKbcoCYzDTUj2XhIgas8PZ7lKGrtmeGTQx0QI8cvq5NaCjG K/hA== 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=jjxxgFhhf7azpYIiDDnL29x0VWBDs9e0DbA+Lsfg1aM=; b=WY/cC38TRuQxWOe0TmX/H38rB2Fvj+Bi7FVV7dR4KBY8UG8oJRNSUgRau3PBsjPW75 Unw7O9iDUIaqQIGeO1s4H/DP8gx+EW9p65EdtBIe3SupI7F3w+4iE6IVw55dnHzEq+3a Dcuf77uePCUtp6MXplLmG3NOwugcN89PrPhePWC5I2mlPxpUdjdnRBMD7Gdkx2wThPyF 7GCkPz+J51InezSRYghVgFmRco6/wyQd7JhFN9Uqyr/nFIymNrvuctV02OelSslCyKwD vMa/b7m1opFAZZlxlVUIX+teT8kSehFcGcO+5b1GSb0xNJWGbrl9mHzYFsllcNoXPSbg lmxw== X-Gm-Message-State: AHYfb5gKARNXW2KDwgIeBS1Wqo9m5K8ejgXvtkH6JFTuzRm+932lULj1 VL9CyR3lbUt0UG8JBn5Wy+RnW8t4yMG1 X-Received: by 10.107.56.214 with SMTP id f205mr4468082ioa.208.1502965345658; Thu, 17 Aug 2017 03:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 17 Aug 2017 03:22:05 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 17 Aug 2017 19:22:05 +0900 Message-ID: To: Tim Chown Cc: Mark Smith , Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a114ac8ca8aaf390556f0639f" Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:22:28 -0000 --001a114ac8ca8aaf390556f0639f Content-Type: text/plain; charset="UTF-8" For non-EUI-64 addresses Linux usually retries. However, the problem is not so much when DAD works as when it *doesn't work* (e.g., because devices drop multicast when asleep). In that case you end up with duplicate addresses. On Thu, Aug 17, 2017 at 7:12 PM, Tim Chown wrote: > > On 17 Aug 2017, at 04:01, Lorenzo Colitti wrote: > > > > On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith > wrote: > > "If IPv6 IIDs were reduced to something like 32 bits, would any of the > > above be impacted: > > > > - Available and Reliable: No. May have a positive influence, as > > availability and reliability possibly could be increased, as ND cache > > resource exhaustion attacks effectiveness would be reduced. > > > > Actually the answer here is also "yes, negatively". It means that > networks with large numbers of users would become unreliable because of IID > collisions. There are networks that run 10k or 20k nodes on a single > subnet. Large corporate networks are an example, or large conferences such > as MWC. > > Is there info anywhere on what the common OSes do when they encounter a > DAD failure - do they give up or try a new tentative address? > > Tim > > --001a114ac8ca8aaf390556f0639f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For non-EUI-64 addresses Linux usually retries.

However, the problem is not so much when DAD works as when it *doe= sn't work* (e.g., because devices drop multicast when asleep). In that = case you end up with duplicate addresses.

On Thu, Aug 17, 2017 at 7:12 PM, Tim Ch= own <Tim.Chown@jisc.ac.uk> wrote:
> On 17 Aug 2017, at = 04:01, Lorenzo Colitti <lorenzo@go= ogle.com> wrote:
>
> On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> "If IPv6 IIDs were reduced to something like 32 bits, would any o= f the
> above be impacted:
>
> - Available and Reliable: No. May have a positive influence, as
> availability and reliability possibly could be increased, as ND cache<= br> > resource exhaustion attacks effectiveness would be reduced.
>
> Actually the answer here is also "yes, negatively". It means= that networks with large numbers of users would become unreliable because = of IID collisions. There are networks that run 10k or 20k nodes on a single= subnet. Large corporate networks are an example, or large conferences such= as MWC.

Is there info anywhere on what the common OSes do when they enc= ounter a DAD failure - do they give up or try a new tentative address?

Tim


--001a114ac8ca8aaf390556f0639f-- From nobody Thu Aug 17 03:48:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA69126B7E for ; Thu, 17 Aug 2017 03:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDeQ24pWHCJt for ; Thu, 17 Aug 2017 03:48:09 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1741200B9 for ; Thu, 17 Aug 2017 03:48:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u139so34214206qka.1 for ; Thu, 17 Aug 2017 03:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYIH+rf2aZdlx3j71feZD9w2hQ2oGQXz8kKLsHUhaWM=; b=jTwpsfTO+O21qtRrzGHQF5lPJMXGgG6z5fskA3gwmHy8G4rA6YA2OL5SWp1rWGgb+Y HuafWIZLiA1g/0iEDq2Ish1peOgbN0QhWR4228fZUenIy17HNSS95n8Aw+jgy8xz+Blc ON9Sb/xS0Sxw3TqhLun5sWWoB3CPDC20CeqXY= 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=AYIH+rf2aZdlx3j71feZD9w2hQ2oGQXz8kKLsHUhaWM=; b=oG0Qen088J8eh1/du5y61noikwV+bHwc2IPzUti19t/WyGgiAc4KApPNO80CZbKmTN gWvoKM7Qn7+PYjoRlcLldvZWBeDCR0vo6o5jyN1d3yNOo8smrRvzkrvhUiMh+IUhfnyC uKVkL2ksXv3ceBAqMjycP7X0s2Fkoyt3DHdWnU6kp6Y3kSdBDBWP9y1tVphp9o+z/1Pa oH8ZBdQs9k/qYF4TGVibkHnZP/hBGyS3REASQpGutDxDP0u/Bu7LQTkfdXEmnMaDGwB+ 5hqGOAdpATwGPrbRcOKoibNv9IQVSGay91VA5DlPlxI/QkzjouVXLZ1rsLjwKGk9OPlq IEgg== X-Gm-Message-State: AHYfb5jAhcSmcoJaRvm1EaYVXkGqcUowJk2qR6LKTe9gvIf3hwNfyB5w Y6zrE1dUVCM7E6bYh/0HXFWD1v6bxD8Y X-Received: by 10.55.52.20 with SMTP id b20mr5922812qka.235.1502966887876; Thu, 17 Aug 2017 03:48:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Timothy Winters Date: Thu, 17 Aug 2017 10:47:56 +0000 Message-ID: To: Lorenzo Colitti , Tim Chown Cc: Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a11477c6e7632040556f0bfe2" Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:48:12 -0000 --001a11477c6e7632040556f0bfe2 Content-Type: text/plain; charset="UTF-8" Most operating systems give up if they fail DAD. Tim On Thu, Aug 17, 2017 at 6:22 AM Lorenzo Colitti wrote: > For non-EUI-64 addresses Linux usually retries. > > However, the problem is not so much when DAD works as when it *doesn't > work* (e.g., because devices drop multicast when asleep). In that case you > end up with duplicate addresses. > > On Thu, Aug 17, 2017 at 7:12 PM, Tim Chown wrote: > >> > On 17 Aug 2017, at 04:01, Lorenzo Colitti wrote: >> > >> > On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith >> wrote: >> > "If IPv6 IIDs were reduced to something like 32 bits, would any of the >> > above be impacted: >> > >> > - Available and Reliable: No. May have a positive influence, as >> > availability and reliability possibly could be increased, as ND cache >> > resource exhaustion attacks effectiveness would be reduced. >> > >> > Actually the answer here is also "yes, negatively". It means that >> networks with large numbers of users would become unreliable because of IID >> collisions. There are networks that run 10k or 20k nodes on a single >> subnet. Large corporate networks are an example, or large conferences such >> as MWC. >> >> Is there info anywhere on what the common OSes do when they encounter a >> DAD failure - do they give up or try a new tentative address? >> >> Tim >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a11477c6e7632040556f0bfe2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Most operating systems give up if they fail DAD.

Tim

On Thu, Aug 17, 2017 at 6:22 AM Lorenzo Colitti <lorenzo@google.com> wrote:
For non-EUI-64 addresses Linux usually= retries.

However, the problem is not so much when DAD w= orks as when it *doesn't work* (e.g., because devices drop multicast wh= en asleep). In that case you end up with duplicate addresses.

On Thu, Aug 17, 201= 7 at 7:12 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> On 17 Aug 2017, at 04:01, Lorenzo Colitti &l= t;lorenzo@google.co= m> wrote:
>
> On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith <markzzzsmith@gmail.com> wrote= :
> "If IPv6 IIDs were reduced to something like 32 bits, would any o= f the
> above be impacted:
>
> - Available and Reliable: No. May have a positive influence, as
> availability and reliability possibly could be increased, as ND cache<= br> > resource exhaustion attacks effectiveness would be reduced.
>
> Actually the answer here is also "yes, negatively". It means= that networks with large numbers of users would become unreliable because = of IID collisions. There are networks that run 10k or 20k nodes on a single= subnet. Large corporate networks are an example, or large conferences such= as MWC.

Is there info anywhere on what the common OSes do when they enc= ounter a DAD failure - do they give up or try a new tentative address?

Tim


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--

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

--001a11477c6e7632040556f0bfe2-- From nobody Thu Aug 17 07:01:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33313239E; Thu, 17 Aug 2017 07:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiKb6xgsNP5S; Thu, 17 Aug 2017 07:01:22 -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 D1FF9126BFD; Thu, 17 Aug 2017 07:01:21 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7HDt50Q041230; Thu, 17 Aug 2017 10:01:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2cd2w1jb6n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 10:01:05 -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 v7HE13gn019646; Thu, 17 Aug 2017 10:01:04 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7HE0v5X018928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Aug 2017 10:00:59 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi134.aldc.att.com (RSA Interceptor); Thu, 17 Aug 2017 14:00:38 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0319.002; Thu, 17 Aug 2017 10:00:37 -0400 From: "STARK, BARBARA H" To: Fred Baker , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "sunset4@ietf.org" Thread-Topic: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt Thread-Index: AQHTFtPhi+wo0/l+sUG0TolNU5N+WqKH5EkAgACh8xA= Date: Thu, 17 Aug 2017 14:00:37 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC00555@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> In-Reply-To: <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170231 Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:01:28 -0000 PiBUaGUgcXVlc3Rpb24gSSB3b3VsZCBhc2sgaXMgd2hldGhlciBvbi1kZW1hbmQgSVB2NCBtYWtl cyBzZW5zZS4gVG8gbXkNCj4gd2F5IG9mIHRoaW5raW5nLCBpdCBhbW91bnRzIHRvIGRlcGxveWlu ZyBhIG5ldyBraW5kIG9mIG5ldHdvcmsuIFdlIGFyZQ0KPiBhc2tpbmcgcGVvcGxlIHRvIGRlcGxv eSBJUHY2IGluIHRoZWlyIElQdjQgbmV0d29ya3MsIG9yIHRvIGRlcGxveSBJUHY2LW9ubHkNCj4g bmV0d29ya3MuIFRoYXQgcmVxdWlyZXMgc29tZSBwb3J0aW9uIG9mIHRoZSBtb25leSBhbmQgdGlt ZSB0aGV5IGhhdmUNCj4gYXZhaWxhYmxlIGZvciBzdWNoIGlzc3Vlcy4gRGVwbG95aW5nIGFuIElQ djQtb24tZGVtYW5kIG5ldHdvcmsgaXMgYW5vdGhlcg0KPiB0aGluZyBjb21wZXRpbmcgZm9yIHRo b3NlIHNhbWUgcmVzb3VyY2VzIC0gaXQgZG9lc24ndCBjcmVhdGUgbmV3IHJlc291cmNlcw0KPiBv ciByZWR1Y2UgdGhlIG1hdHRlcnMgcGVydGFpbmluZyB0byBJUHY2IGRlcGxveW1lbnQgLSBpdCBj cmVhdGVzIGFub3RoZXINCj4gZGVtYW5kIGZvciB0aGUgc2FtZSByZXNvdXJjZXMuIEkgZG9uJ3Qg c2VlIHRoZSBwb2ludC4NCj4gDQo+IEkgc3VzcGVjdCB0aGF0IHRoZSBuZXR3b3JrIGFjdHVhbGx5 IHJvdXRlcyBJUHY0IG5vIG1hdHRlciB3aGF0OyB3aGF0IGlzIGJlaW5nDQo+IGhhbmRlZCBvdXQg b24gZGVtYW5kIGlzIGFuIElQdjQgYWRkcmVzcyB0byBhbiBlZGdlIGRldmljZS4gSG9zdHMgcmln aHQgbm93DQo+IGdldCBJUHY0IChhbmQgSVB2NikgYWRkcmVzc2VzIHdoZW4gdGhleSBkb24ndCBu ZWVkIHRoZW0gc28gdGhleSBjYW4gdXNlDQo+IHRoZW0gd2hlbiB0aGV5IGRvLiBUaGV5IHdvdWxk IG5lZWQgYSBkaWZmZXJlbnQgbW9kZSBvZiBvcGVyYXRpb24sDQo+IHBlcmhhcHMgdHJpZ2dlcmVk IGJ5IHRoZSByZXNvbHZlciBub3RpY2luZyB0aGF0IGFuIGFwcGxpY2F0aW9uIHdhbnRzIHRvIGFj Y2Vzcw0KPiBzb21lIG5hbWUgYW5kIHRoZSBuYW1lIG9ubHkgaGFzIGFuIEEgcmVjb3JkLiBJbiB0 aGF0IG1vZGUgb2Ygb3BlcmF0aW9uLA0KPiB0aGUgaG9zdCBvbmx5IGFza3MgZm9yIChESENQKSBh biBJUHY0IGFkZHJlc3Mgd2hlbiBpdCBuZWVkcyBpdCwgYW5kIHJvdXRpbmcgaW4NCj4gdGhlIG5l dHdvcmsgaXMgdG8gdGhlIGdyYW50ZWQgYWRkcmVzcyBmb3IgdGhlIGxpZmV0aW1lIG9mIHRoZSBh ZGRyZXNzLg0KPiANCj4gRG8gSSBiZWxpZXZlIHdlIGNhbiBkZXNjcmliZSBhbmQgc29sdmUgdGhh dD8gWWVzLiBEbyBJIHRoaW5rIHdlIGNhbiBkbyBpdCBtb3JlDQo+IGNoZWFwbHkgYW5kIHNpbXBs eSB0aGFuIG1vdmluZyBmb2xrcyBhbmQgdGhlaXIgYXBwbGljYXRpb25zIHRvIElQdjYsIGFuZA0K PiBjb252aW5jZSBvcGVyYXRvcnMgdG8gY2hhbmdlIHRoZWlyIG9wZXJhdGlvbmFsIHByYWN0aWNl cyBhY2NvcmRpbmdseT8gTm90DQo+IGV2ZW4gY2xvc2UuIEkgdGhpbmsgaXQgaXMgYSBkaXZlcnNp b24gZnJvbSBJUHY2IGRlcGxveW1lbnQuDQoNCkkgdGhpbmsgIm9uLWRlbWFuZCBJUHY0IiB3b3Vs ZCBiZSByYXRoZXIgZWFzeSB3aXRoIFBQUG9FLiBNYW55ICh0ZWxjbykgSVNQcyBhcmUgc3RpbGwg dXNpbmcgUFBQb0UsIGFuZCB0aGVyZSdzIHN0aWxsIGEgbG90IG9mIGVxdWlwbWVudCBhbmQgcm91 dGVycyB0aGF0IHN1cHBvcnQgaXQuIFRoZSBjb3N0bGllc3QgcGFydCBvZiBQUFBvRSB3YXMgaGVs cCBkZXNrIGNhbGxzIGZvciBwZW9wbGUgd2hvIGZvcmdvdCB0aGVpciBsb2dpbi9wYXNzd29yZC4g SVNQLW1hbmFnZWQgQ0Ugcm91dGVycyAodGhhdCBkbyBQUFBvRSkgaGF2ZSBtb3N0bHkgZXZvbHZl ZCB0byBoYXZlIHRoaXMgYXV0by1jb25maWd1cmVkIGJ5IHRoZSBJU1AuIEJ1dCBub3QgcmV0YWls IENFIHJvdXRlcnMuDQoNCkluIHRoZSBlYXJseSBkYXlzIG9mIHRoZSBJbnRlcm5ldCwgYmVmb3Jl IHRoZSBuZWVkIGZvciBwZXJzaXN0ZW50IElQdjQgY29ubmVjdGl2aXR5IC0tICBieSBhcHBsaWNh dGlvbnMgdXNpbmcga2VlcC1hbGl2ZXMgb3IgYXV0b25vbW91c2x5IGFuZCBmcmVxdWVudGx5IGNo ZWNraW5nIGluIHdpdGggc29tZSBzZXJ2ZXIgLS0gd2FzIHByZXZhbGVudCwgbWFueSBJU1BzIHRo YXQgdXNlZCBQUFBvRSBzdXBwbGllZCBDRSByb3V0ZXJzIHRoYXQgdGltZWQgb3V0IHRoZSBQUFBv RSBjb25uZWN0aW9uICh1c3VhbGx5IGFmdGVyIGFib3V0IDIwIG1pbnV0ZXMgb2Ygbm8gV0FOLWJv dW5kIElQdjQgdHJhZmZpYykuIFRoZXkgYWxzbyBvdmVyLXN1YnNjcmliZWQgdGhlaXIgSVB2NCBh ZGRyZXNzIHNwYWNlLiBUaGUgZGVsYXkgaW4gZXN0YWJsaXNoaW5nIHRoZSBQUFBvRSBjb25uZWN0 aW9uIG9uLWRlbWFuZCAod2hlbiBhIFdBTi1ib3VuZCBJUHY0IHBhY2tldCBjYW1lIGZyb20gdGhl IExBTikgd2FzIHNtYWxsOyBhbmQgaW4gdGhlIGNvbnRleHQgb2Ygc3Vuc2V0dGluZyBJUHY0LCBz dWNoIGEgZGVsYXkgd291bGQgcHJvYmFibHkgYmUgcXVpdGUgYWNjZXB0YWJsZS4gQ2hhdHR5IGFw cGxpY2F0aW9ucyBwdXQgYW4gZW5kIHRvIElQdjQgYWRkcmVzcyBvdmVyLXN1YnNjcmlwdGlvbiBh bmQgUFBQb0UgY29ubmVjdGlvbnMgdGhhdCB0aW1lZCBvdXQuDQoNClNvIEkgdGhpbmsgYW4gb24t ZGVtYW5kIHNvbHV0aW9uIGFscmVhZHkgZXhpc3RzIChjb21wbGV0ZSB3aXRoIGFnaW5nIGVxdWlw bWVudCwgY29kZSwgYW5kIG9wZXJhdGlvbmFsIGtub3dsZWRnZSkuIEZvciB0aG9zZSB3aG8gd2Fu dCBpdC4NCk9mIGNvdXJzZSwgbm8gb24tZGVtYW5kIHNvbHV0aW9uIHdpbGwgd29yayBhcyBsb25n IGFzIHRoZXJlIGFyZSBzdGlsbCBhIGxvdCBvZiBJUHY0LW9ubHkgYXV0b25vbW91c2x5IGNoYXR0 eSBhcHBzLg0KRGlzY2xhaW1lcjogUGxlYXNlIGRvbid0IHRha2UgdGhpcyBlbWFpbCBhcyBhIHN0 YXRlbWVudCB0aGF0IEknbSByZWNvbW1lbmRpbmcgdGhpcywgb3IgdGhhdCBteSBlbXBsb3llciBo YXMgYW55IHN1Y2ggcGxhbnMsIG9yIHRoYXQgSSBoYXZlIGVtb3Rpb25hbCBhdHRhY2htZW50IHRv IHRoaXMgaWRlYSwgb3IgdGhhdCBJIGhhdmUgc29tZSBzb3J0IG9mIGFnZW5kYSByZWdhcmRpbmcg dGhpcy4gSSdtIHByb3ZpZGluZyB0aGlzIHB1cmVseSBhcyB0ZWNobmljYWwgaW5mb3JtYXRpb24s IGluIGNhc2UgcGVvcGxlIHdlcmVuJ3QgYXdhcmUgb2YgaXQuIA0KQmFyYmFyYQ0KDQo= From nobody Thu Aug 17 08:35:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3840C1321BE for ; Thu, 17 Aug 2017 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 3kXtHd4ORexu for ; Thu, 17 Aug 2017 08:35:30 -0700 (PDT) Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) (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 0D0B21321B7 for ; Thu, 17 Aug 2017 08:35:29 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7HFZR8I003944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 Aug 2017 11:35:27 -0400 Received: (qmail 29952 invoked by uid 0); 17 Aug 2017 15:35:27 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 17 Aug 2017 15:35:25 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 17 Aug 2017 11:35:20 -0400 From: Lee Howard To: Mark Smith , Brian E Carpenter CC: Simon Hobson , v6ops list Message-ID: Thread-Topic: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 15:35:32 -0000 On 8/16/17, 10:51 PM, "v6ops on behalf of Mark Smith" wrote: >So how do we evaluate what is the best solution? What are the criteria to >use? > >This discussion is going in circles because I think people have >different opinions on what the criteria are. > >Mark Nottingham has been working on the following draft, > >"The Internet is for End Users" >https://tools.ietf.org/id/draft-nottingham-for-the-users-05.txt > >which says that what is best for the end-user needs should trump any >other parties' needs. I entirely agree. I disagree with that characterization of the draft. I worked with Mark to try to make it clear that it does NOT say =E2=80=9Cend users uber alles." Our goal is not to avoid all potential harm to or constraint of end users; rather, it's to give guidance in a particular situation - when we've identified a conflict between the needs of end users and another stakeholder (e.g., a network operator), and need a "tiebreaker", we should err on the side of finding a solution that doesn't harm end users. =E2=80=9CDoesn=E2=80=99t harm=E2=80=9D is different than =E2=80=9Cbest for,=E2=80=9D and various interest= s compete. Of course, this document is still a draft, and we cannot call is a consensus document. > >I've thought there are the following 3 high level end-user criteria to >use for evaluation: > >* Available and Reliable > >* Secure and Private > >* Cost Effective Good/Fast/Cheap? > >- Secure and Private: Yes, negatively. It is practical to scan 32 bit >address spaces e.g., shodan.io. 64 bit random addresses are effective >at mitigating device discovery via unsolicited packet probing, 32 bit >random addresses would not be. As I read RFC7707 "Network Reconnaissance in IPv6 Networks=E2=80=9D I think you may be overestimating that value. Lee From nobody Thu Aug 17 08:41:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39871323AE for ; Thu, 17 Aug 2017 08:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 gnaghPPM2Vpr for ; Thu, 17 Aug 2017 08:41:16 -0700 (PDT) Received: from atl4mhob20.registeredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) (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 EE2841321C7 for ; Thu, 17 Aug 2017 08:41:14 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob20.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7HFf9sg033784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 Aug 2017 11:41:09 -0400 Received: (qmail 21538 invoked by uid 0); 17 Aug 2017 15:41:09 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 17 Aug 2017 15:41:09 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 17 Aug 2017 11:41:03 -0400 From: Lee Howard To: "STARK, BARBARA H" , Fred Baker , JORDI PALET MARTINEZ CC: "v6ops@ietf.org" , "sunset4@ietf.org" Message-ID: Thread-Topic: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DC00555@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DC00555@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 15:41:18 -0000 On 8/17/17, 10:00 AM, "v6ops on behalf of STARK, BARBARA H" wrote: >> The question I would ask is whether on-demand IPv4 makes sense. > >I think "on-demand IPv4" would be rather easy with PPPoE. Many (telco) >ISPs are still using PPPoE, and there's still a lot of equipment and >routers that support it. That=E2=80=99s exactly how it reads in the gapanalysis draft: it makes sense for PPPoE. However, I will argue to both working groups that we should find an operator who thinks this is a good idea. I hope we can get them to write it up. If there is no such operator, we should remove the section (or at most, footnote it as an idea somebody once thought of). Lee From nobody Thu Aug 17 08:48:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FF21321B7 for ; Thu, 17 Aug 2017 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 4dXJ1O-63ija for ; Thu, 17 Aug 2017 08:48:24 -0700 (PDT) Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) (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 0B8CA13219F for ; Thu, 17 Aug 2017 08:48:23 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7HFmLue010821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 Aug 2017 11:48:21 -0400 Received: (qmail 31296 invoked by uid 0); 17 Aug 2017 15:48:21 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 17 Aug 2017 15:48:20 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 17 Aug 2017 11:48:12 -0400 From: Lee Howard To: DaeYoung KIM , Lorenzo Colitti CC: Simon Hobson , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt References: <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <7A6949B4-C49A-4E3A-BA0E-1465AEB61115@gmail.com> <260A83D9-60ED-40F6-BE41-8E13F466AF9A@gmail.com> <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> In-Reply-To: <386BBA22-2896-4AA1-99BD-EAAF11122C5A@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 15:48:26 -0000 On 8/17/17, 2:49 AM, "v6ops on behalf of DaeYoung KIM" wrote: >Sent from my iPhone > >> Ah, I see. If you're asking whether you can use this technique to hand >>out a /96 per host, then the answer is no. You can't use this technique >>because this technique presumes the use of SLAAC, and SLAAC only works >>with 64-bit prefixes (except for addresses in ::/3, which aren't >>routable on the Internet). >>=20 >> If you're suggesting that SLAAC be changed to support non-64 bit >>prefixes, that topic is out of scope for this document and this working >>group > >As I know, SLAAC by itself doesn't impose restrictions on the IID length. >It's Addr Arch (4291bis) that imposes it. > >Then, are all deployed SLLAC software hard-coded to 64 bits? If properly >implemented, the IID length should remain a parameter that can be set by >an admin. > >Should the latter be the case, my life would get easiest. If you control the software and configuration on the network nodes and on the host devices, you can run your network however you want to. Interoperability with other networks is what matters, and I don=E2=80=99t think it=E2=80=99s affected here. > >> If you're willing to use something other than SLAAC, such as DHCPv6, >>then all you need is one /64 for your whole network and you can number >>as many devices as you want. > >If not for SLAAC, this would certainly be my last option. You can assign addresses on your network using whatever mechanism you want. It sounds like other network operators and software engineers don=E2=80=99t want to modify their systems to accommodate your requirement, but if you don=E2=80=99t need their accommodation, you can build what you want. Lee From nobody Thu Aug 17 09:04:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DD51321D0 for ; Thu, 17 Aug 2017 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbcHlBywk52d for ; Thu, 17 Aug 2017 09:04:02 -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 818471321A7 for ; Thu, 17 Aug 2017 09:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502985840; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=unlHJ1tkx1jfzM1EKaxl4mp/aQOata5YoB3sviuhi08=; b=AT9T/jpDToTaF/B9/piyNCwZ3y4g85y1X6t0QAB7jQ14Ebvr2L1+lFo0BQKbn5pXAdrqcr/W12rtCCnachacw2ESKiN2ILRIC2ftz2J192lTmOmWX4M8ipEF1CvIUO8wvj69UKlR7XoOg1+Weh9VsUtZ0bFcabmNm+AdA85iTa4= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0056.outbound.protection.outlook.com [213.199.154.56]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-128--LSnHWdWPpak26-H33iTog-1; Thu, 17 Aug 2017 17:03:57 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB260.eurprd07.prod.outlook.com (10.242.17.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Thu, 17 Aug 2017 16:03:55 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.01.1385.003; Thu, 17 Aug 2017 16:03:55 +0000 From: Tim Chown To: Timothy Winters CC: Lorenzo Colitti , Simon Hobson , v6ops list Thread-Topic: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) Thread-Index: AQHTFwPkIR0hUkJRmUWLZheKIbsHcqKH3C2AgAB4YwCAAALAgIAABzkAgABYSAA= Date: Thu, 17 Aug 2017 16:03:55 +0000 Message-ID: <6FF0E188-7F66-4494-A6D2-59DDAAB2B92B@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB260; 20:sJr6/TAhhJTdiz8JwV/BJe3OTgtNSAyzZes8v+pdC75Fpa1Dp84faZsmRFLeCm15WZgYZiq/BYqsMLjgYEGHSvOaulpijeJQSC3cKB+3fbb2EHIoa/w6e4k/TBlYgA03p21s7wwxPI5+TUgvPv80Anu4n2AwgLjoXPZW8Q7iWEE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 57cc1be5-0d50-49ea-7166-08d4e5899031 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB260; x-ms-traffictypediagnostic: AM3PR07MB260: x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB260; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB260; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(189002)(199003)(2906002)(101416001)(6436002)(53376002)(3280700002)(7736002)(6246003)(305945005)(6486002)(6506006)(53936002)(50226002)(53366004)(42882006)(8936002)(2950100002)(76176999)(50986999)(93886005)(110136004)(2171002)(6916009)(66066001)(229853002)(81156014)(25786009)(81166006)(8676002)(36756003)(82746002)(106356001)(34040400001)(4326008)(478600001)(97736004)(53546010)(33656002)(1720100001)(5250100002)(2900100001)(230783001)(72206003)(86362001)(189998001)(99286003)(3846002)(57306001)(74482002)(3660700001)(83716003)(54906002)(6306002)(6512007)(966005)(102836003)(6116002)(105586002)(14454004)(68736007)(5660300001)(493534005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB260; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 16:03:55.7740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB260 X-MC-Unique: -LSnHWdWPpak26-H33iTog-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 16:04:06 -0000 Hi, > On 17 Aug 2017, at 11:47, Timothy Winters wrote: >=20 > Most operating systems give up if they fail DAD. For SLAAC, RFC7127 includes a DAD counter in the IID generation algorithm, = and specifies how to use that in https://tools.ietf.org/html/rfc7217#sectio= n-6, but has anyone tested whether existing implementations are doing that? DAD itself failing to detect the duplicate is a separate - but of course im= portant - issue. Tim=20 > Tim >=20 > On Thu, Aug 17, 2017 at 6:22 AM Lorenzo Colitti wrot= e: > For non-EUI-64 addresses Linux usually retries. >=20 > However, the problem is not so much when DAD works as when it *doesn't wo= rk* (e.g., because devices drop multicast when asleep). In that case you en= d up with duplicate addresses. >=20 > On Thu, Aug 17, 2017 at 7:12 PM, Tim Chown wrote: > > On 17 Aug 2017, at 04:01, Lorenzo Colitti wrote: > > > > On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith w= rote: > > "If IPv6 IIDs were reduced to something like 32 bits, would any of the > > above be impacted: > > > > - Available and Reliable: No. May have a positive influence, as > > availability and reliability possibly could be increased, as ND cache > > resource exhaustion attacks effectiveness would be reduced. > > > > Actually the answer here is also "yes, negatively". It means that netwo= rks with large numbers of users would become unreliable because of IID coll= isions. There are networks that run 10k or 20k nodes on a single subnet. La= rge corporate networks are an example, or large conferences such as MWC. >=20 > Is there info anywhere on what the common OSes do when they encounter a D= AD failure - do they give up or try a new tentative address? >=20 > Tim >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 > Now offering testing for SDN applications and controllers in our SDN swit= ch test bed. Learn more today http://bit.ly/SDN_IOLPR >=20 From nobody Thu Aug 17 09:46:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A51321BF; Thu, 17 Aug 2017 09:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqqh75s2A6Ya; Thu, 17 Aug 2017 09:46:20 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19AD132055; Thu, 17 Aug 2017 09:46:20 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id g131so72070443oic.3; Thu, 17 Aug 2017 09:46: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=/V2d7MsnYemaiYJBcvj8gehRaLGhLMKQ9THCPOsE0Tc=; b=E+BIdHrxCHOoA0steNa+6phgsIIXzDkUcfB/N5Z9Oaan2QKPoLD6lXQs5+paoHHK4I axgt3p1YO3/GUsVbwojN0Ucl1S+39n/LDGwBUGA84FZB/IvuvQciGM5Vn0UUZrMO0DFU /H0kLmrRtcWSR+WK/mSnjbYUuyAl3iEkE/dtg0vltY6+TWTr95r2a3PIwWAf1z+GvHqh 1VsjvgIlmBLxa6JIc7eRoytg8Ka+TiJnrcFOotl0mEwsCBxGUncfvSSNUPYJJ89VSZ2d qMDm61R+xCES8GmlxO3dXcH6B4JghzzYhz0zB+MB0LTqQHeBOC66mrHwKS13Rt+zIB5L W6VQ== 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=/V2d7MsnYemaiYJBcvj8gehRaLGhLMKQ9THCPOsE0Tc=; b=q+GNbyDvFGb83q7/lMSTFs7dRdyOS5mV7+PXKgeq932hkqZA6XjptXCHgOlv3QqqML gnjyn/kSihFqKJRy5mMYd/zhPYXACriF/C4i/3vjAbXINKiZcq8LCjfjRTQZdz003IwX +fO0e1B60FVe404RqmfJw+LaIRqvIDeMK0FivHV09nQ4/AJZ0LgdXn4z0syijysWE/wv aYmjaPm3gKkYbvyL6GSLaOnHK641boeU8Kmu+oijEF/U3QR+l+QMJdWjsOe0Kxz3VCs8 7CAkiV/vxZ9mLsKqMCDEUdvLuj3FjmeOc7OKs7WdKvU0DsFWqkmYQQQ7baz3wUHZPREg Z9Fw== X-Gm-Message-State: AHYfb5i4rdP1Ivj+5cBmamye3s5wadJE1wVaGW+mEH/dgn6QDRJtMZZ/ zeoTk461TGv11w== X-Received: by 10.202.74.68 with SMTP id x65mr7677263oia.316.1502988380169; Thu, 17 Aug 2017 09:46:20 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1281? ([2600:8802:5600:1e::1281]) by smtp.gmail.com with ESMTPSA id 82sm4564290oib.57.2017.08.17.09.46.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 09:46:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.3\)) From: Fred Baker In-Reply-To: Date: Thu, 17 Aug 2017 09:46:17 -0700 Cc: "STARK, BARBARA H" , JORDI PALET MARTINEZ , "v6ops@ietf.org" , "sunset4@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <034F179A-7D3D-41DA-AC94-2634AD404BC0@gmail.com> References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DC00555@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Lee Howard X-Mailer: Apple Mail (2.3445.1.3) Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 16:46:22 -0000 > On Aug 17, 2017, at 8:41 AM, Lee Howard wrote: >=20 > I will argue to both working groups that we should find an > operator who thinks this is a good idea. I hope we can get them to = write > it up. If there is no such operator, we should remove the section (or = at > most, footnote it as an idea somebody once thought of). IIRC, Terastream looked at the idea a few years ago and eventually = dropped it. They might be interested to say what their thought processes = were - pro and con.= From nobody Thu Aug 17 09:49:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD0132331 for ; Thu, 17 Aug 2017 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hypergeek-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 dCW4VL-3J6vS for ; Thu, 17 Aug 2017 09:49:52 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0C01321BF for ; Thu, 17 Aug 2017 09:49:52 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id t3so18478838pgt.0 for ; Thu, 17 Aug 2017 09:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hypergeek-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6U0mLEKxyfv9TUEb+NANb0rPu/uv876HU7Pph9a7n0w=; b=E3IU2gZvvPg/lxJhTszlUwLE9UaJurHr8TVEH3uvVwzgNEWaGRX0hAjI468VPKjPn7 30gyQLAtHm4ZQOJr2+FhwJyuX5Yks3g4FEqmkfvCGWDXdTt+xPW7hDvO5Jm47rrZF1L9 rGoa6Za8v4hwVWiAHWhgkoVgvj9BDbXYXpQcSQlVMBJnUkT0g9247xvQgFBQweykx1Xd vV5n/inZcKPXivKQUw9BPmzD5J+L2YSKRJ2EQRyK0h5oGWwIfrZ7T/WS/q6KtULn/1VG iyfvj86OozSpxmlexybmkplc1+xYs9yIAlq8eHk+aO7mkostnD/rx/BLlj5m16hrTMuR jh2g== 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=6U0mLEKxyfv9TUEb+NANb0rPu/uv876HU7Pph9a7n0w=; b=qQntqI27YnnVajCJHH0UYjCb9UX4Q/MIlKxHii78uo0NBmPH35ZYAieIpRa3y0Xtg+ /xNj0fftCLotbJllFlq5n/121MfHodmnt1qxUl3JYWg52CFS7K6dZncD3q+HeGy5pgCe RaOrkES3IYW2kKQfffL4Jy6Gp9KEVi4SB1K8wqd3OURekXYPnAhEb3MR01mfw4kXe7Be hJ2w/UtlHEb2xYo88SCYXUqRvDmw6rxKSFo7dsnt7IT5z4XjCiS7UtK+heUDMZEghaTs NiDxkUz1f0JgEV2rsV7gVn9C3C/9+ZjzdRaejsb8kOGWsJBTQGAnsEyHCDlbYzDqS74Z TzYA== X-Gm-Message-State: AHYfb5hctJEtQNsY+uPJ91ZWwHQmaMPDZJ/f2aTkyhWFVPEIdRcoJm11 dbomCfy/FcCKdjUl X-Received: by 10.84.130.104 with SMTP id 95mr6372509plc.411.1502988592130; Thu, 17 Aug 2017 09:49:52 -0700 (PDT) Received: from ?IPv6:2601:646:8100:14b7:908c:8795:e918:8b54? ([2601:646:8100:14b7:908c:8795:e918:8b54]) by smtp.gmail.com with ESMTPSA id z127sm7496017pfb.64.2017.08.17.09.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 09:49:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "John A. Kilpatrick" In-Reply-To: Date: Thu, 17 Aug 2017 09:49:50 -0700 Cc: Mark Smith , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <94FDF63C-106C-4B90-A564-F47BFBA2F190@hypergeek.net> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 16:49:54 -0000 > Actually the answer here is also "yes, negatively". It means that = networks with large numbers of users would become unreliable because of = IID collisions. There are networks that run 10k or 20k nodes on a single = subnet. Large corporate networks are an example, or large conferences = such as MWC. I would love a way to instrument that. We can do the probability math, = but I=E2=80=99d be curious to see real stats for =E2=80=9COn a network = of X nodes, the average DAD failure rate was Y.=E2=80=9D I had a = segment once with about 6k clients, but I didn=E2=80=99t consider = figuring a way to instrument DAD collisions. =20 --=20 John A. Kilpatrick john@hypergeek.net Email| http://www.hypergeek.net/ remember: no obstacles/only challenges From nobody Thu Aug 17 10:19:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1958131D19 for ; Thu, 17 Aug 2017 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5nS5Sby8S7Lv for ; Thu, 17 Aug 2017 10:19:12 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBAE120727 for ; Thu, 17 Aug 2017 10:19:12 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id m84so6585143qki.5 for ; Thu, 17 Aug 2017 10:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b5mgxTyS56/48LcqK545IkV7B/DvKSgHU/tWSVbJ5dE=; b=gBMCCHVRVrB5zjPJgyDqVPNcf8jsAsY8waB6WEb9+xtsVsVA8GkZVGEZERW/1t43YJ P1CfD7uqbERWmYmoOj9cK3yYGjC45Oj0vuWGlQ7/qywe+B0zh+H6NVMZRkZkOjeHSUET Z357YMqEM8U/feA8gfUk3AiVrmCe5zMtESkcukExOwQCI5RGmQ1l4da1TWCjpHeWzc5r fudmC5ukgpTfcrBuYrTBGuRxOOVFWKVcQsBQA5okr2I4UKz7aG9VfARcbrqXz7SSpGqP Oay+BfMBN4JS0SuBplCVapc7MecdZ43sRUZWnJiNO5DTQwnEWqcdVNHdBEhxMwFnDM5j IoRA== 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=b5mgxTyS56/48LcqK545IkV7B/DvKSgHU/tWSVbJ5dE=; b=GlYu5GCb1j0nru0JGqHA+AOHPZqHPhiefCMJBtWlxsIwAwVK+mNvDrFMPn2apq2dph 7kF4MO8/huiA3sFr4xTQWMXzkBwJCS313v+t5W0klZCtBbUVuRv+FOfAv9DEKyUEn7Xh riY70R0NqgJ4753RcABBtssJXufS9OPmcRTapk+6C6J0PslhV3C3/tVYwgHh4VsmPa74 CDfnLfinacrVcFC4FwJImmnAaYpbCYiEWzpehFDAh782enyT22JjC+vueqV0ZD3wNeg5 NZnYAXoPHh97t0llONhq/pOk600hzAaHVccNQ7BwP0aRwBgGd5OKlKqZbUGsj0KfSPP9 SeVQ== X-Gm-Message-State: AHYfb5g3TUBHilvJD2Yt7bw90IPTEoEhSl62AiVlkkfqaBbUiubOpPU+ DYALN5P4CnJCW/yiJhV7krEE2wi15yF7 X-Received: by 10.55.207.211 with SMTP id v80mr7780252qkl.51.1502990351461; Thu, 17 Aug 2017 10:19:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.165 with HTTP; Thu, 17 Aug 2017 10:19:10 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 17 Aug 2017 10:19:10 -0700 Message-ID: To: Mark Smith Cc: Brian E Carpenter , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 17:19:15 -0000 On Wed, Aug 16, 2017 at 7:51 PM, Mark Smith wrote: > So how do we evaluate what is the best solution? What are the criteria to use? > > This discussion is going in circles because I think people have > different opinions on what the criteria are. > > Mark Nottingham has been working on the following draft, > > "The Internet is for End Users" > https://tools.ietf.org/id/draft-nottingham-for-the-users-05.txt > > which says that what is best for the end-user needs should trump any > other parties' needs. I entirely agree. > > What is best for end-users is the fundamental goal. I've thought it > would be useful to have a set of high level and end-user oriented > criteria to use to evaluate various technical choices, in particular > when there are situations such as this one. > > I've thought there are the following 3 high level end-user criteria to > use for evaluation: > > * Available and Reliable > > * Secure and Private > > * Cost Effective > > It seems to me that all IETF solutions should meet all of these > criteria, ensuring they are prioritising end-user needs. > > I've suggested these to Mark for his ID, and to demonstrate their use, > I used the 64 bit IID example. My evaluation was rushed for the > purposes of example in the email. There are other Secure and Private > impacts other than just being able to successfully scan a 32 bit > address space. Another example is that reducing shrinking IIDs to > increase the number of prefixes available within an assignment e.g. a > /32 doesn't improve Cost Effectiveness because their RIR cost is > trivial (a /48 is 1 or 2 cents per annum), and route table slot use > doesn't change. > > "If IPv6 IIDs were reduced to something like 32 bits, would any of the > above be impacted: > > - Available and Reliable: No. May have a positive influence, as > availability and reliability possibly could be increased, as ND cache > resource exhaustion attacks effectiveness would be reduced. > > - Secure and Private: Yes, negatively. It is practical to scan 32 bit > address spaces e.g., shodan.io. 64 bit random addresses are effective > at mitigating device discovery via unsolicited packet probing, 32 bit > random addresses would not be. > The corollary to "the Internet is for the end users" should be that "end users should never trust the network". If you want security and privacy it should be implemented end to end. Networks do not uniformly provide security for users, which is to say that the base assumption is that they do not provide any security and are themselves insecure. For instance, the moment we send a packet with a source address into the Internet the best security assumption is our address is now known to the whole world-- the packet may be logged by switches, servers log it, there may third party interception, etc. It follows that random addresses are not real security from a user or host point of view. There is a motivation to use different addresses for connections from a host so that two flows cannot be correlated to originating from the same device, but that only works if the device specific portion of the address is different which would not currently be the case for UEs assigned a single /64. Tom From nobody Thu Aug 17 10:38:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FD31323F7 for ; Thu, 17 Aug 2017 10:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA7B5iB65BfT for ; Thu, 17 Aug 2017 10:38:39 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787F5132406 for ; Thu, 17 Aug 2017 10:38:39 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id 130so5819656qkg.2 for ; Thu, 17 Aug 2017 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rDyI+hlc+sw53FzjnWgDuBF2B+zeEyjb21DqlaQbBz4=; b=X1WPbwqB3aqkApoIfO04INqk2goB2Fy8ZIMGSNWLsANVaHQ5N/n/vPrEfkzeYpZcZz EuWqChmwu/8K2S5xYGMcUjqS0oU2QfDhrxMJA0LpoVTPjUUrXQNs2NUdu6YCylACbR8q tyclchwka7hhiq1rS03zPsS5yp/peg6zPJC83zFtdXOg5BfVgEFFYDBIHHzcDpHHytg6 +/OCstzfbRRMkh9SlMlCRXlD+QzfFUjFa8JtR/VX6WlYiGpGTIrhHc+s+QYXnzMTRbB4 0ww9KbIxaIaBW6BwsR/s0e3aKP0e01zYYs17x7QYRMyVwQCWxfuEQoC/oX4Js6hqqGdX oIeQ== 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=rDyI+hlc+sw53FzjnWgDuBF2B+zeEyjb21DqlaQbBz4=; b=tOZCBv//vGaX3YQlQ8C45sXLYcEAUhxnCwa47xljOKLmervk6jYqadR3Ln4acPEClJ g0DuH6NjP4O0GL/lQXcAesbeRlru/fVhDlAD2Hw6uTLFtiLG1G6wwLs01I8oyqCFi/Xe UjgvULoXpil8UVONZtOCTS+nS84MdMS5xN9wMjra376pRjBLlLS2AA+Dvd4ORfSFXURu uoIH78NME7n1wK+RIpewGMv3dPUK9Cpvto59bmaDo6GyPcNevhn0jhw7y6njjCXPKcOY LSWLc+KDiXCVAzqGcIt4s/fV5AeOLGjpWWspM98QgWda0NCsDuqu64SW+2QJBtz5Hnul 1NoQ== X-Gm-Message-State: AHYfb5i7Ccht/TFIchOdjyBCRTuS8KskOpF+x8MLGbqWYgcjnoFTuFVu uTlMJ3Ie30mvAQyapgvYTA== X-Received: by 10.55.41.39 with SMTP id p39mr8748934qkh.353.1502991518674; Thu, 17 Aug 2017 10:38:38 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 26sm2735841qtp.60.2017.08.17.10.38.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 10:38:37 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2C6581C7-8B58-41BB-A869-32EE2A75A53C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 13:38:37 -0400 In-Reply-To: Cc: Mark Smith , Simon Hobson , v6ops list To: Tom Herbert References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 17:38:41 -0000 --Apple-Mail=_2C6581C7-8B58-41BB-A869-32EE2A75A53C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii El 17 ag 2017, a les 13:19, Tom Herbert va escriure: > If you want security and > privacy it should be implemented end to end. Even that's not good enough, since your metadata can be tracked. --Apple-Mail=_2C6581C7-8B58-41BB-A869-32EE2A75A53C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 17 ag 2017, a les 13:19, Tom Herbert <tom@herbertland.com>= va escriure:
If you want security and
privacy it should be implemented end to = end.

Even = that's not good enough, since your metadata can be tracked.

= --Apple-Mail=_2C6581C7-8B58-41BB-A869-32EE2A75A53C-- From nobody Thu Aug 17 10:58:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5690313243A for ; Thu, 17 Aug 2017 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUX8RTlJvkY7 for ; Thu, 17 Aug 2017 10:58:04 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0999413241D for ; Thu, 17 Aug 2017 10:58:04 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o124so32459673qke.3 for ; Thu, 17 Aug 2017 10:58: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 :cc; bh=1eX4YQvEBeX8QBekP41l2Dd9GnBR4L+aqj6TgGa3tTo=; b=woMmswWezNkSlVwSLfH97RWlfs+DzyM432jNPW86JHQGPOMZiGZ2Yuf8zietWH7bw+ LCg1iCNKZ2e1ffhRFya+qaLYy0whl8MJM491cRbS0JpqUG4Fj4rB3NGp8WvrjuEyOXbO HIFeEUYrblQAuTHL7VD4YCjCYuRdvfmaZDJFjBOIfOffeqA6n/GiKt+D+Rv+Z2cdU4Wg 3CFWGbX6iYwjFEL+CLiX6uGoY8TA1HZQVrm2VIm1/4BK2TmhES/zagSPxpYl2vq9dlkI fGsDE2wb7F/dT/KwMW41sNM68Grvivo6va1jqlFUyRfBHdqLfRfjaZl94qPA6d3TeM7Y VzxA== 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=1eX4YQvEBeX8QBekP41l2Dd9GnBR4L+aqj6TgGa3tTo=; b=E3mObUtSdiGoh30+1wBPIEspvZk6MVbIdHGsFRRhsOmHA74YjUFIPiFTMjGGGEqGPr CSAVfgHGXOnW7T3LCtfUKTjQW15Hco6FypbrrlHlEoxMIJ/LfPr5NeqFQT0gEbJ3bm+Y vEhzlsi2LZk0DJclVOX1WTA6keIiVLyESApxA7cYvU99vfpvHzISSmXwPlJ0iMJ0iRWq 8MD8PZpSbjAkadI/2SU06Itvpz0AtLN7HC/obZ1HQC/PS7EzN5gbfMm4D4paWVUPhbnT Jved7G+zhfAz97Us2ld4esl/tHQIqcZRD1IyEga1PZfxNPmeWIw6/+whtUKCux29sMbp rO0w== X-Gm-Message-State: AHYfb5iQtI0tbIxDvF2towu6RY2PLX74Kf1YXPLYXmsflqnXmO1Pl+xp IUlLAIU/PqdvJvwFbpNVi3MDcFz51NeJ X-Received: by 10.55.161.139 with SMTP id k133mr1949060qke.345.1502992683101; Thu, 17 Aug 2017 10:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.165 with HTTP; Thu, 17 Aug 2017 10:58:02 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Thu, 17 Aug 2017 10:58:02 -0700 Message-ID: To: Ted Lemon Cc: Mark Smith , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 17:58:05 -0000 On Thu, Aug 17, 2017 at 10:38 AM, Ted Lemon wrote: > El 17 ag 2017, a les 13:19, Tom Herbert va escriure: > > If you want security and > privacy it should be implemented end to end. > > > Even that's not good enough, since your metadata can be tracked. > Ted, That's a good argument that everything in a packet should be encrypted except for the IP header and options that are necessary for delivery. This becomes essential to prevent tracking. For instance, one of the problems posed in IDEAS list is that long lived connections are easily tracked in time. A proposed solution is to allow dynamically changing addresses of an existing connection. This obfuscates the addresses nicely, but if there's still connection acks #s, seq #s, and ports in plaintext it's little bother to be able track the connection across an address change. So to prevent such tracking, anything in the packet that could be used for tracking identity needs to hidden or obfuscated. Simply using random addresses is not nearly enough. Tom From nobody Thu Aug 17 13:36:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE94013228D for ; Thu, 17 Aug 2017 13:36:51 -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 wTx8ZtJFtHV6 for ; Thu, 17 Aug 2017 13:36:50 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA311323AA for ; Thu, 17 Aug 2017 13:36:50 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id y192so11525437pgd.1 for ; Thu, 17 Aug 2017 13:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EYU+cP1Nr8+1KDurWDrsgcmwqACcHElYS5HENgu9zjA=; b=vVhkEZx7b7eibm6P0AytnCbyoCf5kwmEXlHB5zeTkOP0U9OCA7RZXL6nB2HMDc5Q2u Zlu+hAE5K+AL8M6xraRDpU2JjRKYbSXZhRpwFM0X56Vr4j6qLb5uGQAUtTHH1tIXuY4T kBk3lEw+nYwO7/5sSXkA2f+MgL0YidVujYkmzBZsgssKEZ/1fqGa8q2hymU2wcIbQUXp 94UKk8dayVaI27brdaO7FDmHPMJ1rjXnJKcCb0Q7PXIIg8w5+RgODE5S3vmaCEWMZxn3 nDbeVku2YjquGG+ULKow4yyvqlRXvGPASIT9v+PVU0bIm6yaEl8MD5YUMkQOx4qrXaOX t5bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=EYU+cP1Nr8+1KDurWDrsgcmwqACcHElYS5HENgu9zjA=; b=I5yfkTaVHLbFw1aGIad7Q5oTQNaEqmeq1bp2k5OPxrjzIB/p+f0y+BQvL2jUXCelVI jsQWNS5TCnh8Jb+/58da5Y1YIrOT4AI+vCBzGylJBc4SIEm3cNd/ZBTu0KRM6bifMpHA jaoEpyHBii7JhhVFVcwS9jWRydXji1L3U2WRLgHkw4hwkgsUyY0W0YxO1+IcUPuIQ7fE 79jbpu0Bww/JuCGY7eYGU89OErN5OkaymmJpxHmuJGrQ6KfT7HekTj9iJL9fIg8XADx6 iS/65UUDdYDYQ3LkURha/uDeyTjgruaL+LGX9icbItOra0eh388Q8L/TVkJCwXVGuy2u HGqA== X-Gm-Message-State: AHYfb5hi82t4lFPNbIdjz1vGJ1c5mq6eYBCPl3JDJQutEY9V1GlwzLSI OAwufWmjjlmRwAYg X-Received: by 10.84.129.45 with SMTP id 42mr7060175plb.229.1503002209377; Thu, 17 Aug 2017 13:36:49 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b68sm9313523pfd.33.2017.08.17.13.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 13:36:48 -0700 (PDT) To: DaeYoung KIM , Mark Smith Cc: Lorenzo Colitti , Simon Hobson , v6ops list References: <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <85DFAB58-149C-405E-A497-3CBB497828B4@gmail.com> <1EFE4702-B7E2-4672-BAE2-AE1C0200462E@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 18 Aug 2017 08:36:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1EFE4702-B7E2-4672-BAE2-AE1C0200462E@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:36:52 -0000 On 17/08/2017 18:36, DaeYoung KIM wrote: > > > Sent from my iPhone > >> On 17 Aug 2017, at 15:02, Mark Smith wrote: >> >> Hi, >> >>> On 17 August 2017 at 15:31, DaeYoung KIM wrote: >>> Yes, I did. What do I miss? >> >> It seemed that you might have missed that there are security issues >> IIDs with low entropy e.g., the MAC address derived ones, e.g., being >> vulnerable to address scanning. > > Discussions in that privacy doc are mainly based on a typical legacy network of /64 subsets of an arbitrary size whereas mine example is with a single /96 device. > > On the other hand, I'd be more concerned about the entropy of /64 hosts in a /48 site. Scanning would be over 2^32 /64 hosts. > > Back to 32 bits for my device IIDs, if there be insists, I could switch to 48 bit IIDs with /56 prefixes for my internal devices. I remember I read somewhere that bits around 40 would secure enough entropy for privacy (or was it for collision avoidance?). That's mentioned in a hand-waving way in https://tools.ietf.org/html/rfc7421#section-4.5 2**40 is roughly equal to 10**12, which makes brute-force guessing quite hard. Brian From nobody Thu Aug 17 13:48:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD911323AA for ; Thu, 17 Aug 2017 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51ACeakorsxZ for ; Thu, 17 Aug 2017 13:48:55 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25803126B6E for ; Thu, 17 Aug 2017 13:48:55 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id t80so22599573pgb.5 for ; Thu, 17 Aug 2017 13:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gcUCOwyoTwE+wTbY73ow4KWG0U/fgjZn8TpQlmUNywk=; b=bOiDSDM0KQUis4q3IDKQ6OWaIuD7cU2NlM7N+0RNiyN9D/uJJEVb+T8083gq4cPDmp 2TrH0c2jf7xLNxHE53e1xG5wUvR0h/j255tfpxcNI2ZN9Uf4yMSwOuWZhNO/wYhQRf/t u0vRsP6qwuMY0nmp7jXQoLJTlsdzKjvJ2SZ4kbbGI5zgTShoXjQpzSyPW85NVuTsjzNU EPr0nvEYN9KAPEv/ydptvMs9awIuYQFVx4Vf71RuuYqqKvTWvAUY58V7qeqKgNCl5STe BHtph8ldQfUGTklQx4BG7zvZq0JxzriY8HsZkbM/dsF2kym1Au7+Rd4DDxAcCG9fRkdu CvDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gcUCOwyoTwE+wTbY73ow4KWG0U/fgjZn8TpQlmUNywk=; b=oAVdVuaojdxsHgCE2diAPIT8QrXfAgZv3ch+IbU8IfSmPHkS6g514T1hNdhEyBNNRZ /JFDpS1g+RMpzleU2P7JSsDfciAMC+ZAi5BMeaq+HBvD3FeIIbeKavUIhWfEPd6dTUNF vPYjGaFkQ+VrPEmj4E3mJDZvo2lR/3p+13Q3b2ngIZFFEBwgIDOQMEuElRH2LKpvsLNu kEYPmM1Edp3IbbcG0OlJuCNMvRcRkh1Edhus8L1pKGhyYevmzxP8RQUB00nhf8OIPM61 bfqDfxM+hLLILS48LRws6roaKDPxrJvm36DfQW0mrO2ARTqYTZW6iJ9Xcjp69St27dsU Dxuw== X-Gm-Message-State: AHYfb5iwUBl5bvFgUodCD8d53JUtOb50XA2Dnahrjz0FBegbzrMBX79x rDtjxOJtzvxV1lf3 X-Received: by 10.84.209.170 with SMTP id y39mr4395436plh.340.1503002934572; Thu, 17 Aug 2017 13:48:54 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h14sm8591740pgn.34.2017.08.17.13.48.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 13:48:54 -0700 (PDT) To: DY Kim , Ole Troan Cc: Simon Hobson , v6ops list References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> Date: Fri, 18 Aug 2017 08:48:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:48:56 -0000 On 17/08/2017 21:05, DY Kim wrote: > --- > DY >=20 >=20 >> On 17 Aug 2017, at 17:58, Ole Troan wrote: >> >> Have you read RFC7421? >=20 > Yes, I did. With my own bias, the doc looks quite in the interest of de= fending one school of thoughts. I am puzzled by that remark. The authors included a range of opinions and= we worked hard to presents facts (both facts about the published specifications and= facts about observed behaviour of implementations). And the opening paragraph s= tates "IPv6 routing is entirely based on variable length prefixes (also known a= s variable length subnet masks), there is no basic architectural assumption that n has any particular fixed value." So I'm afraid that the document is actually stating something about reali= ty, whether we like it or not. Brian >=20 >> What problem are you trying to solve? >=20 > Not really. I find it a bit amusing that sometimes logics seem to be ov= erridden under the name of =E2=80=98rough consensus=E2=80=99.=20 >=20 > And =E2=80=98recommend=E2=80=99 is one thing, and =E2=80=98mandate=E2=80= =99 is another. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Aug 17 13:59:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71649131D19; Thu, 17 Aug 2017 13:59:29 -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 5Qrup0QdpvFI; Thu, 17 Aug 2017 13:59:27 -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 E5D90126B6E; Thu, 17 Aug 2017 13:59:27 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7HKtgdD013680; Thu, 17 Aug 2017 16:59:16 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2cdj8wgwt3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 16:59:15 -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 v7HKxENV021626; Thu, 17 Aug 2017 16:59:14 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7HKx9fP021600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Aug 2017 16:59:11 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi134.aldc.att.com (RSA Interceptor); Thu, 17 Aug 2017 20:58:54 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.30]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0319.002; Thu, 17 Aug 2017 16:58:54 -0400 From: "STARK, BARBARA H" To: Lee Howard , Fred Baker , "JORDI PALET MARTINEZ" CC: "v6ops@ietf.org" , "sunset4@ietf.org" Thread-Topic: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt Thread-Index: AQHTFtPhi+wo0/l+sUG0TolNU5N+WqKH5EkAgACh8xCAAG2hgIAACQOA Date: Thu, 17 Aug 2017 20:58:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DC00F4F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <150158713179.9574.7767168468574012763@ietfa.amsl.com> <0E0D8D4F-A487-4572-A7D2-C77635280329@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DC00555@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170338 Archived-At: Subject: Re: [v6ops] [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:59:29 -0000 PiA+PiBUaGUgcXVlc3Rpb24gSSB3b3VsZCBhc2sgaXMgd2hldGhlciBvbi1kZW1hbmQgSVB2NCBt YWtlcyBzZW5zZS4NCj4gPiANCj4gPkkgdGhpbmsgIm9uLWRlbWFuZCBJUHY0IiB3b3VsZCBiZSBy YXRoZXIgZWFzeSB3aXRoIFBQUG9FLiBNYW55ICh0ZWxjbykNCj4gPklTUHMgYXJlIHN0aWxsIHVz aW5nIFBQUG9FLCBhbmQgdGhlcmUncyBzdGlsbCBhIGxvdCBvZiBlcXVpcG1lbnQgYW5kDQo+ID5y b3V0ZXJzIHRoYXQgc3VwcG9ydCBpdC4NCj4gDQo+IFRoYXTigJlzIGV4YWN0bHkgaG93IGl0IHJl YWRzIGluIHRoZSBnYXBhbmFseXNpcyBkcmFmdDogaXQgbWFrZXMgc2Vuc2UgZm9yIFBQUG9FLg0K PiANCj4gSG93ZXZlciwgSSB3aWxsIGFyZ3VlIHRvIGJvdGggd29ya2luZyBncm91cHMgdGhhdCB3 ZSBzaG91bGQgZmluZCBhbiBvcGVyYXRvcg0KPiB3aG8gdGhpbmtzIHRoaXMgaXMgYSBnb29kIGlk ZWEuIEkgaG9wZSB3ZSBjYW4gZ2V0IHRoZW0gdG8gd3JpdGUgaXQgdXAuIElmIHRoZXJlDQo+IGlz IG5vIHN1Y2ggb3BlcmF0b3IsIHdlIHNob3VsZCByZW1vdmUgdGhlIHNlY3Rpb24gKG9yIGF0IG1v c3QsIGZvb3Rub3RlIGl0IGFzDQo+IGFuIGlkZWEgc29tZWJvZHkgb25jZSB0aG91Z2h0IG9mKS4N Cg0KT24tZGVtYW5kIElQdjQgaXMgdW5yZWFsaXN0aWMgaW4gdG9kYXkncyB3b3JsZC4gVG8gYmUg dXNlZnVsLCBpdCByZXF1aXJlcyBhIG1ham9yaXR5IG9mIGN1c3RvbWVycyBoYXZlIG5vIGNoYXR0 eS10by10aGUtSW50ZXJuZXQgSVB2NCBhcHBzIG9uIHRoZWlyIGhvbWUgbmV0d29yay4gVGhhdCdz IG1hbnkgeWVhcnMgYXdheSwgZ2l2ZW4gY29udGludWluZyBzYWxlcyBvZiBJUHY0LW9ubHkgIlNt YXJ0IiBUVnMgYW5kIEJsdS1yYXkgcGxheWVycy4gDQoNCkFzIGZvciBkb2N1bWVudGluZyBob3cg dG8gZG8gUFBQb0Ugb24gZGVtYW5kLCBJIGNvbnNpZGVyIHRoYXQgdW5uZWNlc3NhcnkuIEl0J3Mg YWxyZWFkeSBrbm93biBob3cgdG8gZG8gdGhhdC4gVGhlIGNvZGUsIGVxdWlwbWVudCwgYW5kIG9w ZXJhdGlvbmFsIGV4cGVydGlzZSBhbHJlYWR5IGV4aXN0cyAtLSBlc3BlY2lhbGx5IGFtb25nIElT UHMgd2l0aCBhIGhpc3Rvcnkgb2YgdXNpbmcgUFBQb0UuIEJCRiBldmVuIGhhcyBSRyByZXF1aXJl bWVudHMgZG9jdW1lbnRlZCBmb3IgaXQsIGFuZCBuZXR3b3JrIGVsZW1lbnQgYW5kIGFyY2hpdGVj dHVyZSByZXF1aXJlbWVudHMuIEkgc2VlIG5vIG5lZWQgdG8gY3JlYXRlIGFkZGl0aW9uYWwgZG9j dW1lbnRhdGlvbiBpbiBJRVRGLiBJRVRGIGhhcyBuZXZlciBiZWVuIGEgZ29vZCBwbGFjZSB0byBk b2N1bWVudCBhbnl0aGluZyBzdWJzdGFudGl2ZSByZWxhdGVkIHRvIFBQUG9FIChQUFBvRSBpcyBu b3QgYW4gSUVURiBzdGFuZGFyZDsgaXQgd2FzIHB1Ymxpc2hlZCBhcyBhbiAiaW5kZXBlbmRlbnQg c3VibWlzc2lvbiIgaW5mb3JtYXRpb25hbCBSRkMgYmVjYXVzZSBubyBJRVRGIFdHIHdvdWxkIHRv dWNoIGl0KS4NCg0KSSBkb24ndCBjYXJlIHN0cm9uZ2x5IHdoZXRoZXIgb3Igbm90IG9uLWRlbWFu ZCBJUHY0IGlzIHJlbW92ZWQgZnJvbSB0aGUgZ2FwYW5hbHlzaXMgZHJhZnQgKHdoaWNoIEkgdGhp bmsgaXMgd2hhdCBMZWUgc3VnZ2VzdGVkKS4gQnV0IEkgZG8gZmluZCBpdCBvZGQgdGhhdCBpdCBz aG91bGQgYmUgcmVtb3ZlZCBqdXN0IGJlY2F1c2UgaXQgd291bGQgb25seSBiZSB1c2VmdWwgZHVy aW5nIHRoZSBhY3R1YWwgc3Vuc2V0IG9mIElQdjQgKGFuZCBub3QgaW4gbmVhci10ZXJtIGRlcGxv eW1lbnRzKS4gVGhlIGFuYWx5c2lzIGRvZXMgbm90IGFwcGVhciB0byBiZSB3cml0dGVuIHRvIG9u bHkgZGlzY3VzcyBuZWFyLXRlcm0gcHJvYmxlbXMgdGhhdCBtaWdodCBiZSBleHBlcmllbmNlZCBh bmQgcG90ZW50aWFsIG5lYXItdGVybSBzb2x1dGlvbnMuIFRoaXMgcGFydGljdWxhciBzZWN0aW9u IGNsZWFybHkgbm90ZXMgdGhhdCBpdCBpcyBvbmx5IHJlbGV2YW50IGZvciB0aGUgdGltZSBwZXJp b2Qgd2hlbiBJUHY0IHJlYWxseSBpcyBzdW5zZXR0aW5nLiBJIGNvdWxkIGNlcnRhaW5seSBlbnZp c2lvbiB0aGlzIG1pZ2h0IGJlIHVzZWQgbWFueSB5ZWFycyBmcm9tIG5vdyB3aGVuIGN1cnJlbnQg ZHVhbCBzdGFjayBwcm92aWRlcnMgc3RhcnQgdHVybmluZyBkb3duIElQdjQuIEl0IGFsc28gc2Vl bXMgb2RkIHRvIHJlbW92ZSB0aGUgZ2FwIGFuYWx5c2lzIGp1c3QgYmVjYXVzZSBuby1vbmUgdG9k YXkgd2FudHMgdG8gZGVwbG95IGl0IHRvZGF5ICh3aGljaCwgYXMgdGhlIGFuYWx5c2lzIHNheXMs IHdvdWxkIG5vdCBiZSBhIGdvb2QgaWRlYSkgb3IgZG9jdW1lbnQgaW4gSUVURiBob3cgdG8gZG8g c29tZXRoaW5nIHRoYXQgaXMgd2VsbC1kb2N1bWVudGVkIGVsc2V3aGVyZSBhbmQgd291bGRuJ3Qg YmUgdXNlZnVsIHVudGlsIHllYXJzIGZyb20gbm93LiBUaGUgZ2FwIGFuYWx5c2lzIGRvZXMgcG9p bnQgdG8gd2hlcmUgdGhlIHNvbHV0aW9uIGlzIGN1cnJlbnRseSBkb2N1bWVudGVkLg0KQmFyYmFy YQ0K From nobody Thu Aug 17 16:01:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22F132645 for ; Thu, 17 Aug 2017 16:01:38 -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 14nOIcLRfHFk for ; Thu, 17 Aug 2017 16:01:35 -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 CA8AD1323AA for ; Thu, 17 Aug 2017 16:01:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 2748ABD0 for ; Thu, 17 Aug 2017 23:01:35 +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 JautvbAKN3Yv for ; Thu, 17 Aug 2017 18:01:34 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id D68A9953 for ; Thu, 17 Aug 2017 18:01:34 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id z54so25209692uaz.2 for ; Thu, 17 Aug 2017 16:01:34 -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=axU2UFnDF8sT7y0d2gFc22GEkZwoKad79yIKt0H5MeQ=; b=Dc1z3xLrITZV8uEFK+fOiAquIK67xuAZ2rb5/PFNget9zELNr2aRmydpGBtUt9cTIj 6ipJu5PkJbgdV1llxhSoHRChR+jtfwXHNVE2nIpDFxDH1M0QeYHZ8okMxHKcf+mOsXjt IIBeeVWfhs32C1dwgx0caX/jt+x4gq+2uwFuyyPJlKdNYVt3eTbdOwx803jxBW4B8KuA FWhwm0019cw9bbT1j4UlGyo5NwpO8fJC3abIVttLEZR9U3SEOCug7lsu8LAWMNIaFvtA 2EnPiyOtVh1N2GFaJtXk6m3PlCre+OYYoJXZDrWSbZ/v34lQITuQpCQ5+GFmRIeRe01f payg== 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=axU2UFnDF8sT7y0d2gFc22GEkZwoKad79yIKt0H5MeQ=; b=iwNCsyU3KGquMOYvnQ2JYCpjA6svOnFsqDIwt7tBCCRVa4DC88mnxGxOLDVX1VPbHM Y3xvhmjurQiNQewBmwaQaRcNTjusTLsCUKDx+/lpCvK2eL5wkxsqdePCUWpKTz1Ozx1a 1vfcCudlYK+hkGNEixITSjRWZpgIw93VJWBT4y6hotAjRXZaZ5uQlT2jHojiprcnrN4D ou8458VPJLEIbMBvaSAZ2Npn+kPejjNQRB1NglVcYJhbyzJqRBzJ8vj3EfHXjOyFSkHE gDY2SU9xX/gznMjaOoIKBWklm5oK/vqnVk42rkjbEbJCyYj8HviQV1bLFF14DrZePRVT Htyg== X-Gm-Message-State: AHYfb5jFcuX6qi8hTkLbtmmxRf0gIztRP8kT7ydJ4NqUW7y3lTRKh1Ki AOm9CNKK0jBOZ4k6nBx/0IladsAkkEqCc3PWWgOLM3F8H/HHMYZNtoUBJveuNnT2duCedRQFG/D FOO+vqkpornTfzVEh X-Received: by 10.31.156.135 with SMTP id f129mr4612103vke.90.1503010894291; Thu, 17 Aug 2017 16:01:34 -0700 (PDT) X-Received: by 10.31.156.135 with SMTP id f129mr4612094vke.90.1503010894050; Thu, 17 Aug 2017 16:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.86.21 with HTTP; Thu, 17 Aug 2017 16:01:33 -0700 (PDT) In-Reply-To: <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> From: David Farmer Date: Thu, 17 Aug 2017 18:01:33 -0500 Message-ID: To: Brian E Carpenter Cc: DY Kim , Ole Troan , Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a1140f2706f07280556fafe61" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 23:01:38 -0000 --001a1140f2706f07280556fafe61 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 3:48 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 17/08/2017 21:05, DY Kim wrote: > > --- > > DY > > > > > >> On 17 Aug 2017, at 17:58, Ole Troan wrote: > >> > >> Have you read RFC7421? > > > > Yes, I did. With my own bias, the doc looks quite in the interest of > defending one school of thoughts. > > I am puzzled by that remark. The authors included a range of opinions and > we worked > hard to presents facts (both facts about the published specifications and > facts > about observed behaviour of implementations). And the opening paragraph > states > "IPv6 routing is entirely based on variable length prefixes (also known as > variable > length subnet masks), there is no basic architectural assumption that > n has any particular fixed value." > > So I'm afraid that the document is actually stating something about > reality, > whether we like it or not. > > Brian > I think RFC7421 fairly represents the facts as they are, in section 4.3.2 "Other Observations", it even says; Also, DHCPv6 is in widespread use without any dependency on the /64 boundary. Reportedly, there are deployments of /120 subnets configured using DHCPv6. I just wish we could get RFC4291bis to represent the facts as fairly as RFC7421. No, that doesn't mean that SLAAC with anything other than /64 and 64 bit IIDs should be allowed by RFC4291bis. However, it seems clear that other than for SLAAC, /64 is just a recommendation, an important recommendation all be it, but a recommendation and not a requirement. /64 is a requirement for SLAAC, changing that is out of scope for RFC4291bis as I see it. Personally, I'm just looking for RFC4291bis to represent the reality of IPv6 today. My personal version of that reality is; at work and at home my iPhone, iPad, and MacBook Pro all get IPv6 addresses with SLAAC from a /64 subnet, and I'm happy with that. I wish Comcast would give me more than one /64 at home. Maybe they do now, I haven't had time to screw around with my home network in 12 to 18 months. However, I've had native IPv6 at home from them for 3.5 years now, so I'm doing better than a lot of the world. My iPhone and iPad haver several IPv6 addresses from my carrier AT&T, but I don't seem to use them for Internet access. At work we are #89 and at 63% of our hosts doing IPv6 for July on http://www.worldipv6launch.org/measurements/ and we do SLAAC for most things. However, my MacBook Pro does allow for manual configuration of an IPv6 address and an on-link prefix of any length, and while I haven't tested I suspect the DHCP client will work for with other than /64 too. Also, most laptops and desktops, and all our routes at work allow manual configuration of any length subnets and work with DHCP with any length subnets as well. So can we please get past arguing about letting SLAAC use subnets other than /64, and update RFC4291bis to reflect the reality of IPv6 fully discussed in RFC7421. Once we've done that, then maybe we can look at retooling SLAAC, but that is not simply changing a few words in RFC4291bis, that is a major redevelopment effort, with new running code, and testing like crazy. That will be a lot of work, it may or may not be worth it, but that should come after we get RFC4291bis updated to the real world described in RFC7421 out the door. 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 =============================================== --001a1140f2706f07280556fafe61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 17, 2017 at 3:48 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 17/08/2017 21:05, DY Kim wrote:
> ---
> DY
>
>
>> On 17 Aug 2017, at 17:58, Ole Troan <otroan@employees.org> wrote:
>>
>> Have you read RFC7421?
>
> Yes, I did. With my own bias, the doc looks quite in the interest of d= efending one school of thoughts.

I am puzzled by that remark. The authors included a range of opinions and w= e worked
hard to presents facts (both facts about the published specifications and f= acts
about observed behaviour of implementations). And the opening paragraph sta= tes
"IPv6 routing is entirely based on variable length prefixes (also know= n as variable
length subnet masks), there is no basic architectural assumption that
n has any particular fixed value."

So I'm afraid that the document is actually stating something about rea= lity,
whether we like it or not.

=C2=A0 =C2=A0 Brian

I think RFC7421 fai= rly represents the facts as they are, in section 4.3.2 "Other Observat= ions", it even says;

=C2=A0 =C2=A0Also, DHCPv= 6 is in widespread use without any dependency on the /64
=C2=A0 = =C2=A0boundary.=C2=A0 Reportedly, there are deployments of /120 subnets
=C2=A0 =C2=A0configured using DHCPv6.

I jus= t wish we could get RFC4291bis to represent the facts as fairly as RFC7421.= No, that doesn't mean that SLAAC with anything other than /64 and 64 b= it IIDs should be allowed by RFC4291bis. However, it seems clear that other= than for SLAAC, /64 is just a recommendation, an important recommendation = all be it, but a recommendation and not a requirement. /64 is a requirement= for SLAAC, changing that is out of scope for RFC4291bis as I see it.
=

Personally, I'm just looking for RFC4291bis to repr= esent the reality of IPv6 today. =C2=A0

My persona= l version of that reality is; at work and at home my iPhone, iPad, and MacB= ook Pro all get IPv6 addresses with SLAAC from a /64 subnet, and I'm ha= ppy with that.=C2=A0 I wish Comcast would give me more than one /64 at home= . Maybe they do now, I haven't had time to screw around with my home ne= twork in 12 to 18 months.=C2=A0 However, I've had native IPv6 at home f= rom them for 3.5 years now, so I'm doing better than a lot of the world= . My iPhone and iPad haver several IPv6 addresses from my carrier AT&T,= but I don't seem to use them for Internet access.

=
At work we are #89 and at 63% of our hosts doing IPv6 for July on=C2= =A0http://www.worl= dipv6launch.org/measurements/ and we do SLAAC for most things.

However, my MacBook Pro does allow for manual configuratio= n of an IPv6 address and an on-link prefix of any length, and while I haven= 't tested I suspect the DHCP client will work for with other than /64 t= oo.=C2=A0 Also, most laptops and desktops, and all our routes at work allow= manual configuration of any length subnets and work with DHCP with any len= gth subnets as well.=C2=A0

So can we please get pa= st arguing about letting SLAAC use subnets other than /64, and update RFC42= 91bis to reflect the reality of IPv6 fully discussed in RFC7421. Once we= 9;ve done that, then maybe we can look at retooling SLAAC, but that is not = simply changing a few words in RFC4291bis, that is a major redevelopment ef= fort, with new running code, and testing like crazy. That will be a lot of = work, it may or may not be worth it, but that should come after we get RFC4= 291bis updated to the real world described in RFC7421 out the door.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
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
--001a1140f2706f07280556fafe61-- From nobody Thu Aug 17 16:34:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0C9132429 for ; Thu, 17 Aug 2017 16:34:04 -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 BY4DYgG-qR6x for ; Thu, 17 Aug 2017 16:34:03 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDFE13269E for ; Thu, 17 Aug 2017 16:27:07 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id t80so24674499pgb.5 for ; Thu, 17 Aug 2017 16:27:07 -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=ZeRmFxdNlp7Bho7P1YVHr/1J5fVvgm2P9yRfzq6RNBs=; b=Z8UeVwvpTqOCZ5XjypGUP/qXNnFCpeZHgIIzZVpd30lDeetNGDeuWZUeQKmrPMTqBC q4jucD/PihvE0oDYdJQNdttyt+PFehe5yE6JR3CXjwaC7agKGzVGfcXXhMIk0E5Ta8BQ /fAx0FdVwH+xfrl0wQkWxrUICIHZ0Ru11FQBMMnMGMUEwyL6D/wenH88iFq87rEXe6Wq w/2WtxJG8s6mdje/ZlDXLvvX0ORYntrm89Jua68LgUU3kKps2pKOVSQsYdlXt1M5WMVN itZk28Jnxp75YVSUJDhmu4B9CadO66ik1SCq0PfeM0mAkEtAWzdNn0POF+cqMTFSWec6 aq8Q== 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=ZeRmFxdNlp7Bho7P1YVHr/1J5fVvgm2P9yRfzq6RNBs=; b=lgmg3pb0KJnxLWjP1IH8KxM55Zj+eqCABqL698uKMuyCRieLewxNpVG9mTyUY+qt5+ QhRuggF9NYe4JttBCMQ3PQ7g1KuVrSydHVSr8qcW7/wQLyaJiommEPrYclmRytSryJNo cbhrqRDE6isoKqjlPreQcSApsaEHNMFRclyp4Ay0yHLG2jU9j7wz/NwYgNXe+bg7xVdd Aa+jLU+01ja+zhR9ZUFWt8JjKZhWbhSh2v1Xi/spDd2HZGieNtIahA9TKSggreGNSAwc Y1z5NBKRWzffo1G5RfZYsSynMvPJHtJxysUjTUtwCVF8mvfKC5QDh4O97+tMnPY/j6VT Ds4Q== X-Gm-Message-State: AHYfb5jVqp+EIKXAhqHfnEy8+7KGt38w31+xMoM8pgkfBI5WLCfz4xTg 5YJW7KS67q3ZpQ== X-Received: by 10.84.194.34 with SMTP id g31mr7700604pld.24.1503012427256; Thu, 17 Aug 2017 16:27:07 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id m124sm7310761pga.62.2017.08.17.16.27.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 16:27:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> Date: Fri, 18 Aug 2017 08:27:01 +0900 Cc: Ole Troan , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 23:34:05 -0000 --- DY > On 18 Aug 2017, at 05:48, Brian E Carpenter = wrote: >=20 > I am puzzled by that remark. The authors included a range of opinions = and we worked > hard to presents facts (both facts about the published specifications = and facts > about observed behaviour of implementations). My apology to the authors if my comments fell personal to them. > And the opening paragraph states > "IPv6 routing is entirely based on variable length prefixes (also = known as variable > length subnet masks), there is no basic architectural assumption that > n has any particular fixed value.=E2=80=9D =E2=80=A6 and the conclusion is to stick to the =E2=80=98fixed' value of = 64 bits. > So I'm afraid that the document is actually stating something about = reality, > whether we like it or not. So, done is done=E2=80=A6? SLAAC implementations faithful to the spec should have left the prefix = length open, to be configurable/settable by the admin. If not, the = implementations should have been declared non-conformant with the spec. The rationale for rfc7421 might be that the deployment base is so huge = (counting to billions=E2=80=A6?) that we=E2=80=99d better live with the = =E2=80=98reality=E2=80=99. The rational might be by looking into the = past of 20 years. How many more years do we expect/wish IPv6 is going to prevail? Another = 20 years? Or 100 years? One question to ourselves could be whether to make decision in the = interest of the past 20 years or far more years to come. The count now = might be billions but it is just about to explode by the several orders = of magnitude, with emerging IoT and disruptive applications. Shall we = confine the future births in a cage or shall we set them open to explore = their wild dreams not imaginable by us at this point in the networking = history. Is it a compelling reason to keep those uncountable implementations = interoperable with those of the 90s? How many computer systems, OSs, = programs are interoperable with those of 90s? My loved Macintosh, first-generation MacBook, and the HyperCard don=E2=80=99= t work/interoperate with my new machines, but that=E2=80=99s OK. Old = guys fade away=E2=80=A6 that=E2=80=99s about life. If any implementations are not in conformance with the spec, that=E2=80=99= s them who should fade away, not the ones in conformance. Bad guys = should die, not the other way around. Nothing is too late to change or bring back to right. That would be a school of thoughts I might join. Unfortunately, the IETF =E2=80=98rough consensus=E2=80=99 seems to be = the other way. Then, someone as me as a minority should just step back = and keep silent since it=E2=80=99s the rule of the game that the = majority prevails. Fine. That=E2=80=99s also about life=E2=80=A6 From nobody Thu Aug 17 16:43:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D21132608 for ; Thu, 17 Aug 2017 16:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ssv7-Ka5OSv for ; Thu, 17 Aug 2017 16:43:09 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 03A2D132429 for ; Thu, 17 Aug 2017 16:43:09 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a77so45304721qkb.0 for ; Thu, 17 Aug 2017 16:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OaWyqFYgJ24x7E6C39CdkD2+KzcFeL/7jtBprnjZqiY=; b=ABeKb9EFhQx8sXFnQ8bKhiB3lY5VHWBIZ8gVhcez6ENtPgoBulzNQuTPZdIzpecKSt klGdGhw1JACTTkwQPODUzdgovSU6OdyYoMlIBbrKjLrmXN4+n0MbTztzAWC4Qsw9Vh8g RmkLwAvN0Q/K7wdTwPOs0u42inppLVIFC84xZJYjlMCJIT9KpNUZd+PX+l2DMCn1IQVM FchQBJ7aI9tsNqK42H8uEHVc6+C0XAVWzdrLlhnz5fSwj60sx0fVjmF50DNxHeBHI9s+ 3IXtYVU6xwUqgiocy4MFAo5EfNSBDHGjZnz5TncbEigoe0ehLuGMOHILG++cu7sl88TB hq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OaWyqFYgJ24x7E6C39CdkD2+KzcFeL/7jtBprnjZqiY=; b=qw79m4Q/HRl4JC2eF8kjjpI+fCZ9e0W7gRkQAeq7jTdaqGKDUCHmwSLJhSGI1yYVX4 wr1rsdK9+mMbuw/7oRRnl18o67cs+lwej1HJa5RbtCHrIAp9PfIoFNzP/bKrl4NQ0Y1c JBItRVFFFzP729DcolRrBpsLbIR64CyMky1OaF9QUBsl7kXVdUwvAt+xVQeHfuBAhgtY 1shb3CiL2pal5WD2LifAO574mj7Rgi4g5m1pCu/xye6cfvP2ZqXdA54/rQNqmBKO4yFO gDi7X4IwWkbW0sHBToTYgPQM2aBzmjzjGf2pV2U6Mx0XC9bXgzCauqS+EJgETZaFEqd5 3XSw== X-Gm-Message-State: AHYfb5jHK9KZVCKQjrMKYj2X18rkyVy/+FiwhH1eVkrI2J3Lyasqg8h8 LjuodsY0w26LvXuGpN3426rsvGvfgw== X-Received: by 10.55.144.130 with SMTP id s124mr9960260qkd.136.1503013387999; Thu, 17 Aug 2017 16:43:07 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Thu, 17 Aug 2017 16:43:07 -0700 (PDT) In-Reply-To: <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 17 Aug 2017 16:43:07 -0700 X-Google-Sender-Auth: RWE0bD0DK7mSEIqT2zvnavA1xPk Message-ID: To: DY Kim Cc: Brian E Carpenter , Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 23:43:11 -0000 At Fri, 18 Aug 2017 08:27:01 +0900, DY Kim wrote: > SLAAC implementations faithful to the spec should have left the > prefix length open, to be configurable/settable by the admin. If > not, the implementations should have been declared non-conformant > with the spec. This is not correct. SLAAC implementations faithful to the spec should leave the IID length (and therefore its prefix length) open to the underlying link-type specification (such as RFC2464). It's not open to be configurable/settable by the admin. If an implementation unconditionally hardcodes a particular value such as 64, then technically, it's non-compliant. But as of today it's not distinguishable from truly compliant implementations based on externally visible behavior, since all known (at least as far as I know) such link-type specifications use the same single constant, 64. -- JINMEI, Tatuya From nobody Thu Aug 17 17:44:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB51323D4 for ; Thu, 17 Aug 2017 17:44:27 -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 9LWPeRfRFxuk for ; Thu, 17 Aug 2017 17:44:26 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE36132652 for ; Thu, 17 Aug 2017 17:44:25 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c28so9124377pfe.3 for ; Thu, 17 Aug 2017 17:44:25 -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=vCrLSefTujm8E4YKgCQBCQt1O80NxJFo1qTzSJBucck=; b=DylhLZxmxXlzT1wDj0rQdC/cCmwKV8TAhCNcNZaREM4FYc1aPzq4KyqWXcZ8079Vl1 x/w8gHhN51f0oDKc61KrIDo0rnNtXM84283WcNiXpSNHN0rjvJGrq5rgLTLJNw6Jh0t+ c3vGb1484NrAo1IkxERgtcUwQgcJhETt/qZv+u1xzrzXcmxVgcUf+rGqFax5da8yf9Mi 33+r3A8ut/PM0AWsRThWgI31wIARm+eKPitE3fLLmqMopy6fcCv63Gcv6kXe5hi8Eclg J9kc9Ax9adks7eXsTqyGQnzi+S0lbcPlXdK6EKClkFo75X8mWWTCoNufQSYDKVTT5ZMB l6pw== 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=vCrLSefTujm8E4YKgCQBCQt1O80NxJFo1qTzSJBucck=; b=RXK/E0X1dJHIMtUyZBA2FblKJsuHQm3G8ftWSTwXpKWGca3J/iqYldO9p1BppOIPNG SgkpiQfNxyD2scUFLtzKXHIRsJZyquSeXIFg4jjWhjLfNEMnuwk5yx3wFC6yNV9CSy9q 726Z/+aQ+viDDuaF524YkihRIVsA7cRsvOyIvNU5x7EAMvpbWLHyfG004DEPMIMsdKfx MKpUHQdr5hkhQid0Y2yCuumZBdznEmywN+13mAxh61YL/G9hQOturUURsVNSq4we+BOx sJiXMm6x6QNO/9rKucYEMEZ+UFQ8WlDDoDr5SjgBCtOWRsAnVODwLnILWssREqVf/Bfz E6vA== X-Gm-Message-State: AHYfb5iCyXMTYX88qgU0RGCdd4IYqAsC55WUwu0vhG83CM6VnXVd1vgD wnMhLdisuzd0Cw== X-Received: by 10.99.38.135 with SMTP id m129mr6819845pgm.393.1503017065058; Thu, 17 Aug 2017 17:44:25 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id p2sm7104786pgr.4.2017.08.17.17.44.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 17:44:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 18 Aug 2017 09:44:18 +0900 Cc: Brian E Carpenter , Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <392C32D2-E0C8-477B-9F95-834D193C706A@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 00:44:27 -0000 Now, it=E2=80=99s said the IID should not be derived from the link-layer = address, for privacy. If anything, the link-layer address shall be = conveyed in an option field of a related packet. Now, what still mandates the IID length be 64 bits? --- DY > On 18 Aug 2017, at 08:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > This is not correct. SLAAC implementations faithful to the spec > should leave the IID length (and therefore its prefix length) open to > the underlying link-type specification (such as RFC2464). It's not > open to be configurable/settable by the admin. >=20 > If an implementation unconditionally hardcodes a particular value such > as 64, then technically, it's non-compliant. But as of today it's not > distinguishable from truly compliant implementations based on > externally visible behavior, since all known (at least as far as I > know) such link-type specifications use the same single constant, 64. From nobody Thu Aug 17 18:08:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B5C132677 for ; Thu, 17 Aug 2017 18:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcxt437Zcw0o for ; Thu, 17 Aug 2017 18:08:19 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE4C1243F6 for ; Thu, 17 Aug 2017 18:08:19 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z18so45895324qka.4 for ; Thu, 17 Aug 2017 18:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=5dNYK3JgbQNUk2nmcDFP7YQZkMZ8mNUkmIoh8+HvE5A=; b=BE96fuiybFmPjLXchkwpRfXcSjugUYwNxC1v46pkNIfwCjebFniHfkm+AkM5CxW3f8 S2C8UIsibUvaIUYD+3xUVwovbahe5AdxLjDife0PrNL4G42MyBr7UqqScPgK6J2Sgvh4 Z7O/4A7AsC6f14f92uwOkEyWxeH+bgEmhiuA2m8XCcqSz406n8jRYP+Dcq3SSxaITJoj od8LpAD8Vh7euvuuHzyyayitQ2334oaj9tL4dbs7XPlDgMDb+vLHg2kCU6OytJUQRxvm KPSM5DlWPiAs4L+Stc1eX7VrG59LrbrR7+MH0AoTA7MfQ3H5Y0kFO28do9/jnu4reBw2 Fh6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=5dNYK3JgbQNUk2nmcDFP7YQZkMZ8mNUkmIoh8+HvE5A=; b=hepXxt8qhQKslW9VLDbpG4bbSavH+OBvvpvBQ0v+0gAKRONSDvBKv8cdEHQnNlU9Ap lwGSSfWL9Knb0DZ7/ZBprstcIP1LfsSnIfiCRMZq5xn6zaUzr+u0EMC1/DBtsRfnX3US vKM5SlW2EE6GCIZBeIYR1LquyNDH87ZhvTl+e+a9B/UqM7AYnoB5fDHsFRRDwSOxK1G8 q877DkpiB/AEZafo2C0SxHZI6WiZ2sVIAxpMo+ShEaXwezh9bCJGTSHz3Uug1e8Jc3qt 7dSSNF4NbW6H8My9nWU6Rsja1qjHEWK5n2CW0zWZ7O03gytGq8MusiUX7CbaXnK0UT4k s7iA== X-Gm-Message-State: AHYfb5gRZHeDLYjbv2FX87HWLFAvAL4t5V0ISeqnf0EabvcYrsoIYNGB Sj568ISp2/pXh+toJIehANGpgvW2Y+9E7z4= X-Received: by 10.55.92.130 with SMTP id q124mr9392150qkb.274.1503018498309; Thu, 17 Aug 2017 18:08:18 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Thu, 17 Aug 2017 18:08:17 -0700 (PDT) In-Reply-To: <392C32D2-E0C8-477B-9F95-834D193C706A@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <392C32D2-E0C8-477B-9F95-834D193C706A@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 17 Aug 2017 18:08:17 -0700 X-Google-Sender-Auth: 7YAw1Ed3619ZDexP_YFUGT2HKB4 Message-ID: To: DY Kim Cc: Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:08:21 -0000 At Fri, 18 Aug 2017 09:44:18 +0900, DY Kim wrote: > Now, it=E2=80=99s said the IID should not be derived from the link-layer > address, for privacy. If anything, the link-layer address shall be > conveyed in an option field of a related packet. > > Now, what still mandates the IID length be 64 bits? There can be several answers, but I don't think such a discussion helps. Some people would point to the existing deployment base; some others might say it just must be sufficiently large and we shouldn't change the current constant without a reason to avoid confusion. One can easily find a counter argument to those, but it will simply lead to the circle of arguments we've seen. It's already pretty clear that neither side can persuade the other just through these email threads. If the purpose of the question is to change the current standard value, I'd suggest you write your own draft that updates these RFCs. Just mumbling in this mailing list won't help change it. It's just a waste of our time. -- JINMEI, Tatuya From nobody Thu Aug 17 18:17:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D2013269A for ; Thu, 17 Aug 2017 18:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kLze02lVKgFr for ; Thu, 17 Aug 2017 18:17:14 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F783132143 for ; Thu, 17 Aug 2017 18:17:14 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id j32so28707287iod.0 for ; Thu, 17 Aug 2017 18:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EuezXgdf6J7hpqbpw/sK09UyMsakgvYE4HTAidonJLw=; b=XhnDVgLS+OpBzEwqnLkhgW1BKU/xfRpMuDQ+eu3A3vZBOMY1vWkCfIqEwDy8WE/UTo w8cElXiLnyHGsIndrcfVCQFaxYrSzoI27jWzU+CpcbCu1uArY1++60sJm/VdvyucMw3N eAmngUHm+u1kiejmNTKnvwR4q5+6hVvhbpt++vG/g8VfBaDKTbQpsHslKC+/dHQZOqBO uzljIXOHEdUNw0rLL8YNaE6Q8Wrn3EyHy49EbksnhkXldOjudN9maF47Hckv/uhktFeB qp7HmmVLeLrPSU3Xm4hg1Rrq2GKXymY56srcgY9/JVVJEGb0j+NQlXWk959vDgbGW+PK 0C2g== 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=EuezXgdf6J7hpqbpw/sK09UyMsakgvYE4HTAidonJLw=; b=YHnA7vHzUpjQexof+cxfL+GwML1aY9xwFRTCuH+9vr6D0WNKXjd/sbuvATJWUJl1/U 0YfgeZFLQJirCqgTE38oT3EVqblsKLrc8/V8rKF+fAm1532jc8iJpH8InYZ9FB/zW/9D hLx8BzuNch2Q6wRKTRYjlFlq4tXW5PM55peJYv8xuv+fhdgwz4dyhXe0gsk4VI7Wsy+B 0SuhcGO+ezkZv1RM50+9r+hUmossuuqzmcUlza/E0j1mCcoPcq65M8YRIxtBx7ts4/IU KqHJAZ4MQ0HOUuA/DrsbFkdd4/7MN2Tc/4CIp5uKnFWtzbe1ZURLm/iiAyCW0j3se4lE rAEw== X-Gm-Message-State: AHYfb5ggm4iMutmbdz+s9m55LK8eIV/1ofxJn/xnQ8AI/vERK33etWfI 06VQOeMddHT65GOnhIqFCjmO4tjyXUZW X-Received: by 10.107.56.214 with SMTP id f205mr7021231ioa.208.1503019033354; Thu, 17 Aug 2017 18:17:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 17 Aug 2017 18:16:52 -0700 (PDT) In-Reply-To: References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> From: Lorenzo Colitti Date: Fri, 18 Aug 2017 10:16:52 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: DY Kim , Simon Hobson , v6ops list Content-Type: multipart/alternative; boundary="001a114ac8ca93a5140556fce375" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:17:16 -0000 --001a114ac8ca93a5140556fce375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 18, 2017 at 8:43 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > This is not correct. SLAAC implementations faithful to the spec > should leave the IID length (and therefore its prefix length) open to > the underlying link-type specification (such as RFC2464). It's not > open to be configurable/settable by the admin. > Actually, even more than that. For everything except ::/3 (which it is unlikely that any implementation will encounter), IIDs are 64 bits long because of RFC 4291. Personally, I think this is why there is such a lack of consensus on 4291bis. The lack of consensus is about the future, not the present.Currently, any new link layer that is defined has to either use 64-bit IIDs or update 4291. And any new address assignment mechanism that is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow non-64-bit IIDs, that all goes out of the window. For example: if we remove the 64-bit boundary in 4291, does it instantly become valid to create RFC7217 addresses with 5-bit IIDs? --001a114ac8ca93a5140556fce375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 18, 2017 at 8:43 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
This is = not correct.=C2=A0 SLAAC implementations faithful to the spec
should leave the IID length (and therefore its prefix length) open to
the underlying link-type specification (such as RFC2464).=C2=A0 It's no= t
open to be configurable/settable by the admin.

Actually, even more than that. For everything except ::/3 (which it= is unlikely that any implementation will encounter), IIDs are 64 bits long= because of RFC 4291.

Personally, I think this is = why there is such a lack of consensus on 4291bis. The lack of consensus is = about the future, not the present.Currently, any new link layer that is def= ined has to either use 64-bit IIDs or update 4291. And any new address assi= gnment mechanism that is based on IIDs has to use 64-bit IIDs. If we change= 4291bis to allow non-64-bit IIDs, that all goes out of the window.

For example: if we remove the 64-bit boundary in 4291, do= es it instantly become valid to create RFC7217 addresses with 5-bit IIDs?
--001a114ac8ca93a5140556fce375-- From nobody Thu Aug 17 18:18:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9A913270D for ; Thu, 17 Aug 2017 18:18:34 -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 jkhpMQvwIdLD for ; Thu, 17 Aug 2017 18:18:33 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0468132677 for ; Thu, 17 Aug 2017 18:18:33 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id y129so53609916pgy.4 for ; Thu, 17 Aug 2017 18:18:33 -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=eBqGix7l7ntcvX7O6zjJWdpaXK42XOwAQNC0CcYTd8o=; b=PtHu3UICt/4IqaSlEqFeczJzNhzKZCUIClFl1CEvAbOOKCYAB1v2PeMy1GsABaG4SA QZOahZ0aWl44SnMqfTcilI+oiW+crrIGlCWchEZ+ehytdIwza+VshZ6RgL5HUlwZM7eY kFl3XuSBQCo6f0wdQfzi6UNDyqEwre+kL5JsPCcSfzFipQvwHQ5QrHpz1XVryNpf8EqI u1gk6Utcj+4cYfqf/jbWdCD4mOyl2h5URZUxZheqIGvEXHetnwtXS7DZwYQ76uf6b7ed Hsy4hflKMmHn5d5zfth2zoCE/h4Xtiv2KdzWHnHLrQxGNi/m3pD2kHJsw3DNQ2TMq557 g/Zg== 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=eBqGix7l7ntcvX7O6zjJWdpaXK42XOwAQNC0CcYTd8o=; b=QiPEMJH58BSDxYWI49pDQz2RTmdWNrRnx+t9fwb4O8mTk6rtMcJ9NwtEV4VIHa1I52 jw0zOSmJStZd81Sl7C9WI3J2C1F0MIsCx/lxB9ouJrzXLXVn5waZ0OerdGUn3m590awR P7xoB5uBA0fKsM468JuODIaxU6O9tbTet1+w1uZv5wwCGUemAZC6jp4XNqS78I2/F8lL Ok8cPeeNi6tJ1LKe0IL3zYig2120cigl/8fCEqzV9nNko44Tgx20u+fQbE15tMNMXyKX 99UbuOGz9zxkfEd2N8GlfoRTifGXmeS8M+dLRtiCqUBKcyMzuKxtPJxfY3HiALZd/YtR kvEg== X-Gm-Message-State: AHYfb5gqfdwPV4eR7T/irV2ptlhgmd9yxLtvwhyt8y54dS69NH6lJ5mf yXruc5JsovoYiQ== X-Received: by 10.98.217.10 with SMTP id s10mr7213960pfg.204.1503019113433; Thu, 17 Aug 2017 18:18:33 -0700 (PDT) Received: from [222.113.135.33] ([222.113.135.33]) by smtp.gmail.com with ESMTPSA id f64sm8887281pfb.83.2017.08.17.18.18.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 18:18:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Fri, 18 Aug 2017 10:18:28 +0900 Cc: Simon Hobson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <081C80B2-4812-44E3-921E-D733CFC6B3D4@gmail.com> References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <392C32D2-E0C8-477B-9F95-834D193C706A@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:18:35 -0000 --- DY > On 18 Aug 2017, at 10:08, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > If the purpose of the question is to change the current standard > value, I'd suggest you write your own draft that updates these RFCs. Most probably, it=E2=80=99s going to be just a wast of my time; little = chance to be adopted. > Just mumbling in this mailing list won't help change it. It's just a > waste of our time. OK. Case closed. From nobody Fri Aug 18 09:01:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC311329D2 for ; Fri, 18 Aug 2017 09:01:42 -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 Xb-iI6ZlIiIM for ; Fri, 18 Aug 2017 09:01:40 -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 ECBA31321DC for ; Fri, 18 Aug 2017 09:01:39 -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 v7IG1bVO030165; Fri, 18 Aug 2017 18:01:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E80642045CC; Fri, 18 Aug 2017 18:01:37 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA5C52043B7; Fri, 18 Aug 2017 18:01:37 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7IG1bbQ008952; Fri, 18 Aug 2017 18:01:37 +0200 To: holger.metschulat@telekom.de, v6ops@ietf.org References: <937f22f6-e4b7-b398-9df9-79c36ea2d7ee@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002E21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A002EF9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1be23f5b-f449-9924-8322-f21c4ccbd09e@gmail.com> <787AE7BB302AE849A7480A190F8B93300A002F95@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2c325097-651e-501c-747a-e7a322c3d844@gmail.com> <787AE7BB302AE849A7480A190F8B93300A0032B6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6c43cf08-0bd6-daf4-ea9d-d52c34db2a8c@gmail.com> <6727013e-b5c8-4bee-6127-9e0317b41c9f@gmail.com> <2ff7a4128d1d424f84c35ddcd3eec0fe@HE199744.emea1.cds.t-internal.com> <4f7eaf1f915a4911a428244bdf7ce497@HE199744.emea1.cds.t-internal.com> From: Alexandre Petrescu Message-ID: Date: Fri, 18 Aug 2017 18:01:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4f7eaf1f915a4911a428244bdf7ce497@HE199744.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:01:42 -0000 Hi, Sorry it is just now that I see the email. Since we last discussed I had some revelations, and I must correct myself. Le 17/07/2017 à 09:17, holger.metschulat@telekom.de a écrit : > See below with[HM] > > Holger > > -----Ursprüngliche Nachricht----- Von: v6ops > [mailto:v6ops-bounces@ietf.org] Im Auftrag von Alexandre Petrescu > Gesendet: Freitag, 14. Juli 2017 21:02 An: v6ops@ietf.org Betreff: > Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and > GUA > >> [HM] WWAN Modem Chipsets perform some kind of translation of >> packets, > > This seems like a generalisation. I do not understand what do you > mean by WWAN Modem Chipsets - can you give an example of a WWAN Modem > Chipset? > > In my particular case there is no separated Modem Chipset from an > Application Chipset, or App Processor vs. Broadband Processor, or > something like that that one can find in many smartphones. Or like > Host-IMP distinciton of early RFCs. > > In my case it is an IoT device. It is called an "integrated module" > and it runs linux. It is from Sierra, format CF3, series WP8. > > [HM] Look into their datasheets, they call it "Telecom core" there, > and it seems to be a Qualcomm Hexagon based chipset. I agree. What I tested for these experiments is a Sierra module; it includes in the same circuit one ARM Cortex A5 running a yocto-based OS (a linux distribution for lightweight platforms) and two Qualcomm QDSP6s Hexagon cores. It includes further electronic radio circuits that have less relevance to SLAAC/DHCP (transceivers, amplifiers, etc). It seems some parts of this are called "Snapdragon". The yocto OS provides all its source code including SLAAC/DHCP; yet the part running on the QDSP6 is binary, confidential proprietary of Qualcomm. The code running on QDSP6 seems to be running as a virtual machine as a layer of the yocto OS. Alternative to that proprietary virtual machine is a Hexagon MiniVM. This proprietary virtual machine seems to implement matters related to DHCPv6 and to SLAAC, including some '64' magic numbers; it is indeed something like a black box between what yocto does (RS/RA/NS/NA, DHCPv6 client) and what the cellular network offers. The indicators that tell that this black box implements DHCPv6/SLAAC are confidential indicators. Because of proprietary confidential aspects of Qualcomm it is hard to understand what SLAAC/DHCPv6 on QDSP6 does, and even less to talk publicly about it. > There is only one module running both linux and the cellular > interface. > > [HM] And this module has two processors, one for the application, and > one for the telecom side (usually called "the modem"). YEs, actually three in this particular case: one for yocto, and two for "modem". >> especially ICMPv6 packets, between the interface to the computer >> and the interface towards the provider network. The reason is that >> the computer wants to see an Ethernet broadcast interface, but >> the provider interface is point-to-point. For example, the computer >> needs Neighbor Discovery but this is not available on the >> provider interface. The provider's network device doesn't have a >> MAC address either, so the modem chipset emulates this missing MAC >> to the computer. > > Do you think it is a linux kernel module that performs that > emulation, or is it completely another OS (like ThreadX)? > > [HM] No, it is a separate processor (actually a DSP). YEs, in this Sierra module, there are two QDSP6s, in addition to the yocto. > That emulation must be standardised. > > [HM] Well, obviously nobody saw the need for it until now, it is > actually implementation specific. It would be a good idea indeed to > specify this. I agree with you. There is a strong need to have clear specification of whatever any intermediary box does, especially when it gets in the way. Otherwise it's impossible to continue. > Most of these translation layers drop all DHCPv6 traffic so no > chance to get Prefix Delegation working if it is initiated by the > host. This is indeed a risk. This is something explored as we speak. It would be great to get Qualcomm involved in this. Because I think they sit in the middle, yet a better understanding of SLAAC/DHCP can bring more value. > There is a need for such translation otherwise Ipv6 won't work. Well, I tend to disagree, but discussion may change my point of view. Currently I think the ideal is if that QDSP6 does not do anything - let everything through. For a start. > Ipv4 neither - Ipv4 address assignment on the carrier side does not > use DHCPv4 which the mobile host usually speaks. This is the downside > of presenting an Ethernet interface to the Operating system. The > upside is the there is no need to change OS specific handling of a > WWAN interface since it can be handled like any other Ethernet > interface. Otherwise, each OS would have to implement an interface > driver complying to 3GPP's view of the wireless network > connectivity. Noted. >> So what you capture on WWAN0 (or however your computer interface >> is named) is not what actually goes over the air. > > If you think that something else goes over the air, can you tell me > how, or what capturing tool, did you find out that there is something > else over the air? > > [HM] I traced within the operator's network, looking at the GTP > traffic just in front of the GGSN/PGW. > > My operator asks me the same thing - what goes over the air - and I > dont know what to answer. [HM] Tell them to trace your GTP traffic > right in front of their GGSN/PGW (e.g. Gn interface). Thank you for the advice. This is what we currently do with the help of the operator. We identified some issues. On the mobile side, Qualcomm offers a diagnostic tool (private confidential). This is a matter of Host-IMP interface, RFC 7! Alex From nobody Fri Aug 18 09:07:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9E1329D9 for ; Fri, 18 Aug 2017 09:07:23 -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 59bCl8lsyp17 for ; Fri, 18 Aug 2017 09:07:20 -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 B84601329EA for ; Fri, 18 Aug 2017 09:07:19 -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 v7IG7HJZ044051 for ; Fri, 18 Aug 2017 18:07:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B417E204542 for ; Fri, 18 Aug 2017 18:07:17 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AAD25204425 for ; Fri, 18 Aug 2017 18:07:17 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7IG7G26013018 for ; Fri, 18 Aug 2017 18:07:17 +0200 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> From: Alexandre Petrescu Message-ID: <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> Date: Fri, 18 Aug 2017 18:07:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9948cb75-6c11-9071-697f-a79702472132@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:07:23 -0000 I have been pointed by a helpful person that an Android app for DHCPv6 exists there: https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr It is based on the WIDE DHCPv6 client. Further browsing leads to a discussion of DHCPv6 on Android topic: https://issuetracker.google.com/issues/36949085 Alex Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : > Well, this is to note that we too (Fred mentioned it too earlier) made > the ISC DHCPv6 dhclient work on Android, including DHCPv6 Solicit that > requests Prefix Delegation. > > (but we still dont have a response to DHCP Solicit on cellular link). > > Alex > > Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >> Mark, noted, will try. >> >> Just a note... >> >> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>> >>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>> Alexandre Petrescu writes: >>>> Hello, >>>> >>>> We discussed extensively about the potential use of DHCPv6 >>>> Prefix Delegation on cellular links. >>>> >>>> The chicken issue is the lack of DHCPv6 PD software on typical >>>> User Equipment. For example, there is no DHCPv6-PD app on >>>> Android. The egg issue is the lack of operator support of >>>> DHCPv6-PD towards the User Terminal. For example, there is no >>>> cellular operator answering to DHCPv6-PD requests issued by the >>>> User Terminal. >>>> >>>> To address the chicken issue, we started with an ISC DHCP open >>>> software client, which does implement Prefix Delegation. It can >>>> be (cross)compiled on various platforms; then type "./dhclient -6 >>>> -P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix >>>> Delegation message on the interface. >>>> >>>> However, whereas this software runs ok on interfaces such as >>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>> cellular interface of some IoT cellular platform. The error can >>>> be corrected by the quick-and-dirty solution below. >>> >>> The hack would be better as >>> >>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] = >>> HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif >>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long >>> int)sa->sa_family, name); break; >>> >>> with ARPHRD_XXXX being replaced by the correct macro for 503 from >>> . Something like that is at least portable. >> >> But it means when I go to other platform will have to modify again >> the ISC client source code? >> >> In cellular terminals there are so many non-IEEE different kinds of >> links. >> >> Other clients work out of the box on this - I agree with you, strange >> - "rmnet0" interface. >> >> Alex >> >>> >>> As for the rest of it I have no idea about the presented hardware >>> address of this type so I don't know it the rest of it make sense. >>> >>>> Alex >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> > The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>> >>>> //default: // log_fatal("Unsupported device type %ld for >>>> \"%s\"", // (long int)sa->sa_family, name); default: >>>> hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], >>>> sa->sa_data, 6); break; >>>> >>>> (two programmers worked this out). >>>> >>>> Alex >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 18 10:46:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8C3126B71 for ; Fri, 18 Aug 2017 10:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJtGXIyuxBkK for ; Fri, 18 Aug 2017 10:46:29 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85309120720 for ; Fri, 18 Aug 2017 10:46:29 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x77so12772379qka.5 for ; Fri, 18 Aug 2017 10:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=U5nqUObPM+3mhY8SRSk6m5qkVGybGMx8wCMqk5whvGw=; b=m5X2HjRKoiJw4JsTetL7uu1MzSqkZRYs7XHIl51jsAAynh+SnmkONZUujSV4uE6mIc EMx7yKLT6GuMI8K9upqjiiv/6O4uX7WYYs7Ka2QVvdj2KkunUvZz0ne2nX1G5wTZ+qPM mck+fjYOqql5dvdXSJDI3QlPfCrAeoz9ep/nUZaeQ9bEQvpgvBcGaQOb6aZk6dMlZXlD zkOI4H19QODOPVCsHU7y8dLqiNmvYqD73pf/lcZgH8Wb9LOFOgcTmuEkBA2vvzlD1Ypu RfQk41NPoHKrHWTRZuBLP6I+7ixkl5aw5zUfe6uN0XsxJuVfyu17xf8ClMNeq/C/m0qC LWmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=U5nqUObPM+3mhY8SRSk6m5qkVGybGMx8wCMqk5whvGw=; b=jGhwE+Xl7gbq7qmrpuqythEtDLpoWKyAmwcN67um1kYmepgtg2OFJMNGE124i1idE5 nW7PwFGh/fTDEu0ZM3gN6WpEvBJFM15dSKGXvVWbC5/rOaU7ig50xoCHPOJLsckMfHUM JD10uhqyuX451cRMqD+2dyuUQrMyHEKpre8wNvFEbhTJZU1MaeFL+IHY0Q+NUIY0UK1s NrGVyvSvElb9nS6DLRYFTBMeCIqpVtf4pEFOeRjjrwX6QfN3RYck57Ww/t3ngF5mzs3e nTPX5aSCSn38q1RP9R8ZtTNQ6P7oQ14l8R1ZtvmVBxutLRmxapzmpvJMU5WxEabxaGmJ irFg== X-Gm-Message-State: AHYfb5gV65KQ7ip0WytyCF8A2DnD07OMMBgGgOZZfe6U+IHftQWLtccP ff0HQsKHQCvA9zc1acKU/Vl9OHZGIg== X-Received: by 10.55.3.130 with SMTP id 124mr12504199qkd.78.1503078388480; Fri, 18 Aug 2017 10:46:28 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.52.106 with HTTP; Fri, 18 Aug 2017 10:46:27 -0700 (PDT) In-Reply-To: References: <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 18 Aug 2017 10:46:27 -0700 X-Google-Sender-Auth: rr3EveaM8go2SQZtcMbbxrJTbV4 Message-ID: To: Lorenzo Colitti Cc: Simon Hobson , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 17:46:31 -0000 At Fri, 18 Aug 2017 10:16:52 +0900, Lorenzo Colitti wrote: > > This is not correct. SLAAC implementations faithful to the spec > > should leave the IID length (and therefore its prefix length) open to > > the underlying link-type specification (such as RFC2464). It's not > > open to be configurable/settable by the admin. > > Actually, even more than that. For everything except ::/3 (which it is > unlikely that any implementation will encounter), IIDs are 64 bits long > because of RFC 4291. I knew that, and I actually considered to note that, too. But I chose the most straightforward explanation to point out that the prefix/IID len is NOT "open to be configurable/settable by the admin" according to the protocol specification, in order to avoid unnecessary distraction. > Personally, I think this is why there is such a lack of consensus on > 4291bis. The lack of consensus is about the future, not the > present.Currently, any new link layer that is defined has to either use > 64-bit IIDs or update 4291. And any new address assignment mechanism that > is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow > non-64-bit IIDs, that all goes out of the window. I agree that it's one major source of confusion that both addrarch and link-type specs define the IID length (and the former defines it per address space basis and the latter defines it for a particular link type, and therefore these two could easily be inconsistent). Although I don't know if that's why we don't have consensus for 4291bis. Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07? I'm not sure why we are talking about our favorite topic of 64-bit (or not) IIDs here:-) This thread is even more inappropriate for that topic than 4291bis (even where it's out of scope as it's not feasible to change that as part of promoting it to IS). People who want to discuss the endless IID length debate should really aware of the scope of the topic. -- JINMEI, Tatuya From nobody Fri Aug 18 11:24:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B134132198 for ; Fri, 18 Aug 2017 11:24:56 -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 GoyccVph-2Hm for ; Fri, 18 Aug 2017 11:24:54 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34BE132195 for ; Fri, 18 Aug 2017 11:24:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v7IIOpKm100319 for ; Fri, 18 Aug 2017 20:24:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 87258204638 for ; Fri, 18 Aug 2017 20:24:51 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7DA3F2045D7 for ; Fri, 18 Aug 2017 20:24:51 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7IIOot8026394 for ; Fri, 18 Aug 2017 20:24:51 +0200 To: v6ops@ietf.org References: <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> From: Alexandre Petrescu Message-ID: <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> Date: Fri, 18 Aug 2017 20:24:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 18:24:57 -0000 Le 18/08/2017 à 19:46, 神明達哉 a écrit : > At Fri, 18 Aug 2017 10:16:52 +0900, > Lorenzo Colitti wrote: > >>> This is not correct. SLAAC implementations faithful to the spec >>> should leave the IID length (and therefore its prefix length) open to >>> the underlying link-type specification (such as RFC2464). It's not >>> open to be configurable/settable by the admin. >> >> Actually, even more than that. For everything except ::/3 (which it is >> unlikely that any implementation will encounter), IIDs are 64 bits long >> because of RFC 4291. > > I knew that, and I actually considered to note that, too. But I chose > the most straightforward explanation to point out that the prefix/IID > len is NOT "open to be configurable/settable by the admin" according > to the protocol specification, in order to avoid unnecessary > distraction. > >> Personally, I think this is why there is such a lack of consensus on >> 4291bis. The lack of consensus is about the future, not the >> present.Currently, any new link layer that is defined has to either use >> 64-bit IIDs or update 4291. And any new address assignment mechanism that >> is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow >> non-64-bit IIDs, that all goes out of the window. > > I agree that it's one major source of confusion that both addrarch and > link-type specs define the IID length (and the former defines it per > address space basis and the latter defines it for a particular link > type, and therefore these two could easily be inconsistent). Although > I don't know if that's why we don't have consensus for 4291bis. > > Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07? Is draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 free to use non-64 prefixes per host? Or must it use 64bit prefix per host? Alex > I'm not sure why we are talking about our favorite topic of 64-bit (or > not) IIDs here:-) This thread is even more inappropriate for that > topic than 4291bis (even where it's out of scope as it's not feasible > to change that as part of promoting it to IS). People who want to > discuss the endless IID length debate should really aware of the scope > of the topic. > > -- > JINMEI, Tatuya > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Aug 18 11:47:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E101321A1 for ; Fri, 18 Aug 2017 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4js_cI9A2IIe for ; Fri, 18 Aug 2017 11:47:01 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636521321B8 for ; Fri, 18 Aug 2017 11:47:01 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o124so49199175qke.3 for ; Fri, 18 Aug 2017 11:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gdzFzbxEg18bQJ5Cd4vXB1VyLh2c02rJ813QozMcZIc=; b=tGhoufX+4wvOSlu+Lsk8cggvrg+nnbMg3D2GoqlxFlMhNRweL+dxVaEfXIXcfIOQdW QvW7YFFRUv99R3sfYA2LquOoufIMvYZkRMNjfclHrv4oK4QxJtlNBMqhQnlvxdMLVvwz VXr30YpH8RS8p78NUiCNLLi/Up/v/0VwMnLXA+qwQwbeIHem38GutIZw7LCw1hkuKMwD yCvKFgpEQJqSbBDx57cEvMCQ/j/zbIFhRZaxKxtcwcjToHi+SXaQOzXJQ9FrZElmC2Y/ oegmNFffI12ISotDvosog6SN680hnWdSGrjFXiLSuzfVOw7/JfEaBQQ518CdQY2DbqWy 3//w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gdzFzbxEg18bQJ5Cd4vXB1VyLh2c02rJ813QozMcZIc=; b=ObEx/ck3tzWXjm2RBTPSGIKda/qI9BPpVqPBOpEV+wNYN1rrPsVpS0jcmqKwj9HolH gVAeolZjYYDzHpyB8RhBFD5giGYNFPRvaq+gF9ub98kd636I8tWowQQAulIx5yFb4DFD fbt9OKFg0jJigaLXNUSbPsX5fPr9NtwMH5vXFDeyzy4seXGOnguqPcqLd06fT6oaJ98Z n8h3lOT4v7hytHCrmRYIyPdzvZd43Brk5ktkI+dWn3Zmda9bYblnkP37wT32O6SRq3vk 2lqKKpog59SERGtQWYi0LG/daqv6X5VkacVSxvZThWmTDa2zeI5UZrZvOZrxhJiEwZd2 jAog== X-Gm-Message-State: AHYfb5i9OqWSoQmfOeZlNFCjGSwUq7mpQjguaQyKi6QYo+XH3UkCVbCU UnfRsclsfeseww41pO+Q2NKf8xxt+g== X-Received: by 10.55.168.145 with SMTP id r139mr8653767qke.258.1503082020493; Fri, 18 Aug 2017 11:47:00 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.52.106 with HTTP; Fri, 18 Aug 2017 11:46:59 -0700 (PDT) In-Reply-To: <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> References: <20170807110746.GG45648@Space.Net> <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 18 Aug 2017 11:46:59 -0700 X-Google-Sender-Auth: ItqDCVXXpzsZ9m2Wx1D9Ccc3e9w Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 18:47:06 -0000 At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu wrote: > > Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07? > > Is draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 free to use non-64 > prefixes per host? Or must it use 64bit prefix per host? As long as it uses SLAAC, the IID (and therefore the prefix for it) must be 64 bit today, since there's no standard that specifies a different value. But I don't think that's the inherent limitation of this practice; it's just a result of the limitation of the current standard specs (in fact, it says '"currently" a /64 prefix in Section 4). In any event, my point below was that as long as this draft talks about a live practice using today's standards, it doesn't make sense to discuss whether the choice in those standards (i.e., 64-bit IID) is good/bad in that context. If we want to have that discussion that should take place somewhere else (and not even appropriate for v6ops in general, since changing that would be most likely to involve a protocol change). Especially so when such a discussion always leads to a non-productive repetition of stating different opinions. > > I'm not sure why we are talking about our favorite topic of 64-bit (or > > not) IIDs here:-) This thread is even more inappropriate for that > > topic than 4291bis (even where it's out of scope as it's not feasible > > to change that as part of promoting it to IS). People who want to > > discuss the endless IID length debate should really aware of the scope > > of the topic. -- JINMEI, Tatuya From nobody Fri Aug 18 12:46:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A971320BB for ; Fri, 18 Aug 2017 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukKhkQ_Q9wiY for ; Fri, 18 Aug 2017 12:46:23 -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 9EC2112426E for ; Fri, 18 Aug 2017 12:46:23 -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 v7IJkKYF019382; Fri, 18 Aug 2017 21:46:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FE1E20468C; Fri, 18 Aug 2017 21:46:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 025C8204425; Fri, 18 Aug 2017 21:46:20 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7IJkJCK003792; Fri, 18 Aug 2017 21:46:19 +0200 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: "v6ops@ietf.org" References: <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> From: Alexandre Petrescu Message-ID: <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> Date: Fri, 18 Aug 2017 21:46:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 19:46:26 -0000 Le 18/08/2017 à 20:46, 神明達哉 a écrit : > At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu > wrote: [...] > In any event, my point below was that as long as this draft talks > about a live practice using today's standards, it doesn't make sense > to discuss whether the choice in those standards (i.e., 64-bit IID) > is good/bad in that context. I agree. Maybe the 64bit IID is not a matter of this draft, since this draft is about prefixes. The IID length should be discussed in the other WG. Here, still it makes sense to allow for prefixes shorter than 64 (i.e. unique /63 prefix per Host, such that it can further grow the network by becoming a Router). The draft says: > a Unique IPv6 prefix (currently a /64 prefix) and some flags. That "currently a /64" sounds as a hardcoded value. It should be something like: "a variable length whose value could be /56 for example; it could also be /64". Alex > If we want to have that discussion that should take place somewhere > else (and not even appropriate for v6ops in general, since changing > that would be most likely to involve a protocol change). Especially > so when such a discussion always leads to a non-productive > repetition of stating different opinions. > >>> I'm not sure why we are talking about our favorite topic of >>> 64-bit (or not) IIDs here:-) This thread is even more >>> inappropriate for that topic than 4291bis (even where it's out >>> of scope as it's not feasible to change that as part of promoting >>> it to IS). People who want to discuss the endless IID length >>> debate should really aware of the scope of the topic. > > -- JINMEI, Tatuya > From nobody Fri Aug 18 13:05:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737213218F for ; Fri, 18 Aug 2017 13:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywnhS8WbD2jp for ; Fri, 18 Aug 2017 13:05:38 -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 4CB2A1320BB for ; Fri, 18 Aug 2017 13:05:38 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id g131so106908893oic.3 for ; Fri, 18 Aug 2017 13:05:38 -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=K+wSZJCx6QQS4zBUjEBx1o9rsPSQIG5nZjtfzwZA3UU=; b=dfr/oRcgm9MReCEzTJdqATExd1MM4ONecBaEq/rEBcTGgwW9HnQPMq/0AZ4n3sv/67 vOfgoY+8MJ3rSuYSAyPV5jnaVq00zXfQ7+h7+XnKE8d3UsM+suegDOHis2AIsFZoldHL HgKoEDsc2PKzVbyNtiB4rais5HzSC7SG79yM5WHpNlRvqei8rUftu6N0/RACPhGGaNL6 fr/OYmY7g4pbxRrk/Ols7kVnEUMbH676V5R42T2vmdO8DM8Kz+695dvZ7MDYc8VJgZ9d rEwGRT3eqDSs3SG8M8176FoDAQMr/Jy6ubcTNAWnKSiedMNlOoze+mYBEGgGdfIEF+E9 dktw== 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=K+wSZJCx6QQS4zBUjEBx1o9rsPSQIG5nZjtfzwZA3UU=; b=UeODL0xk0+9ioJPmzqCAjCwPSpgyQ7dhoNJHM8YKzFUkry5qEnvzFetEM5jDFxrEi9 GkgOpnqotgd+LUAIx84/9IWB2XcLVaFMZvxiTiSwdx2kmtIosuYJOLJU1k85Lvkq2VSr +n9jn2I+qidkOrMgo0mDmGwl78dFbUB7OOWQ3vZPPIzTblkcv6obXapXYYfP/Dd2nC1e eZqjzHvrlkHeBzm0ewK/ULwpN1TcphXzYYr2G/NharbqBGpBNXE8xlQ+/S7Ugw0LClb0 gJSblh9Rw5YwiZomKf2Zq4rzLNunM4CQn2GXEk+n0ELbd68/xZUhxgVzFHErKGQRD+yX MsMw== X-Gm-Message-State: AHYfb5jtHFYN/PemcGRIxGNueXeYSlb5H8Kul/wcolG8jWnppKbmWCny PZJ8RotrWlWW5rEeGKw= X-Received: by 10.202.69.70 with SMTP id s67mr12027641oia.22.1503086737568; Fri, 18 Aug 2017 13:05:37 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1281? ([2600:8802:5600:1e::1281]) by smtp.gmail.com with ESMTPSA id t76sm8755506oit.5.2017.08.18.13.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 13:05:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.3\)) From: Fred Baker In-Reply-To: <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> Date: Fri, 18 Aug 2017 13:05:34 -0700 Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> References: <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.1.3) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:05:40 -0000 Hat off... Why not simply say "a prefix"? We are perpetually wrapped around an axle = with the prefix length, but reading this 20 years from now (which is the = perspective one should take in writing an RFC - what will it mean when = it's history?) I don't see why they would worry about the exact length = someone wanted to assign within their own boundaries. > On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 18/08/2017 =C3=A0 20:46, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a = =C3=A9crit : >> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu = wrote: > [...] >> In any event, my point below was that as long as this draft talks = about a live practice using today's standards, it doesn't make sense >> to discuss whether the choice in those standards (i.e., 64-bit IID) = is good/bad in that context. >=20 > I agree. >=20 > Maybe the 64bit IID is not a matter of this draft, since this draft is > about prefixes. >=20 > The IID length should be discussed in the other WG. >=20 > Here, still it makes sense to allow for prefixes shorter than 64 (i.e. > unique /63 prefix per Host, such that it can further grow the network = by > becoming a Router). >=20 > The draft says: >> a Unique IPv6 prefix (currently a /64 prefix) and some flags. >=20 > That "currently a /64" sounds as a hardcoded value. >=20 > It should be something like: "a variable length whose value could be = /56 for example; it could also be /64". >=20 > Alex >=20 >> If we want to have that discussion that should take place somewhere = else (and not even appropriate for v6ops in general, since changing that = would be most likely to involve a protocol change). Especially so when = such a discussion always leads to a non-productive >> repetition of stating different opinions. >>>> I'm not sure why we are talking about our favorite topic of 64-bit = (or not) IIDs here:-) This thread is even more inappropriate for that = topic than 4291bis (even where it's out >>>> of scope as it's not feasible to change that as part of promoting >>>> it to IS). People who want to discuss the endless IID length >>>> debate should really aware of the scope of the topic. >> -- JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 18 13:54:00 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0D6132332; Fri, 18 Aug 2017 13:53:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150308963835.14137.7735718957322221573@ietfa.amsl.com> Date: Fri, 18 Aug 2017 13:53:58 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:53:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-04.txt Pages : 15 Date : 2017-08-18 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 18 13:58:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEE1323A9 for ; Fri, 18 Aug 2017 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 3b3wxTE6SEEp for ; Fri, 18 Aug 2017 13:58:50 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 8F3F3132332 for ; Fri, 18 Aug 2017 13:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503089930; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=W3ZI5vNNfVpCVaaFLQgUxPDMGwlCzEVqqZOJwJ3ZnRg=; b=G4zKHhQ/F+OVrFOm1fGPVTAUV0dC/SlsFynI+mFz8dvJZNFx8wS24fjgeHOZnBs9 nxMwhNevHYXwsmTJHHpYud8TAE60ai83j118/ZDO3z22M2BHSyJ3j9hPE9zz9K+e dCqcDWCvhExlwgPfhMufxv4nJkPt6VNdecpNhgTDrCddK8jKpP5aMEHg1r9Za0UY ppahLVUwgyXFkO5opSqg9GyWsbQDPGcey0rKu9+vj7DenKHvPsmHowzi1EF92+7t cjSk6zmjTBR9KdGRoLntpx0P8IP4U0ubzLVxl/YK0DWrHPwuStdNZXI4tPcCzvrv GwgO0jLsnYF8x34+gpDmfQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 18.1A.30368.A0557995; Fri, 18 Aug 2017 13:58:50 -0700 (PDT) X-AuditID: 11973e13-821a09c0000076a0-99-5997550acdd6 Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay6.apple.com (Apple SCV relay) with SMTP id 45.11.03275.A0557995; Fri, 18 Aug 2017 13:58:50 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.107.180] (unknown [17.234.107.180]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUW008CIFM1YO70@kencur.apple.com> for v6ops@ietf.org; Fri, 18 Aug 2017 13:58:50 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Content-transfer-encoding: quoted-printable Date: Fri, 18 Aug 2017 13:58:49 -0700 References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> To: "v6ops@ietf.org" In-reply-to: Message-id: <24F280B5-4AEF-4FC8-976B-68FEEB015F59@apple.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAYpcsVOj3SYPEfGYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/+iY2wFnTIVB9buY21gfCXWxcjJISFgIrHy6xfWLkYuDiGB 1UwSk95vYoZJzN4xhRkisYlRovPXNyaQBK+AoMSPyfdYuhg5OJgF1CWmTMmFqJnGJHHx0lOw ZmEBaYmuC3dZQWrYBLQkDqwxAgkzC2hLPHl3gRWixE1i/vIGRhCbRUBVonP6OyaIOXeZJc6c XQK2SwQocfrpZbCZnALBEqtutbNC3GAj0b39FSPEobISt2ZfAjtUQmACm8SRhe9YJzAKzUJy 6yyEW2chuWMBI/MqRqHcxMwc3cw8U73EgoKcVL3k/NxNjKBwnW4nvIPx9CqrQ4wCHIxKPLwO f6ZFCrEmlhVX5h5ilOZgURLnvWgLFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBo3T7ZKl9z t/fl+7IHK/ltl9S32VqZLch6sLo+oy/p7TGzUI1bgq7PAp0PMRg5sEj5hTqu1F5W53vNZFLc YjtRzVnrt++eqB9885HPCv1GnxMfD9goBH16l9c3Nb2n5vzyvy8ml4qySlXwCbD/4dm+X+q4 u17Sxtcpi079Mvy/l3vhRfZiwxglluKMREMt5qLiRACHmsV5OAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUiON1OTZcrdHqkwbYjUhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv9Fx9gKOmUqDqzdx9rA+Eqsi5GTQ0LARGL2jinMXYxcHEIC mxglOn99YwJJ8AoISvyYfI+li5GDg1lAXWLKlFyImmlMEhcvPWUGqREWkJbounCXFaSGTUBL 4sAaI5Aws4C2xJN3F1ghStwk5i9vYASxWQRUJTqnv2OCmHOXWeLM2SVgu0SAEqefXgabySkQ LLHqVjsrxA02Et3bXzFCHCorcWv2JeYJjPyzkJw3C+G8WUhWL2BkXsUoUJSak1hpppdYUJCT qpecn7uJERReDYVROxgbllsdYhTgYFTi4X3xc1qkEGtiWXFl7iFGCQ5mJRFetsDpkUK8KYmV ValF+fFFpTmpxYcYq4AemMgsJZqcDwz9vJJ4QxMTAxNjYzNjY3MTc6oIK4nzyhVNjhQSSE8s Sc1OTS1ILYJZzsTBKdXAyJvNtfbCGwep2+nqbyo0l2t9nSQUrzdDaqKea9PT/Uq+q/YfPvDR /7PGhmkHLNXnuVry/rMP7NLuOnH2pocb92EHxVl3DO8cMHrhpNi0YN5lr6uaHd6h8jeud5hO PyI2n+X33Sq/svzgGan/b73ew7DD4OWuPo+A2869QbUOkc/fxE3tvyaRpsRSnJFoqMVcVJwI ABhIzTGKAgAA Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:58:52 -0000 Thanks everyone for the feedback provided during WGLC. The authors = accept the group's consensus that asynchronous DNS should be a SHOULD = rather than a MUST, and we have updated the document accordingly. = Starting with version -04, the "Hostname Resolution Query Handling" = section does not contain any MUSTs. We have also made editorial changes, = clarifications, and addressed other comments received in the past few = weeks. The latest version can be found here: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-04 To everyone who send feedback during WGLC, please let us know whether = version -04 addresses your comments. Thanks, David Schinazi > On Aug 16, 2017, at 11:17, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Tue, 15 Aug 2017 13:39:41 -0700, > Fred Baker wrote: >=20 >> When David and Jinmei started using the word "consensus" and asked >> what the chairs thought, the chairs went off in a huddle. This is us >> coming back. > [...] >> Our perception of the difference between David and Jinmei here >> surrounds getaddrinfo(); David wants all implementations to use the >> AAAA record the instant it comes back, and the A record only if the >> AAAA record is significantly delayed, while Jinmei wants to >> grandfather implementations using existing APIs that insist on >> having both or seeing a timeout. >=20 > To be clear, I personally don't have a *strong* opinion on the choice. > If the wg without me decides a MUST is more appropriate, that's fine. > I raised this point in my review comment just in case it's an > oversight since I've observed this has been a controversial point and > I don't think I saw an explicit wg consensus about that. >=20 > But, if what I feel matters, I actually think a MUST is too strong, > exactly for the reason you explained below, that is, I just don't see > why this requirement must inevitably be a MUST. I also agree > SHOULD/SHOULD NOT is more suitable in cases like this. >=20 >> We (the chairs) have sympathy in both directions, but suspect that >> Jinmei's is more realistic. =46rom a strategic perspective, we want >> all applications to do this; making it harder reduces the >> probability of it happening, and making it easy makes it more >> likely. Not all OS's (think IOT RTOS's) have threads, and not all >> have asynchronous DNS resolution. Practically, we suspect that >> implementors will do what is straightforward, and not do the rest - >> HEv1.5, if you will. In addition, at least the way I use "MUST" in >> an RFC, when I say something MUST (or MUST NOT) be done, failing on >> the point results in something dramatic. If I say that a TCP >> implementation MUST eventually acknowledge every segment it >> correctly receives in sequence, and someone doesn't, the result is a >> perpetual TCP session transmitting and retransmitting the same >> data. That's pretty fundamental. I don't see an interoperability >> failure if an implementation doesn't resolve DNS asynchronously; I >> do see a delay, and a reason that an asynchronous implementation >> might be preferred in the market. So to me, this sounds more like >> "SHOULD/SHOULD NOT" - we would like folks to do this, and if they >> don't they should understand the implications of not doing so, but >> it doesn't break in any fundamental way. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 18 15:12:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8C21321DE for ; Fri, 18 Aug 2017 15:12:17 -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 yFcJlLKQlWI8 for ; Fri, 18 Aug 2017 15:12:15 -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 C4D51132027 for ; Fri, 18 Aug 2017 15:12:15 -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 v7IMCDSF000432; Sat, 19 Aug 2017 00:12:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 042C120465D; Sat, 19 Aug 2017 00:12:13 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DF904204496; Sat, 19 Aug 2017 00:12:12 +0200 (CEST) Received: from [132.166.84.31] ([132.166.84.31]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7IMCBF5021997; Sat, 19 Aug 2017 00:12:12 +0200 To: Fred Baker Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" References: <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> From: Alexandre Petrescu Message-ID: <755d71dd-868e-ce32-37da-96ac3762ef7b@gmail.com> Date: Sat, 19 Aug 2017 00:12:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 22:12:17 -0000 Le 18/08/2017 à 22:05, Fred Baker a écrit : > Hat off... > > Why not simply say "a prefix"? I tend to agree. Alex > We are perpetually wrapped around an axle with the prefix length, but > reading this 20 years from now (which is the perspective one should > take in writing an RFC - what will it mean when it's history?) I > don't see why they would worry about the exact length someone wanted > to assign within their own boundaries. From nobody Fri Aug 18 18:06:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDA132407 for ; Fri, 18 Aug 2017 18:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vgYAF7B2q6U for ; Fri, 18 Aug 2017 18:06:17 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC3E13203D for ; Fri, 18 Aug 2017 18:06:17 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n29so9097120uai.5 for ; Fri, 18 Aug 2017 18:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Bl+om7aj6M6q6dpaLVQW08IMUKTV4sGsadvyIRj4eA4=; b=RcIUfxeSZktc6ufDJyMxxVh+UryAoQ/kJVx+tyFyFJXsz9BZBBWJ/udcb+jxG4/bi8 0Dtrwx4OhfeYFGgrsEL1cdoB0lTdmC7AgKBD4E//fVx0yg/nkLE7+OEFeFz7djNAiZTz NC7Hdp9bgHsLLPgB3SRyBQxNR1NIHYehq6ondf0KgzY3NLjZE7D4lPbqoj6AJN/1Wju5 JFjoVAeXN6Jeqi4Cwm6Lc/OMELt88G6B2Auon9QOyy6MSA/U8/TlJZkpCYR2z4MT493+ EvY15pUvyIDpdZCez0EUqdPw1xmCVoMvtgrLdN16KnpjswiSyENVaPOG85owmR9gclLy m8WA== 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=Bl+om7aj6M6q6dpaLVQW08IMUKTV4sGsadvyIRj4eA4=; b=MuLnhlZlK9hfa4RsdWREpbd3v7sxQHEWPnxNakIzwhnoDPtnRo4dpiVsMMZXd8ZmrG MespeA+5KnWLsbVSLZ/jssoFrF/HwhRctlh4X7/1XsSTMHdR6DBUrOVq9cizGWOk5Sg4 XpuewMRIw28u129vthtyEcTMZaaC6vyU5sEz0dg5tJ/YsSZQz9Xt/sMvRXToGx+OSe3v Ijwz/RJl+gfpe8UkhrUAor2f+jT1XEfPSUm1B8jWI34MOqy/dIf9YGZ0+rrdsmevRH6D nSNBoESDuT6Gfx1Lt/NZjiK8yPqUAsxwaHTA5OAeZ/xPMuDVqShEQJdyS4CPWYWaHG+e THdg== X-Gm-Message-State: AHYfb5iYUh4PIQBS/XO7t0gxftUF+JXx5LN3oTpNNAsTEAPkrCcHmr1h 4agciqGZTSomYGucWTNcdqEnipEpBqCI X-Received: by 10.176.70.145 with SMTP id r17mr7132742uaa.53.1503104776158; Fri, 18 Aug 2017 18:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.7.209 with HTTP; Fri, 18 Aug 2017 18:05:45 -0700 (PDT) In-Reply-To: <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> References: <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> From: Mark Smith Date: Sat, 19 Aug 2017 11:05:45 +1000 Message-ID: To: Fred Baker Cc: Alexandre Petrescu , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:06:18 -0000 On 19 August 2017 at 06:05, Fred Baker wrote: > Hat off... > > Why not simply say "a prefix"? We are perpetually wrapped around an axle = with the prefix length, but reading this 20 years from now (which is the pe= rspective one should take in writing an RFC - what will it mean when it's h= istory?) I don't see why they would worry about the exact length someone wa= nted to assign within their own boundaries. > I think it matters because prefix length is the compliment of IID size, and we know that the size and value of an IID has privacy and security implications. RFC7421, "Analysis of the 64-bit Boundary in IPv6 Addressing", suggests that an IID of at least 40 bits is necessary for privacy. If this draft does not take a position on the size of a prefix given to a host, it should at least highlight that prefix lengths longer than /88 can have corresponding IID size related privacy implications, and may want to reference RFC6973, "Privacy Considerations for Internet Protocols" and RFC7721, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms" for more specific IPv6 addressing discussion. Regards, Mark. From nobody Fri Aug 18 18:17:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC86213241B for ; Fri, 18 Aug 2017 18:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aeiHTjcgKrKG for ; Fri, 18 Aug 2017 18:17:23 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7440126E64 for ; Fri, 18 Aug 2017 18:17:23 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id o72so12680988ita.1 for ; Fri, 18 Aug 2017 18:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YeJG5JI19BLhw9r3ftqo7MyuNJJqL2MtGDyzPpmhCAU=; b=nNkvBGKvwXnAyJ19J94P4RDUXmn2i+9HtxoPEI+ogZlR1GLjvNS7rTmHjBT850n/4c x8n+1nMKAEOE6N11weq1m+5pSvFwXJoQxN7dWJkILWhufOQBHZFS/4epr06kdNsEQjPL reg72t1li/1x1uAqaYv8lzKyQvEsGDGL/g7i2/QVPwnTXAVlwysAxCbf3l3JLN3QotJQ RYGxH+LCpBvwtVKqvqZPHCHrvH+bLkUnMq5UNVWjGrDBDE5XlpxKCGGAy6PxHW57/7xM 0cRbAHKR7DtfBX11S5sNx0nfq8c5qLfvc3UBK4RhP+3arDbO1n7RW+9cZYza/vWZpIQr rU4A== 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=YeJG5JI19BLhw9r3ftqo7MyuNJJqL2MtGDyzPpmhCAU=; b=rz2fl3Xva7lysWDyoxv5i70S/E/CqOoohbvd2XWSY3B3Kc3p857mnYndyT9pydl4u2 U3dcVvARngAePHC0DcQRQhsJY4f2OdFbNUEwipprYkVocbg7VyjBtYWKRI1/zrMzDmnm 5LXorMEIrcQNpq124jynB/gkzVjGXHXiYpd7k3Cddk8+2YjYDx0HFgvPhVPsjHAyGm28 BoMXpTb7tESgO+WqKmu4Bgi5fGWz7NX+3PVrzko7QiWqONu1J1NddBpe3vIXNgAxI8ln hS7uwFNH2of+VKP9KuwbvcXR4SqEhnm6SJhmsjMBhBmgMgs4dljOXvV4O/x/alDcyRjI pHoA== X-Gm-Message-State: AHYfb5g8qqsp+CIl9I1YTeIG3augN8Pn4mh1SPMx5RZUYnT6nT5a+v+4 gMvE+6XoeNKbAaV5FPUdSc2ekU+nXejL X-Received: by 10.36.246.3 with SMTP id u3mr9105ith.4.1503105442684; Fri, 18 Aug 2017 18:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Fri, 18 Aug 2017 18:17:01 -0700 (PDT) In-Reply-To: <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> References: <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> From: Lorenzo Colitti Date: Sat, 19 Aug 2017 10:17:01 +0900 Message-ID: To: Fred Baker Cc: Alexandre Petrescu , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="94eb2c03583af9284c0557110189" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:17:26 -0000 --94eb2c03583af9284c0557110189 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the prefix length changes away from 64 bits it will be a major change that will affect this document in many ways. I'd leave as is. It's definitely useful for the uninitiated reader to know that currently the only prefix size that is valid and accepted by implementations is 64. On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker wrote: > Hat off... > > Why not simply say "a prefix"? We are perpetually wrapped around an axle > with the prefix length, but reading this 20 years from now (which is the > perspective one should take in writing an RFC - what will it mean when it= 's > history?) I don't see why they would worry about the exact length someone > wanted to assign within their own boundaries. > > > On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > > > > > > > Le 18/08/2017 =C3=A0 20:46, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3= =A9crit : > >> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > [...] > >> In any event, my point below was that as long as this draft talks abou= t > a live practice using today's standards, it doesn't make sense > >> to discuss whether the choice in those standards (i.e., 64-bit IID) is > good/bad in that context. > > > > I agree. > > > > Maybe the 64bit IID is not a matter of this draft, since this draft is > > about prefixes. > > > > The IID length should be discussed in the other WG. > > > > Here, still it makes sense to allow for prefixes shorter than 64 (i.e. > > unique /63 prefix per Host, such that it can further grow the network b= y > > becoming a Router). > > > > The draft says: > >> a Unique IPv6 prefix (currently a /64 prefix) and some flags. > > > > That "currently a /64" sounds as a hardcoded value. > > > > It should be something like: "a variable length whose value could be /5= 6 > for example; it could also be /64". > > > > Alex > > > >> If we want to have that discussion that should take place somewhere > else (and not even appropriate for v6ops in general, since changing that > would be most likely to involve a protocol change). Especially so when > such a discussion always leads to a non-productive > >> repetition of stating different opinions. > >>>> I'm not sure why we are talking about our favorite topic of 64-bit > (or not) IIDs here:-) This thread is even more inappropriate for that > topic than 4291bis (even where it's out > >>>> of scope as it's not feasible to change that as part of promoting > >>>> it to IS). People who want to discuss the endless IID length > >>>> debate should really aware of the scope of the topic. > >> -- JINMEI, Tatuya > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c03583af9284c0557110189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the prefix length changes away from 64 bits it will be = a major change that will affect this document in many ways.

<= div>I'd leave as is. It's definitely useful for the uninitiated rea= der to know that currently the only prefix size that is valid and accepted = by implementations is 64.

On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker <fredbake= r.ietf@gmail.com> wrote:
Ha= t off...

Why not simply say "a prefix"? We are perpetually wrapped around = an axle with the prefix length, but reading this 20 years from now (which i= s the perspective one should take in writing an RFC - what will it mean whe= n it's history?) I don't see why they would worry about the exact l= ength someone wanted to assign within their own boundaries.

> On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu <alexandre.petrescu@gmail.c= om> wrote:
>
>
>
> Le 18/08/2017 =C3=A0 20:46, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3= =A9crit :
>> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu <alexandre.petres= cu@gmail.com> wrote:
> [...]
>> In any event, my point below was that as long as this draft talks = about a live practice using today's standards, it doesn't make sens= e
>> to discuss whether the choice in those standards (i.e., 64-bit IID= ) is good/bad in that context.
>
> I agree.
>
> Maybe the 64bit IID is not a matter of this draft, since this draft is=
> about prefixes.
>
> The IID length should be discussed in the other WG.
>
> Here, still it makes sense to allow for prefixes shorter than 64 (i.e.=
> unique /63 prefix per Host, such that it can further grow the network = by
> becoming a Router).
>
> The draft says:
>> a Unique IPv6 prefix (currently a /64 prefix) and some flags.
>
> That "currently a /64" sounds as a hardcoded value.
>
> It should be something like: "a variable length whose value could= be /56 for example; it could also be /64".
>
> Alex
>
>> If we want to have that discussion that should take place somewher= e else (and not even appropriate for v6ops in general, since changing that = would be most likely to involve a protocol change).=C2=A0 Especially so whe= n such a discussion always leads to a non-productive
>> repetition of stating different opinions.
>>>> I'm not sure why we are talking about our favorite top= ic of 64-bit (or not) IIDs here:-)=C2=A0 This thread is even more inappropr= iate for that topic than 4291bis (even where it's out
>>>> of scope as it's not feasible to change that as part o= f promoting
>>>> it to IS).=C2=A0 People who want to discuss the endless II= D length
>>>> debate should really aware of the scope of the topic.
>> -- JINMEI, Tatuya
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops=

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--94eb2c03583af9284c0557110189-- From nobody Fri Aug 18 18:28:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879A3132420 for ; Fri, 18 Aug 2017 18:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 FQ2w53tJc87Q for ; Fri, 18 Aug 2017 18:28:55 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB20126E64 for ; Fri, 18 Aug 2017 18:28:54 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id l19so11054752wmi.1 for ; Fri, 18 Aug 2017 18:28:54 -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=N62Jp738ygALrQ6tOnw6ZK3QJj0fDz9TQ+MnK/DdTY0=; b=f4jR29eBCwe/v4j62gMBD6Z2kShpYDWJFR6eSnh+2yLrV4Av2LLdYHJQzgBM67LGnY ZtSOyoW70KcKLMooEPxaYT6AqC+rdYDfMKH1WIb2Wqpsn9nfTr5PpPfn4fYLOTRytPQt bTDOTMC2ybLUk2yB7/VulcYnvThP7XvDpR9tnahqn7/W7E1JI03S5rccnYWTIHqILYf3 pxXGxIZFvWmSqEAIsmu8lTkAtZeC6dn3YYTU68zY/eNLQWk9EfP8osdX2AU+i1QS8oEs K3psbauQfkZhcVHn71kPPHc1fruE3RejxCMGylifSdDTh5tXx+cOstCGMhYGf53e2Yi9 wFnw== 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=N62Jp738ygALrQ6tOnw6ZK3QJj0fDz9TQ+MnK/DdTY0=; b=gLT2VarvItPJAf3iJ3FrFZ0m0XulNs0nZ8BDB9lIsjtafLxXRV6BNtWKlvZjeVxA5O mqXLe3selw0VruGMIYV4FZK6HT9RbV01v4xp5Rz9BwbDeD0MvvEBO2su5e++UYc9Rk/7 OPTr8Zud240a7NaulbFDo5tZUnNQXvEUeECowFr/IT/Sdko52sXWJms4PUQPT8LLU/VU ML4Sb0iIbuE0m8hX0P2gavYAjJOkP49Qn3uRX0W1fNwQyVUQyT177YSlvtPUsAfj5GXQ pM4AG+UQ3fAWhq3ZIsTqwOrtUYtFqHD5bnxGR8xP+a8tFVx1su2GZQRDHMbDmbI7plly bJUw== X-Gm-Message-State: AHYfb5jRs3UXCwuafMW42O7kYWSiQLSqCQdVApdLDXvKsMZBkB6d/rL0 1Ql45ebfog7RfYOyvPw= X-Received: by 10.28.86.8 with SMTP id k8mr2231353wmb.147.1503106133212; Fri, 18 Aug 2017 18:28:53 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1e::1311? ([2600:8802:5600:1e::1311]) by smtp.gmail.com with ESMTPSA id k29sm6191504wrk.56.2017.08.18.18.28.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 18:28:52 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_63D66DB2-CA7F-4FE8-8F80-CAAA3A65CA81" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.3\)) Message-Id: <22F4F07F-B703-4E57-91DA-725A14101787@gmail.com> References: To: IPv6 Ops WG Date: Fri, 18 Aug 2017 18:28:49 -0700 X-Mailer: Apple Mail (2.3445.1.3) Archived-At: Subject: [v6ops] Fwd: Did something happen with a mail server? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:28:57 -0000 --Apple-Mail=_63D66DB2-CA7F-4FE8-8F80-CAAA3A65CA81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI: The chairs have been getting a bunch of "drop" and "bounce" messages = over the past month. Unfortunately, I don't have a good way to send a = message to the affected parties - they're not receiving messages. = However, if you know someone that is historically on v6ops and thinks = they might suddenly not be - they probably aren't, and this is probably = why. You might forward this to them. > Begin forwarded message: >=20 > From: Glen > Subject: Re: Did something happen with a mail server? > Date: July 18, 2017 at 7:22:05 AM PDT > To: Fred Baker >=20 > Hi Fred - >=20 > Not a glitch, and not anything that happened with the mailing lists. >=20 > Alas, this is a case where Yahoo had implemented a very hard-reject > policy against SPF violations, and I suspect what's happened is that > they've now "extended" that policy to their foreign servers. We've > known for quite some time that nobody @yahoo.com can effectively > participate in any mailing lists (anywhere) because of this - now it > seems that everyone at @yahoo.* is also affected by this. >=20 > = http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-bre= aks-mailing-lists.html > et al >=20 > There is not, alas, anything I can do. You might wish to warn - by > direct email - your @yahoo.* users about this; on the other hand, they > probably already know. They're going to need to move to Google, or > any other, more sane ISP that doesn't have the cavalier attitude Yahoo > does towards their users. >=20 > Sorry! > Glen >=20 >=20 > On Tue, Jul 18, 2017 at 3:38 AM, Fred Baker = wrote: >> I got a bunch of service reports from v6ops@ietf.org, and I'm = suspecting it was a glitch >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: mailman@ietf.org >> To: v6ops-owner@ietf.org >> Cc: >> Bcc: >> Date: Tue, 18 Jul 2017 00:59:44 -0700 >> Subject: Bounce action notification >> This is a Mailman mailing list bounce action notice: >>=20 >> List: v6ops >> Member: goodnessguinness@yahoo.co.uk >> Action: Subscription disabled. >> Reason: Excessive or fatal bounces. >>=20 >>=20 >>=20 >> The triggering bounce notice is attached below. >>=20 >> Questions? Contact the Mailman site administrator at = mailman@ietf.org. And so on= --Apple-Mail=_63D66DB2-CA7F-4FE8-8F80-CAAA3A65CA81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI:

The = chairs have been getting a bunch of "drop" and "bounce" messages over = the past month. Unfortunately, I don't have a good way to send a message = to the affected parties - they're not receiving messages. However, if = you know someone that is historically on v6ops and thinks they might = suddenly not be - they probably aren't, and this is probably why. You = might forward this to them.


Begin = forwarded message:

From: = Glen <glen@amsl.com>
Subject: = Re: Did something = happen with a mail server?
Date: = July 18, 2017 at 7:22:05 AM = PDT
To: = Fred Baker <fredbaker.ietf@gmail.com>
Hi Fred -

Not a glitch, and not anything that happened with the mailing = lists.

Alas, this is a case where Yahoo had = implemented a very hard-reject
policy against SPF = violations, and I suspect what's happened is that
they've = now "extended" that policy to their foreign servers.  We've
known for quite some time that nobody @yahoo.com can = effectively
participate in any mailing lists (anywhere) = because of this - now it
seems that everyone at @yahoo.* = is also affected by this.

http://www.pcworld.com/article/2141120/yahoo-email-antispoofing= -policy-breaks-mailing-lists.html
et al

There is not, alas, anything I can do. =  You might wish to warn - by
direct email - your = @yahoo.* users about this; on the other hand, they
probably = already know.  They're going to need to move to Google, or
any other, more sane ISP that doesn't have the cavalier = attitude Yahoo
does towards their users.

Sorry!
Glen


On Tue, Jul 18, 2017 at 3:38 AM, Fred Baker = <fredbaker.ietf@gmail.com> wrote:
I got a bunch of service reports from = v6ops@ietf.org, and I'm suspecting it was a glitch



---------- Forwarded message = ----------
From: mailman@ietf.org
To: = v6ops-owner@ietf.org
Cc:
Bcc:
Date: Tue, 18 Jul 2017 00:59:44 -0700
Subject: = Bounce action notification
This is a Mailman mailing list = bounce action notice:

=    List:       v6ops
   Member: =     goodnessguinness@yahoo.co.uk
=    Action:     Subscription = disabled.
   Reason: =     Excessive or fatal bounces.



The triggering bounce notice is = attached below.

Questions? Contact the = Mailman site administrator at mailman@ietf.org.

And so on
= --Apple-Mail=_63D66DB2-CA7F-4FE8-8F80-CAAA3A65CA81-- From nobody Fri Aug 18 20:07:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795B613261B for ; Fri, 18 Aug 2017 20:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 VzR3CG4Ftr0Z for ; Fri, 18 Aug 2017 20:07:05 -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 4DAC813261A for ; Fri, 18 Aug 2017 20:07:05 -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 v7J372kN023681; Sat, 19 Aug 2017 05:07:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F37F200CBA; Sat, 19 Aug 2017 05:07:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0D0692018C0; Sat, 19 Aug 2017 05:07:02 +0200 (CEST) Received: from [132.166.84.31] ([132.166.84.31]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7J371AF021408; Sat, 19 Aug 2017 05:07:01 +0200 To: Lorenzo Colitti , Fred Baker Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> From: Alexandre Petrescu Message-ID: <05c09f22-6423-ed08-d84e-54f5af48c354@gmail.com> Date: Sat, 19 Aug 2017 05:07:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 03:07:07 -0000 Le 19/08/2017 à 03:17, Lorenzo Colitti a écrit : > If the prefix length changes away from 64 bits it will be a major change > that will affect this document in many ways. Change? there is no current spec currently requiring the prefix len to be 64Ș 4291 and 2464 talk IID len, not prefix len, right? > I'd leave as is. It's definitely useful for the uninitiated reader to > know that currently the only prefix size that is valid and accepted by > implementations is 64. 64 could be a footnote(?) SLAAC/Ethernet's also works with /48 delivered by ISP and filled-up to 64 by subnetting. "currently /64" - does it mean it is what this deployment does it now? In that case is it maybe INFORMATIONAL rather than BCP? Alex > > On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker > wrote: > > Hat off... > > Why not simply say "a prefix"? We are perpetually wrapped around an > axle with the prefix length, but reading this 20 years from now > (which is the perspective one should take in writing an RFC - what > will it mean when it's history?) I don't see why they would worry > about the exact length someone wanted to assign within their own > boundaries. > > > On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu > > > wrote: > > > > > > > > Le 18/08/2017 à 20:46, 神明達哉 a écrit : > >> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu > > > wrote: > > [...] > >> In any event, my point below was that as long as this draft > talks about a live practice using today's standards, it doesn't make > sense > >> to discuss whether the choice in those standards (i.e., 64-bit > IID) is good/bad in that context. > > > > I agree. > > > > Maybe the 64bit IID is not a matter of this draft, since this > draft is > > about prefixes. > > > > The IID length should be discussed in the other WG. > > > > Here, still it makes sense to allow for prefixes shorter than 64 > (i.e. > > unique /63 prefix per Host, such that it can further grow the > network by > > becoming a Router). > > > > The draft says: > >> a Unique IPv6 prefix (currently a /64 prefix) and some flags. > > > > That "currently a /64" sounds as a hardcoded value. > > > > It should be something like: "a variable length whose value could > be /56 for example; it could also be /64". > > > > Alex > > > >> If we want to have that discussion that should take place > somewhere else (and not even appropriate for v6ops in general, since > changing that would be most likely to involve a protocol change). > Especially so when such a discussion always leads to a non-productive > >> repetition of stating different opinions. > >>>> I'm not sure why we are talking about our favorite topic of > 64-bit (or not) IIDs here:-) This thread is even more inappropriate > for that topic than 4291bis (even where it's out > >>>> of scope as it's not feasible to change that as part of promoting > >>>> it to IS). People who want to discuss the endless IID length > >>>> debate should really aware of the scope of the topic. > >> -- JINMEI, Tatuya > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Fri Aug 18 20:13:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70E13262D for ; Fri, 18 Aug 2017 20:13: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6c8Uv1DJHFfa for ; Fri, 18 Aug 2017 20:13:25 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E56913262A for ; Fri, 18 Aug 2017 20:13:25 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g71so38456160ioe.5 for ; Fri, 18 Aug 2017 20:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5UF8ElgrbKp9myieHjx7P4jSMIQ8exS1wgE4C/y3jlA=; b=eWqeiNBkgy/kbrSQq/8/LLr3zk4o3a99uL8hY4HLIfYq0lUBEylLZ622aIBxSctJkK h8esb2qsj3GBYTG+TZvfFG5sLZzChtg8pjUg3DjBUIuIhBjjIU3hvsyw0dQGyNuSDtpr 8hbe6agG1NmtIBVOGJ4vuxlk3P81/2tR0L8AltKMNuJk9WJjAAxUzBx059r+DXzJGcBe PF34I8t/LnoRc1RsG57EBmY4wldeSC0ikhFc2lJj+Kqb7e5LW39siTf39cIIUD9Xw24D bEyrU6tuee4sr74foJjutm1kug6nl6fNqamylnG3j25C06/L4tW4c3AAUTG8+NNoT8sZ 9CUw== 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=5UF8ElgrbKp9myieHjx7P4jSMIQ8exS1wgE4C/y3jlA=; b=MUrRfO2oIyLb28RzIelgpUBj6souFMvS+mYY8pQQTF5jeukyhC7uCEbihFO/TzfDSS Fn0SUsLUspcRm1NU8uJdF1cViyJvlDKPL18BD4jgCBjiPaMGhP3vRbwSyrXnidhPXReh 8IgSamtmWnSlxK6QdfdWPXmhQbIr2UqXHk9PIasrkQ10kve80nA97vV2qkGdvXVpCylb 4DhY39Q4D4s5ThhRwX20V8+CYZtpgZ30XYh7o8BaWbpD97Z2vTkVOiGzTw/TTMIxGgd/ gusHH3aox7r2ZlISrZ1tGLpVQOCw4shVz80KsLFAPwvtRtUNkQkmpdMoKrd10ybPQYUi yMnQ== X-Gm-Message-State: AHYfb5j27fro4rofOgjouHNtbJ8/+kZa8hY99MIebameHqqmF6myl3gA F8x/ehlYSW6taKcBiQ5UO6GbHvNzs8Dk X-Received: by 10.107.9.203 with SMTP id 72mr2548311ioj.72.1503112404114; Fri, 18 Aug 2017 20:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Fri, 18 Aug 2017 20:13:03 -0700 (PDT) In-Reply-To: <05c09f22-6423-ed08-d84e-54f5af48c354@gmail.com> References: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> <26F2B05C-7697-48D0-8445-5627E22BCAAE@gmail.com> <05c09f22-6423-ed08-d84e-54f5af48c354@gmail.com> From: Lorenzo Colitti Date: Sat, 19 Aug 2017 12:13:03 +0900 Message-ID: To: Alexandre Petrescu Cc: Fred Baker , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="001a113eac58e83025055712a0fb" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 03:13:27 -0000 --001a113eac58e83025055712a0fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 19, 2017 at 12:07 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Le 19/08/2017 =C3=A0 03:17, Lorenzo Colitti a =C3=A9crit : > >> If the prefix length changes away from 64 bits it will be a major change >> that will affect this document in many ways. >> > > Change? there is no current spec currently requiring the prefix len to be > 64=C8=98 4291 and 2464 talk IID len, not prefix len, right? Yes, change is the right word. This is because: 1. This document presumes the use of SLAAC. 2. The prefix length has to be 128-IID length for SLAAC to work. 3. RFC 4291 says that IIDs are 64 bits (except for ::/3, which cannot currently be assigned to any real deployment). Therefore if the prefix length was not /64, no hosts would get any addresses. "currently /64" - does it mean it is what this deployment does it now? In > that case is it maybe INFORMATIONAL rather than BCP? > /64 is what the deployment must do in order to operate. If it doesn't work, then we don't document it in an operational working group. --001a113eac58e83025055712a0fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 19, 2017 at 12:07 PM, Alexandre Petrescu <alexandre.pet= rescu@gmail.com> wrote:
Le 19/08/2017 =C3=A0 03:17, Lorenzo Colitti a =C3=A9crit :
If the prefix length changes away from 64 bits it will be a major change th= at will affect this document in many ways.

Change? there is no current spec currently requiring the prefix len to be 6= 4=C8=98 4291 and 2464 talk IID len, not prefix len, right?

Yes, change is the right word. This is because:
<= ol>
  • This document presumes the use of SLAAC.
  • The prefix length h= as to be 128-IID length for SLAAC to work.
  • RFC 4291 says that I= IDs are 64 bits (except for ::/3, which cannot currently be assigned to any= real deployment).
    • Therefore if the prefix length was not /64= , no hosts would get any addresses.

    "currently /64" - does it mean it is what this = deployment does it now? In that case is it maybe INFORMATIONAL rather than = BCP?

    /64 is what the deployment must do= in order to operate. If it doesn't work, then we don't document it= in an operational working group.
    --001a113eac58e83025055712a0fb-- From nobody Mon Aug 21 05:58:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4430E132A1A; Mon, 21 Aug 2017 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 5Yt2OTluaOER; Mon, 21 Aug 2017 05:58:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30101.outbound.protection.outlook.com [40.107.3.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B486C132A17; Mon, 21 Aug 2017 05:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qkl2/w6zmCe3/Lah89VLdnuLwa0s1AYbcUXI1+pdUt4=; b=R4gYPfz4KjdUv9ll4+PtCrbyDDsWjpX0cYcwdKylWozMaKBaior6JzBt2zy3eWF9LqKlf/Fy7+FQxqyHyiIDryYg0It6quTaePr2+PWTjvXhAs6Glb/7K4bDLtDILUCFLA3CAbQ0MbcZuDLPLfAiX0jPZG5sJp0uYwVAZCvQ488= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1569.eurprd07.prod.outlook.com (10.165.249.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 12:57:59 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07%14]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 12:57:59 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Suresh Krishnan , The IESG CC: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Ron Bonica , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTFuKYQ+gKTl12Z0GuSR6OAMdtbqKO7fkA Date: Mon, 21 Aug 2017 12:57:59 +0000 Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.121.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1569; 6:drxoxg24x5kOR0NTRbEpG3EWtFr5cjvTcenL+5w2nxbj12F8tQnWs7Hmup9kv2y1xgQn9my4+WrLq+sBNs8tugDGkIs0QQmJXMtTgeGjFchlzmaRYqn0cX4jAgm8RF9PyS9Z+AdBtiNe4E5tATGNNLZEbNkfe5X1r9TExEEam62zFc7tA2KfvvPwBfNqEbTAOJbrfWflUAw/NPR6WpIRZe7t8sms/Aut3yyftogBNk/a8Tpj6bZkgxgcem81vvSr1btNzu5L2J70mC6Nd8hUaTZtYbdbvpblYlYry/X8aZEklNAfPprmVk8ZEBjW/IGxKta4eu5wOgZl7wUorhGgKg==; 5:qPs7COUL52ZGPNzZcxuMwuQEqJ30zUv1P5v4BwHqaqf6Nisq/52R2YtI3Z//XJJlGkMEKLJr+f2dvDBDnln3JlK42kBGiNjCf3Ss6cCCtlwgeqv4YuPt1RyRbZ0vq8cnSO2wx7OTZCbRybBnj26sLw==; 24:d0RJnohEdK7B0rug1efy4gvF5BR1sABe9ZvhV7zVWjX1g1xtbhTYe77SUb2uHaspvHIpKCtX9hAuKcGUkk5Zr5EHUQEri+c4ocor/ymjzxo=; 7:0unKRcg7CBE8gc7iXaYiEkYHJ9lM0xIafFA1RbiJrEC5ARwub14TLSwjfLsuwHkgsqWu1+iib86Xq3/podK4TeI2GEHgMUHjDKxrO6kpR7pF8dYVjQ5/XDuVAK05fqvba2x1AYC+59emeOsh9GKG39LXy0xahfzFqW+ujtMuJFETZ7i8qYfUbqnr/6/uMLsZM+ycfO5L0zdjl5CChHn/DehhrL/mprmGd6vqmqffVPM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 586821af-3139-457e-07d4-08d4e8944029 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB1569; x-ms-traffictypediagnostic: AM4PR07MB1569: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1569; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1569; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(76104003)(51914003)(199003)(189002)(66654002)(53936002)(50986999)(54356999)(66066001)(6512007)(99286003)(8666007)(97736004)(6116002)(189998001)(54906002)(76176999)(6506006)(6486002)(101416001)(3846002)(102836003)(68736007)(36756003)(2950100002)(39060400002)(106356001)(6246003)(105586002)(229853002)(230783001)(83716003)(5660300001)(5250100002)(14454004)(7736002)(305945005)(86362001)(8936002)(33656002)(2900100001)(81156014)(81166006)(8676002)(82746002)(4326008)(3660700001)(25786009)(2906002)(478600001)(6436002)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1569; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6E5D28E531F6AF4582BA61DED4144A07@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 12:57:59.4692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1569 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 12:58:04 -0000 SGkgU3VyZXNoLA0KICAgDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldyBhbmQgZmluZGluZyB0 aGVzZSBpc3N1ZXMuIFdoYXQgZG8geW91IHRoaW5rIG9mIHRoZSBwcm9wb3NhbHMgYmVsb3cgdG8g Zml4IHRob3NlIHBvaW50cyBvZiBhdHRlbnRpb24/DQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgIERJU0NVU1M6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgICogU2VjdGlvbiA0DQog ICAgDQogICAgSXQgaXMgbm90IGNsZWFyIHdoYXQgeW91IGludGVuZCBoZXJlDQogICAgDQogICAg IklQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwgPSAzMDBzIg0KICAgIA0KICAgIFRo ZSByb3V0ZXIgYWR2ZXJ0aXNlbWVudCBpbnRlcnZhbCBpcyBub3QgY29uZmlndXJlZCBhcyBhbiBh YnNvbHV0ZSB2YWx1ZSBidXQgYXMNCiAgICBtaW5pbXVtIGFuZCBtYXhpbXVtIGJvdW5kcyAoTWlu UnRyQWR2SW50ZXJ2YWwgYW5kIE1heFJ0ckFkdkludGVydmFsKSB3aGljaCBhcmUNCiAgICB1c2Vk IHRvIGNhbGN1bGF0ZSB0aGUgYWN0dWFsIGFkdmVydGlzZW1lbnQgaW50ZXJ2YWwuIFdoZW4gdGhl IFJBIGlzIHNlbnQgZnJvbQ0KICAgIGFuIGludGVyZmFjZSwgdGhlIGFjdHVhbCBpbnRlcnZhbCBp cyBhbiB1bmlmb3JtbHkgZGlzdHJpYnV0ZWQgcmFuZG9tIHZhbHVlDQogICAgYmV0d2VlbiB0aGUg TWluUnRyQWR2SW50ZXJ2YWwgYW5kIE1heFJ0ckFkdkludGVydmFsLiBBdCB0aGUgdmVyeSBtaW5p bXVtIHlvdQ0KICAgIG5lZWQgdG8gY2xhcmlmeSBpZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIHRo aXMgYXMgYSBsb3dlciBib3VuZCBvciBhcyBhbiB1cHBlcg0KICAgIGJvdW5kLg0KICAgIA0KR1Y+ IEkgY2hhbmdlZCB0aGUgbGluZSB0byBtYWtlIGl0IG1vcmUgY2xlYXIgdGhhdCB0aGUgdGltZXIg aW5kaWNhdGVzIHRoZSBtYXhpbXVtIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwNCkdWPiAgICAgICAg ICA8dD5NYXhpbXVtIElQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwgPSAzMDBzPC90 Pg0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICANCiAgICAqIFNlY3Rpb24gNA0KICAgIA0KICAgIC0+IEkgdGhpbmsgdGV4dCBpcyBu ZWVkZWQgaGVyZSB0byBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUgdGhlIEROUyBzZXJ2ZXIgaXMNCiAg ICBwcm92aWRlZCBpbiB0aGUgUkEgaXRzZWxmICAoUkZDODEwNikNCiAgICANCiAgICAiSW4gYWRk aXRpb24gaXQgd2lsbCB1c2Ugc3RhdGVsZXNzIERIQ1B2NiB0byBnZXQgdGhlIElQdjYgYWRkcmVz cyBvZiB0aGUgRE5TDQogICAgc2VydmVyIg0KICAgIA0KICAgIC0+IEkgYW0gbm90IHN1cmUgd2hh dCBpcyB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcyB0ZXh0Lg0KICAgIA0KICAgICJob3dldmVyIGl0 IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byByZWNlaXZlIGEgc2VydmljZSBwcm92 aWRlcg0KICAgIG1hbmFnZWQgSVB2NiBhZGRyZXNzIg0KICAgIA0KICAgIC0+IFRoaXMgdGV4dCBz ZWVtcyBpbmNvcnJlY3QNCiAgICANCiAgICAiZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0IFNIT1VM RCBzZW5kIHRoaXMgdHJhZmZpYyB0byB0aGUgRmlyc3QgSG9wIFByb3ZpZGVyDQogICAgUm91dGVy Ig0KICAgIA0KICAgIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBleGFjdCBvcHBvc2l0ZS4gaS5l LiBzYXkgKnVuc2V0KiBpbnN0ZWFkIG9mIHNldA0KICAgIA0KICAgICJkdWUgdG8gdGhlIEwtYml0 IGJlaW5nIHVuc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhv cA0KICAgIFByb3ZpZGVyIFJvdXRlciINCiAgICANCkdWPiBXaGF0IGFib3V0IHRoZSBmb2xsb3dp bmcgbW9kaWZpY2F0aW9uIGluIHRoZSB0ZXh0Og0KDQpPTEQ6DQpUaGUgYXJjaGl0ZWN0ZWQgcmVz dWx0IG9mIGRlc2lnbmluZyB0aGUgUkEgYXMgZG9jdW1lbnRlZCBhYm92ZSBpcw0KICAgdGhhdCBl YWNoIFVFL3N1YnNjcmliZXIgZ2V0cyBpdHMgb3duIHVuaXF1ZSBJUHY2IHByZWZpeCBmb3Igd2hp Y2ggaXQNCiAgIGNhbiB1c2UgU0xBQUMgb3IgYW55IG90aGVyIG1ldGhvZCB0byBzZWxlY3QgaXRz IC8xMjggdW5pcXVlIGFkZHJlc3MuDQogICBJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0ZWxl c3MgREhDUHY2IHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzIG9mDQogICB0aGUgRE5TIHNlcnZlciwg aG93ZXZlciBpdCBTSE9VTEQgTk9UIHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZQ0KICAg YSBzZXJ2aWNlIHByb3ZpZGVyIG1hbmFnZWQgSVB2NiBhZGRyZXNzLiAgSWYgdGhlIFVFL3N1YnNj cmliZXINCiAgIGRlc2lyZXMgdG8gc2VuZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3Ro ZXIgVUUvc3Vic2NyaWJlcg0KICAgZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBj b21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZA0KICAgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRv IHRoZSBMLWJpdCBzZXQsIGl0IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgdG8gdGhlIEZp cnN0IEhvcCBQcm92aWRlciBSb3V0ZXIuDQoNCk5ldzoNClRoZSBhcmNoaXRlY3RlZCByZXN1bHQg b2YgZGVzaWduaW5nIHRoZSBSQSBhcyBkb2N1bWVudGVkIGFib3ZlIGlzDQp0aGF0IGVhY2ggVUUv c3Vic2NyaWJlciBnZXRzIGl0cyBvd24gdW5pcXVlIElQdjYgcHJlZml4IGZvciB3aGljaCBpdA0K Y2FuIHVzZSBTTEFBQyBvciBhbnkgb3RoZXIgbWV0aG9kIHRvIHNlbGVjdCBpdHMgLzEyOCB1bmlx dWUgYWRkcmVzcy4gDQpFaXRoZXIgc3RhdGVsZXNzIERIQ1B2NiA8eHJlZiB0YXJnZXQ9IlJGQzM3 MzYiPlJGQzM3MzY8L3hyZWY+IG9yIElQdjYgDQpSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBPcHRpb25z IGZvciBETlMgQ29uZmlndXJhdGlvbiANCjx4cmVmIHRhcmdldD0iUkZDODEwNiI+UkZDODEwNjwv eHJlZj4gY2FuIGJlIHVzZWQgdG8gZ2V0IHRoZSANCklQdjYgYWRkcmVzcyBvZiB0aGUgRE5TIHNl cnZlci4gSWYgdGhlIFVFL3N1YnNjcmliZXIgZGVzaXJlcyB0byBzZW5kDQphbnl0aGluZyBleHRl cm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlciBkZXZpY2VzIChhc3N1bWluZyBkZXZp Y2UNCnRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBwb3J0ZWQpLCB0 aGVuLCBkdWUgdG8gdGhlDQpMLWJpdCBiZWluZyB1bnNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0 cmFmZmljIHRvIHRoZSBGaXJzdCBIb3AgUHJvdmlkZXINClJvdXRlci48L3Q+DQoNCg0KDQpLaW5k IFJlZ2FyZHMsDQpHLw0KDQo= From nobody Mon Aug 21 06:16:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF74132A38; Mon, 21 Aug 2017 06:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 xCPcTRU_K9Y9; Mon, 21 Aug 2017 06:16:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20137.outbound.protection.outlook.com [40.107.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1D7132A3E; Mon, 21 Aug 2017 06:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=br7t4Skggj6gIOdL5vJu1PxkU5smk1wqHPtLricDoFU=; b=V46XRTYclhDneR/CGkikOQnw1JwRUmk98/YeZjgLDQGRYZ4jlOwYOs7DRNihNMfs3TKnKYN163FLoSKVnvCtLYPUu+bZPNbylMLjOkU8Nn8WoS+Q/r1L2XQjJCPMSQld8MUgzGagji6PFphd17C2Ev5vB807DXm061W5Iq/xPnM= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1378.eurprd07.prod.outlook.com (10.164.82.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 13:16:32 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07%14]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 13:16:32 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Lorenzo Colitti , Suresh Krishnan CC: The IESG , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTFuKYQ+gKTl12Z0GuSR6OAMdtbqKHnUIAgAdV5AA= Date: Mon, 21 Aug 2017 13:16:31 +0000 Message-ID: <96F993A7-09BE-4A15-8057-0CAC99E374E0@nokia.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [135.245.121.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1378; 6:4GGfQ0M2mY5o811Kqgj5Y7nDzeOh6ZXBW3w6qzMB7QeVj8QoVCRt+fl/AYedoKWPSDwhOESQaX+3qh9Sn3BDlvYd7Xj4DbOwrOT1fCl2YpzXvjxwRRcDkjoSB29phl4T4+LYFlQ4BENBfzX4fIUkkjb+r+HD5yeg4wLyQ3GLCcoonEKC1NvkViK1+tQx/Ce7rVyBTFvACQ+MDmWJHSqgrPC67O8y/0/IsNfifSa9XNOec5pVtrVGQw9nzY2JUVZzN5adC2w2L5m5qVen6I6eHA7R61qJEbL1R6dXPAZAMd9dVoelbRMJ+ZDkUoBG/GiLutEdl8dlDVIiMZ90prOrKw==; 5:bFLZS6tRuUsB6dcTs8cl6D92oHBI1ReRrSsemsjRA4UitxyTUw7vciO/+43aUWImeAKs/nTV27IrSHcGgSiooWDkeUqDSYpiLVzBTk/yOrq31YZ3dQdE35iVuGfphL8gadczf5Z7lL4BdDXAbfpZiQ==; 24:LBmwFm0gd4kRwJu9Ha6fEEPAbG6s3PiA/JvexY9+ghtwHSKVMqB9RWrtesjgRaN6uRrB+xCC81Wj8P80ZdUmMznbx2aWgVB4HogvudM0sI8=; 7:/jVCSAZmhpULnRU6e+vSzljK/cU+lHg0UYxAbSYJIMLubiayC+lYdPF0Y08ufFzJpacBdkRZWbmGke614xXOFp4RvyX5+21OoYUaxbp0ZH/E4LTcQudMizrT/TKpRxxe4JLMByly3wy3d6Cb1ao0uICajRkZai1rcW7WTReGUjTm784P3k0OSWi+V3K6dkwj3fEDuJsHnmINJB7KSjLQydZKXBfP4GkyWNiDfqlvAig= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 355bff20-6c95-4ef2-ca19-08d4e896d746 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB1378; x-ms-traffictypediagnostic: AM4PR07MB1378: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(62221491112393)(211936372134217)(95692535739014)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(920507026)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1378; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1378; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(199003)(24454002)(189002)(377454003)(14454004)(5250100002)(6486002)(6506006)(66066001)(9326002)(101416001)(561944003)(229853002)(86362001)(36756003)(68736007)(53546010)(54356999)(2950100002)(50986999)(6246003)(97736004)(39060400002)(6306002)(76176999)(3280700002)(99286003)(53936002)(4326008)(34040400001)(3660700001)(54906002)(25786009)(189998001)(2900100001)(33656002)(478600001)(7736002)(81166006)(3846002)(5660300001)(83716003)(102836003)(6116002)(81156014)(6436002)(8936002)(105586002)(8676002)(2906002)(106356001)(230783001)(236005)(6512007)(82746002)(54896002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1378; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_96F993A709BE4A1580570CAC99E374E0nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 13:16:32.0092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1378 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:16:51 -0000 --_000_96F993A709BE4A1580570CAC99E374E0nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhlIG1lbnRpb25lZCB0aW1lciBjb21lcyBmcm9tIEpvaG4gQnJ6b3pv d3NraeKAmXMgYmlnIHNjYWxlIG5ldHdvcmsgZGVwbG95bWVudOKApg0KUkZDNzc3MiBpbmRpY2F0 ZXMgdGhhdCBmb3IgbGFwdG9wcyBldGMgaXQgZG9lcyBub3QgcmVhbGx5IG1hdHRlciByZWdhcmRp bmcgYmF0dGVyeSBwb3dlciwgYnV0IHRoYXQgZm9yIGVuZXJneSBjb25zZXJ2YXRpdmUgZGV2aWNl cyBjdXJyZW50bHkgYSA3IFJB4oCZcyBwZXIgaG91ciAoYXNzdW1pbmcgdGhvc2UgY29uc3VtZSAw LjFtVykuDQoNCknigJlsbCBsZWF2ZSBpdCB0byBKb2huIEJyem96b3dza2kgdG8gcHJvdmlkZSBm ZWVkYmFjayByZWdhcmRpbmcgc2V0dGluZyBvZiB0aW1lciB0byAzMDAgc2VjIGhhcyBiZWVuIGEg cHJhY3RpY2FsIHVzZXIgZXhwZXJpZW5jZSBwcm9ibGVtIGZvciBuZXR3b3JrIHVzZXJzPyBNYXli ZSB0aGVyZSBpcyB1c2VyIGV4cGVyaWVuY2UgaW5mbw0Kbm93IHRoYXQgdGhlIGRlcGxveW1lbnQg aGFzIGJlZW4gb3V0IGluIHRoZSB3aWxkIGZvciBzb21lIHRpbWUuDQoNClRoZSBjdXJyZW50IG1v ZGlmaWVkIHRleHQgcHJvcG9zYWwgaXM6DQogICBNYXhpbXVtIElQdjYgUm91dGVyIEFkdmVydGlz ZW1lbnQgSW50ZXJ2YWwgPSAzMDBzDQoNCkFsdGVybmF0aXZlbHksIFJGQzQ4NjEgZG9jdW1lbnRz IHNvbWUgdGltZXJzLCBhbmQgbWF5YmUgaXRzIGJldHRlciBmb3IgZHJhZnQtaWV0Zi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QgdG8gcmVmZXJlbmNlIFJGQzQ4NjEgdGltZXJzIGlu c3RlYWQ/IE1heWJlIHRoaXMgZHJhZnQgc2hvdWxkIG9ubHkgZG9jdW1lbnQgcHJlZml4LWxpZmUg dGltZXM/DQoNCkcvDQoNCkZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29t Pg0KRGF0ZTogVGh1cnNkYXksIDE3IEF1Z3VzdCAyMDE3IGF0IDAxOjE1DQpUbzogU3VyZXNoIEty aXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPiwgImRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGll dGYub3JnIiA8ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0 Zi5vcmc+LCAiZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QuYWxs QGlldGYub3JnIiA8ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qu YWxsQGlldGYub3JnPiwgInY2b3BzLWNoYWlyc0BpZXRmLm9yZyIgPHY2b3BzLWNoYWlyc0BpZXRm Lm9yZz4sICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN ClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGpvaG5f YnJ6b3pvd3NraUBjb21jYXN0LmNvbT4sIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4s IDxyYm9uaWNhQGp1bmlwZXIubmV0PiwgPGxlZUBhc2dhcmQub3JnPiwgPGZyZWRiYWtlci5pZXRm QGdtYWlsLmNvbT4sIDxiY2xhaXNlQGNpc2NvLmNvbT4sIDx3YXJyZW5Aa3VtYXJpLm5ldD4sIFJv biBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIDE3 IEF1Z3VzdCAyMDE3IGF0IDAxOjE1DQoNCk9uIFRodSwgQXVnIDE3LCAyMDE3IGF0IDc6NTQgQU0s IFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbTxtYWlsdG86c3VyZXNo LmtyaXNobmFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KSXQgaXMgbm90IGNsZWFyIHdoYXQgeW91IGlu dGVuZCBoZXJlDQoNCiJJUHY2IFJvdXRlciBBZHZlcnRpc2VtZW50IEludGVydmFsID0gMzAwcyIN Cg0KSSdsbCBhbHNvIHBvaW50IG91dCB5ZXQgYWdhaW4gdGhhdCB0aGlzIHZhbHVlIGlzIGluIGNv bmZsaWN0IHdpdGggUkZDIDc3NzIgaW4gdGhlIGNhc2Ugb2YgbmV0d29ya3MgdGhhdCBhcmUgcHJv dmlkZSBzZXJ2aWNlIGZvciBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcy4gVGhlIHRleHQgc2hvdWxk IGVpdGhlciBiZSBjaGFuZ2VkIHRvIGZvbGxvdyB0aGF0IFJGQyBvciB0byBleHBsYWluIHRoZSBy ZWFzb24gZm9yIHRoZSBjb25mbGljdC4NCg== --_000_96F993A709BE4A1580570CAC99E374E0nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBMb3JlbnpvLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBtZW50aW9uZWQgdGltZXIgY29tZXMgZnJvbSBKb2hu IEJyem96b3dza2nigJlzIGJpZyBzY2FsZSBuZXR3b3JrIGRlcGxveW1lbnTigKYNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlJGQzc3NzIgaW5kaWNhdGVzIHRoYXQgZm9yIGxhcHRvcHMgZXRjIGl0IGRvZXMgbm90IHJlYWxs eSBtYXR0ZXIgcmVnYXJkaW5nIGJhdHRlcnkgcG93ZXIsIGJ1dCB0aGF0IGZvciBlbmVyZ3kgY29u c2VydmF0aXZlIGRldmljZXMgY3VycmVudGx5IGEgNyBSQeKAmXMgcGVyIGhvdXINCiAoYXNzdW1p bmcgdGhvc2UgY29uc3VtZSAwLjFtVykuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJlsbCBs ZWF2ZSBpdCB0byBKb2huIEJyem96b3dza2kgdG8gcHJvdmlkZSBmZWVkYmFjayByZWdhcmRpbmcg c2V0dGluZyBvZiB0aW1lciB0byAzMDAgc2VjIGhhcyBiZWVuIGEgcHJhY3RpY2FsIHVzZXIgZXhw ZXJpZW5jZSBwcm9ibGVtIGZvciBuZXR3b3JrIHVzZXJzPyBNYXliZQ0KIHRoZXJlIGlzIHVzZXIg ZXhwZXJpZW5jZSBpbmZvIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPm5vdyB0aGF0IHRoZSBkZXBsb3ltZW50IGhhcyBiZWVu IG91dCBpbiB0aGUgd2lsZCBmb3Igc29tZSB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo ZSBjdXJyZW50IG1vZGlmaWVkIHRleHQgcHJvcG9zYWwgaXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7 IE1heGltdW0gSVB2NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBJbnRlcnZhbCA9IDMwMHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5BbHRlcm5hdGl2ZWx5LCBSRkM0ODYxIGRvY3VtZW50cyBzb21lIHRp bWVycywgYW5kIG1heWJlIGl0cyBiZXR0ZXIgZm9yIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0IHRvIHJlZmVyZW5jZSBSRkM0ODYxIHRpbWVycyBpbnN0ZWFkPyBN YXliZQ0KIHRoaXMgZHJhZnQgc2hvdWxkIG9ubHkgZG9jdW1lbnQgcHJlZml4LWxpZmUgdGltZXM/ IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkcvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+ TG9yZW56byBDb2xpdHRpICZsdDtsb3JlbnpvQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlRodXJzZGF5LCAxNyBBdWd1c3QgMjAxNyBhdCAwMToxNTxicj4NCjxiPlRvOiA8L2I+U3Vy ZXNoIEtyaXNobmFuICZsdDtzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+VGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQt aWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmcmZ3Q7LCAmcXVv dDtkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC5hbGxAaWV0Zi5v cmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LmFsbEBpZXRmLm9yZyZndDssDQogJnF1b3Q7djZvcHMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZs dDt2Nm9wcy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt2Nm9wc0BpZXRmLm9yZyBXRyZxdW90 OyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbdjZvcHNd IFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3QtMDc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPGJyPg0KPGI+ UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5S ZXNlbnQtVG86IDwvYj4mbHQ7am9obl9icnpvem93c2tpQGNvbWNhc3QuY29tJmd0OywgJmx0O2d1 bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tJmd0OywgJmx0O3Jib25pY2FAanVuaXBlci5uZXQm Z3Q7LCAmbHQ7bGVlQGFzZ2FyZC5vcmcmZ3Q7LCAmbHQ7ZnJlZGJha2VyLmlldGZAZ21haWwuY29t Jmd0OywgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0OywgJmx0O3dhcnJlbkBrdW1hcmkubmV0Jmd0 OywgUm9uIEJvbmljYSAmbHQ7cmJvbmljYUBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5SZXNlbnQt RGF0ZTogPC9iPlRodXJzZGF5LCAxNyBBdWd1c3QgMjAxNyBhdCAwMToxNTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIEF1ZyAxNywgMjAxNyBhdCA3OjU0IEFNLCBTdXJlc2ggS3Jpc2huYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG5vdCBjbGVhciB3aGF0 IHlvdSBpbnRlbmQgaGVyZTxicj4NCjxicj4NCiZxdW90O0lQdjYgUm91dGVyIEFkdmVydGlzZW1l bnQgSW50ZXJ2YWwgPSAzMDBzJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2xsIGFsc28gcG9pbnQgb3V0IHlldCBhZ2Fp biB0aGF0IHRoaXMgdmFsdWUgaXMgaW4gY29uZmxpY3Qgd2l0aCBSRkMgNzc3MiBpbiB0aGUgY2Fz ZSBvZiBuZXR3b3JrcyB0aGF0IGFyZSBwcm92aWRlIHNlcnZpY2UgZm9yIGJhdHRlcnktcG93ZXJl ZCBkZXZpY2VzLiBUaGUgdGV4dCBzaG91bGQgZWl0aGVyIGJlIGNoYW5nZWQgdG8gZm9sbG93IHRo YXQgUkZDIG9yIHRvIGV4cGxhaW4gdGhlIHJlYXNvbiBmb3IgdGhlDQogY29uZmxpY3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_96F993A709BE4A1580570CAC99E374E0nokiacom_-- From nobody Mon Aug 21 06:50:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4261513235C for ; Mon, 21 Aug 2017 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEmD2A7_ZXJF for ; Mon, 21 Aug 2017 06:50:30 -0700 (PDT) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D86124207 for ; Mon, 21 Aug 2017 06:50:30 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7LDoRld019798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Aug 2017 09:50:27 -0400 Received: (qmail 30769 invoked by uid 0); 21 Aug 2017 13:50:27 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 21 Aug 2017 13:50:27 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 21 Aug 2017 09:50:24 -0400 From: Lee Howard To: "STARK, BARBARA H" , "jordi.palet@consulintel.es" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis References: <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:50:32 -0000 On 8/16/17, 5:32 PM, "v6ops on behalf of STARK, BARBARA H" wrote: >Inline... >Barbara > >> draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when >>IPv4 >> is no longer available. > >Yes: Not available (through any means) on the WAN. But still used on the >LAN. Problem 1 applies both to a home router and a LAN client interpreting a lack of DHCP response as an error. I don=E2=80=99t think this needs to be separat= e problems for router and device, do you? Problem 2 is for when IPv4 is not available on the WAN but the router advertises DHCP to the LAN. Problems 3-5 (Section 2.2) "Disabling IPv4 in the LAN=E2=80=9D are not about when it=E2=80=99s still used on the LAN. > >> So, if RFC7084 is an IPv6 only-CE (even if the CE can have an IPv4 >>stack), then >> we have those problems when there is no IPv4 connectivity. > >Yes: We will have the described problems if there is no IPv4 available on >the WAN (through any means). > >> If the IPv6-CE supports transition, then you never have those problems, >> because the goal of the transition support is precisely to avoid them. >>It is not >> a matter of IPv4 in the WAN. You can have IPv6-only WAN, but transition >>can >> resolve that. >>=20 >> Or I=E2=80=99m missing anything in your opinion? > >Please correct me if I'm wrong, but I thought all the described >mechanisms require a correlated capability in the WAN. Just because a CE >router supports all of these doesn't mean any of them necessarily exist >in the WAN, or that configuration of any of them via DHCPv6 is supported >by the ISP (WAN may have capability but requires manual CE Router config >which many end users won't know how to do). So I think support in the CE >Router, by itself, is insufficient to ensure IPv4 WAN availability. >Therefore, even if a CE Router supports all of these, it is still >possible for there to be no IPv4 WAN connection. IMO, CE Router >requirements that explicitly target IPv6-only operation would be a very >logical place to include requirements for "what to do when there is no >IPv4 in the WAN". This makes sense to me, though I might amend it to, "what to do when there is no native IPv4 or IPv4 transition mechanism in the WAN=E2=80=9D > >> The problem here, in my opinion is that in the actual RFC7084 you >>=E2=80=9Callow=E2=80=9D the >> support of IPv4, so is in that case when, if there is no transition >>support, the >> problems 1-5 may be presented in the LANs. >>=20 >> So, one alternative is again considering my proposal of making an >>RFC7084 >> with is =E2=80=9Creally=E2=80=9D only-IPv6 (removing ALL the IPv4 support in that >>document), >> and then it make sense to have other documents with the transition >>support, >> etc., and then finding the right one for resolving the problems above. > >Because of the existence of the CE Router IPv6 Ready certification >program, the many references to RFC 7084 made by external orgs, etc. I >continue to be opposed to changing it. That would almost certainly cause >confusion, and is unnecessary. Requirements related to IPv6-only WAN >connections (with or without the WAN supporting configuration or >termination of an IPv4 tunneling mechanism) can all logically go in a >single new doc. > >> Actually, some of the problems, in my opinion, can be resolved just in >>the OS, >> but is not a matter here to discuss one by one. For example, problem 1, >> some OS may believe there is only =E2=80=9CInternet=E2=80=9D if there is a DHCP serv= er >> responding, even if they have IPv6 connectivity, etc., but this can be >>sorted >> out in the actual RFC7084 if there is IPv4 stack, and there is no >>transition >> support and there is not IPv4 support, by making sure that the DHCPv4 >> server in the CE is not turned on in that case =E2=80=A6 > >That's a bad idea. I expect my home network to operate in the absence of >any and all WAN IP connections. I refuse to buy (or sell or recommend) a >CE router that does not continue to operate its DHCPv4 server in the >absence of IPv4 WAN connectivity. Also, I disagree with putting any >LAN-side IPv4 protocol requirements into a 7084bis. I no longer need IPv4 in my home network, except in translation. Can=E2=80=99t I just turn it off? If I can, even if it=E2=80=99s manual, then what happ= ens? I realize the fallacy of assuming I=E2=80=99m a typical user, but in three years when 80% of US connections are IPv6, aren=E2=80=99t we thinking seriously about i= t? Lee From nobody Mon Aug 21 07:06:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BE4132A5C for ; Mon, 21 Aug 2017 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 cI2toOAC4Htf for ; Mon, 21 Aug 2017 07:06:28 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6C8132A52 for ; Mon, 21 Aug 2017 07:06:26 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 76so32907012ith.0 for ; Mon, 21 Aug 2017 07:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F0iIVEqaCHa4TCWpUrC+XOfeAHUxg8LMp4hm/loDYaU=; b=rYfVh18ZXwBw3LFzyFac0IywxuGG7iDA6jWyCu6nBbahMJOr33blUOh44O9TuXRVfb aNxIPBDEiFMfuQ9Rrzh3zgGscKKstRqHxigx++hKt3F6enOxkNr2/QHZ14dYWbqeqHBX WjLMOxFmIreJJExkiIbBC8w5bsOouRDkQYIh2oOp+CBEQTnfkBwCkjWOaJQaFw5JN5uA WRCKY9LOyw8//qVHJuTH23hOQdCShio7FgwO1phQjS6j7PJ71eiPSO1h3UuUkhEI8+uG jmkxtblH6AXealqpuha5w9da+AAWCAqtVUPl+qu8me5rhz/uRkMwiSynJeeyVckbE/ZR eQkQ== 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=F0iIVEqaCHa4TCWpUrC+XOfeAHUxg8LMp4hm/loDYaU=; b=Uw1wp8RxSAq0kDotXfui9EBPsNxQv2+r4R/ACaZ1VfaifJss4VF5L413B9t8nbcG1P w6aF/I+lBmQ4CcHNT623tKMCvNMEJKz4LLroYAxVcLOZXTRsQkWUudwHHmxum34rB/3v DI9+t+gRkDSHmBtRIXPjCUZK9l37NwQHZfeAA0Oh2+rfcysopl5hPAYpQ4N2pUc2oxWQ maZADkARIlWCM+zDEz6Cgg8yL4lf4VPT/e4a7CxxothJOcjeMS9mbBqBYupF9TdnLueB LEYw2dam5RPwaLStq1GIW63gmfQEiwpC5gtKqT2ZYlJPo2msfYk4ZnW5vkzLy8DsEzSj EKwA== X-Gm-Message-State: AHYfb5hNYdAfGN14PdYeOa9avseFXFyrrNIFKRRTTiCKyH7kiG9o2fGY daQtke9hl+YdGwrY7rTr/NNEg+F73qcC X-Received: by 10.36.203.132 with SMTP id u126mr6954306itg.133.1503324385021; Mon, 21 Aug 2017 07:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Mon, 21 Aug 2017 07:06:24 -0700 (PDT) Received: by 10.107.27.203 with HTTP; Mon, 21 Aug 2017 07:06:24 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <96F993A7-09BE-4A15-8057-0CAC99E374E0@nokia.com> From: Lorenzo Colitti Date: Mon, 21 Aug 2017 23:06:24 +0900 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Suresh Krishnan , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops@ietf.org WG" , The IESG Content-Type: multipart/alternative; boundary="94eb2c0b09c4f41ebd055743fb16" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:06:30 -0000 --94eb2c0b09c4f41ebd055743fb16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 21 Aug 2017 22:16, "Van De Velde, Gunter (Nokia - BE/Antwerp)" < gunter.van_de_velde@nokia.com> wrote: RFC7772 indicates that for laptops etc it does not really matter regarding battery power, but that for energy conservative devices currently a 7 RA=E2= =80=99s per hour (assuming those consume 0.1mW). Right, there is a conflict - a max RA interval of 300s is a min interval of 100s and an average interval of 200s. That's 18 RAs per hour. 7772 recommends about 7. --94eb2c0b09c4f41ebd055743fb16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On 21 Aug 2017 22:16, "Van De Velde, Gunter (Nokia - BE/Antw= erp)" <gunter.van_= de_velde@nokia.com> wrote:

    RFC7772 indicates that for laptops etc it does not really matter regarding= battery power, but that for energy conservative devices currently a 7 RA= =E2=80=99s per hour (assuming those consume 0.1mW).

    <= /div>
    Right, there is a conflict - a max RA interval of 30= 0s is a min interval of 100s and an average interval of 200s. That's 18= RAs per hour. 7772 recommends about 7.
    --94eb2c0b09c4f41ebd055743fb16-- From nobody Mon Aug 21 07:29:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7851321F1; Mon, 21 Aug 2017 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 A012To0gygKp; Mon, 21 Aug 2017 07:28:53 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0104.outbound.protection.outlook.com [104.47.0.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E4D13202D; Mon, 21 Aug 2017 07:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N9SvguVX4II06GnapC5ykzryq95FWC33mtkT6IDoPkQ=; b=EZQazVXvI4P6AuyPQ0NreU2zEjctE8djZyH744sNsqG6KfFlUSih5WQqU1tJZKwwR3B8xbg/+cIOfFKX9mtypSXU/JDMAbE3hT8l9f4sbv23gYDZegq82YLW78Mz512gdCwuXzOsYIwG9sYh7hd5y//xLQz0tEmbzVqINmShydc= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1667.eurprd07.prod.outlook.com (10.166.133.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 14:28:49 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07%14]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 14:28:49 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Ben Campbell , The IESG CC: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Ron Bonica , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) Thread-Index: AQHTGonOrrx+vGn0WU2/SnPvj62Bww== Date: Mon, 21 Aug 2017 14:28:49 +0000 Message-ID: <9D6F471C-120A-425D-8D55-889242CF7BC9@nokia.com> References: <150292010454.15048.16601305330115893059.idtracker@ietfa.amsl.com> In-Reply-To: <150292010454.15048.16601305330115893059.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.121.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1667; 6:ZzZulR5DFa/Louuyj6DNHzANDWnRRkigpmqWNhS9KRKjizQArgWkfQTixfXI21ChGZjPd2TcldOIIfnj/BVRB0eSxoIuGpXiqNnJyQASF+H9DA+nPAX6HKQv7vq4sjV96uO7+FWsIMplUEgvK5lkJby05PCF/dMcqgslV4Hchqah4zdI7BtHrW45L+7HKywzWXneqfX2Hj+NnvQLYexyUYTrhsRJU3QLie66wGl0QRkMgTsi7H15Sv+b3TNag+TXk0C8PquwIXLsxUm3iKdeAZ+3kJLnU/a/pgUnjHD4gWa3CapmTu8KGFHAMgQGV2jBAhaZlLtkU/E5s0GyCpBZew==; 5:pTZt9IBWMQ0XdRiSwIQzH8QWcigS9mwAK+kep5TClq5N5RMLiB6VnavjJm++xfXYcbChsZgdX0eCQ3hN2R/yVdKZ3gAOWc4mjwpNZHthxJVcNimQS6A3+0GEke8a4ULIJzsSxATmRAOII0ebg94i3g==; 24:rylZmbP4Gd0z1BvMLjZAL7FCiEMcmp/hsxOcqKn1lmXH+E81g3MS1K1677TjBTJDujD2oHqWXZjDrUrDQ3qwwFTe21LtjqqWucwgyqYeRtE=; 7:h3pvfRuUbqiq9baZloy1tpVFSIHTpcagStZeB4khuh6ZgUc2lnTf62k1+tthmdY6K3t/6VYCYSxQblgGaEiOjDuVeFbeC85z29OP7XAwVHK/MNXREcynf2rGv934L3ctugpeHQINLSnNUhd9cv2agVgJ3quVADZg5W1FKyKgls8qYxxdhd3/ms90vNj5oidmf18DZB4xP7wJbcXad2W/SmOUa8kavKPV6kMqvr3naNA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d996eab-de05-4457-b267-08d4e8a0f0b2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB1667; x-ms-traffictypediagnostic: AM4PR07MB1667: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1667; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1667; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(16064003)(24454002)(189002)(199003)(51914003)(8676002)(6306002)(6512007)(66066001)(7736002)(99286003)(81166006)(81156014)(83716003)(305945005)(4326008)(54906002)(2950100002)(6116002)(6436002)(229853002)(14454004)(6486002)(3846002)(102836003)(3660700001)(53936002)(86362001)(53546010)(3280700002)(189998001)(478600001)(5250100002)(8936002)(82746002)(76176999)(25786009)(33656002)(68736007)(6506006)(230783001)(106356001)(966005)(6246003)(50986999)(54356999)(105586002)(5660300001)(36756003)(101416001)(8666007)(2906002)(97736004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1667; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4154C2B1C980F14180959EB42ACED57D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 14:28:49.6268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1667 Archived-At: Subject: Re: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:28:56 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIExvb2sgZm9yIEdWPg0KDQpPbiAxNi8w OC8yMDE3LCAyMzo0OCwgIkJlbiBDYW1wYmVsbCIgPGJlbkBub3N0cnVtLmNvbT4gd3JvdGU6DQoN CiAgICBCZW4gQ2FtcGJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQogICAgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qt MDc6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAgIGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgDQogICAgDQog ICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgDQogICAgDQogICAgVGhlIGRvY3Vt ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJl Og0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Lw0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICBJIGhh dmUgbm8gdGVjaG5pY2FsIGNvbW1lbnRzLCBidXQgYSBudW1iZXIgb2YgZWRpdG9yaWFsIGNvbW1l bnRzOg0KICAgIA0KICAgIC0gR2VuZXJhbDogSSB0aGluayB0aGlzIGNvdWxkIHVzZSBhbm90aGVy IHByb29mcmVhZGluZyBhbmQvb3IgZWRpdGluZyBwYXNzIGZvcg0KICAgIHRoZSBmb2xsb3dpbmcg aXNzdWVzOiAtLSBJbmNvbnNpc3RlbnQgdGVuc2UtLWVzcGVjaWFsbHkgdXNlIG9mIGZ1dHVyZSBv cg0KICAgIHByZXNlbnQgY29udGludW91cy4gLS0gV29yZHkgYW5kIGNvbnZvbHV0ZWQgc2VudGVu Y2VzIC0tIFVzZSBvZiAiLyIgYXMgYQ0KICAgIGNvbmp1bmN0aW9uLg0KDQpHVj4gSSBkZWNpZGVk IHRvIHN3YXAg4oCdVUUvc3Vic2NyaWJlcuKAnSB3aXRoIOKAnXN1YnNjcmliZXLigJ0gdGhyb3Vn aCB0aGUgZG9jdW1lbnQNCiAgICANCiAgICAtIEFic3RyYWN0Og0KICAgIFRoZSBhYnN0cmFjdCBp cyBsb25nZXIgYW5kIG1vcmUgZGV0YWlsZWQgdGhhbiBpcyB1c2VmdWwuIFRoZSBsYXN0IHBhcmFn cmFwaA0KICAgIGNvdWxkIGhhdmUgc3Rvb2QgYWxvbmUgYXMgdGhlIGFic3RyYWN0LiBJdCdzIG5v dCBjbGVhciB0byBtZSBpZiAiaG9zdHMNCiAgICAoc3Vic2NyaWJlcnMpIiBtZWFucyBzb21ldGhp bmcgZGlmZmVyZW50IHRoYW4gImhvc3RzIiBpbiBjb250ZXh0Lg0KICAgIA0KR1Y+IGFjay4gSSBy ZW1vdmVkIGZpcnN0IHR3byBwYXJhZ3JhcGhzLiBUaGUgYWJzdHJhY3Qgbm93IHNpbXBseSByZWFk czoNCg0KVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3Rp bmcgSVB2NiBwcm90b2NvbHMNCnRvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVl IElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGEgdW5pcXVlDQpJUHY2IGFkZHJlc3MgZnJvbSBhIHNo YXJlZCBJUHY2IHByZWZpeCkuIEJlbmVmaXRzIG9mIHVuaXF1ZSBJUHY2IHByZWZpeCANCm92ZXIg YSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXIgaW5jbHVkZSBp bXByb3ZlZCANCmhvc3QgaXNvbGF0aW9uIGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyIG1hbmFnZW1l bnQuPC90Pg0KDQoNCiAgICAtMToNCiAgICBQbGVhc2UgZXhwYW5kICJJQV9OQSIgb24gZmlyc3Qg dXNlLg0KR1Y+IERIQ1AgSUFfTkEgKElkZW50aXR5IEFzc29jaWF0aW9uIC0gTm9uLXRlbXBvcmFy eSBBZGRyZXNzKQ0KDQogICAgcy8iVGhpcyBkb2N1bWVudCB3aWxsIGZvY3VzLi4uIi8iVGhpcyBk b2N1bWVudCBmb2N1c2VzLi4uIg0KR1YuIEFjaw0KICAgIA0KICAgICJBcyBzdWNoIHRoZSB1c2UN CiAgICAgICBvZiBJUHY2IFNMQUFDIGJhc2VkIHN1YnNjcmliZXIgYW5kIGFkZHJlc3MgbWFuYWdl bWVudCBmb3IgcHJvdmlkZXINCiAgICAgICBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNlcnZpY2Vz IGlzIHRoZSByZWNvbW1lbmRlZCB0ZWNobm9sb2d5IG9mDQogICAgICAgY2hvaWNlLCBhcyBpdCBk b2VzIG5vdCBleGNsdWRlIGFueSBrbm93biBJUHY2IGltcGxlbWVudGF0aW9uLiINCiAgICBEb2Vz IHRoaXMgZG9jdW1lbnQgbWFrZSB0aGF0IHJlY29tbWVuZGF0aW9uLCBvciBpcyB0aGF0IHNvbWUg cHJlLWV4aXN0aW5nDQogICAgcmVjb21tZW5kYXRpb24/DQogICAgDQpHVj4gcmVwaHJhc2VkOg0K VG8gbm90IGV4Y2x1ZGUgYW55IGtub3duIElQdjYgaW1wbGVtZW50YXRpb25zLCBJUHY2IFNMQUFD IGJhc2VkIHN1YnNjcmliZXIgYW5kIGFkZHJlc3MgDQptYW5hZ2VtZW50IGlzIHRoZSByZWNvbW1l bmRlZCB0ZWNobm9sb2d5IHRvIHJlYWNoIGhpZ2hlc3QgcGVyY2VudGFnZSANCm9mIGNvbm5lY3Rl ZCBJUHY2IGRldmljZXMgb24gYSBwcm92aWRlciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNlcnZp Y2UuDQoNCg0KDQogICAgLTM6ICJUaGUgQmVzdCBDdXJyZW50IFByYWN0aWNlIGRvY3VtZW50ZWQg aW4gdGhpcyBub3RlIGlzIHRvIHByb3ZpZGUgYQ0KICAgICAgIHVuaXF1ZSBJUHY2IHByZWZpeCB0 byBob3N0cy9zdWJzY3JpYmVycyBkZXZpY2VzIGNvbm5lY3RlZCB0byB0aGUNCiAgICAgICBwcm92 aWRlciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrLiINCiAgICANCiAgICBUaGUgc2VudGVuY2UgaGFy ZCB0byBmb2xsb3cuIENvbnNpZGVyICJUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMuLi4iLiAgSSdt IG5vdA0KICAgIHN1cmUgaG93IHRvIGludGVycHJldCAiaG9zdHMvc3Vic2NyaWJlcnMgZGV2aWNl cyINCiAgICANCkdWPiByZXBocmFzZWQgdG86DQrigJxUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMg cHJvdmlkaW5nIGEgdW5pcXVlIElQdjYgcHJlZml4IHRvIGRldmljZXMgY29ubmVjdGVkIHRvIHRo ZSBtYW5hZ2VkIHNoYXJlZA0KICAgICAgbmV0d29yay7igJ0NCg0KICAgICJFYWNoIHVuaXF1ZSBJ UHY2IHByZWZpeCBjYW4NCiAgICAgICBmdW5jdGlvbiBhcyBjb250cm9sLXBsYW5lIGFuY2hvciBw b2ludCB0byBtYWtlIHN1cmUgdGhhdCBlYWNoDQogICAgICAgc3Vic2NyaWJlciBpcyByZWNlaXZp bmciDQogICAgcy8iLi4uIHN1YnNjcmliZXIgaXMgcmVjZWl2aW5nIC4uLiIvIi4uLiBzdWJzY3Jp YmVyIHJlY2VpdmVzLi4uIg0KICAgIA0KR1Y+IGFjaywgbW9kaWZpZWQNCg0KICAgIC00OiBJcyAi Rmlyc3QgSG9wIFByb3ZpZGVyIFJvdXRlciIgZGlmZmVyZW50IHRoYW4gIkZpcnN0IEhvcCBSb3V0 ZXIiPw0KR1Y+IEluZGVlZC4gSSBtb2RpZmllZCB0aGUgdGV4dCBhY2NvcmRpbmdseS4NCg0KICAg IEluIHRoZSBsYXN0IGJ1bGxldCAoTC1mbGFnPTApLCBhcmUgTkVWRVIgYW5kIEFMV0FZUyBpbiBh bGwtY2FwcyBleHBlY3RlZCB0bw0KICAgIGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgdGhhbiBpZiB0 aGV5IGhhZCBub3JtYWwgY2FwaXRhbGl6YXRpb24/DQoNCkdWPiBJIG1vZGlmaWVkIGFjY29yZGlu Z2x5IHRvIGxvd2VyIGNhcHMNCiAgICANCiAgICBUaGUgc2VudGVuY2Ugc3RhcnRpbmcgd2l0aCAi VGhlIGFyY2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBIGFzDQogICAgZG9jdW1l bnRlZCBhYm92ZS4uLiIgaXMgY29udm9sdXRlZCBhbmQgaGFyZCB0byBmb2xsb3cuDQoNCkdWPiBy ZS1lZGl0ZWQgdG8gYmUgbW9yZSByZWFkYWJsZToNCiAgICAgIFRoZSBhcmNoaXRlY3RlZCByZXN1 bHQgb2YgZGVzaWduaW5nIHRoZSBSQSBhcyBkb2N1bWVudGVkIGFib3ZlIGlzDQogICAgICB0aGF0 IGVhY2ggc3Vic2NyaWJlciBnZXRzIGl0cyBvd24gdW5pcXVlIElQdjYgcHJlZml4LiBFYWNoIGhv c3QgY2FuIGNvbnNlcXVlbnRseSANCiAgICAgIHVzZSBTTEFBQyBvciBhbnkgb3RoZXIgbWV0aG9k IG9mIGNob2ljZSB0byBzZWxlY3QgaXRzIC8xMjggdW5pcXVlIGFkZHJlc3MNCiANCg0KICAgDQog ICAgIi4uLiBob3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byByZWNl aXZlDQogICAgICAgYSBzZXJ2aWNlIHByb3ZpZGVyIG1hbmFnZWQgSVB2NiBhZGRyZXNzIjogSXMg dGhhdCByZWFsbHkgYSBub3JtYXRpdmUNCiAgICAgICByZXF1aXJlbWVudCwgb3IgaXMgaXQgYSBz dGF0ZW1lbnQgb2YgZmFjdCBhYm91dCBleGlzdGluZyByZXF1aXJlbWVudHM/DQoNCkdWPiBUaGlz IHRleHQgaGFzIGJlZW4gbW9kaWZpZWQgYmFzZWQgdXBvbiBhbm90aGVyIGNvbW1lbnQNCg0KICAg IA0KICAgICJpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMNCiAgICAgICB0byB0aGUgRmlyc3Qg SG9wIFByb3ZpZGVyIFJvdXRlci4iIDogc3RhdGVtZW50IG9mIGZhY3Q/DQpHVj4gaXQgSXMgd2hh dCBzaG91bGQgaGFwcGVuIGlmIElQdjYgc3RhY2sgYmVoYXZlIGFzIHByZS1zY3JpYmVkDQoNCg0K ICAgIC0gNTogIlRvIHJlZHVjZQ0KICAgICAgIHVuZGVzaXJlZCByZXNvdXJjZSBjb25zdW1wdGlv biBvbiB0aGUgRmlyc3QgSG9wIFJvdXRlciB0aGUgZGVzaXJlIGlzDQogICAgICAgdG8gcmVtb3Zl IFVFL3N1YnNjcmliZXIgY29udGV4dCBpbiB0aGUgY2FzZSBvZiBub24tcGVybWFuZW50IFVFLCBz dWNoDQogICAgICAgYXMgaW4gdGhlIGNhc2Ugb2YgV2lGaSBob3RzcG90cyBhcyBxdWlja2x5IGFz IHBvc3NpYmxlLiAiDQogICAgQ29udm9sdXRlZCBzZW50ZW5jZS4NCiAgICANCiAgICAiQSBwb3Nz aWJsZSBzb2x1dGlvbiBpcyB0byB1c2UgYSBzdWJzY3JpYmVyIGluYWN0aXZpdHkgdGltZXIgd2hp Y2gsIGFmdGVyDQogICAgICAgdHJhY2tpbmcgYSBwcmUtZGVmaW5lZCAoY3VycmVudGx5IHVuc3Bl Y2lmaWVkKSBudW1iZXIgb2YgbWludXRlcywNCiAgICAgICBkZWxldGVzIHRoZSBzdWJzY3JpYmVy IGNvbnRleHQgb24gdGhlIEZpcnN0IEhvcCBSb3V0ZXIuIg0KICAgIA0KICAgIHMvd2hpY2gvdGhh dCAgIChDb25zaWRlciAiIC4uLiB0aW1lciB0aGF0IGRlbGV0ZXMuLi5hZnRlciBhIHByZWRldGVy bWluZWQNCiAgICBudW1iZXIgb2YgbWludXRlcyINCiAgICANCkdWPiBUZXh0IHJlLWVkaXRlZDoN CiAgICAgIFRoZSBzdGF0ZWxlc3MgbmF0dXJlIG9mIHRoZSBzdWJzY3JpYmVyIElQdjYgU0xBQUMg Y29ubmVjdGl2aXR5DQogICAgICBtb2RlbCBpbnRyb2R1Y2VzIG5vbi1vcHRpbWFsIHJlc291cmNl IGNvbnN1bXB0aW9uIChpLmUuIG1lbW9yeSwgDQogICAgICBuZWlnaGJvciBzdGF0ZSkgb24gdGhl IEZpcnN0IEhvcCBSb3V0ZXIuIFRvIHJlZHVjZSB1bmRlc2lyZWQgcmVzb3VyY2UgDQogICAgICBj b25zdW1wdGlvbiwgc3VjaCBhcyBpbiB0aGUgY2FzZSBvZiBXaUZpIGhvdHNwb3RzLCBpcyB0byBy ZW1vdmUgc3Vic2NyaWJlciANCiAgICAgIGNvbnRleHQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSB3 aGVuIGEgZGV2aWNlIG9yIHN1YnNjcmliZXIgYmVjb21lcyBub24tYWN0aXZlLiANCiAgICAgIEEg cG9zc2libGUgc29sdXRpb24gaXMgdG8gdXNlIGEgc3Vic2NyaWJlciBvciBkZXZpY2UgaW5hY3Rp dml0eSB0aW1lciwNCiAgICAgIHRoYXQgYWZ0ZXIgdHJhY2tpbmcgYSBwcmUtZGVmaW5lZCAoY3Vy cmVudGx5IHVuc3BlY2lmaWVkKSBudW1iZXIgb2YgbWludXRlcywNCiAgICAgIGRlbGV0ZXMgdGhl IHN1YnNjcmliZXIgY29udGV4dCBvbiB0aGUgRmlyc3QgSG9wIFJvdXRlci4NCg0KICAgIC03OiAi VGhlDQogICAgICAgY29tYmluYXRpb24gb2YgYm90aCBJUHY2IHByaXZhY3kgZXh0ZW5zaW9ucyBh bmQgb3BlcmF0b3IgYmFzZWQNCiAgICAgICBhc3NpZ25tZW50IG9mIGEgVW5pcXVlIElQdjYgUHJl Zml4IHBlciBIb3N0IHByb3ZpZGVzIGVhY2gNCiAgICAgICBpbXBsZW1lbnRpbmcgb3BlcmF0b3Ig YSB0b29sIHRvIG1hbmFnZSBhbmQgcHJvdmlkZSBzdWJzY3JpYmVyDQogICAgICAgc2VydmljZXMg YW5kIGhlbmNlIHJlZHVjZXMgdGhlIGV4cGVyaWVuY2VkIHByaXZhY3kgd2l0aGluIGVhY2gNCiAg ICAgICBvcGVyYXRvciBjb250cm9sbGVkIGRvbWFpbi4iDQogICAgDQogICAgSSBoYXZlIHRyb3Vi bGUgZm9sbG93aW5nIHRoYXQgc2VudGVuY2UuIElzIHRoZSBwb2ludCB0byBzYXkgdGhhdCBwcm92 aWRpbmcNCiAgICB0b29scyB0byBtYW5hZ2UgYW5kIHByb3ZpZGUgc2VydmljZXMgcmVkdWNlcyBw cml2YWN5IGluIGdlbmVyYWw/IEFzIHdvcmRlZCwgaXQNCiAgICBhbG1vc3Qgc291bmRzIGxpa2Ug dGhpcyBpcyBtZWFudCBhcyBhIGZlYXR1cmUsIHdoaWNoIEkgYXNzdW1lIGlzIG5vdCB0aGUgY2Fz ZS4NCiAgICANCkdWPiByZS1lZGl0ZWQgdGhlIHRleHQ6DQoJICBUaGUgbWVjaGFuaWNzIG9mIElQ djYgcHJpdmFjeSBleHRlbnNpb25zIDx4cmVmIHRhcmdldD0iUkZDNDk0MSI+UkZDNDk0MTwveHJl Zj4gDQoJICBpcyBjb21wYXRpYmxlIHdpdGggYXNzaWdubWVudCBvZiBhIHVuaXF1ZSBJUHY2IFBy ZWZpeCBwZXIgSG9zdC4NCgkgIEhvd2V2ZXIsIHdoZW4gY29tYmluaW5nIGJvdGggSVB2NiBwcml2 YWN5IGV4dGVuc2lvbnMgYW5kIGEgdW5pcXVlIElQdjYgUHJlZml4IHBlciBIb3N0IA0KCSAgYSBy ZWR1Y2VkIHByaXZhY3kgZXhwZXJpZW5jZSBmb3IgdGhlIHN1YnNjcmliZXIgaXMgaW50cm9kdWNl ZCwgYmVjYXVzZSBhIA0KCSAgcHJlZml4IG1heSBiZSBhc3NvY2lhdGVkIHdpdGggYSBzdWJzY3Jp YmVyLCBldmVuIHdoZW4gdGhlIHN1YnNjcmliZXIgDQoJICBpbXBsZW1lbnRlZCBJUHY2IHByaXZh Y3kgZXh0ZW5zaW9ucyA8eHJlZiB0YXJnZXQ9IlJGQzQ5NDEiPlJGQzQ5NDE8L3hyZWY+Lg0KICAg ICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Aug 21 07:34:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC13132113; Mon, 21 Aug 2017 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 1_uBb6_A1W2g; Mon, 21 Aug 2017 07:34:09 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00096.outbound.protection.outlook.com [40.107.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B441320BD; Mon, 21 Aug 2017 07:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=79nlPtGoy3snuX4q9JsvUpPGBRCFHtCJaA+xC35+BMA=; b=jopHdkN0CUbtk6V+uOZTr/g394QzxWkDQ7tAA3R6pNyFywlICPidAys/1Fi9UDVcJrHq5TyJuhRM/cwnFa8yxwzlAAgbqtwwbnTMlz032qV/YzfK+nevXA9n/37Ngq/SRH9t6Ey7YB8kZAR3ic4dRARdQGROYkE5j/18b5uMAgU= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB3329.eurprd07.prod.outlook.com (10.171.189.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 14:34:05 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::dfc:8ef3:9884:fe07%14]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 14:34:05 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Spencer Dawkins , The IESG CC: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Ron Bonica , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) Thread-Index: AQHTGoqK4Pyn7AeyqkiKOtbon7FoqA== Date: Mon, 21 Aug 2017 14:34:05 +0000 Message-ID: References: <150281697383.21119.5857202226751657961.idtracker@ietfa.amsl.com> In-Reply-To: <150281697383.21119.5857202226751657961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [135.245.121.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3329; 6:59txBYx2ZN1C+n7NaNzsy3TRAN7oDcTsgdbne/Rvh9OL4rfoKXzh/dRDnp77L5yxfwgFwkoNFjuqKgb2dzjkKBgUBt+cBgVBeTxTz4kOrnE6WGkpGevuCtfxryd4+P6IVRirJWqlPO0MJ90rco20sFQzF7dsmGfQOcM96hlhRhBy2+YYfj8AfcYch25mqYsbQC9Cd36cWcjk3YmWo4jDU98Yl1X9GZoDjFgd+qY/TmU8288LCt50RIbfwdozUQxpfz/1Yih7Z0wAbCdTA7NmEEbMU1Gl2iQy3qLlFagJD64T3MX4VLX+/4FmZKKZarp3PoFo2z9ONRtSO5rutJdAAA==; 5:SFg5Sft5WFyGEO21IHej5UreqygzEBl2knNqfQQYBr26Qu78m/I1mTHb/rGtrc/RXvcRO/NFjkqlzv+9cNesZzElDLHlujjkapTZZKy+6O1G9JzXot3uUYZ1rS09uPdsgJ7nFuWfdYCjnUeWb5yUog==; 24:goFslzwJwQfZhjYdGNGb5Vwbm64R1VXwtVYwwTHwXDUG5DALM/OCMgzYfJRDLTS2aYced5xYC28ppr2Rj760PaY2PrB/X5yVU0DTV2MX6Nc=; 7:s9sBP9YhOJAwNCf+xjcDkmIcAAYoUBZXWB1RyxP64Pk5lAZd2JPq5F+Udn4WQDfgAzkkfOCGYlhomVR5Nk9TbakJ3lk8CSltLcPkn7iBxoZJYh1hCoS5MjX5e+5zeekHypQDx9sPuVElJ1BHa/a8LwarAZ2xkZ3IVit2jmaVqlk1E/hsWy4gfdKQdlvq+pC+TfasVvrHGRo9jiV9vv0Elh8paue7braidHg0bYFvSY4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4a724899-2a4b-4d6f-fcd7-08d4e8a1ad1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB3329; x-ms-traffictypediagnostic: AM4PR07MB3329: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3329; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3329; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(51914003)(199003)(24454002)(189002)(189998001)(5660300001)(5250100002)(97736004)(2900100001)(82746002)(86362001)(83716003)(2906002)(53546010)(478600001)(3280700002)(3660700001)(6436002)(68736007)(76176999)(7736002)(50986999)(54356999)(966005)(6506006)(230783001)(305945005)(39060400002)(53936002)(6512007)(6306002)(54906002)(101416001)(33656002)(66066001)(36756003)(6246003)(4326008)(229853002)(6486002)(99286003)(3846002)(105586002)(8936002)(2950100002)(106356001)(8666007)(102836003)(6116002)(14454004)(8676002)(25786009)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3329; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 14:34:05.7012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3329 Archived-At: Subject: Re: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:34:16 -0000 VGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbi4gDQpUaGUgYWJzdHJhY3QgaGFzIGJlZW4gbW9kaWZp ZWQgYmFzZWQgdXBvbiBJRVNHIGZlZWRiYWNrLg0KDQpBcyByZXN1bHQgb25seSB0aGUgbGFzdCBw YXJhZ3JhcGggcmVtYWlucyBmcm9tIHRoZSBvcmlnaW5hbCB0ZXh0LiBJdCByZWFkcyBlYXNpZXIg YW5kIGlzIGJldHRlciB0byB0aGUgcG9pbnQgZm9yIGFuIGFic3RyYWN0Lg0KDQpBbGwgdGhlIGJl c3QsDQpHLw0KDQpPbiAxNS8wOC8yMDE3LCAxOTowOSwgIlNwZW5jZXIgRGF3a2lucyIgPHNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIFNwZW5jZXIgRGF3a2lucyBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1p ZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNzogTm8gT2JqZWN0aW9uDQog ICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICANCiAgICANCiAgICBQbGVhc2UgcmVmZXIgdG8g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1s DQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt cGVyLWhvc3QvDQogICAgDQogICAgDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1F TlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIE9uZSBuaXQ6DQogICAgDQogICAgUGxl YXNlIGNvbnNpZGVyIG1vdmluZw0KICAgIA0KICAgICAgIEJlbmVmaXRzIG9mIHVuaXF1ZQ0KICAg ICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZp Y2UgcHJvdmlkZXINCiAgICAgICBpbmNsdWRlIGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9u IGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyDQogICAgICAgbWFuYWdlbWVudC4NCiAgICANCiAgICB0 byB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBBYnN0cmFjdC4gSeKAmW0gYXNzdW1pbmcgdGhh dCB0aGlzIGV4cGxhaW5zIHRoZQ0KICAgIOKAnG5lZWRzIHRoYXQgaGF2ZSBhcmlzZW7igJ0gaW4g dGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSBBYnN0cmFjdCwgb2YgY291cnNlLg0KICAgIA0KICAg IA0KICAgIA0KDQo= From nobody Mon Aug 21 11:08:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29F61326BB for ; Mon, 21 Aug 2017 11:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.6 X-Spam-Level: ** X-Spam-Status: No, score=2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdNWsOYDBrCh for ; Mon, 21 Aug 2017 11:08:51 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA25132403 for ; Mon, 21 Aug 2017 11:08:50 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u139so86334075qka.1 for ; Mon, 21 Aug 2017 11:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c1FMDVE2n2stsO30F7kTt4JMuymNp02ygXuQ+rJsYKc=; b=NGqIVkuJCMEg4Gn/+ddZnmIktS5ZHFLIQv2LA+tMhe75mxwxA0rxATs6sVXJztp26e YwP532ewl+B1itVIE0uxY/q4XD+g4kVpdqWDc/aRs1OoWNq+GqdzW7VQbqnFB2Fo3Z9h 5IkrMDzhVh99qED3ctpbFXAhoqautkFII+vERdgKurtm8K/iDBpgdxQlF+WfR9EA3WSg YFgtrCRMXr0VUkLgILngtxPRrOD3LinOfDoj6wSamMg7QT11z83TnppaTri/Q0di6QMr 4mLagMFAjcNKpw1zvcJBe+e3hMtrTHqYhamtl5yabfYTi+QQjV3rX8AVz7svJxR+2uuw UN7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c1FMDVE2n2stsO30F7kTt4JMuymNp02ygXuQ+rJsYKc=; b=P6M64BnmRFDL3Qb8X4V0BwBu1m95KdP4HNY1H1rcHeRoYUAATQTWNBXX7MlCr7vymg s1cE5pIkJeZ5gqVOmy540iW0GSKxO8u8L7yy0hONGNvDwpC+FbGrGFEgeABw0qWhTLru iTZdm/f/ef2uYu44/mYgoQm15tAr9NmxXKhpQIaymtD1zd5AZUiW/9j0jl0uUgpfgsej 3orZL5rks6WFdnvN3cb8V+1NvcBPOIC1WABInuPfz1kZNQ6ToSA+xrZOv8S5zFUK1HRR yjkltNabG7ttDQEFw67WtEY8Shbf0SQpGmfwKojYzqs6fh8g9wdU5UWvyn3Iru8Omw6d gtqg== X-Gm-Message-State: AHYfb5jNsqXXKtBS8hzGR0rx9ktVD33KQEaIjTsjXodB0X2jpXErRmFa HDo+Kkj0ByiwWhH5ovkorLoRjlnaZQ== X-Received: by 10.55.168.145 with SMTP id r139mr19511105qke.258.1503338929483; Mon, 21 Aug 2017 11:08:49 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.52.103 with HTTP; Mon, 21 Aug 2017 11:08:48 -0700 (PDT) In-Reply-To: <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> References: <20170810055819.GQ45648@Space.Net> <51268C23-40F4-4476-9025-A1DD3BA37BC3@thehobsons.co.uk> <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 21 Aug 2017 11:08:48 -0700 X-Google-Sender-Auth: RTUEU2-9QfD9AqEvkPDr29CmKqI Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:08:53 -0000 At Fri, 18 Aug 2017 21:46:18 +0200, Alexandre Petrescu wrote: > Here, still it makes sense to allow for prefixes shorter than 64 (i.e. > unique /63 prefix per Host, such that it can further grow the network by > becoming a Router). > > The draft says: > > a Unique IPv6 prefix (currently a /64 prefix) and some flags. > > That "currently a /64" sounds as a hardcoded value. > > It should be something like: "a variable length whose value could be /56 > for example; it could also be /64". Today you can't use a prefix for SLAAC unless its length is 64 due to the facts that - All today's defined IIDs have 64 bits in length - Hosts reject the prefix unless the sum of the prefix's length and the IID length equals to 128 (which means the prefix length must be 64) according to RFC4862 You may not like it or might want to say "it doesn't have to be that way"), but that's the fact today. As long as draft-ietf-v6ops-unique-ipv6-prefix-per-host talks about today's practice, I don't think anything that doesn't work today is in the scope of this document. We may or may not choose to include the specific number of 64 in the doc, on which I don't have a strong opinion. But ""a variable length whose value could be /56 for example" is very misleading since /56 for SLAAC doesn't work today (perhaps "could" tries to express the subtle nuance, but that would be quite misleading). -- JINMEI, Tatuya From nobody Mon Aug 21 18:05:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F20A132742 for ; Mon, 21 Aug 2017 18:05:41 -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, 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 8mSosNNKcTAr for ; Mon, 21 Aug 2017 18:05:39 -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 AAF46132AE5 for ; Mon, 21 Aug 2017 18:05:39 -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 E636534B5DB; Tue, 22 Aug 2017 01:05:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B334A160051; Tue, 22 Aug 2017 01:05:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7D526160053; Tue, 22 Aug 2017 01:05:36 +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 kVMCBtU1J2hq; Tue, 22 Aug 2017 01:05:36 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 31416160051; Tue, 22 Aug 2017 01:05:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CC31E82DBEBF; Tue, 22 Aug 2017 11:05:33 +1000 (AEST) To: David Schinazi Cc: "v6ops@ietf.org" From: Mark Andrews References: <4058EE05-9C9D-47BC-BA37-742FD222F6BA@apple.com> <5542934D-6ED9-47C2-A406-360C41433BD6@gmail.com> <24F280B5-4AEF-4FC8-976B-68FEEB015F59@apple.com> In-reply-to: Your message of "Fri, 18 Aug 2017 13:58:49 -0700." <24F280B5-4AEF-4FC8-976B-68FEEB015F59@apple.com> Date: Tue, 22 Aug 2017 11:05:33 +1000 Message-Id: <20170822010533.CC31E82DBEBF@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] WGLC for RFC6555bis - Asynchronous DNS Resolution X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 01:05:41 -0000 In message <24F280B5-4AEF-4FC8-976B-68FEEB015F59@apple.com>, David Schinazi writes: > Thanks everyone for the feedback provided during WGLC. The authors accept > the group's consensus that asynchronous DNS should be a SHOULD rather > than a MUST, and we have updated the document accordingly. Starting with > version -04, the "Hostname Resolution Query Handling" section does not > contain any MUSTs. We have also made editorial changes, clarifications, > and addressed other comments received in the past few weeks. > > The latest version can be found here: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-04 > > To everyone who send feedback during WGLC, please let us know whether > version -04 addresses your comments. I still think the 50ms wait is too simplistic and fails to account for DNS cache misses. HE should result is IPv6 being used most of the time even if the zone administrator has a zero TTL set on the AAAA RRset and a non zero TTL on the A RRset. It is possible to achieve this but not how the document is currently written. It requires waiting enough time for a cache refresh attempt to complete. This time starts when the AAAA lookup is made and is enough time for a single query to be answered from the other side of the planet O(250ms). Both this time and the 50ms wait from the A lookup succeeding must complete before the IPv4 connect attempt starts if there is no response to the AAAA lookup. At the moment we have a tail wagging the dog senario where host operators are going to have to keep AAAA RRsets TTL with similar or larger than A RRset TTLs to avoid hosts using HE2 using IPv4 as the primary transport. > Thanks, > David Schinazi -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Aug 22 02:28:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03971132076 for ; Tue, 22 Aug 2017 02:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G6yW2L5H02o7 for ; Tue, 22 Aug 2017 02:28:39 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3131321B6 for ; Tue, 22 Aug 2017 02:28:39 -0700 (PDT) Received: from [IPv6:2a02:2168:2b44:b400:81bc:8972:3b06:37a3] (unknown [IPv6:2a02:2168:2b44:b400:81bc:8972:3b06:37a3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B70A682BF5; Tue, 22 Aug 2017 11:30:07 +0200 (CEST) To: Tim Chown , Lorenzo Colitti Cc: Simon Hobson , v6ops list References: From: Fernando Gont Message-ID: <989e7a6f-ca77-f024-fc21-5641c9c4db4c@si6networks.com> Date: Tue, 22 Aug 2017 11:25:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 09:28:42 -0000 On 08/17/2017 12:12 PM, Tim Chown wrote: >> On 17 Aug 2017, at 04:01, Lorenzo Colitti wrote: >> >> On Thu, Aug 17, 2017 at 11:51 AM, Mark Smith wrote: >> "If IPv6 IIDs were reduced to something like 32 bits, would any of the >> above be impacted: >> >> - Available and Reliable: No. May have a positive influence, as >> availability and reliability possibly could be increased, as ND cache >> resource exhaustion attacks effectiveness would be reduced. >> >> Actually the answer here is also "yes, negatively". It means that networks with large numbers of users would become unreliable because of IID collisions. There are networks that run 10k or 20k nodes on a single subnet. Large corporate networks are an example, or large conferences such as MWC. > > Is there info anywhere on what the common OSes do when they encounter a DAD failure - do they give up or try a new tentative address? For legaxy (pre RFC7217) they give up -- after all, you wouldn't know how to form a new IID if you have to base it on the undelying link layer address. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 22 07:15:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EA913243A for ; Tue, 22 Aug 2017 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_SUMOF=5, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGgApRNljlUR for ; Tue, 22 Aug 2017 07:15:41 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B371E1200F3 for ; Tue, 22 Aug 2017 07:15:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v7MEFchu077097; Tue, 22 Aug 2017 16:15:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 210C220250F; Tue, 22 Aug 2017 16:15:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 134612024EB; Tue, 22 Aug 2017 16:15:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7MEFbnj029135; Tue, 22 Aug 2017 16:15:37 +0200 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: "v6ops@ietf.org" References: <7CB3B027-714C-4F18-8AD9-E76060137891@employees.org> <82CBE1F8-F9A5-463F-8DB1-B92E5A3F6582@gmail.com> <009d739f-f1e3-0212-c105-48f16768e0d0@gmail.com> <85D0C0DD-D09D-4DE9-A8A7-42C04071484B@gmail.com> <7c03f1c5-8930-6930-9f93-ddfb85c8e825@gmail.com> <85066e19-4dbc-f408-4a00-c5b6d7b73d20@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 22 Aug 2017 16:15:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 14:15:43 -0000 Le 21/08/2017 à 20:08, 神明達哉 a écrit : > At Fri, 18 Aug 2017 21:46:18 +0200, > Alexandre Petrescu wrote: > >> Here, still it makes sense to allow for prefixes shorter than 64 (i.e. >> unique /63 prefix per Host, such that it can further grow the network by >> becoming a Router). >> >> The draft says: >>> a Unique IPv6 prefix (currently a /64 prefix) and some flags. >> >> That "currently a /64" sounds as a hardcoded value. >> >> It should be something like: "a variable length whose value could be /56 >> for example; it could also be /64". > > Today you can't use a prefix for SLAAC unless its length is 64 due to > the facts that > - All today's defined IIDs have 64 bits in length > - Hosts reject the prefix unless the sum of the prefix's length and > the IID length equals to 128 (which means the prefix length must be > 64) according to RFC4862 > > You may not like it or might want to say "it doesn't have to be that > way"), but that's the fact today. As long as > draft-ietf-v6ops-unique-ipv6-prefix-per-host talks about today's > practice, I don't think anything that doesn't work today is in the > scope of this document. > > We may or may not choose to include the specific number of 64 in the > doc, on which I don't have a strong opinion. But ""a variable length > whose value could be /56 for example" is very misleading since /56 for > SLAAC doesn't work today (perhaps "could" tries to express the subtle > nuance, but that would be quite misleading). Because I agree with you, I will reformulate: Leaving 64 there comforts operators and equipment manufacturers in ==64 barriers preventing the network to grow at the edges. HTTP parallel: it would be unconceivable to write an I-D with 'currently' HTTP traffic is in clear, requesting the WG to make it a BCP. Rather suggest HTTPS be BCP. IPv4 parallel: write an "IPv4-prefix-per-Host" I-D, because 'currently'. Alex > > -- > JINMEI, Tatuya > From nobody Tue Aug 22 14:39:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168F132A7B; Tue, 22 Aug 2017 14:38:53 -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 ASAdQoWNHOQZ; Tue, 22 Aug 2017 14:38:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F67132A77; Tue, 22 Aug 2017 14:38:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 13BDCB80EA7; Tue, 22 Aug 2017 14:38:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Message-Id: <20170822213823.13BDCB80EA7@rfc-editor.org> Date: Tue, 22 Aug 2017 14:38:23 -0700 (PDT) Archived-At: Subject: [v6ops] RFC 8215 on Local-Use IPv4/IPv6 Translation Prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 21:38:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8215 Title: Local-Use IPv4/IPv6 Translation Prefix Author: T. Anderson Status: Standards Track Stream: IETF Date: August 2017 Mailbox: tore@redpill-linpro.com Pages: 7 Characters: 14846 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-v4v6-xlat-prefix-02.txt URL: https://www.rfc-editor.org/info/rfc8215 DOI: 10.17487/RFC8215 This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. This document is a product of the IPv6 Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Aug 22 16:31:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBAF132ABA; Tue, 22 Aug 2017 16:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 9FmwODfTqJzf; Tue, 22 Aug 2017 16:31:38 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E400B1329A7; Tue, 22 Aug 2017 16:31:37 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id 190so399384itx.3; Tue, 22 Aug 2017 16:31:37 -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=Xj1ZAji0a+2V0S+0fWAewfHb3avty6DRSyH2vP4ssyY=; b=LqLYB7CI36vKLPtV0YEHITxnUSfDktJrZorY9ZzWEL0xYwJ/30340amyADJ1OJGfKA LCGF1qj6ht25iSBe8ORbKaLh7YN3No3/vfb7RAt4VWkTAbLsoiju3Gfg3L7UZ9iTqwB2 VLSXyzzax9ZUMpoVYY1UUMUj/MZFiN8xFtjiyXADWltiThM30uEzB06so6xltnYcWG3i TjYxOmKrtbbHPhl6sAL1bH31bEQyIVteLhrtI27hEbltMhgG7RhoEESPPojfC06LIz/4 owpYcHSjrx3SXPDpyzOIcpBqdXfsv+MRnvaYpfsMgroFAocAOjzuISLMvr8VofayxV4q 1pkw== 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=Xj1ZAji0a+2V0S+0fWAewfHb3avty6DRSyH2vP4ssyY=; b=F1xQ1EzRs3+aNC3FIsKK/ppiOu7qgDYj4fOZk5YJ/5wnXHtT5UArZxDL7MLFnS+xAT a99+eay0rh0qOVPJBo1eCFhSa3PKCJ8sg0p2+Nu2S8dVz69hT1Nlp8R2iHoVGBa5RWWE 5DxBb15QYVA2K5aArNQ6wyjboZb6Nl3H97EArkyy6O/m/eOnwc3qWQGz27VnV2dbe6wF 5VXu0rLz5tN6/yM7hHYZNB+wMi0dHNGngkPpC2t8NcY+DZeSHeGN+uVdTwiRSl5T9x6d BuGqq9eCIigkTozGf8ioW6L3lZaHY/HbNiL9qJKFznE4MMxZ9AdNBYPvwwHg9r4Mmy7h Tg3g== X-Gm-Message-State: AHYfb5gY2V0pA2WIa3hYIrsp+oFQP42JRgJv1SyM2e88A8l1GveSmGsP GImg6s864HNIaA== X-Received: by 10.36.250.198 with SMTP id v189mr1638627ith.107.1503444697239; Tue, 22 Aug 2017 16:31:37 -0700 (PDT) Received: from ?IPv6:2600:1005:b06f:721:316c:341:5965:8a4a? ([2600:1005:b06f:721:316c:341:5965:8a4a]) by smtp.gmail.com with ESMTPSA id l97sm81959ioi.61.2017.08.22.16.31.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 16:31:36 -0700 (PDT) From: Suresh Krishnan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6BD8C8BB-D004-450C-82B7-879B16E95CDB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 22 Aug 2017 19:31:30 -0400 In-Reply-To: Cc: The IESG , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Ron Bonica , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 23:31:41 -0000 --Apple-Mail=_6BD8C8BB-D004-450C-82B7-879B16E95CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Gunter, Thanks for the proposed text changes. They adequately address my = DISCUSS points. I am hoping you will also converge in the discussion = with Lorenzo on the actual value for the timer and/or specify an = applicability statement. I will clear once the new revision posts. Regards Suresh > On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) = wrote: >=20 > Hi Suresh, >=20 > Many thanks for the review and finding these issues. What do you think = of the proposals below to fix those points of attention? >=20 > = ---------------------------------------------------------------------- > DISCUSS: > = ---------------------------------------------------------------------- >=20 > * Section 4 >=20 > It is not clear what you intend here >=20 > "IPv6 Router Advertisement Interval =3D 300s" >=20 > The router advertisement interval is not configured as an absolute = value but as > minimum and maximum bounds (MinRtrAdvInterval and = MaxRtrAdvInterval) which are > used to calculate the actual advertisement interval. When the RA is = sent from > an interface, the actual interval is an uniformly distributed = random value > between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very = minimum you > need to clarify if you would like to have this as a lower bound or = as an upper > bound. >=20 > GV> I changed the line to make it more clear that the timer indicates = the maximum Advertisement Interval > GV> Maximum IPv6 Router Advertisement Interval =3D = 300s >=20 > = ---------------------------------------------------------------------- > COMMENT: > = ---------------------------------------------------------------------- >=20 > * Section 4 >=20 > -> I think text is needed here to handle the case where the DNS = server is > provided in the RA itself (RFC8106) >=20 > "In addition it will use stateless DHCPv6 to get the IPv6 address = of the DNS > server" >=20 > -> I am not sure what is the motivation for this text. >=20 > "however it SHOULD NOT use stateful DHCPv6 to receive a service = provider > managed IPv6 address" >=20 > -> This text seems incorrect >=20 > "due to the L-bit set, it SHOULD send this traffic to the First Hop = Provider > Router" >=20 > I think it should be the exact opposite. i.e. say *unset* instead = of set >=20 > "due to the L-bit being unset, it SHOULD send this traffic to the = First Hop > Provider Router" >=20 > GV> What about the following modification in the text: >=20 > OLD: > The architected result of designing the RA as documented above is > that each UE/subscriber gets its own unique IPv6 prefix for which it > can use SLAAC or any other method to select its /128 unique address. > In addition it will use stateless DHCPv6 to get the IPv6 address of > the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive > a service provider managed IPv6 address. If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router. >=20 > New: > The architected result of designing the RA as documented above is > that each UE/subscriber gets its own unique IPv6 prefix for which it > can use SLAAC or any other method to select its /128 unique address.=20= > Either stateless DHCPv6 RFC3736 or = IPv6=20 > Router Advertisement Options for DNS Configuration=20 > RFC8106 can be used to get the=20 > IPv6 address of the DNS server. If the UE/subscriber desires to send > anything external including other UE/subscriber devices (assuming = device > to device communications is enabled and supported), then, due to the > L-bit being unset, it SHOULD send this traffic to the First Hop = Provider > Router. >=20 >=20 >=20 > Kind Regards, > G/ --Apple-Mail=_6BD8C8BB-D004-450C-82B7-879B16E95CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Gunter,
      Thanks for the proposed text = changes. They adequately address my DISCUSS points. I am hoping you will = also converge in the discussion with Lorenzo on the actual value for the = timer and/or specify an applicability statement. I will clear once the = new revision posts.

    Regards
    Suresh

    On = Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) = <gunter.van_de_velde@nokia.com> wrote:

    Hi Suresh,
    Many thanks for the review and finding these = issues. What do you think of the proposals below to fix those points of = attention?

       ---------------------------------------------= -------------------------
       DISCUSS:
       ---------------------------------------------= -------------------------

       * Section 4
       It is not clear what you = intend here

       "IPv6 Router = Advertisement Interval =3D 300s"

       The router advertisement = interval is not configured as an absolute value but as
       minimum and maximum bounds = (MinRtrAdvInterval and MaxRtrAdvInterval) which are
       used to calculate the actual = advertisement interval. When the RA is sent from
       an interface, the actual = interval is an uniformly distributed random value
       between the MinRtrAdvInterval = and MaxRtrAdvInterval. At the very minimum you
       need to clarify if you would = like to have this as a lower bound or as an upper
       bound.
    GV> I changed the line to make it more clear = that the timer indicates the maximum Advertisement Interval
    GV> =          <t>Maximum = IPv6 Router Advertisement Interval =3D 300s</t>
       ---------------------------------------------= -------------------------
       COMMENT:
       ---------------------------------------------= -------------------------

       * Section 4
       -> I think text is needed = here to handle the case where the DNS server is
       provided in the RA itself =  (RFC8106)

       "In addition = it will use stateless DHCPv6 to get the IPv6 address of the = DNS
       server"
       -> I am not sure what is = the motivation for this text.

       "however it SHOULD NOT use = stateful DHCPv6 to receive a service provider
       managed IPv6 = address"

       -> This = text seems incorrect

       "due to the L-bit set, it = SHOULD send this traffic to the First Hop Provider
       Router"
       I think it should be the exact = opposite. i.e. say *unset* instead of set

       "due to the L-bit being unset, = it SHOULD send this traffic to the First Hop
       Provider Router"
    GV> What about the following modification in = the text:

    OLD:
    The architected result of designing the RA as = documented above is
      that each = UE/subscriber gets its own unique IPv6 prefix for which it
      can use SLAAC or any other method to = select its /128 unique address.
      In addition it will = use stateless DHCPv6 to get the IPv6 address of
      the DNS server, however it SHOULD = NOT use stateful DHCPv6 to receive
      a service provider = managed IPv6 address.  If the UE/subscriber
      desires to send anything external = including other UE/subscriber
      devices (assuming = device to device communications is enabled and
      supported), then, due to the L-bit = set, it SHOULD send this traffic
      to the First Hop = Provider Router.

    New:
    The architected result of designing the RA as = documented above is
    that each UE/subscriber gets its = own unique IPv6 prefix for which it
    can use SLAAC or any other = method to select its /128 unique address. 
    Either stateless DHCPv6 <xref = target=3D"RFC3736">RFC3736</xref> or IPv6 
    Router Advertisement Options for DNS = Configuration <xref = target=3D"RFC8106">RFC8106</xref> can be used to get the 
    IPv6 address of the DNS server. If the = UE/subscriber desires to send
    anything external including = other UE/subscriber devices (assuming device
    to device communications is enabled and = supported), then, due to the
    L-bit being unset, it SHOULD = send this traffic to the First Hop Provider
    Router.</t>

    Kind Regards,
    G/

    = --Apple-Mail=_6BD8C8BB-D004-450C-82B7-879B16E95CDB-- From nobody Wed Aug 23 15:00:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB4132A2B for ; Wed, 23 Aug 2017 15:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH-MICuDyztb for ; Wed, 23 Aug 2017 15:00:24 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D37F132A18 for ; Wed, 23 Aug 2017 15:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7NM0M7R003666; Wed, 23 Aug 2017 15:00:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7NM0EKq003599 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 15:00:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 23 Aug 2017 15:00:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 23 Aug 2017 15:00:14 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" CC: james woodyatt Thread-Topic: Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjueg== Date: Wed, 23 Aug 2017 22:00:14 +0000 Message-ID: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:00:26 -0000 With RFC7934, we already have BCP recommendations on host address availabil= ity with benefits including privacy addressing, tethering, VM support, etc. Now= , with 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', we are seeing operational g= uidance on delegating unique IPv6 prefixes to hosts. With the advent of these recommendations and practices, we see an operation= al advantage for hosts to discover the delegated prefixes of neighbors on the = link so that communications can go directly from peer to peer for better performanc= e and to reduce the load on routers. This becomes especially important when t= here are many nodes on the link and/or when the performance in the direct path f= rom peer-to-peer is substantially better than the performance in the "dogleg" p= ath from peer-to-router-to-peer. We would like to invite discussion in this forum as to the operational bene= fits and implications of such a capability. This could provide guidance for solu= tion alternatives that may be taken up in other working groups. Thanks in advanc= e for your insights. Fred and James From nobody Wed Aug 23 15:22:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F0132A41 for ; Wed, 23 Aug 2017 15:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DlGiC5fuNUSK for ; Wed, 23 Aug 2017 15:21:58 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01421321C8 for ; Wed, 23 Aug 2017 15:21:57 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s143so8850841ywg.1 for ; Wed, 23 Aug 2017 15:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=78FushxMMpvCXUlwju88o2eXoerVDy50J5CKLqKl7jY=; b=Ut5PrUFJJWTMmg/Hbs3wfLrEFkNkJ0wJhJznl99hXAPJGl/TmXS02vL6Ln/vBAsLsX 7ECz+WFMKhbsp1iP5wAwvN/oDcrJYSFG/NjZkMmtGygDfSxgxH3ENgPATorY5JdfGSp6 WB8KAjGuDum3YvRH8lyir3/FAbFTag2kL+lhSHq1WBEd9AIrUVXcoOifcGq0Z72fDpsa TvHJt8AA32XLjqZ0gNnRQOsgfawXefq0kbLGmvJyphgBJc7xDC1MMmKRx1kzvckxdb6s bhmAVlwRPgfKs/MjlautDflptDpo83CEugZGJxvy0l5cfMVvt4KVysbs9uuQ0uBSSUc1 41Dw== 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=78FushxMMpvCXUlwju88o2eXoerVDy50J5CKLqKl7jY=; b=M9bsUd9vo7dkmWAIKCQsZ4uf5fyvbbiT6BQw1bHTgJUb1FNnAdmPsVgaCjpfB6zZ2/ 4tJTZdytEgI8+RG6Ojs4F08gFJaw66/RngihjN35XmwCMpiS7i3cbtgPqCBSghR7VspS SysTyvY6DygcsDPep4Jl+LhVCEXUQL9BFFW3DuXeoL7x956faE1JndT19JwGAvWl2B+O pRbGyY+YgywZ8l+sCZ8UtO5mfpaXQ5e+GW+4o80F0SXPePTgkw9GUzeyJlLMUQ6Glfpr GWDnVFDNORV1Urkli9foJdlGDvpsFqsDK31GWT6G9t8kOhW/XTAFeN0TZ3eSVenLBxoo 4sdQ== X-Gm-Message-State: AHYfb5h3zlMfOHd1QoCQutU9IpNeWZn/nDtoiX0W4WP8BZv7glPXQ3DS gpZwFBCiW5ft3KNlk6Vd5rvuuk+xoq2y X-Google-Smtp-Source: ADKCNb7mcBo+TSUzjOGBUOG2XNgmBnp27GGfTVujv1HKtL9/4z2kzDH+3I65vT818L7vLg4gJdxLfOQ3EKFmLXeVlQQ= X-Received: by 10.129.109.198 with SMTP id i189mr3254402ywc.289.1503526916824; Wed, 23 Aug 2017 15:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.4.205 with HTTP; Wed, 23 Aug 2017 15:21:36 -0700 (PDT) In-Reply-To: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> From: Erik Kline Date: Wed, 23 Aug 2017 15:21:36 -0700 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , james woodyatt Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114dcee2cfe8860557732310" Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:22:00 -0000 --001a114dcee2cfe8860557732310 Content-Type: text/plain; charset="UTF-8" On 23 August 2017 at 15:00, Templin, Fred L wrote: > With RFC7934, we already have BCP recommendations on host address availability > with benefits including privacy addressing, tethering, VM support, etc. Now, with > 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', we are seeing operational guidance > on delegating unique IPv6 prefixes to hosts. > > With the advent of these recommendations and practices, we see an operational > advantage for hosts to discover the delegated prefixes of neighbors on the link so > that communications can go directly from peer to peer for better performance > and to reduce the load on routers. This becomes especially important when there > are many nodes on the link and/or when the performance in the direct path from > peer-to-peer is substantially better than the performance in the "dogleg" path > from peer-to-router-to-peer. > > We would like to invite discussion in this forum as to the operational benefits > and implications of such a capability. This could provide guidance for solution > alternatives that may be taken up in other working groups. Thanks in advance > for your insights. I don't think it's going to prove wise to support a model where neighbors share the same L2 broadcast domain but each receives different RAs (to get their unique prefixes). --001a114dcee2cfe8860557732310 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgpwd64BJOAq/LDqqiQQ89St/xWIt/zhCB /yGacEOSVB0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODIz MjIyMTU3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBANGs+zgz6ucXgAPAeVnkITBt7sqcwp/JRCeS3hvjX66LXvsv10tQ VGtlEhekFkhR+ijl7/ZX4fKgxCdoun+p84ukQ5QKtkkb7Lei6wRBq8ewieqtql871XWE4aw5ciKQ dYj9p4OEFFI2Un/05yXGCSrYARV+BvAv2VCxuMm/fuXkyF1tStVXgUOlblQwsKpSAmJgMQd8ybXW nrM6uwil4mfVSbxwAwf98+vsmmu/hWefNiXWEP4Thwdu1aTAyo8LvVpJsXBvQpbFSTF3QgbxFiQV vSwT+EgGM0BkqBDv+iLft2QNtQVO/TB3arPZX1NCUFqUK/HsCPQ1fKA2cwLF7KU= --001a114dcee2cfe8860557732310-- From nobody Wed Aug 23 15:45:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B47132A56 for ; Wed, 23 Aug 2017 15:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_H9H9BWsvxS for ; Wed, 23 Aug 2017 15:45:44 -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 5736A132A53 for ; Wed, 23 Aug 2017 15:45:43 -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 v7NMjgmP002082; Wed, 23 Aug 2017 15:45:42 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7NMjek5002065 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 15:45:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 23 Aug 2017 15:45:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 23 Aug 2017 15:45:39 -0700 From: "Templin, Fred L" To: Erik Kline CC: "v6ops@ietf.org" , james woodyatt Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegAPiXkAAA4YUmA= Date: Wed, 23 Aug 2017 22:45:39 +0000 Message-ID: References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0021_01D31C26.DD8D3430" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 22:45:46 -0000 ------=_NextPart_000_0021_01D31C26.DD8D3430 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi Erik, > -----Original Message----- > From: Erik Kline [mailto:ek@google.com] > Sent: Wednesday, August 23, 2017 3:22 PM > To: Templin, Fred L > Cc: v6ops@ietf.org; james woodyatt > Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host > > On 23 August 2017 at 15:00, Templin, Fred L wrote: > > With RFC7934, we already have BCP recommendations on host address availability > > with benefits including privacy addressing, tethering, VM support, etc. Now, with > > 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', we are seeing operational guidance > > on delegating unique IPv6 prefixes to hosts. > > > > With the advent of these recommendations and practices, we see an operational > > advantage for hosts to discover the delegated prefixes of neighbors on the link so > > that communications can go directly from peer to peer for better performance > > and to reduce the load on routers. This becomes especially important when there > > are many nodes on the link and/or when the performance in the direct path from > > peer-to-peer is substantially better than the performance in the "dogleg" path > > from peer-to-router-to-peer. > > > > We would like to invite discussion in this forum as to the operational benefits > > and implications of such a capability. This could provide guidance for solution > > alternatives that may be taken up in other working groups. Thanks in advance > > for your insights. > > I don't think it's going to prove wise to support a model where > neighbors share the same L2 broadcast domain but each receives > different RAs (to get their unique prefixes). Trying to understand your comments. Are you referring to a mechanism where prefix delegation to individual hosts is coordinated via RAs instead of via something like DHCPv6 PD? Or, are you referring to unicast RAs instead of multicast? Or, some combination of the two? In any event, the operational capability we are referring to is completely independent of the manner in which prefixes are delegated to hosts, and works the same way regardless of the mechanisms. Thanks - Fred ------=_NextPart_000_0021_01D31C26.DD8D3430 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVuTCCBCcw ggMPoAMCAQICECF2PaKfTBqRTnjJxGi7hjUwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCVVMx DzANBgNVBAoTBkJvZWluZzEUMBIGA1UECxMLY2VydHNlcnZlcnMxETAPBgNVBAsTCG5ldHNjYXBl MTYwNAYDVQQDEy1UaGUgQm9laW5nIENvbXBhbnkgUm9vdCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDAwMzE3MDgwMDAwWhcNMjExMjE1MDAxNjIwWjB/MQswCQYDVQQGEwJVUzEPMA0GA1UEChMG Qm9laW5nMRQwEgYDVQQLEwtjZXJ0c2VydmVyczERMA8GA1UECxMIbmV0c2NhcGUxNjA0BgNVBAMT LVRoZSBCb2VpbmcgQ29tcGFueSBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMQjWT4y7Hftm6Ucjl1iE8kmd3jukPKkWmg2T/STJmRRnl2F JKDYRNc0HmgHbZqb/RUiAlIvWogHb1WbTdFG3aj2mRp8iFsAaTPl0yxq3TrsdWh8FpaKnYzxp2nF R/pZgH/Dj7DFQo8RCW1JghP+bvgDHNvMa0I3FKHxfN9JiEkWO4fGvo96kjIvwXHHW6wZer5r+jwa FhCDs5mhMPe+YFdUOPC4Yf3DHDYUoCLScGfkkvgeeYJHuGpfEEsFRIHCVaC+utfuP9NbVBihNerT N2ZWIjN4rdoQ+kADKgbzuHH5fDohu9ktX4isClvXP1rBxmNGUP7tjdV+ntjSoLDlLu0CAwEAAaOB njCBmzARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBQ0Yvzg /aYq8ohbBb00yBpxUQaSgTAdBgNVHQ4EFgQUNGL84P2mKvKIWwW9NMgacVEGkoEwEAYJKwYBBAGC NxUBBAMCAQEwIwYJKwYBBAGCNxUCBBYEFNAvWn93Mvxk+0L4K22nnhdsByxbMA0GCSqGSIb3DQEB BQUAA4IBAQChJxOLrU97lJEXLPauW4mXs9qtag/huL1TnRppOWfya14SpSMkV0MP15ACHUw+lpBt bHJu151lX5Diq2zJ+VtzTW+sxm2q+nuduqC9XgIw09CSkrzzIK1AB/3hFKnlg2FD9rc8wT08vkRU NaAp0afJPd1RhKCzrXiLq//lRkfatz10+ByYXumadmpC9mUi8M8vMyvtK6OpxYjN9BREPT/3foO0 BN7zTX1C00zW5qBsiGfqPgZdCqHL35fQgQLwso8fsqJpBxZX8H7+eybmxrkFI7xC1fWrF12TVDB6 IPbq/IVTLKVVDyPPICyWdQINe2dGZNz96hbwxASOO69aAGnoMIIFgjCCBGqgAwIBAgITbwAoANDG r3HlaRy+BgABACgA0DANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQm9l aW5nMRQwEgYDVQQLEwtjZXJ0c2VydmVyczEjMCEGA1UEAxMaQm9laW5nIFNlY3VyZSBNZXNzYWdp bmcgRzIwHhcNMTcwMTIzMTU0ODEyWhcNMTkwMTIzMTU0ODEyWjCBgTEPMA0GA1UEChMGQm9laW5n MRkwFwYDVQQLExBTZWN1cmUgTWVzc2FnaW5nMRcwFQYDVQQDEw5GcmVkIEwgVGVtcGxpbjEQMA4G A1UEAxMHMTYzMTE3MzEoMCYGCSqGSIb3DQEJARYZRnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtCeHT1RQtzW2B2M/Wld/aqS2U12FR8E1pqZgbmpN I3em2jvzYgdgw4RVzy+ePYds6BmuQnEC5F06XIjDH0aVMQQjH1JmXC/6c33h0JZTRBCEyvpC8hqd 6ywrjeEXDd8U0dSxJQppU5SvE3v9IAjCWHdDOj9QEKgyFdLSvA3pK38CAwEAAaOCApwwggKYMDsG CSsGAQQBgjcVBwQuMCwGJCsGAQQBgjcVCIHBxU2CrKkuhPmPIeaqT5SDAIFX2fANhI+4agIBZAIB BzATBgNVHSUEDDAKBggrBgEFBQcDBDALBgNVHQ8EBAMCB4AwGwYJKwYBBAGCNxUKBA4wDDAKBggr BgEFBQcDBDAdBgNVHQ4EFgQUKp6AIIOh1+sZ7CumJtMQJojvC1YwJAYDVR0RBB0wG4EZRnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTAfBgNVHSMEGDAWgBT5rMwSEc1yAUULFmWlUGeEDn3dXDCB1AYD VR0fBIHMMIHJMIHGoIHDoIHAhj5odHRwOi8vY3JsLmJvZWluZy5jb20vY3JsL0JvZWluZyUyMFNl Y3VyZSUyME1lc3NhZ2luZyUyMEcyLmNybIZ+bGRhcDovL2Rpci5ib2VpbmcuY29tL0NOPUJvZWlu ZyUyMFNlY3VyZSUyME1lc3NhZ2luZyUyMEcyLG91PXBraSxvdT1jZXJ0c2VydmVycyxvPWJvZWlu ZyxjPXVzP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MIHcBggrBgEFBQcBAQSBzzCB zDBKBggrBgEFBQcwAoY+aHR0cDovL2NybC5ib2VpbmcuY29tL2NybC9Cb2VpbmclMjBTZWN1cmUl MjBNZXNzYWdpbmclMjBHMi5jcnQwfgYIKwYBBQUHMAKGcmxkYXA6Ly9kaXIuYm9laW5nLmNvbS9D Tj1Cb2VpbmclMjBTZWN1cmUlMjBNZXNzYWdpbmclMjBHMixvdT1wa2ksb3U9Y2VydHNlcnZlcnMs bz1ib2VpbmcsYz11cz9jQUNlcnRpZmljYXRlO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAZ+37 bHVHfO746FhMYdJyQ0+KeIZY9k6Vycp9W5L3j/zg2VVfkVjD+fz2jARw0BFnqocmhjC3uSKDrcRp eaqMxYcnLHNRw1TVvTTa9xB6L6pDdBf43C86ITGaOjmTnJzALWqpnp0LKtBiWr1LPniz1D5wUx6d iqDvIJkd1Ay+/yR2JeskSyXdSg+eJSatBZAtsyZMOHTvepkZoqPyTfhZN9V6YDgscVOgyYY2ugGP LVBW5vMcUtGmuR0FzJYxLVLuoFbZe0Sa4T9G0hLaFsqnrcrMfiEqfZabCUpK7YOSPlTP+39zAW/q QFhcQtiJbM6Nb2G4aFpILcCfR7rFV1HhkzCCBccwggSvoAMCAQICE28AKADPF1f7iK2Yl8cAAQAo AM8wDQYJKoZIhvcNAQEFBQAwWTELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkJvZWluZzEUMBIGA1UE CxMLY2VydHNlcnZlcnMxIzAhBgNVBAMTGkJvZWluZyBTZWN1cmUgTWVzc2FnaW5nIEcyMB4XDTE3 MDEyMzE1NDgwN1oXDTE5MDEyMzE1NDgwN1owgYExDzANBgNVBAoTBkJvZWluZzEZMBcGA1UECxMQ U2VjdXJlIE1lc3NhZ2luZzEXMBUGA1UEAxMORnJlZCBMIFRlbXBsaW4xEDAOBgNVBAMTBzE2MzEx NzMxKDAmBgkqhkiG9w0BCQEWGUZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20wgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMQaj/2McB0kmO9LCcOcZ74duu3GF3U4R5SpDtBKlhA9srd0hztsgBqk XYq+F9Ma7mOf8BqH6rC4gwGGTx1vaHbRkylgymIamK2jQWELdl6I0Q0ANpKQE4sqbPy3cQ/E+7aQ oQSZXIcrKmH0yoOU6BXqbYlMoGsBsL9uszjhh2l5AgMBAAGjggLhMIIC3TA7BgkrBgEEAYI3FQcE LjAsBiQrBgEEAYI3FQiBwcVNgqypLoT5jyHmqk+UgwCBV4e70ESf5WECAWQCAQUwEwYDVR0lBAww CgYIKwYBBQUHAwQwCwYDVR0PBAQDAgUgMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwQwYJ KoZIhvcNAQkPBDYwNDALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAS0wHQYDVR0OBBYEFBU3Ak1jDterTnG2CqJ3vPZT3ciQMCQGA1UdEQQdMBuBGUZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20wHwYDVR0jBBgwFoAU+azMEhHNcgFFCxZlpVBnhA593VwwgdQG A1UdHwSBzDCByTCBxqCBw6CBwIY+aHR0cDovL2NybC5ib2VpbmcuY29tL2NybC9Cb2VpbmclMjBT ZWN1cmUlMjBNZXNzYWdpbmclMjBHMi5jcmyGfmxkYXA6Ly9kaXIuYm9laW5nLmNvbS9DTj1Cb2Vp bmclMjBTZWN1cmUlMjBNZXNzYWdpbmclMjBHMixvdT1wa2ksb3U9Y2VydHNlcnZlcnMsbz1ib2Vp bmcsYz11cz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCB3AYIKwYBBQUHAQEEgc8w gcwwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jcmwuYm9laW5nLmNvbS9jcmwvQm9laW5nJTIwU2VjdXJl JTIwTWVzc2FnaW5nJTIwRzIuY3J0MH4GCCsGAQUFBzAChnJsZGFwOi8vZGlyLmJvZWluZy5jb20v Q049Qm9laW5nJTIwU2VjdXJlJTIwTWVzc2FnaW5nJTIwRzIsb3U9cGtpLG91PWNlcnRzZXJ2ZXJz LG89Ym9laW5nLGM9dXM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBALUY 3nKZOwmVSAauYsqzOAje3ASDwaN+lhnTUw4amHVSBXmISNVvKPXkpDpQF8IJMfm4gK4pW3qg7IXx NjyZJKRXw1UlFQ5AGo7WxK2jFp3ois8+ubkCwcT7kszfwF3JIUohNZ3BblHsloCkVt3L8/LQQpsZ HNkLUutEfKZug7KE+DB2DcYpsbJMA2MhaMCI/tqdp38vBfcqBRkR606+6rwvxj6fElnfxD1VkAvX 62sZoZuqIczNhb1sphefbLgKk8aqUTBcMKM9Isir//FG4yGOzT9yrfXKePzBDdPh87lUvX/3oYHL N+5LcQeP0kt7EnPtvGq0eQ2Ud4JPww57UhUwggY5MIIFIaADAgECAgphGpOWAAEAAAAYMA0GCSqG SIb3DQEBBQUAMH8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZCb2VpbmcxFDASBgNVBAsTC2NlcnRz ZXJ2ZXJzMREwDwYDVQQLEwhuZXRzY2FwZTE2MDQGA1UEAxMtVGhlIEJvZWluZyBDb21wYW55IFJv b3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDUzMDAxMzMyNloXDTE5MDUzMDAxNDMyNlow WTELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkJvZWluZzEUMBIGA1UECxMLY2VydHNlcnZlcnMxIzAh BgNVBAMTGkJvZWluZyBTZWN1cmUgTWVzc2FnaW5nIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA2/79eo4tofzDt+AqPdhej1Q8HUT+cYp1BtpnM5ICPw2PimpHQl57FwWjGfn6ZAV+ rL5gMn7gpigWTKpsdBDaEpnZFMbaRDJVGR5Yxk6VdUNi2y3socQ36u0ak5OuIAwyihRqtgSmvvuR J3xOqAIk8PjEUtDTF/vewoZ8wP0HdNFz7y4u9Qbmt+yctNBCwcN0W1tbqrriQxSwUBkdnP/GRgFa F5+3JZZvSNvh+Lhnaak34GjzVt0vslTAR60vT9kIfohGwZOimntHQvl/s+oxOTE5oaX1lHgHzY4G mmr/Mh5OQOdDRDzgyyqcWqw0pxP4tauBIgPR5qWJmyacCQRrpwIDAQABo4IC2zCCAtcwDgYDVR0P AQH/BAQDAgHGMBAGCSsGAQQBgjcVAQQDAgEBMCMGCSsGAQQBgjcVAgQWBBTubYUt7CrS7W5m9Ef8 P2vWmxeUVDAdBgNVHQ4EFgQU+azMEhHNcgFFCxZlpVBnhA593VwwFwYDVR0gBBAwDjAMBgorBgEE AUkPAwECMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUNGL84P2mKvKIWwW9NMgacVEGkoEwgfwGA1UdHwSB9DCB8TCB7qCB66CB6IZVaHR0 cDovL2NybC5ib2VpbmcuY29tL2NybC9UaGUlMjBCb2VpbmclMjBDb21wYW55JTIwUm9vdCUyMENl cnRpZmljYXRlJTIwQXV0aG9yaXR5LmNybIaBjmxkYXA6Ly9kaXIuYm9laW5nLmNvbS9DTj1UaGUl MjBCb2VpbmclMjBDb21wYW55JTIwUm9vdCUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5LE9VPWNl cnRzZXJ2ZXJzLE89Qm9laW5nLEM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkw ggEFBggrBgEFBQcBAQSB+DCB9TBhBggrBgEFBQcwAoZVaHR0cDovL2NybC5ib2VpbmcuY29tL2Ny bC9UaGUlMjBCb2VpbmclMjBDb21wYW55JTIwUm9vdCUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5 LmNydDCBjwYIKwYBBQUHMAKGgYJsZGFwOi8vZGlyLmJvZWluZy5jb20vQ049VGhlJTIwQm9laW5n JTIwQ29tcGFueSUyMFJvb3QlMjBDZXJ0aWZpY2F0ZSUyMEF1dGhvcml0eSxPVT1jZXJ0c2VydmVy cyxPPUJvZWluZyxDPVVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQBe B8T6WiG5FIpA6tc/vX8kpIEnsts1VWy6LJG9OzdMoF1cf0PgsICawRkkCZiSWbD+k0M8webFw3h0 NJdjiENq+8IgTxFdeElfEJNiRCiDp3zMIT1YION/89vl7hutd6Be6apYK9rg862NabAThbs0we9V TV2Nxao+Vjmq3olYjfCrJT6+VRvwekT4gYfJIiL7Nd3qyU1PsCFOQy/NLp20IqXlBiMUUj0Tt8lc kJx8n79ep0hzWNova8ulzWG9JZDQ68NrzuQZ24Sqq28ZfLKFa30q6yBLpYwO701U9P7tS3MJgw+O coBveH/6wsZ4BJ+pz6rqGt0DuGJmUj/4j2nfMYIDEjCCAw4CAQEwcDBZMQswCQYDVQQGEwJVUzEP MA0GA1UEChMGQm9laW5nMRQwEgYDVQQLEwtjZXJ0c2VydmVyczEjMCEGA1UEAxMaQm9laW5nIFNl Y3VyZSBNZXNzYWdpbmcgRzICE28AKADQxq9x5WkcvgYAAQAoANAwCQYFKw4DAhoFAKCCAfgwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODIzMjI0NTM3WjAjBgkq hkiG9w0BCQQxFgQUJF06GP211kboBZEo9q5hff0PvmEwfwYJKwYBBAGCNxAEMXIwcDBZMQswCQYD VQQGEwJVUzEPMA0GA1UEChMGQm9laW5nMRQwEgYDVQQLEwtjZXJ0c2VydmVyczEjMCEGA1UEAxMa Qm9laW5nIFNlY3VyZSBNZXNzYWdpbmcgRzICE28AKADPF1f7iK2Yl8cAAQAoAM8wgYEGCyqGSIb3 DQEJEAILMXKgcDBZMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQm9laW5nMRQwEgYDVQQLEwtjZXJ0 c2VydmVyczEjMCEGA1UEAxMaQm9laW5nIFNlY3VyZSBNZXNzYWdpbmcgRzICE28AKADPF1f7iK2Y l8cAAQAoAM8wgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoG CCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEB BQAEgYBfcuBUd6yYs6+8K4adS0pP4BrjlbZaive/gmQxLOXf2jI5wpj860QkF8V2ZIygtRyq7kCf 82MsmoGyGTND++2ZBb5zm6vW4bfQhkTqLs2DmuCzKuT18b6Qb03CZJFK6Qk7gOuzvHLZLdpYnXqH 9vVIOqhEYnbhMg7RAzTlNUQOTAAAAAAAAA== ------=_NextPart_000_0021_01D31C26.DD8D3430-- From nobody Wed Aug 23 17:01:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABE91320BB for ; Wed, 23 Aug 2017 17:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ALMGyfnZVfhM for ; Wed, 23 Aug 2017 17:01:48 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6CE1329EF for ; Wed, 23 Aug 2017 17:01:48 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id c76so5532399itb.1 for ; Wed, 23 Aug 2017 17:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zc20x9TBlPhGggZWQFg8AmhWh/6KlQe752Hy12gNpQI=; b=gRTbVR6FaR8HtHFDo/aAPUpz7IY645CM8IObD810CC4l10t7csiIKohEJM6XGU033x JfTRlPBwxtw/msYgZnrocER1z+su46g1VMSlYXQmwGsltk+LRuunwFEorjiTBoAx6qyo RNL8BjexAZ2OmvQSAZD4OQax0fK99cCcUP8kCjdLFrBKAv90pSrx9KfHaxgaFr61Bb4p zrkpiFz1oeitJMUALVU63QfCvCILgu7QAF9D4kdb+T+k07vcq4feuOKuhVWWMPBde5EZ 3Pa0xTdsYvovnwNrtJvFnZNXPrWvo/G0oOXocACJ9dMnr6zINgbl5vs8lJQyNyjvqhpf Wlgg== 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=zc20x9TBlPhGggZWQFg8AmhWh/6KlQe752Hy12gNpQI=; b=SlCdgN4jZPHrS4CdbO33vCEy6EvoqRsuyLcSajWxtxPHtKjrpKE6XGhE1SMFYLDZ61 GCIw13zGenR37hkdX9BleLX4gsG1H5ftDI5M/Gb/NP5sk4fFhkIdFt+oxy7U7+TvIsqI q/P4hj9LrAHY+aXRLm4mJ9BKtGQgDFKx+6+p89VSQ2qDe0E0XETFBoSAzTPrXqDd0c27 0c4zRlfFKj3tnUa7rdj4khyDSX7saHDQYndpdwJKQhH1GFBchF5QoN3WgVGOLE84V9t2 17b6FIvXMaJK5b6yQBRNA8DdZhzJrWOVUU2KUF/VJ7ybJUJCaYcc515FIJsEV2VkPYZh IpjA== X-Gm-Message-State: AHYfb5j4y9qVBmGfJ2xMcMaNx/KS+46ePj6Zg7KBqfHj5xZTJjgHx74m i8koZKpDWYlbwLGX9vw0ZQgSXSItT5ZM X-Google-Smtp-Source: ADKCNb5vDNQiGEF83UVjGxIw7amXhf25l4YeDqsIU/3NzabvZxnOO7wMOIsL+SpA3qJByhPvXkh5UhUOsddqpgFT3d4= X-Received: by 10.36.203.132 with SMTP id u126mr4863110itg.133.1503532907022; Wed, 23 Aug 2017 17:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 23 Aug 2017 17:01:26 -0700 (PDT) In-Reply-To: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 24 Aug 2017 09:01:26 +0900 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , james woodyatt Content-Type: multipart/alternative; boundary="94eb2c0b09c4d562460557748807" Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 00:01:50 -0000 --94eb2c0b09c4d562460557748807 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L wrote: > With RFC7934, we already have BCP recommendations on host address > availability > With the advent of these recommendations and practices, we see an > operational > advantage for hosts to discover the delegated prefixes of neighbors on the > link so > that communications can go directly from peer to peer for better > performance > and to reduce the load on routers. I'm not sure that would be generally useful, because: 1. It only makes sense if router load is a problem. That is unlikely to happen in many scenarios, for example the common use case of a wifi network that hands out a /64 to every host. In such a deployment, the packets have to travel through the AP anyway, and cross-talk is likely to be extremely limited compared to Internet-bound traffic. Most network infrastructure is actually point-to-point these days. 2. Allowing cross-talk between devices on the same link raises a number of security issues because malicious hosts can mount L2 attacks against other hosts on the network - for example, they can attempt to prevent other hosts from forming IPv6 addresses by replying to DAD probes, they can send rogue RAs, they can forge redirects, etc. --94eb2c0b09c4d562460557748807 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= hu, Aug 24, 2017 at 7:00 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
    With RFC7934= , we already have BCP recommendations on host address availability
    With = the advent of these recommendations and practices, we see an operational advantage for hosts to discover the delegated prefixes of neighbors on the = link so
    that communications can go directly from peer to peer for better performanc= e
    and to reduce the load on routers.

    I'm = not sure that would be generally useful, because:
    1. It only= makes sense if router load is a problem. That is unlikely to happen in man= y scenarios, for example the common use case of a wifi network that hands o= ut a /64 to every host. In such a deployment, the packets have to travel th= rough the AP anyway, and cross-talk is likely to be extremely limited compa= red to Internet-bound traffic. Most network infrastructure is actually poin= t-to-point these days.
    2. Allowing cross-talk between devices on the s= ame link raises a number of security issues because malicious hosts can mou= nt L2 attacks against other hosts on the network - for example, they can at= tempt to prevent other hosts from forming IPv6 addresses by replying to DAD= probes, they can send rogue RAs, they can forge redirects, etc.
    <= /div>
    --94eb2c0b09c4d562460557748807-- From nobody Wed Aug 23 18:02:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A3E1329A7 for ; Wed, 23 Aug 2017 18:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 qHGRpxo3UbCE for ; Wed, 23 Aug 2017 18:02:44 -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 CF33E1320BB for ; Wed, 23 Aug 2017 18:02:44 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 2529A185 for ; Thu, 24 Aug 2017 01:02:44 +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 g8Ma9p6OqoeD for ; Wed, 23 Aug 2017 20:02:44 -0500 (CDT) Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id ED2346C0 for ; Wed, 23 Aug 2017 20:02:43 -0500 (CDT) Received: by mail-io0-f198.google.com with SMTP id 28so13757406ioh.1 for ; Wed, 23 Aug 2017 18:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iUrU78zmvqOxX6wRGR5YW9fNG/Mz8P1X4zav87e5oak=; b=c1LzvuyJANf0Lv0ajCYevjGtDD5fcUwSCmc8Q7fj+ZFsDixsLSy95fr8sBYWuQ8IsP D72YIEtkH1wHVYAYFfcRR9iZvvScIztRAQ13aSMzNLHMZoKnpxk+WGTsUyKaWdmoX6wp /kIXMss7qykWycT44IoqF3n1IQt8olQO0AwdFXDnaj+hu6JSHcB1d8oWWZLFIGH0hZBu 6BUK872UpspGjAAj4R0Xwtg/aKpDC/3TinktMCOhw8V8kjrpdpzodTv9kikcXMYjIV5X lXx1mmiwaA3nue3Z1YcShbOhJZS1A77ckrW0P8p8/+CCwCsImfgXPvsUOToh3z+MHop/ jzag== 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=iUrU78zmvqOxX6wRGR5YW9fNG/Mz8P1X4zav87e5oak=; b=iCzv+9ipk5YWYcFcPDCmYGv8RFJOlOGsgjqVZtE/KsjaHNy2i1rjgQ34QJ/18R9dhW 1I16keZcOskeor3uxM/JtKpplTQ46lI4SddgTh07rM+e2fsXdSdKEOR/ol3qx3CVppjN EUGT/xx1l+GGTqog2gzb7/LPJOUDPVuNgKN3zHuJWF0ORW95VGN4tUAVEWy4YdmltSxl KDt1/jo6t//rZeWd9xcWah6O2vj0ceJQ7EBA1rgowbvx8KSqkU6lucdbYTdhlreluOlG 8n1FO+SxBYyFJH8FB2QFYJfMpDHnNHEyNgNAixXLnCxLlROGp1w4HppujOQWv24kFQW+ VxKA== X-Gm-Message-State: AHYfb5hccRy7P7BuF6cPLhhXBM20PK6qlgdUJvlaEpAPQzFNxJn+2OcK OsNYPQipHui5Lyz3OQwl2+UN043UdP2nnpV8A49AkOFJi6A/3xJw337GM3GrZnBH8wx30fwDkq0 y X-Received: by 10.107.133.97 with SMTP id h94mr4072699iod.227.1503536563284; Wed, 23 Aug 2017 18:02:43 -0700 (PDT) X-Received: by 10.107.133.97 with SMTP id h94mr4072685iod.227.1503536563033; Wed, 23 Aug 2017 18:02:43 -0700 (PDT) Received: from [172.20.20.20] ([73.94.200.11]) by smtp.gmail.com with ESMTPSA id z140sm1551722itb.30.2017.08.23.18.02.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 18:02:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DA84E33E-F02D-4F98-9A6B-024917AD8639 Mime-Version: 1.0 (1.0) From: David Farmer X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 23 Aug 2017 20:02:40 -0500 Cc: "Templin, Fred L" , james woodyatt , "v6ops@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> To: Lorenzo Colitti Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 01:02:47 -0000 --Apple-Mail-DA84E33E-F02D-4F98-9A6B-024917AD8639 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Aug 23, 2017, at 19:01, Lorenzo Colitti wrote: >=20 >> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L wrote: >> With RFC7934, we already have BCP recommendations on host address availab= ility >> With the advent of these recommendations and practices, we see an operati= onal >> advantage for hosts to discover the delegated prefixes of neighbors on th= e link so >> that communications can go directly from peer to peer for better performa= nce >> and to reduce the load on routers. >=20 > I'm not sure that would be generally useful, because: > It only makes sense if router load is a problem. That is unlikely to happe= n in many scenarios, for example the common use case of a wifi network that h= ands out a /64 to every host. In such a deployment, the packets have to trav= el through the AP anyway, and cross-talk is likely to be extremely limited c= ompared to Internet-bound traffic. Most network infrastructure is actually p= oint-to-point these days. > Allowing cross-talk between devices on the same link raises a number of se= curity issues because malicious hosts can mount L2 attacks against other hos= ts on the network - for example, they can attempt to prevent other hosts fro= m forming IPv6 addresses by replying to DAD probes, they can send rogue RAs,= they can forge redirects, etc. Further, one of the primary motivations for this mechanism was to greatly re= duced ND traffic on links with lots of hosts, frequently many thousands of h= osts. It seems very unlikely you could facilitate this cross-talk communicat= ions without ND or a new protocol, supported by hosts, with more or less ver= y similar traffic characteristics as ND, therefore defeating one of the prim= ary purposes for the mechanism in the first place. If you want hosts on the same link to communicate directly, we already know h= ow to do that, use classic multiple host per prefix subnets. As I said befor= e this mechanism isn't intended as a universal replacement for classic subne= ts. David Farmer --Apple-Mail-DA84E33E-F02D-4F98-9A6B-024917AD8639 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    On Aug 23, 2017, at= 19:01, Lorenzo Colitti <lorenzo@go= ogle.com> wrote:

    On Thu, Aug 2= 4, 2017 at 7:00 AM, Templin, Fred L <Fred.L.Templin@boeing.com&g= t; wrote:
    With RFC7934, we already ha= ve BCP recommendations on host address availability
    With the advent of th= ese recommendations and practices, we see an operational
    advantage for hosts to discover the delegated prefixes of neighbors on the l= ink so
    that communications can go directly from peer to peer for better performance=
    and to reduce the load on routers.

    I'm not s= ure that would be generally useful, because:
    1. It only makes= sense if router load is a problem. That is unlikely to happen in many scena= rios, for example the common use case of a wifi network that hands out a /64= to every host. In such a deployment, the packets have to travel through the= AP anyway, and cross-talk is likely to be extremely limited compared to Int= ernet-bound traffic. Most network infrastructure is actually point-to-point t= hese days.
    2. Allowing cross-talk between devices on the same link rais= es a number of security issues because malicious hosts can mount L2 attacks a= gainst other hosts on the network - for example, they can attempt to prevent= other hosts from forming IPv6 addresses by replying to DAD probes, they can= send rogue RAs, they can forge redirects, etc.
    <= /div>
    Further, one of the primary motivations for thi= s mechanism was to greatly reduced ND traffic on links with lots of hosts, f= requently many thousands of hosts. It seems very unlikely you could facilita= te this cross-talk communications without ND or a new protocol, supported by= hosts, with more or less very similar traffic characteristics as ND, theref= ore defeating one of the primary purposes for the mechanism in the first pla= ce.

    If you want hosts on the same link to communica= te directly, we already know how to do that, use classic multiple host per p= refix subnets. As I said before this mechanism isn't intended as a universal= replacement for classic subnets.

    David Farmer

    = --Apple-Mail-DA84E33E-F02D-4F98-9A6B-024917AD8639-- From nobody Thu Aug 24 01:21:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF2132925 for ; Thu, 24 Aug 2017 01:21:40 -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 25QrCSMQPjQF for ; Thu, 24 Aug 2017 01:21:38 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF121321A0 for ; Thu, 24 Aug 2017 01:21:38 -0700 (PDT) Received: from h.hanazo.no (unknown [77.16.75.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 3125E2D5049; Thu, 24 Aug 2017 08:13:19 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DA59EFDB568C; Thu, 24 Aug 2017 10:13:15 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EEF065D8-5C3D-4A46-A26F-D903A15073F6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 24 Aug 2017 10:13:14 +0200 In-Reply-To: Cc: Lorenzo Colitti , james woodyatt , "v6ops@ietf.org" To: David Farmer References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 08:21:40 -0000 --Apple-Mail=_EEF065D8-5C3D-4A46-A26F-D903A15073F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L = wrote: >> With RFC7934, we already have BCP recommendations on host address = availability >> With the advent of these recommendations and practices, we see an = operational >> advantage for hosts to discover the delegated prefixes of neighbors = on the link so >> that communications can go directly from peer to peer for better = performance >> and to reduce the load on routers. >>=20 >> I'm not sure that would be generally useful, because: >> =E2=80=A2 It only makes sense if router load is a problem. That = is unlikely to happen in many scenarios, for example the common use case = of a wifi network that hands out a /64 to every host. In such a = deployment, the packets have to travel through the AP anyway, and = cross-talk is likely to be extremely limited compared to Internet-bound = traffic. Most network infrastructure is actually point-to-point these = days. >> =E2=80=A2 Allowing cross-talk between devices on the same link = raises a number of security issues because malicious hosts can mount L2 = attacks against other hosts on the network - for example, they can = attempt to prevent other hosts from forming IPv6 addresses by replying = to DAD probes, they can send rogue RAs, they can forge redirects, etc. > Further, one of the primary motivations for this mechanism was to = greatly reduced ND traffic on links with lots of hosts, frequently many = thousands of hosts. It seems very unlikely you could facilitate this = cross-talk communications without ND or a new protocol, supported by = hosts, with more or less very similar traffic characteristics as ND, = therefore defeating one of the primary purposes for the mechanism in the = first place. >=20 > If you want hosts on the same link to communicate directly, we already = know how to do that, use classic multiple host per prefix subnets. As I = said before this mechanism isn't intended as a universal replacement for = classic subnets. Indeed. The only difference is that host to host now happens at L3 = instead of L2. That hosts are on the same link is typically emulated at L2, we largely = stopped building shared media links in the 80s. ;-) This is just making the L3 topology reflect reality. Ole --Apple-Mail=_EEF065D8-5C3D-4A46-A26F-D903A15073F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZnoqbAAoJEL7aWKiYQt92ZjIP/iR9bpUEjlWKce1yg3Recf6E Ad0F4GY051Wr4eIQNGSsDY6OK/Ru98tc5nPrumt+bsPO5z2WsF7sBTuKUNoFUoXU nC5SB32IwuSGrBTKCbjd5Y2qdhKtYFLDSPZ9RMtVYJYmGnLoZRlBTEE9FQ2aVF5N wz2O+AmcCje9scI+TCMzChMCQczMLeLDmM6Dnf/Bx7OeXK1vircuKQ4zJEewfc8B bW5xT3afMVGvwFyMzx2S/Df2CtjAzV+vYd7zyLNy4CfK0XGzslIbInCBjVCwk++Z OSC/WP2T9EQP/2w+wx6dNuLv3GVXE1ZIv0qOFIOBIIqrsHI2J1v3ftr63DIcgRrC 5VEDV0p6VqJESrgF0AXT2Dcrsv7+liX8on66qYzanCUQXygv6YcYrjFli/iXj6mb Sf2UCon9VfGfSPbVuvTuGFiixHoeVMlvL9eGHZRk15dt+iBhAYNM4c67UayiYQ52 gnXt3w/IoF4UuCS2DO2wzzEKttp7Jt9JHHJt0v88FDQGhc/ay81Ky9crpzmpbNk1 MyvoP0m0Hv+13SeC0jCneGnL7u2B+PcD2pa4y0LwmTBuZPon8saZ8oZgIC1a5QPL l6c7tkmsVYSwM5LB7gWmWGbXazEviJoqIQQatyM//L0PFkG1XPCG23XXRtL6+U9k k4lQBwt0b0yHFaOv8kv7 =A+wb -----END PGP SIGNATURE----- --Apple-Mail=_EEF065D8-5C3D-4A46-A26F-D903A15073F6-- From nobody Thu Aug 24 03:18:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7F1132924 for ; Thu, 24 Aug 2017 03:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc5u3EYGRV7o for ; Thu, 24 Aug 2017 03:18:06 -0700 (PDT) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::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 D36D2132914 for ; Thu, 24 Aug 2017 03:18:05 -0700 (PDT) Received: by mail-ua0-x242.google.com with SMTP id c11so892049uad.3 for ; Thu, 24 Aug 2017 03:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=X8TFof52ku/+xTKSt/m6JQwuOx9+xaN6Ki6gKuoinVY=; b=q9V2Fmzppr0aSe2879MH7UK2Nrfd4o1EaCB8kDuAi62PViP/2UVKW/aDji1TK46C8x oSTnZZHCkRPidmxifH64oYcigbtW6YJiY4Xhs4N1nU3qygosDmR2ZRqtghXBOUMxsrj2 hw2kz8dIzEITJvn+xRnFvwZn6JyjW0ruhNM9/OGMxLn49HUOKjw8nS+sMnjqtXVbHOQU 9X/rAw4RLIsSi+0KF5rPrGvDiHWEm85qjLVzGr3gYCC4+1dprZZVjegA9ssyZrfdXoSj VT+rOfGUjTIAPQw+YV9K6tsTKnvqTgnWKSmTRWsWIecNrBHoVwDdVG9sZNyM+X6VW0nv TK9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=X8TFof52ku/+xTKSt/m6JQwuOx9+xaN6Ki6gKuoinVY=; b=FV+atchLXI7j7qiQJOW2xCmNCCN+/dDbfrgjBm0fOfJosk//e1s3Y7GY4jwaCxxlIK ANvqUPpviv42AUXZcRpWdo1xK3j1o8XQuUxLgy1oBZ/XLe7OUKam/2lleB+SJQuQi7PG 3h715+3sOtPgTQRTsvndl7fX3UvzwrbMpvoi+tmv/mBkYcp6k1JdRAT8lB14qjJ/GjNP nncLwpNjttmbSVJX9Z177LLu4IhqDI9aImx7UIacTaYetox2LAFDurCwfjPYDqTqVK64 k2nSujBs/uIpVCWXmsQaVsovIlNjk6D0yOqb/47c9eFdXwzvksi5wHxsdK4EZq/JrkCT Z/Wg== X-Gm-Message-State: AHYfb5iKRer5b9hKjZ2SNE2n3d6ymKBLDJscZWj+YHwTL8YFR1zPIzd5 JtGZrVMFVspJC1BEkQUyUCCofiBdfQ== X-Received: by 10.159.61.46 with SMTP id l46mr289668uai.53.1503569884871; Thu, 24 Aug 2017 03:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Thu, 24 Aug 2017 03:17:34 -0700 (PDT) From: Mark Smith Date: Thu, 24 Aug 2017 20:17:34 +1000 Message-ID: To: Ole Troan Cc: David Farmer , james woodyatt , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 10:18:08 -0000 On 24 August 2017 at 18:13, Ole Troan wrote: >>> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L wrote: >>> With RFC7934, we already have BCP recommendations on host address availability >>> With the advent of these recommendations and practices, we see an operational >>> advantage for hosts to discover the delegated prefixes of neighbors on the link so >>> that communications can go directly from peer to peer for better performance >>> and to reduce the load on routers. >> If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets. > > Indeed. The only difference is that host to host now happens at L3 instead of L2. > That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-) > This is just making the L3 topology reflect reality. > The trouble is that IPv6 by default doesn't really reflect that reality. Its link layer reachability assumptions are inconsistent. Per RFC5942, the link-local prefix is assumed to to be on-link, so link-local destinations are assumed to be directly reachable across the link, while all other prefixes are to be assumed off-link, so all other destinations have to be reached via a router. The link-local direct reachability assumption also exists is in the RFC6724 source/destination address selection algorithm, as link-local destinations are preferred over ULA and GUAs if there is a set of destinations to choose from. An a "private VLAN", this LL on-link/GUA/ULA off-link assumption could cause an end-user application problems. For pure IPv6, the LL connection attempt will have to fail before the ULA and/or GUA destinations are attempted, likely incurring end-user visible multi-second delays, and then they're likely to succeed because the router will trombone the traffic back onto the link to the destination. (i.e., Nodes A and B on same link, A -> B via LL fails, A -> RTR -> B via ULA/GUA succeeds). If the application is using Happy Eyeballs, the failure of the IPv6 LL would cause the IPv4 alternative to be used even though alternative ULA or GUA destinations would have probably worked immediately. Regards, Mark. From nobody Thu Aug 24 03:53:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B22132707 for ; Thu, 24 Aug 2017 03:53:50 -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 29ZGEkdT6iAv for ; Thu, 24 Aug 2017 03:53:49 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6500B1321C9 for ; Thu, 24 Aug 2017 03:53:49 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id q10so1487415pge.1 for ; Thu, 24 Aug 2017 03:53:49 -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=j47Ie2znnC/7dccTp2Am73hMVfbca0Mwo7yZI+XJw10=; b=kONML77ptPS3d4Numu92a0IRl9h0czJ8V6YJpquSfnLu7NG20BprTFWZaLePAw+dwO YiiMkjkG/DWzmSPTPUd8pLT755pRrUkpyomSg+J6CG6LWV9syoduVDmPwULKgcaf1d2u HPa3xpnt7pZq/0MHrKEVDj7cfx8IsyPabc8wzsFSgsET8FJXgaH2+0FXDMw8kXgPlz9c bFZILSTcBofja2VG10uCFwgcb3l8og3efLfIpeS3FqeGsmUczyjKb3eH4uy+cZG0St6g FXw61H37UIYhatWk+I/+Tnq2dDZWgkrcBltU/19E6SgdqTmycY4BGqZEP1T3T9qsszZs P60Q== 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=j47Ie2znnC/7dccTp2Am73hMVfbca0Mwo7yZI+XJw10=; b=kXPxIAmR92ARaTWma+NESFXvoHZQmpNRYLv3Q1+zneZeolREPNd86TW95W1y89WZZX pPuxDXgTy0WVlktNVUxy71NjlHBw6W/bAjMeoPH8EN6ntQQsP7Ml6FWb6AqRM4H9CwE5 8KXCY0IgWKAdK4WntDpcn5beClZkuLFmwqP/H88xIryy3R7Rf1tfphc2NavcjdMmO8sg erq5D20NjLtUjASM0eSJcRAjHNl+8VXBHQXcK3WotuZYEtYAp89mBJ0j9PRfMcbgVgwu n7dBNG17XQSmeBDINax5weZwnR6JpfxgsCXTyPQgAo1teQMDu4/RBV85f/H3WEkFloaG +unQ== X-Gm-Message-State: AHYfb5gmDhAke9Rjq15QraW7rwsMqam1kRcxsgPubUUFxluiwQfS/0AX SDGI0+pFbVsvog== X-Received: by 10.99.111.197 with SMTP id k188mr5743753pgc.431.1503572029024; Thu, 24 Aug 2017 03:53:49 -0700 (PDT) Received: from [112.167.24.163] ([112.167.24.163]) by smtp.gmail.com with ESMTPSA id g2sm7405451pgu.86.2017.08.24.03.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 03:53:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Thu, 24 Aug 2017 19:53:43 +0900 Cc: Ole Troan , "v6ops@ietf.org" , james woodyatt Content-Transfer-Encoding: quoted-printable Message-Id: <1098009C-8FCA-47A5-82E3-FA0B1F8F3857@gmail.com> References: To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 10:53:50 -0000 Questions for clarification: --- DY > On 24 Aug 2017, at 19:17, Mark Smith wrote: >=20 > Per RFC5942, the link-local prefix is assumed to to be on-link, Do you mean, by =E2=80=98link-local prefix', specifically the prefix = =E2=80=98FE80=E2=80=99 (1111 1110 1000) as specified in Sec. 2.4.6 of = RFC4291? > so link-local destinations are assumed to be directly reachable across > the link Do you mean, by =E2=80=98link-local destination=E2=80=99, the Link-Local = IPv6 Unicast Address as defined in Sec. 2.4.6. of RFC4291? From nobody Thu Aug 24 04:41:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9813293C for ; Thu, 24 Aug 2017 04:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvzeF2M9UqR9 for ; Thu, 24 Aug 2017 04:41:52 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51F813219B for ; Thu, 24 Aug 2017 04:41:51 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g36so1181926uaa.0 for ; Thu, 24 Aug 2017 04:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHK8MltG7wL+MbGNsSkGP1x2oFutfvdOl5yRDC7g3TA=; b=s52n1A3mhGDCku1cfgENTuNJPCkuOJ3W3zHjhP7M6z5emnQ1O7KbGHaJMiq0M8z8L3 EKtVge+sZRD1fSohib8XK7jrw4WsvLjyU2MyW4bANZcKjDzIYzEwa23UGYzNX7Swj4QJ XXnlI4XUX3PIV0RMrj8LEEKVa0pmKAXcAPXeyEH8/pr90mQIEsnAGfPR8T9AAwofXm0q ACu0B+AYJZOA9D0rg8cF0k5YGaZyKsf3JW49hpBDsNOBDqs1Lm0g3HazCTnTlhzMZ2K1 shBjyHxev/o+UKh2cxb3iDnt0zdMJhIMobW+qnLaIN9LWau3+8QoH+NQLaLQRQiJWIno OrSQ== 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=EHK8MltG7wL+MbGNsSkGP1x2oFutfvdOl5yRDC7g3TA=; b=lZiQg3cLIEvnClf303C99pqRUzqHbb8voCZYePcX2fkX/H67Ry+MT0A6fTHrp5EOeT CMEvQeMLtGgey+M4bl83NSjRtJUwzd5H/DYZ1K4zHyHcAV3PWa96sXvhVpX36UDe67lO lH3oLH97VaeUMzLadd0/y21EPZCCEYfNq0kXeYWJ4irg3hePsHYVBBIZGBuuFyg06Hec rKmj2ry7x9TCAslGiEHEro6uucQ21mQfhls8nsN3Xj+YX0SLrI9C2ZyHkQmO/YLWEMO0 bvr4YYLKMf4nsRcfV0axNJjr1W9FACg3MeqmYpyLuKmOoHQ1qKNT+/1Kga5W3/GrvlLJ rqTg== X-Gm-Message-State: AHYfb5hED/S+ICGKPZjN4HVz7jh6PtN8m2/v9RZV5STYF1pcUU2ZZbzW Bpw66f3K/uVAd3tCcuQZLBJem5l/dA== X-Received: by 10.176.76.92 with SMTP id d28mr4503598uag.116.1503574910956; Thu, 24 Aug 2017 04:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Thu, 24 Aug 2017 04:41:20 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Thu, 24 Aug 2017 21:41:20 +1000 Message-ID: To: Ole Troan Cc: "v6ops@ietf.org" , james woodyatt Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 11:41:54 -0000 On 24 August 2017 at 20:17, Mark Smith wrote: > On 24 August 2017 at 18:13, Ole Troan wrote: >>>> On Thu, Aug 24, 2017 at 7:00 AM, Templin, Fred L wrote: >>>> With RFC7934, we already have BCP recommendations on host address availability >>>> With the advent of these recommendations and practices, we see an operational >>>> advantage for hosts to discover the delegated prefixes of neighbors on the link so >>>> that communications can go directly from peer to peer for better performance >>>> and to reduce the load on routers. > > > >>> If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets. >> >> Indeed. The only difference is that host to host now happens at L3 instead of L2. >> That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-) >> This is just making the L3 topology reflect reality. >> > > The trouble is that IPv6 by default doesn't really reflect that > reality. Its link layer reachability assumptions are inconsistent. > > Per RFC5942, the link-local prefix is assumed to to be on-link, so > link-local destinations are assumed to be directly reachable across > the link, while all other prefixes are to be assumed off-link, so all > other destinations have to be reached via a router. > By default I mean. The RA PIO L flag changes the off-link assumption for other non-LL on-link prefixes if set for them in the corresponding RA PIOs. It isn't possible to invert the LL on-link assumption so that LL destinations that are also on the same link are then reachable via a router on the link. > The link-local direct reachability assumption also exists is in the > RFC6724 source/destination address selection algorithm, as link-local > destinations are preferred over ULA and GUAs if there is a set of > destinations to choose from. > > An a "private VLAN", this LL on-link/GUA/ULA off-link assumption could > cause an end-user application problems. For pure IPv6, the LL > connection attempt will have to fail before the ULA and/or GUA > destinations are attempted, likely incurring end-user visible > multi-second delays, and then they're likely to succeed because the > router will trombone the traffic back onto the link to the > destination. (i.e., Nodes A and B on same link, A -> B via LL fails, A > -> RTR -> B via ULA/GUA succeeds). > > If the application is using Happy Eyeballs, the failure of the IPv6 LL > would cause the IPv4 alternative to be used even though alternative > ULA or GUA destinations would have probably worked immediately. > > Regards, > Mark. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 24 04:51:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABFE13219B for ; Thu, 24 Aug 2017 04:50:59 -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 qWMgZA9Vt4zt for ; Thu, 24 Aug 2017 04:50:58 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A835E126C7A for ; Thu, 24 Aug 2017 04:50:58 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id q10so2220724pge.1 for ; Thu, 24 Aug 2017 04:50:58 -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=YURcBuz5WugymxiTK0yhkYyq2cilDmMiaYdO2Fj+Fmw=; b=GFfLk3b1TOpPZN6PQ+0ijZHbw4xfw+QcZGnhV95UVhreWSRMbRRm9WBXvZq5M7RCFs 4tuJcQWRvMJinHtGlLoKXVFNkFE+Doe3nL2t5auQf2psfoMzeZ55Te3C4CIQCiM1IzIh pNL7v/Zt8L06zypBX1m+dqWJTfcuTZGTpnzPIHWkywOlvWG5+NWHuJj1UB0HurLbk9JM sZyt9WoLMHW/4jno2U8IvE1Vs9smTNneVtArwrdzGybluiuK0MUGcEPutKNJMFGPBBfg Sez1dsiq2Bx+EuNk/juy7WbMrKbtydDAOO5IYiNEib3RkEsz3aV6wFMxISUAKxGNNvTR d0LA== 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=YURcBuz5WugymxiTK0yhkYyq2cilDmMiaYdO2Fj+Fmw=; b=IHALInofu/lix3q970Dw88jZGQiboroluaXCBT3KjH6/zZBrHOg1aVMewzsOg1RcQl k/s4SC0aedxTyD47adQl4BpAZr5YdNuYZ030M8aoY5abFudBj1QAr0dps5t2l4yJXuB0 MT2wnoKvF5lxnaBN3x4AxLTEbYcARwpkd6/9siiTktW0GhHhQMUsd5xsreewjXVGEeAm x3g16HRbMRF6vXLjqBQhUwllThHgL63hjnXp1aDar/IxjKlFU9RLZBrbMHTZ/PdZ3FKe yTPmgsqJW5Tx+3NZs4V2nIAp/vZZpJ4FaL5dUSkJLFQr7IjilmjOnUjQSIouANslNFYT weAA== X-Gm-Message-State: AHYfb5jbHTeYsf6EPSTN0hPW8Ub2TJOeoMUtaQ4HySanKnuGTsm4O+7E TNX4T4zBxvPH7A== X-Received: by 10.99.157.204 with SMTP id i195mr6002091pgd.101.1503575458292; Thu, 24 Aug 2017 04:50:58 -0700 (PDT) Received: from [112.167.24.163] ([112.167.24.163]) by smtp.gmail.com with ESMTPSA id l24sm7502806pgu.91.2017.08.24.04.50.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 04:50:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Thu, 24 Aug 2017 20:50:53 +0900 Cc: Ole Troan , james woodyatt , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> References: To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 11:51:00 -0000 A typo=E2=80=A6? Did you mean to say: "LL destinations that are also on the same link are then directly = reachable.=E2=80=9D --- DY > On 24 Aug 2017, at 20:41, Mark Smith wrote: >=20 > It isn't possible to invert the LL on-link assumption so that > LL destinations that are also on the same link are then reachable via > a router on the link. From nobody Thu Aug 24 05:12:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963331326AA for ; Thu, 24 Aug 2017 05:12: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMZ6gXb4slHd for ; Thu, 24 Aug 2017 05:12:42 -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 72A10132223 for ; Thu, 24 Aug 2017 05:12:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id E02A61A071 for ; Thu, 24 Aug 2017 12:12:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Thu, 24 Aug 2017 13:12:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 12:12:44 -0000 Ole Troan wrote: >> If you want hosts on the same link to communicate directly, we = already know how to do that, use classic multiple host per prefix = subnets. As I said before this mechanism isn't intended as a universal = replacement for classic subnets. >=20 > Indeed. The only difference is that host to host now happens at L3 = instead of L2. > That hosts are on the same link is typically emulated at L2, we = largely stopped building shared media links in the 80s. ;-) > This is just making the L3 topology reflect reality. You seem to be confusing shared media with broadcast domain. The fact = that we now use L2 switching (ie no longer a shared media) doesn't = affect the fact that the broadcast domain is now (excepting deliberate = filtering) the same. Just switching from shared media (eg 10base2 and = 10base5) to switched media (10/100/1000baseT) hasn't moved anything = between L2 and L3 - again, absent adding features such as filtering to = actively prevent the normal L2-L2 process. From nobody Thu Aug 24 07:49:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2450132964 for ; Thu, 24 Aug 2017 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqv2zPGPZTE3 for ; Thu, 24 Aug 2017 07:49:12 -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 70EF3132962 for ; Thu, 24 Aug 2017 07:49:12 -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 v7OEnB2C056629; Thu, 24 Aug 2017 07:49:11 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OEn6Vv056543 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 07:49:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 07:49:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 07:49:05 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" , james woodyatt Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegATBg4AAA+87oA= Date: Thu, 24 Aug 2017 14:49:05 +0000 Message-ID: References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b48b91ac692c4d468118c4622343b957XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:49:15 -0000 --_000_b48b91ac692c4d468118c4622343b957XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCsOYICAxLiBJdCBvbmx5IG1ha2VzIHNlbnNlIGlmIHJvdXRlciBsb2FkIGlz IGEgcHJvYmxlbS4NCk5vLCBpdCBhbHNvIG1ha2VzIHNlbnNlIGlmIHRoZSBwZXJmb3JtYW5jZSBi ZXR3ZWVuIHBlZXItdG8tcGVlciBpcyBzaWduaWZpY2FudGx5IGdyZWF0ZXINCnRoYW4gZnJvbSBw ZWVyLXRvLXJvdXRlci10by1wZWVyLiBGb3IgaW5zdGFuY2UsIHRoZSByb3V0ZXIgY291bGQgYmUg bG9jYXRlZCBmYXIgYXdheSBmcm9tDQplaXRoZXIgcGVlciBvbiB2ZXJ5IGxhcmdlIGxpbmtzLg0K w5ggIFRoYXQgaXMgdW5saWtlbHkgdG8gaGFwcGVuIGluIG1hbnkgc2NlbmFyaW9zLCBmb3IgZXhh bXBsZSB0aGUgY29tbW9uIHVzZSBjYXNlIG9mIGEgd2lmaSBuZXR3b3JrIHRoYXQgaGFuZHMgb3V0 IGEgLzY0IHRvIGV2ZXJ5IGhvc3QuIEluIHN1Y2ggYSBkZXBsb3ltZW50LCB0aGUgcGFja2V0cyBo YXZlIHRvIHRyYXZlbCB0aHJvdWdoIHRoZSBBUCBhbnl3YXkNCk9uIHZlcnkgbGFyZ2UgV2lGaSBk ZXBsb3ltZW50cywgdGhlcmUgbWF5IGJlIG1hbnkgQVBzIGFuZCB0aGUgcm91dGVyIGZ1bmN0aW9u DQptYXkgYmUgbG9jYXRlZCBvbiBhIFdpcmVsZXNzIExBTiBjb250cm9sbGVyIGZhciBhd2F5IGZy b20gdGhlIEFQcy4NCsOYICBhbmQgY3Jvc3MtdGFsayBpcyBsaWtlbHkgdG8gYmUgZXh0cmVtZWx5 IGxpbWl0ZWQgY29tcGFyZWQgdG8gSW50ZXJuZXQtYm91bmQgdHJhZmZpYy4gTW9zdCBuZXR3b3Jr IGluZnJhc3RydWN0dXJlIGlzIGFjdHVhbGx5IHBvaW50LXRvLXBvaW50IHRoZXNlIGRheXMuDQpJ IHRoaW5rIHlvdSBhcmUgbWFraW5nIGEgZ2VuZXJhbGl6YXRpb24gYmFzZWQgb24gYSBsaW1pdGVk IGFzc3VtcHRpb25zIG9mIHRoZQ0KdHlwZXMgb2YgdXNlIGNhc2VzLiBQZWVyLXRvLXBlZXIgaXMg Z29pbmcgdG8gYmUgdXNlZnVsIGZvciB1c2UgY2FzZXMgc3VjaCBhcw0KZW50ZXJwcmlzZSBtb2Jp bGUgZGV2aWNlIHVzZXJzLCB3aXJlbGVzcyBMQU4gdXNlcnMsIGFlcm9uYXV0aWNhbCBjb21tdW5p Y2F0aW9ucw0KYmV0d2VlbiBhaXJjcmFmdCBhbmQgYWlyIHRyYWZmaWMgY29udHJvbGxlcnMsIGV0 Yy4gVGhpcyBmdW5jdGlvbiBpcyB0YXJnZXRlZCB0byBhbnkNCmxpbmsgdGhhdCBjYW4gcnVuIElQ djYgTkQsIGFuZCB0aGVyZSBhcmUgbWFueSB1c2UgY2FzZXMgZm9yIGxhcmdlIHNoYXJlZCBsaW5r cw0Kd2l0aCBtYW55IG5vZGVzIHRoYXQgbmVlZCB0byBjb21tdW5pY2F0ZSBwZWVyLXRvLXBlZXIu DQoNCsOYICAyLiBBbGxvd2luZyBjcm9zcy10YWxrIGJldHdlZW4gZGV2aWNlcyBvbiB0aGUgc2Ft ZSBsaW5rIHJhaXNlcyBhIG51bWJlciBvZiBzZWN1cml0eSBpc3N1ZXMNClRoZSBzZWN1cml0eSBp c3N1ZXMgYXJlIHRoZSBzYW1lIGFzIGZvciBzdGFuZGFyZCBJUHY2IE5EIFJlZGlyZWN0LiBUaGlz IGZ1bmN0aW9uIGlzDQp1c2VmdWwgd2hlbiB0aGUgUmVkaXJlY3QgYXBwbGllcyB0byBhbiBlbnRp cmUgcHJlZml4IGluc3RlYWQgb2YgYSBzaW5nbGV0b24gYWRkcmVzcy4NCg0Kw5ggIGJlY2F1c2Ug bWFsaWNpb3VzIGhvc3RzIGNhbiBtb3VudCBMMiBhdHRhY2tzIGFnYWluc3Qgb3RoZXIgaG9zdHMg b24gdGhlIG5ldHdvcmsgLSBmb3IgZXhhbXBsZSwgdGhleSBjYW4gYXR0ZW1wdCB0byBwcmV2ZW50 IG90aGVyIGhvc3RzIGZyb20gZm9ybWluZyBJUHY2IGFkZHJlc3NlcyBieSByZXBseWluZyB0byBE QUQgcHJvYmVzLCB0aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhleSBjYW4gZm9yZ2UgcmVkaXJl Y3RzLCBldGMuDQpZb3UgYXJlIGVudW1lcmF0aW5nIGlzc3VlcyB3aXRoIElQdjYgTkQgdGhhdCBo YXZlIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzDQpmdW5jdGlvbi4gQWxsIG9mIHRoZSBzZWN1cmlu ZyBjb25jZXJucyB5b3UgYXJlIGNpdGluZyBwZXJ0YWluIHRvIElQdjYgTkQgb24NCmFueSBsaW5r IHR5cGUsIGFuZCBub3QganVzdCB0aG9zZSB0aGF0IGVtcGxveSB0aGlzIGZ1bmN0aW9uLg0KDQpU aGFua3MgLSBGcmVkDQoNCg0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3Jlbnpv QGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyMywgMjAxNyA1OjAxIFBNDQpU bzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IHY2b3Bz QGlldGYub3JnOyBqYW1lcyB3b29keWF0dCA8amh3QGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVlIElQdjYgcHJlZml4ZXMgcGVyIGhvc3QN Cg0KT24gVGh1LCBBdWcgMjQsIDIwMTcgYXQgNzowMCBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4g d3JvdGU6DQpXaXRoIFJGQzc5MzQsIHdlIGFscmVhZHkgaGF2ZSBCQ1AgcmVjb21tZW5kYXRpb25z IG9uIGhvc3QgYWRkcmVzcyBhdmFpbGFiaWxpdHkNCldpdGggdGhlIGFkdmVudCBvZiB0aGVzZSBy ZWNvbW1lbmRhdGlvbnMgYW5kIHByYWN0aWNlcywgd2Ugc2VlIGFuIG9wZXJhdGlvbmFsDQphZHZh bnRhZ2UgZm9yIGhvc3RzIHRvIGRpc2NvdmVyIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ZXMgb2YgbmVp Z2hib3JzIG9uIHRoZSBsaW5rIHNvDQp0aGF0IGNvbW11bmljYXRpb25zIGNhbiBnbyBkaXJlY3Rs eSBmcm9tIHBlZXIgdG8gcGVlciBmb3IgYmV0dGVyIHBlcmZvcm1hbmNlDQphbmQgdG8gcmVkdWNl IHRoZSBsb2FkIG9uIHJvdXRlcnMuDQoNCkknbSBub3Qgc3VyZSB0aGF0IHdvdWxkIGJlIGdlbmVy YWxseSB1c2VmdWwsIGJlY2F1c2U6DQoNCiAgMS4gIEl0IG9ubHkgbWFrZXMgc2Vuc2UgaWYgcm91 dGVyIGxvYWQgaXMgYSBwcm9ibGVtLiBUaGF0IGlzIHVubGlrZWx5IHRvIGhhcHBlbiBpbiBtYW55 IHNjZW5hcmlvcywgZm9yIGV4YW1wbGUgdGhlIGNvbW1vbiB1c2UgY2FzZSBvZiBhIHdpZmkgbmV0 d29yayB0aGF0IGhhbmRzIG91dCBhIC82NCB0byBldmVyeSBob3N0LiBJbiBzdWNoIGEgZGVwbG95 bWVudCwgdGhlIHBhY2tldHMgaGF2ZSB0byB0cmF2ZWwgdGhyb3VnaCB0aGUgQVAgYW55d2F5LCBh bmQgY3Jvc3MtdGFsayBpcyBsaWtlbHkgdG8gYmUgZXh0cmVtZWx5IGxpbWl0ZWQgY29tcGFyZWQg dG8gSW50ZXJuZXQtYm91bmQgdHJhZmZpYy4gTW9zdCBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGlz IGFjdHVhbGx5IHBvaW50LXRvLXBvaW50IHRoZXNlIGRheXMuDQogIDIuICBBbGxvd2luZyBjcm9z cy10YWxrIGJldHdlZW4gZGV2aWNlcyBvbiB0aGUgc2FtZSBsaW5rIHJhaXNlcyBhIG51bWJlciBv ZiBzZWN1cml0eSBpc3N1ZXMgYmVjYXVzZSBtYWxpY2lvdXMgaG9zdHMgY2FuIG1vdW50IEwyIGF0 dGFja3MgYWdhaW5zdCBvdGhlciBob3N0cyBvbiB0aGUgbmV0d29yayAtIGZvciBleGFtcGxlLCB0 aGV5IGNhbiBhdHRlbXB0IHRvIHByZXZlbnQgb3RoZXIgaG9zdHMgZnJvbSBmb3JtaW5nIElQdjYg YWRkcmVzc2VzIGJ5IHJlcGx5aW5nIHRvIERBRCBwcm9iZXMsIHRoZXkgY2FuIHNlbmQgcm9ndWUg UkFzLCB0aGV5IGNhbiBmb3JnZSByZWRpcmVjdHMsIGV0Yy4NCg== --_000_b48b91ac692c4d468118c4622343b957XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTQyMDE1MzI0Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTYwNjE3Nzg2IDg5NjU2MjA0MiA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjc3OTAyNzgyMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU3NzUw MTI2Mjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNzM1NjIwMTg4Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNTc3NTAxMjYyO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE3Nzc2MDI0 NTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01Nzc1MDEyNjI7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+MS4gSXQgb25seSBtYWtlcyBzZW5zZSBpZiByb3V0ZXIg bG9hZCBpcyBhIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjoj MkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+Tm8sIGl0IGFsc28g bWFrZXMgc2Vuc2UgaWYgdGhlIHBlcmZvcm1hbmNlIGJldHdlZW4gcGVlci10by1wZWVyIGlzIHNp Z25pZmljYW50bHkgZ3JlYXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxs LWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj50aGFu IGZyb20gcGVlci10by1yb3V0ZXItdG8tcGVlci4gRm9yIGluc3RhbmNlLCB0aGUgcm91dGVyIGNv dWxkIGJlIGxvY2F0ZWQgZmFyIGF3YXkgZnJvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0 ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAw LjAlIj5laXRoZXIgcGVlciBvbiB2ZXJ5IGxhcmdlIGxpbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhhdCBpcyB1bmxpa2Vs eSB0byBoYXBwZW4gaW4gbWFueSBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHRoZSBjb21tb24gdXNl IGNhc2Ugb2YgYSB3aWZpIG5ldHdvcmsgdGhhdCBoYW5kcyBvdXQgYSAvNjQgdG8gZXZlcnkgaG9z dC4gSW4gc3VjaCBhIGRlcGxveW1lbnQsIHRoZSBwYWNrZXRzIGhhdmUgdG8gdHJhdmVsIHRocm91 Z2ggdGhlIEFQIGFueXdheTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk9uIHZlcnkgbGFyZ2UgV2lGaSBkZXBsb3ltZW50cywg dGhlcmUgbWF5IGJlIG1hbnkgQVBzIGFuZCB0aGUgcm91dGVyIGZ1bmN0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPm1heSBiZSBsb2NhdGVkIG9uIGEgV2lyZWxlc3MgTEFOIGNvbnRyb2xsZXIgZmFyIGF3YXkg ZnJvbSB0aGUgQVBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+YW5kIGNyb3NzLXRhbGsgaXMgbGlrZWx5IHRvIGJlIGV4dHJlbWVs eSBsaW1pdGVkIGNvbXBhcmVkIHRvIEludGVybmV0LWJvdW5kIHRyYWZmaWMuIE1vc3QgbmV0d29y ayBpbmZyYXN0cnVjdHVyZSBpcyBhY3R1YWxseSBwb2ludC10by1wb2ludCB0aGVzZSBkYXlzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPkkgdGhpbmsgeW91IGFyZSBtYWtpbmcgYSBnZW5lcmFsaXphdGlvbiBiYXNlZCBvbiBh IGxpbWl0ZWQgYXNzdW1wdGlvbnMgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnR5cGVzIG9mIHVzZSBj YXNlcy4gUGVlci10by1wZWVyIGlzIGdvaW5nIHRvIGJlIHVzZWZ1bCBmb3IgdXNlIGNhc2VzIHN1 Y2ggYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+ZW50ZXJwcmlzZSBtb2JpbGUgZGV2aWNlIHVzZXJzLCB3aXJl bGVzcyBMQU4gdXNlcnMsIGFlcm9uYXV0aWNhbCBjb21tdW5pY2F0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5iZXR3ZWVuIGFpcmNyYWZ0IGFuZCBhaXIgdHJhZmZpYyBjb250cm9sbGVycywgZXRjLiBUaGlz IGZ1bmN0aW9uIGlzIHRhcmdldGVkIHRvIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5saW5rIHRoYXQgY2Fu IHJ1biBJUHY2IE5ELCBhbmQgdGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIGZvciBsYXJnZSBzaGFy ZWQgbGlua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+d2l0aCBtYW55IG5vZGVzIHRoYXQgbmVlZCB0byBjb21t dW5pY2F0ZSBwZWVyLXRvLXBlZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oldpbmdk aW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjIuIEFsbG93aW5nIGNyb3NzLXRhbGsgYmV0d2VlbiBkZXZpY2VzIG9u IHRoZSBzYW1lIGxpbmsgcmFpc2VzIGEgbnVtYmVyIG9mIHNlY3VyaXR5IGlzc3VlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PlRoZSBzZWN1cml0eSBpc3N1ZXMgYXJlIHRoZSBzYW1lIGFzIGZvciBzdGFuZGFyZCBJUHY2IE5E IFJlZGlyZWN0LiBUaGlzIGZ1bmN0aW9uIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnVzZWZ1bCB3aGVuIHRo ZSBSZWRpcmVjdCBhcHBsaWVzIHRvIGFuIGVudGlyZSBwcmVmaXggaW5zdGVhZCBvZiBhIHNpbmds ZXRvbiBhZGRyZXNzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPmJlY2F1c2UgbWFsaWNpb3VzIGhvc3RzIGNhbiBtb3VudCBMMiBhdHRhY2tzIGFn YWluc3Qgb3RoZXIgaG9zdHMgb24gdGhlIG5ldHdvcmsgLSBmb3IgZXhhbXBsZSwgdGhleSBjYW4g YXR0ZW1wdCB0byBwcmV2ZW50IG90aGVyIGhvc3RzIGZyb20gZm9ybWluZyBJUHY2IGFkZHJlc3Nl cyBieSByZXBseWluZyB0byBEQUQgcHJvYmVzLCB0aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhl eSBjYW4gZm9yZ2UNCiByZWRpcmVjdHMsIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Zb3UgYXJlIGVudW1lcmF0aW5n IGlzc3VlcyB3aXRoIElQdjYgTkQgdGhhdCBoYXZlIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPmZ1bmN0aW9uLiBBbGwgb2YgdGhlIHNlY3VyaW5nIGNvbmNlcm5zIHlvdSBh cmUgY2l0aW5nIHBlcnRhaW4gdG8gSVB2NiBORCBvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5hbnkgbGluayB0 eXBlLCBhbmQgbm90IGp1c3QgdGhvc2UgdGhhdCBlbXBsb3kgdGhpcyBmdW5jdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxv cmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAy MywgMjAxNyA1OjAxIFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzsg amFtZXMgd29vZHlhdHQgJmx0O2pod0Bnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3Y2b3BzXSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVlIElQdjYgcHJlZml4ZXMgcGVy IGhvc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNCwgMjAxNyBhdCA3OjAwIEFNLCBUZW1wbGlu LCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0 YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggUkZD NzkzNCwgd2UgYWxyZWFkeSBoYXZlIEJDUCByZWNvbW1lbmRhdGlvbnMgb24gaG9zdCBhZGRyZXNz IGF2YWlsYWJpbGl0eTxicj4NCldpdGggdGhlIGFkdmVudCBvZiB0aGVzZSByZWNvbW1lbmRhdGlv bnMgYW5kIHByYWN0aWNlcywgd2Ugc2VlIGFuIG9wZXJhdGlvbmFsPGJyPg0KYWR2YW50YWdlIGZv ciBob3N0cyB0byBkaXNjb3ZlciB0aGUgZGVsZWdhdGVkIHByZWZpeGVzIG9mIG5laWdoYm9ycyBv biB0aGUgbGluayBzbzxicj4NCnRoYXQgY29tbXVuaWNhdGlvbnMgY2FuIGdvIGRpcmVjdGx5IGZy b20gcGVlciB0byBwZWVyIGZvciBiZXR0ZXIgcGVyZm9ybWFuY2U8YnI+DQphbmQgdG8gcmVkdWNl IHRoZSBsb2FkIG9uIHJvdXRlcnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUgdGhhdCB3b3VsZCBiZSBnZW5l cmFsbHkgdXNlZnVsLCBiZWNhdXNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9s IHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzQiPg0KSXQgb25seSBtYWtlcyBzZW5zZSBpZiByb3V0ZXIgbG9hZCBpcyBhIHBy b2JsZW0uIFRoYXQgaXMgdW5saWtlbHkgdG8gaGFwcGVuIGluIG1hbnkgc2NlbmFyaW9zLCBmb3Ig ZXhhbXBsZSB0aGUgY29tbW9uIHVzZSBjYXNlIG9mIGEgd2lmaSBuZXR3b3JrIHRoYXQgaGFuZHMg b3V0IGEgLzY0IHRvIGV2ZXJ5IGhvc3QuIEluIHN1Y2ggYSBkZXBsb3ltZW50LCB0aGUgcGFja2V0 cyBoYXZlIHRvIHRyYXZlbCB0aHJvdWdoIHRoZSBBUCBhbnl3YXksIGFuZA0KIGNyb3NzLXRhbGsg aXMgbGlrZWx5IHRvIGJlIGV4dHJlbWVseSBsaW1pdGVkIGNvbXBhcmVkIHRvIEludGVybmV0LWJv dW5kIHRyYWZmaWMuIE1vc3QgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBpcyBhY3R1YWxseSBwb2lu dC10by1wb2ludCB0aGVzZSBkYXlzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij4NCkFsbG93aW5nIGNyb3NzLXRhbGsgYmV0d2Vl biBkZXZpY2VzIG9uIHRoZSBzYW1lIGxpbmsgcmFpc2VzIGEgbnVtYmVyIG9mIHNlY3VyaXR5IGlz c3VlcyBiZWNhdXNlIG1hbGljaW91cyBob3N0cyBjYW4gbW91bnQgTDIgYXR0YWNrcyBhZ2FpbnN0 IG90aGVyIGhvc3RzIG9uIHRoZSBuZXR3b3JrIC0gZm9yIGV4YW1wbGUsIHRoZXkgY2FuIGF0dGVt cHQgdG8gcHJldmVudCBvdGhlciBob3N0cyBmcm9tIGZvcm1pbmcgSVB2NiBhZGRyZXNzZXMgYnkg cmVwbHlpbmcNCiB0byBEQUQgcHJvYmVzLCB0aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhleSBj YW4gZm9yZ2UgcmVkaXJlY3RzLCBldGMuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b48b91ac692c4d468118c4622343b957XCH150608nwnosboeingcom_-- From nobody Thu Aug 24 07:53:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BEF132962 for ; Thu, 24 Aug 2017 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPD9FjDeyw_L for ; Thu, 24 Aug 2017 07:53:57 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30BE1329AB for ; Thu, 24 Aug 2017 07:53:56 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 77so2986571iou.3 for ; Thu, 24 Aug 2017 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e24mfk2l15GpvkooL152fmwNwkrVefy6DwzHofJtxrA=; b=aKFYFJMvnmKfBVdMSj1h7RESvJcYqSVNfbdEL7Uh3Up6hpmGRTPQUbIm7/gJRVlC2S K2Kl3MLcxMiK2ujQhrGdUs+nQeWZeLv08S79pPUXAs2fT1fuVihmqatTDiBx6JVM1nsp EJt39xOyh7qNf7tmSoeueLbs9/fpksB8RVtLeh7Fdj8W3zvds/sGXjlF6sLslxIX+uJU gx2CHsI5chumqaY/XDJ1M+HLue9l95UpIEzP+S8EI9X8+vXR90abTb75z/mb6wQYhADA /HZK9ErR1f8Z3if0WDG6i0LlSvpZb05A4rN78TB5obBV5TJOgTSKXHHUWePMYGwHcjeQ bKqw== 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=e24mfk2l15GpvkooL152fmwNwkrVefy6DwzHofJtxrA=; b=oxsZWSPSvFuogJz9VaI6leRS5TxwXDydRY8lmArkYKdx6tCbX4RFEuC5neJ05EuJV2 cE8qoqZj+GrJ67xzoo9ji/5yf1adpZdo8h38xdzfUYJEBDY/IXrqBpHmaE5k9HQDZ2+g Zspk6/dLZo1XokHmc8Al9tAnUXf9VE0wrZhyJsY/0N/1wNJW7VaSF/2hi73s5Eswfy1q kEeknHjMNNEtdh1qxQvQL1mhNvLMNoU4M9IQXOsSsBgDuuw/PXim7/w4IoPxVzSht3Cr BEbbr1B5WGPxQPcNsFgjSdhe23d5ZGTrGSOMQ9g5qP3segysIwP/b4FKXO/VPMKZChgU ygFw== X-Gm-Message-State: AHYfb5gVG+L+nmgCEztFgNN6afiCv4n62vID7oizuk/r05quLFyJ6TAf 7/Alw3ieYDQPxJQ1DTf8TYHLcP4KW1kG X-Google-Smtp-Source: ADKCNb5uE9jLPMN8+1K03rp43lfLbllYv0gDNZu04Z8u//Fv7r/LzVr6vnoCUXTMdM3+QamEq5HnccajZdv+cnmdXAk= X-Received: by 10.107.48.21 with SMTP id w21mr6471178iow.12.1503586435935; Thu, 24 Aug 2017 07:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 24 Aug 2017 07:53:35 -0700 (PDT) In-Reply-To: References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 24 Aug 2017 23:53:35 +0900 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , james woodyatt Content-Type: multipart/alternative; boundary="001a1144412867d9b7055780ff44" Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:53:58 -0000 --001a1144412867d9b7055780ff44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2017 at 11:49 PM, Templin, Fred L wrote: > No, it also makes sense if the performance between peer-to-peer is > significantly greater > > than from peer-to-router-to-peer. For instance, the router could be > located far away from > > either peer on very large links. > I didn't say it was impossible, I just said it's unlikely. > =C3=98 That is unlikely to happen in many scenarios, for example the com= mon > use case of a wifi network that hands out a /64 to every host. In such a > deployment, the packets have to travel through the AP anyway > > On very large WiFi deployments, there may be many APs and the router > function > > may be located on a Wireless LAN controller far away from the APs. > ... which are very likely to be connected using fiber links that are much faster and more reliable than the wifi link itself. > =C3=98 because malicious hosts can mount L2 attacks against other hosts = on > the network - for example, they can attempt to prevent other hosts from > forming IPv6 addresses by replying to DAD probes, they can send rogue RAs= , > they can forge redirects, etc. > > You are enumerating issues with IPv6 ND that have nothing to do with this > > function. All of the securing concerns you are citing pertain to IPv6 ND = on > > any link type, and not just those that employ this function. > Actually, they do have a lot to do with this function. One of the major advantages of assigning a distinct prefix per host is *precisely* the avoidance of these security issues. You're proposing bringing them back again. --001a1144412867d9b7055780ff44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= hu, Aug 24, 2017 at 11:49 PM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

    No, it also mak= es sense if the performance between peer-to-peer is significantly greater

    than from peer-to-rout= er-to-peer. For instance, the router could be located far away from<= u>

    either peer on very la= rge links.


    I didn= 9;t say it was impossible, I just said it's unlikely.
    =C2=A0<= /div>

    =C3=98=C2=A0 That is unlikely to happen in many scenarios, f= or example the common use case of a wifi network that hands out a /64 to ev= ery host. In such a deployment, the packets have to travel through the AP a= nyway

    On very large WiFi dep= loyments, there may be many APs and the router function

    may be located on a Wi= reless LAN controller far away from the APs.


    ... which are very likely to be connected using fi= ber links that are much faster and more reliable than the wifi link itself.=

    =C3=98=C2=A0 because malicious hosts can mount L2 attacks ag= ainst other hosts on the network - for example, they can attempt to prevent= other hosts from forming IPv6 addresses by replying to DAD probes, they ca= n send rogue RAs, they can forge redirects, etc.

    You are enumerating is= sues with IPv6 ND that have nothing to do with this

    function. All of the s= ecuring concerns you are citing pertain to IPv6 ND on<= /p>

    any link type, and not= just those that employ this function.

    <= div>
    Actually, they do have a lot to do with this function. O= ne of the major advantages of assigning a distinct prefix per host is *prec= isely* the avoidance of these security issues. You're proposing bringin= g them back again.
    --001a1144412867d9b7055780ff44-- From nobody Thu Aug 24 07:57:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F025C132962 for ; Thu, 24 Aug 2017 07:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUt7HuAuIINy for ; Thu, 24 Aug 2017 07:57:33 -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 7CAEC132940 for ; Thu, 24 Aug 2017 07:57:33 -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 v7OEvXAf056188; Thu, 24 Aug 2017 07:57:33 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OEvTxv056132 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 07:57:29 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 07:57:28 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 07:57:28 -0700 From: "Templin, Fred L" To: David Farmer , Lorenzo Colitti CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegATBg4AAAIjeAAADjVoAA== Date: Thu, 24 Aug 2017 14:57:28 +0000 Message-ID: <0eb44f4890234a8888159c1e222f5d54@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_0eb44f4890234a8888159c1e222f5d54XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:57:36 -0000 --_000_0eb44f4890234a8888159c1e222f5d54XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCg0Kw5ggIEZ1cnRoZXIsIG9uZSBvZiB0aGUgcHJpbWFyeSBtb3RpdmF0aW9u cyBmb3IgdGhpcyBtZWNoYW5pc20gd2FzIHRvIGdyZWF0bHkgcmVkdWNlZCBORCB0cmFmZmljIG9u IGxpbmtzIHdpdGggbG90cyBvZiBob3N0cywgZnJlcXVlbnRseSBtYW55IHRob3VzYW5kcyBvZiBo b3N0cy4NCg0KWWVzLCBsYXJnZSBsaW5rcyB3aXRoIG1hbnkgaG9zdHMg4oCTIHRob3VzYW5kcyBv ciBtb3JlLiBCdXQsIGl0IGFsc28gYXBwbGllcyB0byBhbnkNCmxpbmsgdHlwZSBhbmQgbm90IGp1 c3QgaHVnZSBvbmVzLg0KDQoNCsOYICBJdCBzZWVtcyB2ZXJ5IHVubGlrZWx5IHlvdSBjb3VsZCBm YWNpbGl0YXRlIHRoaXMgY3Jvc3MtdGFsayBjb21tdW5pY2F0aW9ucyB3aXRob3V0IE5EIG9yIGEg bmV3IHByb3RvY29sLCBzdXBwb3J0ZWQgYnkgaG9zdHMsIHdpdGggbW9yZSBvciBsZXNzIHZlcnkg c2ltaWxhciB0cmFmZmljIGNoYXJhY3RlcmlzdGljcyBhcyBORCwgdGhlcmVmb3JlIGRlZmVhdGlu ZyBvbmUgb2YgdGhlIHByaW1hcnkgcHVycG9zZXMgZm9yIHRoZSBtZWNoYW5pc20gaW4gdGhlIGZp cnN0IHBsYWNlLg0KDQpTdGFuZGFyZCBORCBpcyBhc3N1bWVkIGFzIHRoZSBzdXBwb3J0aW5nIGZ1 bmN0aW9uLCB3aXRoIE5EIG1lc3NhZ2VzIGNhcnJ5aW5nIHByZWZpeA0KaW5mb3JtYXRpb24uIEl0 IGlzIGluY3JlbWVudGFsbHktZGVwbG95YWJsZSwgYW5kIGFkb3B0ZXJzIHdpbGwgc2VlIHRoZSBi ZW5lZml0cyB3aGlsZQ0KbGVnYWN5IGhvc3RzIHdpbGwgY29udGludWUgdG8gb3BlcmF0ZSBhcyB0 aGV5IGFsd2F5cyBoYXZlLg0KDQoNCsOYICBJZiB5b3Ugd2FudCBob3N0cyBvbiB0aGUgc2FtZSBs aW5rIHRvIGNvbW11bmljYXRlIGRpcmVjdGx5LCB3ZSBhbHJlYWR5IGtub3cgaG93IHRvIGRvIHRo YXQsIHVzZSBjbGFzc2ljIG11bHRpcGxlIGhvc3QgcGVyIHByZWZpeCBzdWJuZXRzLiBBcyBJIHNh aWQgYmVmb3JlIHRoaXMgbWVjaGFuaXNtIGlzbid0IGludGVuZGVkIGFzIGEgdW5pdmVyc2FsIHJl cGxhY2VtZW50IGZvciBjbGFzc2ljIHN1Ym5ldHMuDQoNClJGQzc5MzQgYW5kIOKAmGRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N04oCZIGFyZSBlc3RhYmxpc2hpbmcN Cm9wZXJhdGlvbmFsIGd1aWRlbGluZXMgZm9yIGhvc3RzIHRvIHJlY2VpdmUgdGhlaXIgb3duIHBy aXZhdGUgcHJlZml4ZXMgZm9yIHVzZQ0KaW4gd2hhdGV2ZXIgd2F5IHRoZXkgY2hvb3NlLiBXZSB3 aWxsIHdhbnQgZm9yIHRoZXNlIGhvc3RzIHRvIGJlIGFibGUgdG8NCmVzdGFibGlzaCBwZWVyLXRv LXBlZXIgY29tbXVuaWNhdGlvbnMgd2l0aG91dCBoYXZpbmcgdG8gbGV2ZXJhZ2UgYSBzaGFyZWQN CnN1Ym5ldCBwcmVmaXguDQoNClRoYW5rcyAtIEZyZWQNCg0KDQoNCkZyb206IERhdmlkIEZhcm1l ciBbbWFpbHRvOmZhcm1lckB1bW4uZWR1XQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjMsIDIw MTcgNjowMyBQTQ0KVG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KQ2M6 IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGphbWVzIHdvb2R5 YXR0IDxqaHdAZ29vZ2xlLmNvbT47IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVlIElQdjYgcHJlZml4ZXMgcGVyIGhvc3QNCg0KDQoN Ck9uIEF1ZyAyMywgMjAxNywgYXQgMTk6MDEsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29n bGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNCk9uIFRodSwgQXVnIDI0 LCAyMDE3IGF0IDc6MDAgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5n LmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KV2l0aCBSRkM3 OTM0LCB3ZSBhbHJlYWR5IGhhdmUgQkNQIHJlY29tbWVuZGF0aW9ucyBvbiBob3N0IGFkZHJlc3Mg YXZhaWxhYmlsaXR5DQpXaXRoIHRoZSBhZHZlbnQgb2YgdGhlc2UgcmVjb21tZW5kYXRpb25zIGFu ZCBwcmFjdGljZXMsIHdlIHNlZSBhbiBvcGVyYXRpb25hbA0KYWR2YW50YWdlIGZvciBob3N0cyB0 byBkaXNjb3ZlciB0aGUgZGVsZWdhdGVkIHByZWZpeGVzIG9mIG5laWdoYm9ycyBvbiB0aGUgbGlu ayBzbw0KdGhhdCBjb21tdW5pY2F0aW9ucyBjYW4gZ28gZGlyZWN0bHkgZnJvbSBwZWVyIHRvIHBl ZXIgZm9yIGJldHRlciBwZXJmb3JtYW5jZQ0KYW5kIHRvIHJlZHVjZSB0aGUgbG9hZCBvbiByb3V0 ZXJzLg0KDQpJJ20gbm90IHN1cmUgdGhhdCB3b3VsZCBiZSBnZW5lcmFsbHkgdXNlZnVsLCBiZWNh dXNlOg0KDQogIDEuICBJdCBvbmx5IG1ha2VzIHNlbnNlIGlmIHJvdXRlciBsb2FkIGlzIGEgcHJv YmxlbS4gVGhhdCBpcyB1bmxpa2VseSB0byBoYXBwZW4gaW4gbWFueSBzY2VuYXJpb3MsIGZvciBl eGFtcGxlIHRoZSBjb21tb24gdXNlIGNhc2Ugb2YgYSB3aWZpIG5ldHdvcmsgdGhhdCBoYW5kcyBv dXQgYSAvNjQgdG8gZXZlcnkgaG9zdC4gSW4gc3VjaCBhIGRlcGxveW1lbnQsIHRoZSBwYWNrZXRz IGhhdmUgdG8gdHJhdmVsIHRocm91Z2ggdGhlIEFQIGFueXdheSwgYW5kIGNyb3NzLXRhbGsgaXMg bGlrZWx5IHRvIGJlIGV4dHJlbWVseSBsaW1pdGVkIGNvbXBhcmVkIHRvIEludGVybmV0LWJvdW5k IHRyYWZmaWMuIE1vc3QgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBpcyBhY3R1YWxseSBwb2ludC10 by1wb2ludCB0aGVzZSBkYXlzLg0KICAyLiAgQWxsb3dpbmcgY3Jvc3MtdGFsayBiZXR3ZWVuIGRl dmljZXMgb24gdGhlIHNhbWUgbGluayByYWlzZXMgYSBudW1iZXIgb2Ygc2VjdXJpdHkgaXNzdWVz IGJlY2F1c2UgbWFsaWNpb3VzIGhvc3RzIGNhbiBtb3VudCBMMiBhdHRhY2tzIGFnYWluc3Qgb3Ro ZXIgaG9zdHMgb24gdGhlIG5ldHdvcmsgLSBmb3IgZXhhbXBsZSwgdGhleSBjYW4gYXR0ZW1wdCB0 byBwcmV2ZW50IG90aGVyIGhvc3RzIGZyb20gZm9ybWluZyBJUHY2IGFkZHJlc3NlcyBieSByZXBs eWluZyB0byBEQUQgcHJvYmVzLCB0aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhleSBjYW4gZm9y Z2UgcmVkaXJlY3RzLCBldGMuDQpGdXJ0aGVyLCBvbmUgb2YgdGhlIHByaW1hcnkgbW90aXZhdGlv bnMgZm9yIHRoaXMgbWVjaGFuaXNtIHdhcyB0byBncmVhdGx5IHJlZHVjZWQgTkQgdHJhZmZpYyBv biBsaW5rcyB3aXRoIGxvdHMgb2YgaG9zdHMsIGZyZXF1ZW50bHkgbWFueSB0aG91c2FuZHMgb2Yg aG9zdHMuIEl0IHNlZW1zIHZlcnkgdW5saWtlbHkgeW91IGNvdWxkIGZhY2lsaXRhdGUgdGhpcyBj cm9zcy10YWxrIGNvbW11bmljYXRpb25zIHdpdGhvdXQgTkQgb3IgYSBuZXcgcHJvdG9jb2wsIHN1 cHBvcnRlZCBieSBob3N0cywgd2l0aCBtb3JlIG9yIGxlc3MgdmVyeSBzaW1pbGFyIHRyYWZmaWMg Y2hhcmFjdGVyaXN0aWNzIGFzIE5ELCB0aGVyZWZvcmUgZGVmZWF0aW5nIG9uZSBvZiB0aGUgcHJp bWFyeSBwdXJwb3NlcyBmb3IgdGhlIG1lY2hhbmlzbSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCklm IHlvdSB3YW50IGhvc3RzIG9uIHRoZSBzYW1lIGxpbmsgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHks IHdlIGFscmVhZHkga25vdyBob3cgdG8gZG8gdGhhdCwgdXNlIGNsYXNzaWMgbXVsdGlwbGUgaG9z dCBwZXIgcHJlZml4IHN1Ym5ldHMuIEFzIEkgc2FpZCBiZWZvcmUgdGhpcyBtZWNoYW5pc20gaXNu J3QgaW50ZW5kZWQgYXMgYSB1bml2ZXJzYWwgcmVwbGFjZW1lbnQgZm9yIGNsYXNzaWMgc3VibmV0 cy4NCg0KRGF2aWQgRmFybWVyDQoNCg== --_000_0eb44f4890234a8888159c1e222f5d54XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjI3MTUyMjIwNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU3 NzUwMTI2Mjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyMDgxNDQ0MjMyOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2NjE2NjU5NTQgNjc2OTg2OTkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoy Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5GdXJ0aGVyLCBvbmUgb2YgdGhlIHByaW1hcnkgbW90aXZhdGlvbnMgZm9yIHRoaXMg bWVjaGFuaXNtIHdhcyB0byBncmVhdGx5IHJlZHVjZWQgTkQgdHJhZmZpYyBvbiBsaW5rcyB3aXRo IGxvdHMgb2YgaG9zdHMsIGZyZXF1ZW50bHkgbWFueSB0aG91c2FuZHMgb2YgaG9zdHMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5ZZXMsIGxhcmdl IGxpbmtzIHdpdGggbWFueSBob3N0cyDigJMgdGhvdXNhbmRzIG9yIG1vcmUuIEJ1dCwgaXQgYWxz byBhcHBsaWVzIHRvIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5saW5rIHR5cGUgYW5kIG5vdCBqdXN0IGh1 Z2Ugb25lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SXQgc2Vl bXMgdmVyeSB1bmxpa2VseSB5b3UgY291bGQgZmFjaWxpdGF0ZSB0aGlzIGNyb3NzLXRhbGsgY29t bXVuaWNhdGlvbnMgd2l0aG91dCBORCBvciBhIG5ldyBwcm90b2NvbCwgc3VwcG9ydGVkIGJ5IGhv c3RzLCB3aXRoIG1vcmUgb3IgbGVzcyB2ZXJ5IHNpbWlsYXIgdHJhZmZpYyBjaGFyYWN0ZXJpc3Rp Y3MgYXMgTkQsIHRoZXJlZm9yZSBkZWZlYXRpbmcgb25lIG9mIHRoZSBwcmltYXJ5DQogcHVycG9z ZXMgZm9yIHRoZSBtZWNoYW5pc20gaW4gdGhlIGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+U3RhbmRhcmQgTkQgaXMgYXNzdW1l ZCBhcyB0aGUgc3VwcG9ydGluZyBmdW5jdGlvbiwgd2l0aCBORCBtZXNzYWdlcyBjYXJyeWluZyBw cmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+aW5mb3JtYXRpb24uIEl0IGlzIGluY3JlbWVudGFsbHktZGVw bG95YWJsZSwgYW5kIGFkb3B0ZXJzIHdpbGwgc2VlIHRoZSBiZW5lZml0cyB3aGlsZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5sZWdhY3kgaG9zdHMgd2lsbCBjb250aW51ZSB0byBvcGVyYXRlIGFzIHRoZXkgYWx3 YXlzIGhhdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgeW91IHdhbnQgaG9zdHMgb24gdGhlIHNh bWUgbGluayB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSwgd2UgYWxyZWFkeSBrbm93IGhvdyB0byBk byB0aGF0LCB1c2UgY2xhc3NpYyBtdWx0aXBsZSBob3N0IHBlciBwcmVmaXggc3VibmV0cy4gQXMg SSBzYWlkIGJlZm9yZSB0aGlzIG1lY2hhbmlzbSBpc24ndCBpbnRlbmRlZCBhcyBhIHVuaXZlcnNh bCByZXBsYWNlbWVudCBmb3IgY2xhc3NpYyBzdWJuZXRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UkZDNzkzNCBhbmQg4oCYZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3TigJkgYXJlIGVzdGFibGlzaGluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj5vcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvciBob3N0cyB0byByZWNlaXZlIHRo ZWlyIG93biBwcml2YXRlIHByZWZpeGVzIGZvciB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+aW4gd2hhdGV2 ZXIgd2F5IHRoZXkgY2hvb3NlLiBXZSB3aWxsIHdhbnQgZm9yIHRoZXNlIGhvc3RzIHRvIGJlIGFi bGUgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+ZXN0YWJsaXNoIHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9u cyB3aXRob3V0IGhhdmluZyB0byBsZXZlcmFnZSBhIHNoYXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5zdWJu ZXQgcHJlZml4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzIC0g RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1 bW4uZWR1XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDIzLCAyMDE3IDY6 MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IExvcmVuem8gQ29saXR0aSAmbHQ7bG9yZW56b0Bnb29nbGUu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tJmd0OzsgamFtZXMgd29vZHlhdHQgJmx0O2pod0Bnb29nbGUuY29tJmd0Ozsg djZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gUGVlciBkaXNj b3ZlcnkgZm9yIHVuaXF1ZSBJUHY2IHByZWZpeGVzIHBlciBob3N0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpPbiBBdWcgMjMsIDIwMTcsIGF0IDE5OjAxLCBMb3JlbnpvIENvbGl0 dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNCwgMjAx NyBhdCA3OjAwIEFNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5n LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldpdGggUkZDNzkzNCwgd2UgYWxyZWFkeSBoYXZlIEJDUCByZWNvbW1lbmRh dGlvbnMgb24gaG9zdCBhZGRyZXNzIGF2YWlsYWJpbGl0eTxicj4NCldpdGggdGhlIGFkdmVudCBv ZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgYW5kIHByYWN0aWNlcywgd2Ugc2VlIGFuIG9wZXJhdGlv bmFsPGJyPg0KYWR2YW50YWdlIGZvciBob3N0cyB0byBkaXNjb3ZlciB0aGUgZGVsZWdhdGVkIHBy ZWZpeGVzIG9mIG5laWdoYm9ycyBvbiB0aGUgbGluayBzbzxicj4NCnRoYXQgY29tbXVuaWNhdGlv bnMgY2FuIGdvIGRpcmVjdGx5IGZyb20gcGVlciB0byBwZWVyIGZvciBiZXR0ZXIgcGVyZm9ybWFu Y2U8YnI+DQphbmQgdG8gcmVkdWNlIHRoZSBsb2FkIG9uIHJvdXRlcnMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1 cmUgdGhhdCB3b3VsZCBiZSBnZW5lcmFsbHkgdXNlZnVsLCBiZWNhdXNlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgb25seSBtYWtlcyBzZW5zZSBp ZiByb3V0ZXIgbG9hZCBpcyBhIHByb2JsZW0uIFRoYXQgaXMgdW5saWtlbHkgdG8gaGFwcGVuIGlu IG1hbnkgc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSB0aGUgY29tbW9uIHVzZSBjYXNlIG9mIGEgd2lm aSBuZXR3b3JrIHRoYXQgaGFuZHMgb3V0IGEgLzY0IHRvIGV2ZXJ5IGhvc3QuIEluIHN1Y2ggYSBk ZXBsb3ltZW50LCB0aGUgcGFja2V0cyBoYXZlIHRvIHRyYXZlbCB0aHJvdWdoIHRoZSBBUCBhbnl3 YXksIGFuZA0KIGNyb3NzLXRhbGsgaXMgbGlrZWx5IHRvIGJlIGV4dHJlbWVseSBsaW1pdGVkIGNv bXBhcmVkIHRvIEludGVybmV0LWJvdW5kIHRyYWZmaWMuIE1vc3QgbmV0d29yayBpbmZyYXN0cnVj dHVyZSBpcyBhY3R1YWxseSBwb2ludC10by1wb2ludCB0aGVzZSBkYXlzLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkFsbG93 aW5nIGNyb3NzLXRhbGsgYmV0d2VlbiBkZXZpY2VzIG9uIHRoZSBzYW1lIGxpbmsgcmFpc2VzIGEg bnVtYmVyIG9mIHNlY3VyaXR5IGlzc3VlcyBiZWNhdXNlIG1hbGljaW91cyBob3N0cyBjYW4gbW91 bnQgTDIgYXR0YWNrcyBhZ2FpbnN0IG90aGVyIGhvc3RzIG9uIHRoZSBuZXR3b3JrIC0gZm9yIGV4 YW1wbGUsIHRoZXkgY2FuIGF0dGVtcHQgdG8gcHJldmVudCBvdGhlciBob3N0cyBmcm9tIGZvcm1p bmcgSVB2NiBhZGRyZXNzZXMgYnkgcmVwbHlpbmcNCiB0byBEQUQgcHJvYmVzLCB0aGV5IGNhbiBz ZW5kIHJvZ3VlIFJBcywgdGhleSBjYW4gZm9yZ2UgcmVkaXJlY3RzLCBldGMuPG86cD48L286cD48 L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZ1cnRoZXIsIG9uZSBvZiB0aGUg cHJpbWFyeSBtb3RpdmF0aW9ucyBmb3IgdGhpcyBtZWNoYW5pc20gd2FzIHRvIGdyZWF0bHkgcmVk dWNlZCBORCB0cmFmZmljIG9uIGxpbmtzIHdpdGggbG90cyBvZiBob3N0cywgZnJlcXVlbnRseSBt YW55IHRob3VzYW5kcyBvZiBob3N0cy4gSXQgc2VlbXMgdmVyeSB1bmxpa2VseSB5b3UgY291bGQg ZmFjaWxpdGF0ZSB0aGlzIGNyb3NzLXRhbGsgY29tbXVuaWNhdGlvbnMgd2l0aG91dA0KIE5EIG9y IGEgbmV3IHByb3RvY29sLCBzdXBwb3J0ZWQgYnkgaG9zdHMsIHdpdGggbW9yZSBvciBsZXNzIHZl cnkgc2ltaWxhciB0cmFmZmljIGNoYXJhY3RlcmlzdGljcyBhcyBORCwgdGhlcmVmb3JlIGRlZmVh dGluZyBvbmUgb2YgdGhlIHByaW1hcnkgcHVycG9zZXMgZm9yIHRoZSBtZWNoYW5pc20gaW4gdGhl IGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB5b3Ugd2FudCBob3N0cyBvbiB0aGUgc2FtZSBsaW5rIHRvIGNvbW11bmlj YXRlIGRpcmVjdGx5LCB3ZSBhbHJlYWR5IGtub3cgaG93IHRvIGRvIHRoYXQsIHVzZSBjbGFzc2lj IG11bHRpcGxlIGhvc3QgcGVyIHByZWZpeCBzdWJuZXRzLiBBcyBJIHNhaWQgYmVmb3JlIHRoaXMg bWVjaGFuaXNtIGlzbid0IGludGVuZGVkIGFzIGEgdW5pdmVyc2FsIHJlcGxhY2VtZW50IGZvciBj bGFzc2ljIHN1Ym5ldHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkRhdmlkIEZhcm1lcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0eb44f4890234a8888159c1e222f5d54XCH150608nwnosboeingcom_-- From nobody Thu Aug 24 08:01:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68713237B for ; Thu, 24 Aug 2017 08:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq3cw7LA6exs for ; Thu, 24 Aug 2017 08:01:11 -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 5E93D132940 for ; Thu, 24 Aug 2017 08:01:10 -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 v7OF18qL014537; Thu, 24 Aug 2017 08:01:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OF15AQ014476 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 08:01:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 08:01:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 08:01:05 -0700 From: "Templin, Fred L" To: Ole Troan , David Farmer CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegATBg4AAAIjeAAADwmRAAAAiLgg Date: Thu, 24 Aug 2017 15:01:05 +0000 Message-ID: <6efca4610b2f420da50c44138d3fb96d@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:01:13 -0000 SGkgT2xlLA0KDQo+IFRoYXQgaG9zdHMgYXJlIG9uIHRoZSBzYW1lIGxpbmsgaXMgdHlwaWNhbGx5 IGVtdWxhdGVkIGF0IEwyLCB3ZSBsYXJnZWx5IHN0b3BwZWQgYnVpbGRpbmcgc2hhcmVkIG1lZGlh IGxpbmtzIGluIHRoZSA4MHMuIDstKQ0KDQpTaGFyZWQgbWVkaWEgbGlua3MgaGF2ZSBub3QgZ29u ZSBhd2F5IGFuZCBjb250aW51ZSB0byBmbG91cmlzaC4gV2Ugc2VlIHRoZW0NCmluIGxhcmdlIFZQ TnMsIGVudGVycHJpc2UgbmV0d29ya3MsIGFlcm9uYXV0aWNhbCBjb21tdW5pY2F0aW9ucywgZXRj LiBFdmVuDQp5b3VyIDZyZCBwcm9wb3NhbCBpcyBhbiBleGFtcGxlIG9mIGEgbGFyZ2Ugc2hhcmVk IGxpbmsgKGFzIGlzIElTQVRBUCwgZnJvbSB3aGljaA0KNnJkICJib3Jyb3dlZCIgdGhlIGxpbmsg bW9kZWwpLg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgT2xlIFRyb2FuDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjQsIDIwMTcgMToxMyBBTQ0K PiBUbzogRGF2aWQgRmFybWVyIDxmYXJtZXJAdW1uLmVkdT4NCj4gQ2M6IGphbWVzIHdvb2R5YXR0 IDxqaHdAZ29vZ2xlLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNd IFBlZXIgZGlzY292ZXJ5IGZvciB1bmlxdWUgSVB2NiBwcmVmaXhlcyBwZXIgaG9zdA0KPiANCj4g Pj4gT24gVGh1LCBBdWcgMjQsIDIwMTcgYXQgNzowMCBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPj4gV2l0aCBSRkM3OTM0LCB3ZSBhbHJl YWR5IGhhdmUgQkNQIHJlY29tbWVuZGF0aW9ucyBvbiBob3N0IGFkZHJlc3MgYXZhaWxhYmlsaXR5 DQo+ID4+IFdpdGggdGhlIGFkdmVudCBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgYW5kIHByYWN0 aWNlcywgd2Ugc2VlIGFuIG9wZXJhdGlvbmFsDQo+ID4+IGFkdmFudGFnZSBmb3IgaG9zdHMgdG8g ZGlzY292ZXIgdGhlIGRlbGVnYXRlZCBwcmVmaXhlcyBvZiBuZWlnaGJvcnMgb24gdGhlIGxpbmsg c28NCj4gPj4gdGhhdCBjb21tdW5pY2F0aW9ucyBjYW4gZ28gZGlyZWN0bHkgZnJvbSBwZWVyIHRv IHBlZXIgZm9yIGJldHRlciBwZXJmb3JtYW5jZQ0KPiA+PiBhbmQgdG8gcmVkdWNlIHRoZSBsb2Fk IG9uIHJvdXRlcnMuDQo+ID4+DQo+ID4+IEknbSBub3Qgc3VyZSB0aGF0IHdvdWxkIGJlIGdlbmVy YWxseSB1c2VmdWwsIGJlY2F1c2U6DQo+ID4+IAnigKIgSXQgb25seSBtYWtlcyBzZW5zZSBpZiBy b3V0ZXIgbG9hZCBpcyBhIHByb2JsZW0uIFRoYXQgaXMgdW5saWtlbHkgdG8gaGFwcGVuIGluIG1h bnkgc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSB0aGUgY29tbW9uIHVzZQ0KPiBjYXNlIG9mIGEgd2lm aSBuZXR3b3JrIHRoYXQgaGFuZHMgb3V0IGEgLzY0IHRvIGV2ZXJ5IGhvc3QuIEluIHN1Y2ggYSBk ZXBsb3ltZW50LCB0aGUgcGFja2V0cyBoYXZlIHRvIHRyYXZlbCB0aHJvdWdoIHRoZSBBUCBhbnl3 YXksDQo+IGFuZCBjcm9zcy10YWxrIGlzIGxpa2VseSB0byBiZSBleHRyZW1lbHkgbGltaXRlZCBj b21wYXJlZCB0byBJbnRlcm5ldC1ib3VuZCB0cmFmZmljLiBNb3N0IG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUgaXMgYWN0dWFsbHkgcG9pbnQtdG8tDQo+IHBvaW50IHRoZXNlIGRheXMuDQo+ID4+IAni gKIgQWxsb3dpbmcgY3Jvc3MtdGFsayBiZXR3ZWVuIGRldmljZXMgb24gdGhlIHNhbWUgbGluayBy YWlzZXMgYSBudW1iZXIgb2Ygc2VjdXJpdHkgaXNzdWVzIGJlY2F1c2UgbWFsaWNpb3VzIGhvc3Rz IGNhbiBtb3VudA0KPiBMMiBhdHRhY2tzIGFnYWluc3Qgb3RoZXIgaG9zdHMgb24gdGhlIG5ldHdv cmsgLSBmb3IgZXhhbXBsZSwgdGhleSBjYW4gYXR0ZW1wdCB0byBwcmV2ZW50IG90aGVyIGhvc3Rz IGZyb20gZm9ybWluZyBJUHY2IGFkZHJlc3NlcyBieQ0KPiByZXBseWluZyB0byBEQUQgcHJvYmVz LCB0aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhleSBjYW4gZm9yZ2UgcmVkaXJlY3RzLCBldGMu DQo+ID4gRnVydGhlciwgb25lIG9mIHRoZSBwcmltYXJ5IG1vdGl2YXRpb25zIGZvciB0aGlzIG1l Y2hhbmlzbSB3YXMgdG8gZ3JlYXRseSByZWR1Y2VkIE5EIHRyYWZmaWMgb24gbGlua3Mgd2l0aCBs b3RzIG9mIGhvc3RzLCBmcmVxdWVudGx5DQo+IG1hbnkgdGhvdXNhbmRzIG9mIGhvc3RzLiBJdCBz ZWVtcyB2ZXJ5IHVubGlrZWx5IHlvdSBjb3VsZCBmYWNpbGl0YXRlIHRoaXMgY3Jvc3MtdGFsayBj b21tdW5pY2F0aW9ucyB3aXRob3V0IE5EIG9yIGEgbmV3IHByb3RvY29sLA0KPiBzdXBwb3J0ZWQg YnkgaG9zdHMsIHdpdGggbW9yZSBvciBsZXNzIHZlcnkgc2ltaWxhciB0cmFmZmljIGNoYXJhY3Rl cmlzdGljcyBhcyBORCwgdGhlcmVmb3JlIGRlZmVhdGluZyBvbmUgb2YgdGhlIHByaW1hcnkgcHVy cG9zZXMgZm9yDQo+IHRoZSBtZWNoYW5pc20gaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiA+DQo+ID4g SWYgeW91IHdhbnQgaG9zdHMgb24gdGhlIHNhbWUgbGluayB0byBjb21tdW5pY2F0ZSBkaXJlY3Rs eSwgd2UgYWxyZWFkeSBrbm93IGhvdyB0byBkbyB0aGF0LCB1c2UgY2xhc3NpYyBtdWx0aXBsZSBo b3N0IHBlciBwcmVmaXgNCj4gc3VibmV0cy4gQXMgSSBzYWlkIGJlZm9yZSB0aGlzIG1lY2hhbmlz bSBpc24ndCBpbnRlbmRlZCBhcyBhIHVuaXZlcnNhbCByZXBsYWNlbWVudCBmb3IgY2xhc3NpYyBz dWJuZXRzLg0KPiANCj4gSW5kZWVkLiBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgaG9zdCB0 byBob3N0IG5vdyBoYXBwZW5zIGF0IEwzIGluc3RlYWQgb2YgTDIuDQo+IFRoYXQgaG9zdHMgYXJl IG9uIHRoZSBzYW1lIGxpbmsgaXMgdHlwaWNhbGx5IGVtdWxhdGVkIGF0IEwyLCB3ZSBsYXJnZWx5 IHN0b3BwZWQgYnVpbGRpbmcgc2hhcmVkIG1lZGlhIGxpbmtzIGluIHRoZSA4MHMuIDstKQ0KPiBU aGlzIGlzIGp1c3QgbWFraW5nIHRoZSBMMyB0b3BvbG9neSByZWZsZWN0IHJlYWxpdHkuDQo+IA0K PiBPbGUNCg== From nobody Thu Aug 24 08:31:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6D1321C7 for ; Thu, 24 Aug 2017 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFcGli7yQr8I for ; Thu, 24 Aug 2017 08:31:13 -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 C8281132256 for ; Thu, 24 Aug 2017 08:31:13 -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 v7OFU8W6049570; Thu, 24 Aug 2017 08:30:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OFU60v049537 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 08:30:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-11.nw.nos.boeing.com (137.136.239.220) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 08:30:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 08:30:06 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" , james woodyatt Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegATBg4AAA+87oAAD2uDgAANxAAA Date: Thu, 24 Aug 2017 15:30:06 +0000 Message-ID: <23e19b3a83054369881a3248d24fec34@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_23e19b3a83054369881a3248d24fec34XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:31:16 -0000 --_000_23e19b3a83054369881a3248d24fec34XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KDQrDmCAgSSBkaWRuJ3Qgc2F5IGl0IHdhcyBpbXBvc3NpYmxlLCBJIGp1 c3Qgc2FpZCBpdCdzIHVubGlrZWx5Lg0KDQpJIHRoaW5rIHlvdSBhcmUgdGFraW5nIGEgdG9vIGxp bWl0ZWQgdmlld3BvaW50IG9mIHRoZSBhcHBsaWNhYmxlIHVzZSBjYXNlcy4gVGhlcmUNCndpbGwg YmUgbWFueSB1c2UgY2FzZXMgd2hlcmUgcGVlci10by1wZWVyIHBlcmZvcm1hbmNlIGlzIG11Y2gg YmV0dGVyIHRoYW4NCnBlZXItdG8tcm91dGVyLXRvLXBlZXIuDQoNCg0Kw5ggICB3aGljaCBhcmUg dmVyeSBsaWtlbHkgdG8gYmUgY29ubmVjdGVkIHVzaW5nIGZpYmVyIGxpbmtzIHRoYXQgYXJlIG11 Y2ggZmFzdGVyIGFuZCBtb3JlIHJlbGlhYmxlIHRoYW4gdGhlIHdpZmkgbGluayBpdHNlbGYuDQoN ClRoYXQgaXMgdHJ1ZSwgYnV0IGl0IHdvdWxkIHN0aWxsIGdvIGFzIHdpZmktdG8tZmliZXItdG8t d2lmaSB3aXRob3V0IGhhdmluZyB0bw0KZ28gYXMgd2lmaS10by1maWJlci10by1yb3V0ZXItdG8t ZmliZXItdG8td2lmaS4gU28sIGl0IGlzIHN0aWxsIGFuIGltcHJvdmVtZW50Lg0KDQoNCsOYICBB Y3R1YWxseSwgdGhleSBkbyBoYXZlIGEgbG90IHRvIGRvIHdpdGggdGhpcyBmdW5jdGlvbi4gT25l IG9mIHRoZSBtYWpvciBhZHZhbnRhZ2VzIG9mIGFzc2lnbmluZyBhIGRpc3RpbmN0IHByZWZpeCBw ZXIgaG9zdCBpcyAqcHJlY2lzZWx5KiB0aGUgYXZvaWRhbmNlIG9mIHRoZXNlIHNlY3VyaXR5IGlz c3Vlcy4gWW91J3JlIHByb3Bvc2luZyBicmluZ2luZyB0aGVtIGJhY2sgYWdhaW4uDQoNCkRpc2Fn cmVlIOKAkyB0aGlzIGRvZXMgbm90IGludHJvZHVjZSBuZXcgdnVsbmVyYWJpbGl0aWVzIGJleW9u ZCB3aGF0IGlzIGFscmVhZHkNCmluIElQdjYgTkQuIEFuZCBhZ2FpbiwgSSB0aGluayB5b3UgbWF5 IGJlIHRha2luZyB0b28gbGltaXRlZCBhIHZpZXcgb24gdGhlDQp0eXBlcyBvZiB1c2UgY2FzZXMg dGhhdCB0aGlzIG1pZ2h0IGFwcGx5IHRvLiBUaGlzIGFwcGxpZXMgdG8gYW55IGxpbmsgdHlwZSB3 aGVyZQ0KcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIGFyZSBzZWVuIGFzIGFuIGFkdmFudGFn ZS4gSXQgZG9lcyBub3QgaGF2ZSB0bw0KYmUgdXNlZCBvbiBsaW5rcyB3aGVyZSBwZWVyLXRvLXJv dXRlci10by1wZWVyIGlzIHByZWZlcnJlZC4NCg0KVGhpbmsgb2YgdGhpcyBhcyBhbiBhbmFsb2cg b2YgdGhlIElQdjYgTkQgUmVkaXJlY3QgZnVuY3Rpb24uIEl0IGlzIHRydWUgdGhhdA0Kb24gbWFu eSBsaW5rIHR5cGVzIFJlZGlyZWN0cyBhcmUgdHVybmVkIG9mZiBieSBkZWZhdWx0LiBCdXQsIG9u IGxpbmtzIHdoZXJlDQpSZWRpcmVjdHMgYXJlIHVzZWZ1bCB0aGVuIHRoaXMgZnVuY3Rpb24gd2ls bCBhbHNvIGJlIHVzZWZ1bC4NCg0KVGhhbmtzIC0gRnJlZA0KDQoNCkZyb206IExvcmVuem8gQ29s aXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MjQsIDIwMTcgNzo1NCBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZzsgamFtZXMgd29vZHlhdHQgPGpod0Bnb29nbGUu Y29tPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gUGVlciBkaXNjb3ZlcnkgZm9yIHVuaXF1ZSBJUHY2 IHByZWZpeGVzIHBlciBob3N0DQoNCk9uIFRodSwgQXVnIDI0LCAyMDE3IGF0IDExOjQ5IFBNLCBU ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCk5vLCBpdCBhbHNvIG1ha2VzIHNlbnNlIGlmIHRo ZSBwZXJmb3JtYW5jZSBiZXR3ZWVuIHBlZXItdG8tcGVlciBpcyBzaWduaWZpY2FudGx5IGdyZWF0 ZXINCnRoYW4gZnJvbSBwZWVyLXRvLXJvdXRlci10by1wZWVyLiBGb3IgaW5zdGFuY2UsIHRoZSBy b3V0ZXIgY291bGQgYmUgbG9jYXRlZCBmYXIgYXdheSBmcm9tDQplaXRoZXIgcGVlciBvbiB2ZXJ5 IGxhcmdlIGxpbmtzLg0KDQpJIGRpZG4ndCBzYXkgaXQgd2FzIGltcG9zc2libGUsIEkganVzdCBz YWlkIGl0J3MgdW5saWtlbHkuDQoNCj4gIFRoYXQgaXMgdW5saWtlbHkgdG8gaGFwcGVuIGluIG1h bnkgc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSB0aGUgY29tbW9uIHVzZSBjYXNlIG9mIGEgd2lmaSBu ZXR3b3JrIHRoYXQgaGFuZHMgb3V0IGEgLzY0IHRvIGV2ZXJ5IGhvc3QuIEluIHN1Y2ggYSBkZXBs b3ltZW50LCB0aGUgcGFja2V0cyBoYXZlIHRvIHRyYXZlbCB0aHJvdWdoIHRoZSBBUCBhbnl3YXkN Ck9uIHZlcnkgbGFyZ2UgV2lGaSBkZXBsb3ltZW50cywgdGhlcmUgbWF5IGJlIG1hbnkgQVBzIGFu ZCB0aGUgcm91dGVyIGZ1bmN0aW9uDQptYXkgYmUgbG9jYXRlZCBvbiBhIFdpcmVsZXNzIExBTiBj b250cm9sbGVyIGZhciBhd2F5IGZyb20gdGhlIEFQcy4NCg0KLi4uIHdoaWNoIGFyZSB2ZXJ5IGxp a2VseSB0byBiZSBjb25uZWN0ZWQgdXNpbmcgZmliZXIgbGlua3MgdGhhdCBhcmUgbXVjaCBmYXN0 ZXIgYW5kIG1vcmUgcmVsaWFibGUgdGhhbiB0aGUgd2lmaSBsaW5rIGl0c2VsZi4NCg0KPiAgYmVj YXVzZSBtYWxpY2lvdXMgaG9zdHMgY2FuIG1vdW50IEwyIGF0dGFja3MgYWdhaW5zdCBvdGhlciBo b3N0cyBvbiB0aGUgbmV0d29yayAtIGZvciBleGFtcGxlLCB0aGV5IGNhbiBhdHRlbXB0IHRvIHBy ZXZlbnQgb3RoZXIgaG9zdHMgZnJvbSBmb3JtaW5nIElQdjYgYWRkcmVzc2VzIGJ5IHJlcGx5aW5n IHRvIERBRCBwcm9iZXMsIHRoZXkgY2FuIHNlbmQgcm9ndWUgUkFzLCB0aGV5IGNhbiBmb3JnZSBy ZWRpcmVjdHMsIGV0Yy4NCllvdSBhcmUgZW51bWVyYXRpbmcgaXNzdWVzIHdpdGggSVB2NiBORCB0 aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHRoaXMNCmZ1bmN0aW9uLiBBbGwgb2YgdGhlIHNl Y3VyaW5nIGNvbmNlcm5zIHlvdSBhcmUgY2l0aW5nIHBlcnRhaW4gdG8gSVB2NiBORCBvbg0KYW55 IGxpbmsgdHlwZSwgYW5kIG5vdCBqdXN0IHRob3NlIHRoYXQgZW1wbG95IHRoaXMgZnVuY3Rpb24u DQoNCkFjdHVhbGx5LCB0aGV5IGRvIGhhdmUgYSBsb3QgdG8gZG8gd2l0aCB0aGlzIGZ1bmN0aW9u LiBPbmUgb2YgdGhlIG1ham9yIGFkdmFudGFnZXMgb2YgYXNzaWduaW5nIGEgZGlzdGluY3QgcHJl Zml4IHBlciBob3N0IGlzICpwcmVjaXNlbHkqIHRoZSBhdm9pZGFuY2Ugb2YgdGhlc2Ugc2VjdXJp dHkgaXNzdWVzLiBZb3UncmUgcHJvcG9zaW5nIGJyaW5naW5nIHRoZW0gYmFjayBhZ2Fpbi4NCg== --_000_23e19b3a83054369881a3248d24fec34XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm0tNDM3MDQ3Nzk5NzU4NDcwOTU3Mm1zb2xpc3RwYXJhZ3Jh cGgsIGxpLm0tNDM3MDQ3Nzk5NzU4NDcwOTU3Mm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTQzNzA0 Nzc5OTc1ODQ3MDk1NzJtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTQzNzA0 Nzc5OTc1ODQ3MDk1NzJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc1NTg0NTQ0Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUzNTcyMjQwMiAxMzQwNjU2NjA2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PkkgZGlkbid0IHNheSBpdCB3YXMgaW1wb3NzaWJsZSwgSSBqdXN0IHNhaWQgaXQncyB1bmxpa2Vs eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkg dGhpbmsgeW91IGFyZSB0YWtpbmcgYSB0b28gbGltaXRlZCB2aWV3cG9pbnQgb2YgdGhlIGFwcGxp Y2FibGUgdXNlIGNhc2VzLiBUaGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj53aWxsIGJlIG1hbnkgdXNlIGNh c2VzIHdoZXJlIHBlZXItdG8tcGVlciBwZXJmb3JtYW5jZSBpcyBtdWNoIGJldHRlciB0aGFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPnBlZXItdG8tcm91dGVyLXRvLXBlZXIuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDIw NjAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT4mbmJzcDt3aGljaCBhcmUgdmVyeSBsaWtlbHkgdG8gYmUgY29ubmVjdGVk IHVzaW5nIGZpYmVyIGxpbmtzIHRoYXQgYXJlIG11Y2ggZmFzdGVyIGFuZCBtb3JlIHJlbGlhYmxl IHRoYW4gdGhlIHdpZmkgbGluayBpdHNlbGYuPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhdCBpcyB0cnVlLCBidXQgaXQg d291bGQgc3RpbGwgZ28gYXMgd2lmaS10by1maWJlci10by13aWZpIHdpdGhvdXQgaGF2aW5nIHRv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPmdvIGFzIHdpZmktdG8tZmliZXItdG8tcm91dGVyLXRvLWZpYmVyLXRv LXdpZmkuIFNvLCBpdCBpcyBzdGlsbCBhbiBpbXByb3ZlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5BY3R1YWxseSwgdGhleSBkbyBoYXZlIGEgbG90IHRvIGRvIHdpdGggdGhpcyBmdW5jdGlv bi4gT25lIG9mIHRoZSBtYWpvciBhZHZhbnRhZ2VzIG9mIGFzc2lnbmluZyBhIGRpc3RpbmN0IHBy ZWZpeCBwZXIgaG9zdCBpcyAqcHJlY2lzZWx5KiB0aGUgYXZvaWRhbmNlIG9mIHRoZXNlIHNlY3Vy aXR5IGlzc3Vlcy4gWW91J3JlIHByb3Bvc2luZyBicmluZ2luZyB0aGVtIGJhY2sgYWdhaW4uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5EaXNhZ3Jl ZSDigJMgdGhpcyBkb2VzIG5vdCBpbnRyb2R1Y2UgbmV3IHZ1bG5lcmFiaWxpdGllcyBiZXlvbmQg d2hhdCBpcyBhbHJlYWR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPmluIElQdjYgTkQuIEFuZCBhZ2FpbiwgSSB0 aGluayB5b3UgbWF5IGJlIHRha2luZyB0b28gbGltaXRlZCBhIHZpZXcgb24gdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPnR5cGVzIG9mIHVzZSBjYXNlcyB0aGF0IHRoaXMgbWlnaHQgYXBwbHkgdG8uIFRoaXMg YXBwbGllcyB0byBhbnkgbGluayB0eXBlIHdoZXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnBlZXItdG8tcGVl ciBjb21tdW5pY2F0aW9ucyBhcmUgc2VlbiBhcyBhbiBhZHZhbnRhZ2UuIEl0IGRvZXMgbm90IGhh dmUgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+YmUgdXNlZCBvbiBsaW5rcyB3aGVyZSBwZWVyLXRvLXJvdXRl ci10by1wZWVyIGlzIHByZWZlcnJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPlRoaW5rIG9mIHRoaXMgYXMgYW4gYW5hbG9nIG9mIHRoZSBJUHY2IE5EIFJlZGlyZWN0IGZ1 bmN0aW9uLiBJdCBpcyB0cnVlIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+b24gbWFueSBsaW5rIHR5cGVz IFJlZGlyZWN0cyBhcmUgdHVybmVkIG9mZiBieSBkZWZhdWx0LiBCdXQsIG9uIGxpbmtzIHdoZXJl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPlJlZGlyZWN0cyBhcmUgdXNlZnVsIHRoZW4gdGhpcyBmdW5jdGlvbiB3 aWxsIGFsc28gYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3Jlbnpv IENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIEF1Z3VzdCAyNCwgMjAxNyA3OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGlu LCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiB2Nm9wc0BpZXRmLm9yZzsgamFtZXMgd29vZHlhdHQgJmx0O2pod0Bnb29nbGUuY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVl IElQdjYgcHJlZml4ZXMgcGVyIGhvc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNCwgMjAxNyBh dCAxMTo0OSBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRjU1OTciPk5v LCBpdCBhbHNvIG1ha2VzIHNlbnNlIGlmIHRoZSBwZXJmb3JtYW5jZSBiZXR3ZWVuIHBlZXItdG8t cGVlciBpcyBzaWduaWZpY2FudGx5IGdyZWF0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3Ij50aGFuIGZyb20g cGVlci10by1yb3V0ZXItdG8tcGVlci4gRm9yIGluc3RhbmNlLCB0aGUgcm91dGVyIGNvdWxkIGJl IGxvY2F0ZWQgZmFyIGF3YXkgZnJvbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRjU1OTciPmVpdGhlciBwZWVyIG9uIHZl cnkgbGFyZ2UgbGlua3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbid0IHNheSBp dCB3YXMgaW1wb3NzaWJsZSwgSSBqdXN0IHNhaWQgaXQncyB1bmxpa2VseS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFu Pg0KVGhhdCBpcyB1bmxpa2VseSB0byBoYXBwZW4gaW4gbWFueSBzY2VuYXJpb3MsIGZvciBleGFt cGxlIHRoZSBjb21tb24gdXNlIGNhc2Ugb2YgYSB3aWZpIG5ldHdvcmsgdGhhdCBoYW5kcyBvdXQg YSAvNjQgdG8gZXZlcnkgaG9zdC4gSW4gc3VjaCBhIGRlcGxveW1lbnQsIHRoZSBwYWNrZXRzIGhh dmUgdG8gdHJhdmVsIHRocm91Z2ggdGhlIEFQIGFueXdheTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+T24gdmVyeSBsYXJn ZSBXaUZpIGRlcGxveW1lbnRzLCB0aGVyZSBtYXkgYmUgbWFueSBBUHMgYW5kIHRoZSByb3V0ZXIg ZnVuY3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5tYXkgYmUgbG9jYXRlZCBvbiBhIFdpcmVsZXNzIExB TiBjb250cm9sbGVyIGZhciBhd2F5IGZyb20gdGhlIEFQcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Li4uIHdoaWNoIGFyZSB2ZXJ5IGxpa2VseSB0byBiZSBjb25uZWN0ZWQgdXNpbmcgZmli ZXIgbGlua3MgdGhhdCBhcmUgbXVjaCBmYXN0ZXIgYW5kIG1vcmUgcmVsaWFibGUgdGhhbiB0aGUg d2lmaSBsaW5rIGl0c2VsZi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tNDM3MDQ3Nzk5NzU4NDcwOTU3Mm1zb2xpc3RwYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFuPmJlY2F1c2UgbWFsaWNpb3VzIGhv c3RzIGNhbiBtb3VudCBMMiBhdHRhY2tzIGFnYWluc3Qgb3RoZXIgaG9zdHMgb24gdGhlIG5ldHdv cmsgLSBmb3IgZXhhbXBsZSwgdGhleSBjYW4gYXR0ZW1wdCB0byBwcmV2ZW50IG90aGVyIGhvc3Rz IGZyb20gZm9ybWluZyBJUHY2IGFkZHJlc3NlcyBieSByZXBseWluZyB0byBEQUQgcHJvYmVzLCB0 aGV5IGNhbiBzZW5kIHJvZ3VlIFJBcywgdGhleSBjYW4gZm9yZ2UgcmVkaXJlY3RzLCBldGMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5Zb3UgYXJlIGVudW1lcmF0aW5nIGlzc3VlcyB3aXRoIElQdjYgTkQgdGhhdCBoYXZl IG5vdGhpbmcgdG8gZG8gd2l0aCB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ZnVuY3Rpb24uIEFsbCBv ZiB0aGUgc2VjdXJpbmcgY29uY2VybnMgeW91IGFyZSBjaXRpbmcgcGVydGFpbiB0byBJUHY2IE5E IG9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+YW55IGxpbmsgdHlwZSwgYW5kIG5vdCBqdXN0IHRob3NlIHRo YXQgZW1wbG95IHRoaXMgZnVuY3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVh bGx5LCB0aGV5IGRvIGhhdmUgYSBsb3QgdG8gZG8gd2l0aCB0aGlzIGZ1bmN0aW9uLiBPbmUgb2Yg dGhlIG1ham9yIGFkdmFudGFnZXMgb2YgYXNzaWduaW5nIGEgZGlzdGluY3QgcHJlZml4IHBlciBo b3N0IGlzICpwcmVjaXNlbHkqIHRoZSBhdm9pZGFuY2Ugb2YgdGhlc2Ugc2VjdXJpdHkgaXNzdWVz LiBZb3UncmUgcHJvcG9zaW5nIGJyaW5naW5nIHRoZW0gYmFjayBhZ2Fpbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_23e19b3a83054369881a3248d24fec34XCH150608nwnosboeingcom_-- From nobody Thu Aug 24 08:50:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC91200F3 for ; Thu, 24 Aug 2017 08:49:58 -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 rsoYcW9BSvQ2 for ; Thu, 24 Aug 2017 08:49:57 -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 533CF124E15 for ; Thu, 24 Aug 2017 08:49:57 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id A003E943 for ; Thu, 24 Aug 2017 15:49:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoiEsDHb83k6 for ; Thu, 24 Aug 2017 10:49:56 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 6ECEA645 for ; Thu, 24 Aug 2017 10:49:56 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id d36so801637uag.2 for ; Thu, 24 Aug 2017 08:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=To3EbagqZ1sSKJaF5tTVMnecy7mArM3q9C1B+SAx69c=; b=XAz1p5tJTafM8HyeNkHVMu5hnQ7ihlOv2tPjNulX/E4DH4Bg6SytKkZlqotOrXdRnO ASvwwdevV4QOg8Hpnn6QjPy35ATyXyF7JgVViR5Y9Sr/+69q/QEmaRjT2seoa0t6E7hp 6NmLS3FctQ7HBYSmOHqM+oH43PabCSH94vUbUqXdk0LCNTzFpqKUbYIakauunKgDGzJ8 zWMdQZ4RKbr/ou5UALUbLCjlUc5VT6+Rj4hMC0MaKctPEi77OeaDeJlQWhJDnZGaQN1r oa2SW2EpjQZZh4FPiQC5hZTL4DturIPhS1xS1r0FXu/HEjnO3JLDyfv0wp7Ej8eh1YnG M95w== 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=To3EbagqZ1sSKJaF5tTVMnecy7mArM3q9C1B+SAx69c=; b=ji6SpvB59BOIFXv1BJjxtpP3j0FBtpm61j97iBaLgwnk8aLaiCGvLMY0t3Cg4MDXbQ w15MDujTRLMMftk69crr54+rneiAzc5h7eMG15+CRAy/tfVPFlX62Djuwd1tQ4H3N8xK rH3iMgY8Ju/cqH+d0n6WWb8+hWT0u6b88gcUy3BWBY4/5aJhys8bq1nPq7rSY34EXscY 78pT3UFjAoSiYGMgOmiPMr8+vTonwjc4xKnrCEvx/xuuMzcqUSK+Z+i/DxHiaalHeubv GPcVcRkCETJ3S9j8i316bFS+bC0SB93+svDGRr6fHcE/zSJE6k4kBFSt5HAsU/T/AGVD Vbrg== X-Gm-Message-State: AHYfb5g7e4CjVIjGtCnY5PEQr4eH0+L9ugtQhCM1uPgljtdvbZe/jTsF gH0RDA2DPPcSlke+YRDeYB7aoaJhAbqMJPeLUXrHcl46foQZ2p2xDKnl/Kkx1H4FXfY3RLTYuSK 4uo3dqzQxvfwHNiYE X-Received: by 10.31.156.135 with SMTP id f129mr4831108vke.90.1503589795506; Thu, 24 Aug 2017 08:49:55 -0700 (PDT) X-Received: by 10.31.156.135 with SMTP id f129mr4831102vke.90.1503589795293; Thu, 24 Aug 2017 08:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Thu, 24 Aug 2017 08:49:53 -0700 (PDT) In-Reply-To: <0eb44f4890234a8888159c1e222f5d54@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <0eb44f4890234a8888159c1e222f5d54@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Thu, 24 Aug 2017 10:49:53 -0500 Message-ID: To: "Templin, Fred L" Cc: Lorenzo Colitti , james woodyatt , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a1140f270a30f00055781c736" Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:49:59 -0000 --001a1140f270a30f00055781c736 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2017 at 9:57 AM, Templin, Fred L wrote: > Hi David, > > =C3=98 If you want hosts on the same link to communicate directly, we > already know how to do that, use classic multiple host per prefix subnets= . > As I said before this mechanism isn't intended as a universal replacement > for classic subnets. > > > > RFC7934 and =E2=80=98draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80= =99 are > establishing > > operational guidelines for hosts to receive their own private prefixes fo= r > use > > in whatever way they choose. We will want for these hosts to be able to > > establish peer-to-peer communications without having to leverage a shared > > subnet prefix. > > > > Thanks - Fred > RFC7934 simply points out one way to achieve its goals is to assign a prefix to a host, it is also quite clear that SLAAC on classic subnets equally meets it's goals, and even DHCPv6 IA_NA, while less preferred, can meet it's goals in some situations. Also, per host prefixes are clearly brought up by RFC7934 in the context of reducing ND traffic. RFC7934 expresses no preference for host per prefix over classic subnets with SLAAC, only a preference for host per prefix over classic subnets with DHCPv6 IA_NA. Furthermore, the abstract of =E2=80=98draft-ietf-v6ops-unique-ipv6-prefix-p= er-host=E2=80=99 clearly limits the scope of it's applicability. Again prefix per host is not a universal replacement for classic subnets, and neither RFC7934 or =E2=80=98draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 even attempt= s to make it so. 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 --001a1140f270a30f00055781c736 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu, Aug 24, 2017 at 9:57 AM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

    Hi David,

    =C2=A0=C3=98=C2=A0 If you want hosts on the same link to communicate dire= ctly, we already know how to do that, use classic multiple host per prefix = subnets. As I said before this mechanism isn't intended as a universal = replacement for classic subnets.

    =C2=A0

    RFC7934 and =E2= =80=98draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 are establ= ishing

    operational guide= lines for hosts to receive their own private prefixes for use=

    in whatever way t= hey choose. We will want for these hosts to be able to=

    establish peer-to= -peer communications without having to leverage a shared

    subnet prefix.=

    =C2=A0<= /u>

    Thanks - Fred

    =C2=A0
    RFC7934 simply points= out one way to achieve its goals is to assign a prefix to a host, it is al= so quite clear that SLAAC on classic subnets equally meets it's goals, = and even DHCPv6 IA_NA, while less preferred, can meet it's goals in som= e situations.=C2=A0 Also, per host prefixes are clearly brought up by RFC79= 34 in the context of reducing ND traffic.=C2=A0 RFC7934 expresses no prefer= ence for host per prefix over classic subnets with SLAAC, only a preference= for host per prefix=C2=A0over classic subnets with DHCPv6 IA_NA. =C2=A0

    Furthermore, the abstract of=C2=A0=E2=80=98draft-ietf-v6ops-unique-ipv6-prefix-per-host=E2=80=99 clear= ly limits the scope of it's applicability. Again prefix per host= is not a universal replacement for classic subnets, and neither RFC7934 or= =C2=A0=E2=80=98draft-ietf-v6ops-unique-i= pv6-prefix= -per-host=E2=80=99 even attempts to make it so.

    =
    Thanks
    --=C2=A0
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
    Networking & Telecommunication Services
    Offic= e of Information Technology
    University of Minnesota=C2=A0=C2=A0
    2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --001a1140f270a30f00055781c736-- From nobody Thu Aug 24 09:05:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2435132626 for ; Thu, 24 Aug 2017 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm6eJrI_BL8v for ; Thu, 24 Aug 2017 09:04:58 -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 7A7E3132620 for ; Thu, 24 Aug 2017 09:04:58 -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 v7OG4vTg058514; Thu, 24 Aug 2017 09:04:57 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OG4oHC058351 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 09:04:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 09:04:50 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 09:04:50 -0700 From: "Templin, Fred L" To: David Farmer CC: Lorenzo Colitti , james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] Peer discovery for unique IPv6 prefixes per host Thread-Index: AdMcWrUsVv10IFiBQeGRAzU3kxjuegATBg4AAAIjeAAADjVoAAAQxu6AAA5/N5A= Date: Thu, 24 Aug 2017 16:04:50 +0000 Message-ID: <06c2406b206a45d69d149bf5b3c3a0e6@XCH15-06-08.nw.nos.boeing.com> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <0eb44f4890234a8888159c1e222f5d54@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_06c2406b206a45d69d149bf5b3c3a0e6XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:05:01 -0000 --_000_06c2406b206a45d69d149bf5b3c3a0e6XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCg0Kw5ggIFJGQzc5MzQgc2ltcGx5IHBvaW50cyBvdXQgb25lIHdheSB0byBh Y2hpZXZlIGl0cyBnb2FscyBpcyB0byBhc3NpZ24gYSBwcmVmaXggdG8gYSBob3N0LCBpdCBpcyBh bHNvIHF1aXRlIGNsZWFyIHRoYXQgU0xBQUMgb24gY2xhc3NpYyBzdWJuZXRzIGVxdWFsbHkgbWVl dHMgaXQncyBnb2FscywgYW5kIGV2ZW4gREhDUHY2IElBX05BLCB3aGlsZSBsZXNzIHByZWZlcnJl ZCwgY2FuIG1lZXQgaXQncyBnb2FscyBpbiBzb21lIHNpdHVhdGlvbnMuICBBbHNvLCBwZXIgaG9z dCBwcmVmaXhlcyBhcmUgY2xlYXJseSBicm91Z2h0IHVwIGJ5IFJGQzc5MzQgaW4gdGhlIGNvbnRl eHQgb2YgcmVkdWNpbmcgTkQgdHJhZmZpYy4gIFJGQzc5MzQgZXhwcmVzc2VzIG5vIHByZWZlcmVu Y2UgZm9yIGhvc3QgcGVyIHByZWZpeCBvdmVyIGNsYXNzaWMgc3VibmV0cyB3aXRoIFNMQUFDLCBv bmx5IGEgcHJlZmVyZW5jZSBmb3IgaG9zdCBwZXIgcHJlZml4IG92ZXIgY2xhc3NpYyBzdWJuZXRz IHdpdGggREhDUHY2IElBX05BLg0KDQpUaGlzIGFwcHJvYWNoIGRvZXMgcmVkdWNlIE5EIG1lc3Nh Z2luZy4gSW5zdGVhZCBvZiBvbmUgUmVkaXJlY3QgcGVyIGVhY2ggc2luZ2xldG9uIElQdjYNCmRl c3RpbmF0aW9uIGl0IGlzIG9uZSBSZWRpcmVjdCBwZXIgZGVsZWdhdGVkIHByZWZpeC4gVGhlcmUg aXMgbm8gREFEIG9uIHRoZSBsaW5rLCBlaXRoZXIsIGFzDQp0aGUgZGVsZWdhdGVkIHByZWZpeGVz IGFyZSBub3QgYXNzaWduZWQgdG8gdGhlIGxpbmsgb3ZlciB3aGljaCB0aGV5IGFyZSBkZWxlZ2F0 ZWQuDQoNCg0Kw5ggIEZ1cnRoZXJtb3JlLCB0aGUgYWJzdHJhY3Qgb2Yg4oCYZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3TigJkgY2xlYXJseSBsaW1pdHMgdGhlIHNj b3BlIG9mIGl0J3MgYXBwbGljYWJpbGl0eS4gQWdhaW4gcHJlZml4IHBlciBob3N0IGlzIG5vdCBh IHVuaXZlcnNhbCByZXBsYWNlbWVudCBmb3IgY2xhc3NpYyBzdWJuZXRzLCBhbmQgbmVpdGhlciBS RkM3OTM0IG9yIOKAmGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 4oCZIGV2ZW4gYXR0ZW1wdHMgdG8gbWFrZSBpdCBzby4NCg0KSSByZWFkIHRoYXQgYWJzdHJhY3Qg YXMgYXBwbHlpbmcgdG8gYW55IGxpbmsgdHlwZS4gSXQgc2F5czoNCg0K4oCcVHlwaWNhbGx5IGhv c3RzIChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29yaywgZWl0aGVyIHdpcmVkIG9yIHdp cmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBXaUZpLCBldGPigJ0NCg0KVGhlIOKAnGV0Yy7igJ0g bWVhbnMgdGhhdCB0aGlzIGNhbiBhcHBseSB0byBhbnkgbGluayB0eXBlLiBUaGVyZSB3aWxsIGJl IGEgdmVyeSBicm9hZA0KZG9tYWluIG9mIGFwcGxpY2FiaWxpdHksIGJ1dCBpbiB0aGUgZW5kIGxp bmtzIGFyZSBsaW5rcyBhbmQgSVB2NiBORCBhcHBsaWVzLg0KDQpUaGFua3MgLSBGcmVkDQoNCg0K DQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NClNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMjQsIDIwMTcgODo1MCBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xl LmNvbT47IGphbWVzIHdvb2R5YXR0IDxqaHdAZ29vZ2xlLmNvbT47IHY2b3BzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVlIElQdjYgcHJlZml4 ZXMgcGVyIGhvc3QNCg0KDQoNCk9uIFRodSwgQXVnIDI0LCAyMDE3IGF0IDk6NTcgQU0sIFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGkgRGF2aWQsDQogPiAgSWYgeW91IHdhbnQgaG9zdHMg b24gdGhlIHNhbWUgbGluayB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSwgd2UgYWxyZWFkeSBrbm93 IGhvdyB0byBkbyB0aGF0LCB1c2UgY2xhc3NpYyBtdWx0aXBsZSBob3N0IHBlciBwcmVmaXggc3Vi bmV0cy4gQXMgSSBzYWlkIGJlZm9yZSB0aGlzIG1lY2hhbmlzbSBpc24ndCBpbnRlbmRlZCBhcyBh IHVuaXZlcnNhbCByZXBsYWNlbWVudCBmb3IgY2xhc3NpYyBzdWJuZXRzLg0KDQpSRkM3OTM0IGFu ZCDigJhkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdOKAmSBhcmUg ZXN0YWJsaXNoaW5nDQpvcGVyYXRpb25hbCBndWlkZWxpbmVzIGZvciBob3N0cyB0byByZWNlaXZl IHRoZWlyIG93biBwcml2YXRlIHByZWZpeGVzIGZvciB1c2UNCmluIHdoYXRldmVyIHdheSB0aGV5 IGNob29zZS4gV2Ugd2lsbCB3YW50IGZvciB0aGVzZSBob3N0cyB0byBiZSBhYmxlIHRvDQplc3Rh Ymxpc2ggcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIHdpdGhvdXQgaGF2aW5nIHRvIGxldmVy YWdlIGEgc2hhcmVkDQpzdWJuZXQgcHJlZml4Lg0KDQpUaGFua3MgLSBGcmVkDQoNClJGQzc5MzQg c2ltcGx5IHBvaW50cyBvdXQgb25lIHdheSB0byBhY2hpZXZlIGl0cyBnb2FscyBpcyB0byBhc3Np Z24gYSBwcmVmaXggdG8gYSBob3N0LCBpdCBpcyBhbHNvIHF1aXRlIGNsZWFyIHRoYXQgU0xBQUMg b24gY2xhc3NpYyBzdWJuZXRzIGVxdWFsbHkgbWVldHMgaXQncyBnb2FscywgYW5kIGV2ZW4gREhD UHY2IElBX05BLCB3aGlsZSBsZXNzIHByZWZlcnJlZCwgY2FuIG1lZXQgaXQncyBnb2FscyBpbiBz b21lIHNpdHVhdGlvbnMuICBBbHNvLCBwZXIgaG9zdCBwcmVmaXhlcyBhcmUgY2xlYXJseSBicm91 Z2h0IHVwIGJ5IFJGQzc5MzQgaW4gdGhlIGNvbnRleHQgb2YgcmVkdWNpbmcgTkQgdHJhZmZpYy4g IFJGQzc5MzQgZXhwcmVzc2VzIG5vIHByZWZlcmVuY2UgZm9yIGhvc3QgcGVyIHByZWZpeCBvdmVy IGNsYXNzaWMgc3VibmV0cyB3aXRoIFNMQUFDLCBvbmx5IGEgcHJlZmVyZW5jZSBmb3IgaG9zdCBw ZXIgcHJlZml4IG92ZXIgY2xhc3NpYyBzdWJuZXRzIHdpdGggREhDUHY2IElBX05BLg0KDQpGdXJ0 aGVybW9yZSwgdGhlIGFic3RyYWN0IG9mIOKAmGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N04oCZIGNsZWFybHkgbGltaXRzIHRoZSBzY29wZSBvZiBpdCdzIGFwcGxp Y2FiaWxpdHkuIEFnYWluIHByZWZpeCBwZXIgaG9zdCBpcyBub3QgYSB1bml2ZXJzYWwgcmVwbGFj ZW1lbnQgZm9yIGNsYXNzaWMgc3VibmV0cywgYW5kIG5laXRoZXIgUkZDNzkzNCBvciDigJhkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdOKAmSBldmVuIGF0dGVtcHRz IHRvIG1ha2UgaXQgc28uDQoNClRoYW5rcw0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpm YXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcg JiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hu b2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAg ICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENl bGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg== --_000_06c2406b206a45d69d149bf5b3c3a0e6XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLmdtYWlsLW0yMTIxOTE5MjAxNTA1OTk0NjI3bXNvbGlzdHBh cmFncmFwaCwgbGkuZ21haWwtbTIxMjE5MTkyMDE1MDU5OTQ2Mjdtc29saXN0cGFyYWdyYXBoLCBk aXYuZ21haWwtbTIxMjE5MTkyMDE1MDU5OTQ2Mjdtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLW1fMjEyMTkxOTIwMTUwNTk5NDYyN21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxOTUxMjAzNTIwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxOTk2NzU4OTQgNjM3OTM1NzEwIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UkZD NzkzNCBzaW1wbHkgcG9pbnRzIG91dCBvbmUgd2F5IHRvIGFjaGlldmUgaXRzIGdvYWxzIGlzIHRv IGFzc2lnbiBhIHByZWZpeCB0byBhIGhvc3QsIGl0IGlzIGFsc28gcXVpdGUgY2xlYXIgdGhhdCBT TEFBQyBvbiBjbGFzc2ljIHN1Ym5ldHMgZXF1YWxseSBtZWV0cyBpdCdzIGdvYWxzLCBhbmQgZXZl biBESENQdjYgSUFfTkEsIHdoaWxlIGxlc3MgcHJlZmVycmVkLCBjYW4gbWVldCBpdCdzDQogZ29h bHMgaW4gc29tZSBzaXR1YXRpb25zLiZuYnNwOyBBbHNvLCBwZXIgaG9zdCBwcmVmaXhlcyBhcmUg Y2xlYXJseSBicm91Z2h0IHVwIGJ5IFJGQzc5MzQgaW4gdGhlIGNvbnRleHQgb2YgcmVkdWNpbmcg TkQgdHJhZmZpYy4mbmJzcDsgUkZDNzkzNCBleHByZXNzZXMgbm8gcHJlZmVyZW5jZSBmb3IgaG9z dCBwZXIgcHJlZml4IG92ZXIgY2xhc3NpYyBzdWJuZXRzIHdpdGggU0xBQUMsIG9ubHkgYSBwcmVm ZXJlbmNlIGZvciBob3N0IHBlciBwcmVmaXgmbmJzcDtvdmVyIGNsYXNzaWMNCiBzdWJuZXRzIHdp dGggREhDUHY2IElBX05BLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+VGhpcyBhcHByb2FjaCBkb2VzIHJlZHVjZSBORCBtZXNzYWdpbmcuIEluc3Rl YWQgb2Ygb25lIFJlZGlyZWN0IHBlciBlYWNoIHNpbmdsZXRvbiBJUHY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PmRlc3RpbmF0aW9uIGl0IGlzIG9uZSBSZWRpcmVjdCBwZXIgZGVsZWdhdGVkIHByZWZpeC4gVGhl cmUgaXMgbm8gREFEIG9uIHRoZSBsaW5rLCBlaXRoZXIsIGFzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnRoZSBk ZWxlZ2F0ZWQgcHJlZml4ZXMgYXJlIG5vdCBhc3NpZ25lZCB0byB0aGUgbGluayBvdmVyIHdoaWNo IHRoZXkgYXJlIGRlbGVnYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5GdXJ0aGVybW9yZSwgdGhl IGFic3RyYWN0IG9mJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAmGRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N04oCZIGNsZWFybHkgbGltaXRzIHRo ZSBzY29wZSBvZiBpdCdzIGFwcGxpY2FiaWxpdHkuDQo8L3NwYW4+QWdhaW4gcHJlZml4IHBlciBo b3N0IGlzIG5vdCBhIHVuaXZlcnNhbCByZXBsYWNlbWVudCBmb3IgY2xhc3NpYyBzdWJuZXRzLCBh bmQgbmVpdGhlciBSRkM3OTM0IG9yJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKA mGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N04oCZIGV2ZW4gYXR0 ZW1wdHMgdG8gbWFrZSBpdCBzby48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHJlYWQgdGhhdCBhYnN0cmFjdCBhcyBhcHBseWluZyB0 byBhbnkgbGluayB0eXBlLiBJdCBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+4oCcVHlwaWNhbGx5IGhvc3RzIChzdWJzY3JpYmVycykgb24gYSBzaGFyZWQgbmV0d29y aywgZWl0aGVyIHdpcmVkIG9yIHdpcmVsZXNzLCBzdWNoIGFzIEV0aGVybmV0LCBXaUZpLCBldGPi gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZSDigJxldGMu4oCdIG1l YW5zIHRoYXQgdGhpcyBjYW4gYXBwbHkgdG8gYW55IGxpbmsgdHlwZS4gVGhlcmUgd2lsbCBiZSBh IHZlcnkgYnJvYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ZG9tYWluIG9mIGFwcGxpY2FiaWxpdHksIGJ1dCBp biB0aGUgZW5kIGxpbmtzIGFyZSBsaW5rcyBhbmQgSVB2NiBORCBhcHBsaWVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzIC0gRnJlZCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERhdmlkIEZhcm1lciBb bWFpbHRvOmZhcm1lckB1bW4uZWR1XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1 c3QgMjQsIDIwMTcgODo1MCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTG9yZW56byBDb2xp dHRpICZsdDtsb3JlbnpvQGdvb2dsZS5jb20mZ3Q7OyBqYW1lcyB3b29keWF0dCAmbHQ7amh3QGdv b2dsZS5jb20mZ3Q7OyB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2 b3BzXSBQZWVyIGRpc2NvdmVyeSBmb3IgdW5pcXVlIElQdjYgcHJlZml4ZXMgcGVyIGhvc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgMjQsIDIw MTcgYXQgOTo1NyBBTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIERhdmlkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsNCjwvc3Bhbj5JZiB5b3Ugd2FudCBob3N0cyBvbiB0aGUgc2FtZSBsaW5r IHRvIGNvbW11bmljYXRlIGRpcmVjdGx5LCB3ZSBhbHJlYWR5IGtub3cgaG93IHRvIGRvIHRoYXQs IHVzZSBjbGFzc2ljIG11bHRpcGxlIGhvc3QgcGVyIHByZWZpeCBzdWJuZXRzLiBBcyBJIHNhaWQg YmVmb3JlIHRoaXMgbWVjaGFuaXNtIGlzbid0IGludGVuZGVkIGFzIGEgdW5pdmVyc2FsIHJlcGxh Y2VtZW50IGZvciBjbGFzc2ljIHN1Ym5ldHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UkZDNzkzNCBhbmQg4oCYZHJhZnQtaWV0Zi12Nm9w cy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3TigJkgYXJlIGVzdGFibGlzaGluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPm9wZXJhdGlvbmFsIGd1aWRlbGluZXMgZm9yIGhvc3RzIHRvIHJlY2VpdmUgdGhl aXIgb3duIHByaXZhdGUgcHJlZml4ZXMgZm9yIHVzZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPmluIHdoYXRl dmVyIHdheSB0aGV5IGNob29zZS4gV2Ugd2lsbCB3YW50IGZvciB0aGVzZSBob3N0cyB0byBiZSBh YmxlIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ZXN0YWJsaXNoIHBlZXItdG8tcGVlciBjb21tdW5pY2F0 aW9ucyB3aXRob3V0IGhhdmluZyB0byBsZXZlcmFnZSBhIHNoYXJlZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PnN1Ym5ldCBwcmVmaXguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ VGhhbmtzIC0gRnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRkM3OTM0IHNpbXBseSBw b2ludHMgb3V0IG9uZSB3YXkgdG8gYWNoaWV2ZSBpdHMgZ29hbHMgaXMgdG8gYXNzaWduIGEgcHJl Zml4IHRvIGEgaG9zdCwgaXQgaXMgYWxzbyBxdWl0ZSBjbGVhciB0aGF0IFNMQUFDIG9uIGNsYXNz aWMgc3VibmV0cyBlcXVhbGx5IG1lZXRzIGl0J3MgZ29hbHMsIGFuZCBldmVuIERIQ1B2NiBJQV9O QSwgd2hpbGUgbGVzcyBwcmVmZXJyZWQsIGNhbiBtZWV0IGl0J3MgZ29hbHMgaW4gc29tZQ0KIHNp dHVhdGlvbnMuJm5ic3A7IEFsc28sIHBlciBob3N0IHByZWZpeGVzIGFyZSBjbGVhcmx5IGJyb3Vn aHQgdXAgYnkgUkZDNzkzNCBpbiB0aGUgY29udGV4dCBvZiByZWR1Y2luZyBORCB0cmFmZmljLiZu YnNwOyBSRkM3OTM0IGV4cHJlc3NlcyBubyBwcmVmZXJlbmNlIGZvciBob3N0IHBlciBwcmVmaXgg b3ZlciBjbGFzc2ljIHN1Ym5ldHMgd2l0aCBTTEFBQywgb25seSBhIHByZWZlcmVuY2UgZm9yIGhv c3QgcGVyIHByZWZpeCZuYnNwO292ZXIgY2xhc3NpYyBzdWJuZXRzIHdpdGgNCiBESENQdjYgSUFf TkEuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5GdXJ0aGVybW9yZSwgdGhlIGFic3RyYWN0IG9mJm5ic3A7PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPuKAmGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o b3N04oCZIGNsZWFybHkgbGltaXRzIHRoZSBzY29wZSBvZiBpdCdzIGFwcGxpY2FiaWxpdHkuDQo8 L3NwYW4+QWdhaW4gcHJlZml4IHBlciBob3N0IGlzIG5vdCBhIHVuaXZlcnNhbCByZXBsYWNlbWVu dCBmb3IgY2xhc3NpYyBzdWJuZXRzLCBhbmQgbmVpdGhlciBSRkM3OTM0IG9yJm5ic3A7PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAmGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N04oCZIGV2ZW4gYXR0ZW1wdHMgdG8gbWFrZSBpdCBzby48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHUiIHRhcmdl dD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFt cDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24g VGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4N CjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6 IDYxMi02MjYtMDgxNTxicj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5Jm5ic3A7Jm5ic3A7 IENlbGw6IDYxMi04MTItOTk1Mjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_06c2406b206a45d69d149bf5b3c3a0e6XCH150608nwnosboeingcom_-- From nobody Thu Aug 24 10:38:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576DB132646 for ; Thu, 24 Aug 2017 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in43Xz6CJ0gA for ; Thu, 24 Aug 2017 10:38:02 -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 D93D213247A for ; Thu, 24 Aug 2017 10:38:02 -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 v7OHc2wN013412; Thu, 24 Aug 2017 10:38:02 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7OHc0Tv013395 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 24 Aug 2017 10:38:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 24 Aug 2017 10:38:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 24 Aug 2017 10:38:00 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcw== Date: Thu, 24 Aug 2017 17:37:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 17:38:04 -0000 In section 2, the document says: " o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router" Please change to say: "o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router unless the shared network explicitly permits peer-to-peer operations" Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 24 12:45:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680F113213F for ; Thu, 24 Aug 2017 12:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4Fl4amhG2jeu for ; Thu, 24 Aug 2017 12:44:59 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F269A1321A4 for ; Thu, 24 Aug 2017 12:44:58 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 78BF32D5043; Thu, 24 Aug 2017 19:44:57 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 46097FDE7D4D; Thu, 24 Aug 2017 21:44:54 +0200 (CEST) From: Ole Troan Message-Id: <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_51872C5B-CCB5-4249-B180-4F64A70F5565"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 24 Aug 2017 21:44:53 +0200 In-Reply-To: <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> Cc: v6ops@ietf.org To: Simon Hobson References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:45:00 -0000 --Apple-Mail=_51872C5B-CCB5-4249-B180-4F64A70F5565 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simon, >>> If you want hosts on the same link to communicate directly, we = already know how to do that, use classic multiple host per prefix = subnets. As I said before this mechanism isn't intended as a universal = replacement for classic subnets. >>=20 >> Indeed. The only difference is that host to host now happens at L3 = instead of L2. >> That hosts are on the same link is typically emulated at L2, we = largely stopped building shared media links in the 80s. ;-) >> This is just making the L3 topology reflect reality. >=20 > You seem to be confusing shared media with broadcast domain. The fact = that we now use L2 switching (ie no longer a shared media) doesn't = affect the fact that the broadcast domain is now (excepting deliberate = filtering) the same. Just switching from shared media (eg 10base2 and = 10base5) to switched media (10/100/1000baseT) hasn't moved anything = between L2 and L3 - again, absent adding features such as filtering to = actively prevent the normal L2-L2 process. L2 bridging is just emulating a shared media out of a star topology. In this model the L3 links follow the physical topology. I.e. routing = all the way to the edge. And no need for bridges. Ole --Apple-Mail=_51872C5B-CCB5-4249-B180-4F64A70F5565 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZnyy1AAoJEL7aWKiYQt92m+oP/0OxKh29n8wbeka7e1xpNVll /StiBWVeBchSmbK6Zx71oJMQh6wtwcI/wJLUiIzQXRfeFAMbfQawtO0klk/uDCWW RFQrtSMjVTbB/GjZ3LSFszAMiAWfdGwwvWsCLuZTom8nsK/CYZfluU0HkVrtoZyE GtfcuZesi83F1tflLgIukMvVohZJajM5aeqSAanjYMD0Qg5bG3rrp3MnrrmPdmyk i5iRehVc+EFFcdgrjiKojjnHMRW4MC8JOIBkp1d2Y8wT1x/pX1wpulRRkRFsIP5z IVs7hJ6MTcfCz/hAOKAj6cSqnR07JnInOlOeQFbJp19ZNwqpXWR3u9De9mDL1W/C F5pOb7Zm+KgKMQIKSqlDEWpKJ17PgVhu60R3mwSfZUVU6UOIHSLuNHTG+NfXKb8a noIAZkiBu9oXiCgZWRz07wl4QnCS1ivDBQuWUvMedF5ujYDLFGmzLdQyQmliJ3Dd hSzDBSMW2GF63s7llkTMAvhWQYvLmGakKULzj+6sDaQ24QZm0m2mNACdE+9FPDrB eWUiveVFA+SN/O8wk+Un5rMu2D+4lRGwgicAaqQJSNj1hDZagXAIREqww+QXzreB wi7V9o3nV9XlS7WTfSJ5QwlGXTIFBI1tZLe+wSU99MuF3aA60mpK0qocM8o3MZbN JGkbcs74Z9+Bx8P8IVnR =q/RE -----END PGP SIGNATURE----- --Apple-Mail=_51872C5B-CCB5-4249-B180-4F64A70F5565-- From nobody Thu Aug 24 12:50:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53313219C for ; Thu, 24 Aug 2017 12:50:51 -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 yjclD22HD7Gx for ; Thu, 24 Aug 2017 12:50:49 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9678D13207A for ; Thu, 24 Aug 2017 12:50:49 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D99932D5045; Thu, 24 Aug 2017 19:50:48 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id F1CB7FDE98C4; Thu, 24 Aug 2017 21:50:47 +0200 (CEST) From: Ole Troan Message-Id: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3FB9FAE9-E594-41F1-9218-0592DAD238BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 24 Aug 2017 21:50:47 +0200 In-Reply-To: Cc: David Farmer , james woodyatt , "v6ops@ietf.org" To: Mark Smith References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:50:51 -0000 --Apple-Mail=_3FB9FAE9-E594-41F1-9218-0592DAD238BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, >>> If you want hosts on the same link to communicate directly, we = already know how to do that, use classic multiple host per prefix = subnets. As I said before this mechanism isn't intended as a universal = replacement for classic subnets. >>=20 >> Indeed. The only difference is that host to host now happens at L3 = instead of L2. >> That hosts are on the same link is typically emulated at L2, we = largely stopped building shared media links in the 80s. ;-) >> This is just making the L3 topology reflect reality. >>=20 >=20 > The trouble is that IPv6 by default doesn't really reflect that > reality. Its link layer reachability assumptions are inconsistent. >=20 > Per RFC5942, the link-local prefix is assumed to to be on-link, so > link-local destinations are assumed to be directly reachable across > the link, while all other prefixes are to be assumed off-link, so all > other destinations have to be reached via a router. >=20 > The link-local direct reachability assumption also exists is in the > RFC6724 source/destination address selection algorithm, as link-local > destinations are preferred over ULA and GUAs if there is a set of > destinations to choose from. >=20 > An a "private VLAN", this LL on-link/GUA/ULA off-link assumption could > cause an end-user application problems. For pure IPv6, the LL > connection attempt will have to fail before the ULA and/or GUA > destinations are attempted, likely incurring end-user visible > multi-second delays, and then they're likely to succeed because the > router will trombone the traffic back onto the link to the > destination. (i.e., Nodes A and B on same link, A -> B via LL fails, A > -> RTR -> B via ULA/GUA succeeds). I don't think we should blame IPv6 subnet model for the hack of private = VLANs. And of course if you map L3 subnets to the physical topology and do = s/bridging/routing/g then this problem doesn't exist. > If the application is using Happy Eyeballs, the failure of the IPv6 LL > would cause the IPv4 alternative to be used even though alternative > ULA or GUA destinations would have probably worked immediately. A typical application wouldn't not connect using an link-local address. Best regards, Ole --Apple-Mail=_3FB9FAE9-E594-41F1-9218-0592DAD238BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZny4XAAoJEL7aWKiYQt92WK4QAMBolxLNJszdzs9d0TNNaO5N BiS3TwakQZ/2V5SJjuymxBR8U+1zEBwiLVyohzlDptHP4zXm+HK223j6dfretkbk /1/S6987/v0IHn0gF7evmYa0Oqng3MndLVakj/C+joR1Yj16AjzChi2efZ9FNtj2 ZTI3heVB6m6rcS3pJv3tPv0Esr4h5wUN+yMfa6NI8B2Mg+0JaY2waknKD17ErmHP TKDqMvZacWFWWS039GODXRuZu9mjc8IPlQegc0Ia/pATOPJqn4ycaBwzkkoMJKrW EHLfItr3achIyxTI7SCBa7hVYZSN2DaezpTNUYePKg/ifQp8C6M+X7dSIyLLzeqi j6qyZxLn2yMS1OHrDwyr22LcJQXlWOlYL1nSQ1mkLejrMeHjNNAW2P9ng2iuJg7W tnsDh8ttHEWU6cb8VsQORdD+ZvM31jkZ6qwXEh6j6/NnGW1J/zbNxWXinnwlxm4A zqum1WP69PIX0PXgJ69uMxk3OBICCs2ja8BshYGsPK/6KK9XFybOxX9mnQad/505 4/d/ABspLEJBzRbrrDwLLZ6I6UHCLN+hRTLQRdgvuOKG9ukIXT6aVsY0sxme85qS 6xC8+HLtsRnee4Sje82kZdEs7nBDAe8jXWNhVq95EJhUa1P78P1x0TDoJ7E6YMTt 3FYl2Ccs1CL0QAfmlkoZ =Sj8a -----END PGP SIGNATURE----- --Apple-Mail=_3FB9FAE9-E594-41F1-9218-0592DAD238BF-- From nobody Thu Aug 24 13:15:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B0132113 for ; Thu, 24 Aug 2017 13:15: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW_dlN0Yh0A6 for ; Thu, 24 Aug 2017 13:15:38 -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 ABBC61321C4 for ; Thu, 24 Aug 2017 13:15:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9B1F31A071 for ; Thu, 24 Aug 2017 20:15:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> Date: Thu, 24 Aug 2017 21:15:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <937DF46E-BF31-4998-AF96-A80A32376B64@thehobsons.co.uk> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:15:41 -0000 Ole Troan wrote: > L2 bridging is just emulating a shared media out of a star topology. Hmm, an interesting view on things. But in terms of "what can talk to = what" there is no difference. > In this model the L3 links follow the physical topology. I.e. routing = all the way to the edge. And no need for bridges. So are you saying that there is a separate router port per host ? From nobody Thu Aug 24 13:18:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6071913235A for ; Thu, 24 Aug 2017 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUxw_Q2IM2yf for ; Thu, 24 Aug 2017 13:18:22 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889A21323A2 for ; Thu, 24 Aug 2017 13:18:22 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6807942921 for ; Thu, 24 Aug 2017 22:18:20 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 585F94291E; Thu, 24 Aug 2017 22:18:20 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 5569F20928; Thu, 24 Aug 2017 22:18:20 +0200 (CEST) Date: Thu, 24 Aug 2017 22:18:20 +0200 From: Gert Doering To: Simon Hobson Cc: "v6ops@ietf.org list" Message-ID: <20170824201820.GF45648@Space.Net> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> <937DF46E-BF31-4998-AF96-A80A32376B64@thehobsons.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <937DF46E-BF31-4998-AF96-A80A32376B64@thehobsons.co.uk> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:18:30 -0000 Hi, On Thu, Aug 24, 2017 at 09:15:32PM +0100, Simon Hobson wrote: > So are you saying that there is a separate router port per host ? On modern switch/router gear, the difference between "a switch port" and "a router port" is sometimes only a config flag. No performance difference, just looking at different parts of the header... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Aug 24 17:51:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0751329CD for ; Thu, 24 Aug 2017 17:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXY0XA6skSk7 for ; Thu, 24 Aug 2017 17:51:00 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80120132377 for ; Thu, 24 Aug 2017 17:51:00 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id j46so3600669uag.1 for ; Thu, 24 Aug 2017 17:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Jcii25RuA5gPV0isIi2/+AItr4/KmfOYW9AC68cO/I=; b=f+genoHaVFRaGFEBJbAqANgh1b8ZkLQvPUXpZopZK/9o5fOLHxYrPQId2+YgfoZ3BX IJxF/P0SY+S1f3o/bdhAQNjI361UK4Xz2BLe8b/KUyCKpP64RT5cFHrYtz3WsEPjro08 t4zq7gXvmAXWJAbeCSQt2UN/BISnYOGXIbISz1hbvjR8lrav+jmX/6jCZIkbfX3PUW0n HgH6NMncZv4fhdT99llmJ2Z63RzFFr7vjCsRm2425mp3asjmVDhjKNRwP11mTsUV11Xk yIZUpsmj/TdxUxWpZJlGCxE9Z+d4fPPdhgMbD/vpvad9gjZcA5bsWDaOE0mDpvVMNSxa XhGA== 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=+Jcii25RuA5gPV0isIi2/+AItr4/KmfOYW9AC68cO/I=; b=Hzg0+Df12Q4nCQvlcelCWP7Tu7zxf+l5S85Rg+yqAADGTRdDC5l+DQnCpIzKGkqJUs FsLpt+sAmFMvKoR2FQxSj52Gn1hzcErWmG+RhIm22lU8zExodcE1xvFQw/vL5NCnB5dT FEY9ZnFIURRT4spisqoy+hDC6LvEFWImj2G1l+d5iIoHUCPt4m6OieZKFR9uDjizyqlS Fg+5ZxuhiqY7OWe+z1Ahfn/04pxsrW/iMdhvFRdhU1v9++VNYpbXPeOuDTyFir+rY04t nTNH8blAyFOWio3hCiZ+CZdv2DaGLHdAphkhM0F0JFLiMu7WAMDiqI8QlP4uIIdwJanm CqLQ== X-Gm-Message-State: AHYfb5gpFnIobSOgi4pGScpC1zF2t6+1SM0Ox0myiKaoa8xhJK8Etivi 2diEiA+orQmwmwJ3YSlGV5ZWvfRvXg== X-Received: by 10.176.21.178 with SMTP id i47mr5663985uae.120.1503622259421; Thu, 24 Aug 2017 17:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Thu, 24 Aug 2017 17:50:29 -0700 (PDT) In-Reply-To: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> From: Mark Smith Date: Fri, 25 Aug 2017 10:50:29 +1000 Message-ID: To: Ole Troan Cc: David Farmer , james woodyatt , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 00:51:02 -0000 On 25 August 2017 at 05:50, Ole Troan wrote: > Mark, > >>>> If you want hosts on the same link to communicate directly, we already know how to do that, use classic multiple host per prefix subnets. As I said before this mechanism isn't intended as a universal replacement for classic subnets. >>> >>> Indeed. The only difference is that host to host now happens at L3 instead of L2. >>> That hosts are on the same link is typically emulated at L2, we largely stopped building shared media links in the 80s. ;-) >>> This is just making the L3 topology reflect reality. >>> >> >> The trouble is that IPv6 by default doesn't really reflect that >> reality. Its link layer reachability assumptions are inconsistent. >> >> Per RFC5942, the link-local prefix is assumed to to be on-link, so >> link-local destinations are assumed to be directly reachable across >> the link, while all other prefixes are to be assumed off-link, so all >> other destinations have to be reached via a router. >> >> The link-local direct reachability assumption also exists is in the >> RFC6724 source/destination address selection algorithm, as link-local >> destinations are preferred over ULA and GUAs if there is a set of >> destinations to choose from. >> >> An a "private VLAN", this LL on-link/GUA/ULA off-link assumption could >> cause an end-user application problems. For pure IPv6, the LL >> connection attempt will have to fail before the ULA and/or GUA >> destinations are attempted, likely incurring end-user visible >> multi-second delays, and then they're likely to succeed because the >> router will trombone the traffic back onto the link to the >> destination. (i.e., Nodes A and B on same link, A -> B via LL fails, A >> -> RTR -> B via ULA/GUA succeeds). > > I don't think we should blame IPv6 subnet model for the hack of private VLANs. I don't think I am. I think some things have changed over time, and the consequences of the changes may not have been fully recognised. - we have a new type of link now - "constrained broadcast multi-access" (in addition to p2p, NBMA, and "Broadcast Multi-Access" e.g. traditional Ethernet/TR/ARCnet etc.). There are multiple examples - Private VLANs, TR101 VLANs with 1:N forwarding, 802.11 with station isolation. They're common and they're not going to go away. - we are now attaching untrusted and potentially malicious hosts to the same link. We used to only attach trusted hosts to the same link, with link boundaries (e.g., VLAN boundaries) being the security/trust domain boundaries. Trust of hosts/nodes was also inherent in the link-layer forwarding capability of any-to-any. Private VLANs etc. are a response to now untrusted host attachment to the same link. I think it should be clear in discussion and now specifications as to whether the hosts or more generally nodes attached to the same link are trusted or not by their link peers. > And of course if you map L3 subnets to the physical topology and do s/bridging/routing/g then this problem doesn't exist. > RFC4007 permits packets with LLs to be routed, as long as it is back out the same interface that the packet was received on. However, it isn't possible to instruct hosts to send LLs to a router to be forwarded back onto the link - they'll always ND for the destination because of the RFC5942 LL on-link default. >> If the application is using Happy Eyeballs, the failure of the IPv6 LL >> would cause the IPv4 alternative to be used even though alternative >> ULA or GUA destinations would have probably worked immediately. > > A typical application wouldn't not connect using an link-local address. > MDNS specifies to use LLs, so any application service that is announced using MDNS expects to use LLs. "IPv6 Address Usage Recommendations" https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-03 recommends using IPv6 address scopes to limit the attack surface of listening application services e.g., bind to ULA rather than GUA if the service is only to be accessed from within the local network. In cases where it would be useful and possible, binding a service to only Link-Local addresses reduces that attack surface further. I think there are other benefits of using Link-Local addresses in applications: "How to use IPv6 Link-Local Addresses in Applications" https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 Regards, Mark. From nobody Thu Aug 24 18:32:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76AC1329DE for ; Thu, 24 Aug 2017 18:32:13 -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 1SkVm7_ZtNix for ; Thu, 24 Aug 2017 18:32:12 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501941329DC for ; Thu, 24 Aug 2017 18:32:12 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id b8so6362533pgn.5 for ; Thu, 24 Aug 2017 18:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HIG7olbcd23Mhy7WmMqUn9hsZCYAr94VWc7gJ5+h7c4=; b=dCvABbxerdtKLrEGGX83ulLh25yHVCRdxd23dMQ7kVGJ0SoOH75AXkjvzH/Qk85ue6 vWEf5pTpnMS4M9HMOiQxzOPNTC2d6mb6i5uRfkNewSyntKcqFXzarqRwzSVAH4xPbg50 I6xceRpfFxtUGzpOL+zUcOW9OidXEgy6s+7kUHagTfm4XP6jzAvSP2l3J/+/xeMKHWkC AeB9JJCk2X2OURn3J+RgjVWl4XA//NHM97jwl9FLQPC47gFAVN5jjlnMRoFqfiDUB8Ev wtH0bHOr7bz+mWLs1DxNgDCXWaWTk3ktsjlVWabzP4YGALzWvXQZyr2mP+GktdArLDfA KyGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HIG7olbcd23Mhy7WmMqUn9hsZCYAr94VWc7gJ5+h7c4=; b=lj3xtTEmRXGeGpWCazcsU43B50rKX2lUUrSMNi/BTLEGznZja1V8R/WhrVbdSwTDor RhgKok/f24IjyBAU3mjx4m3FDBiSVJgTYikKLXie+y0SWwN3Yo4ReE7edOh6EzoiCaBc 7TAJZM0lc2vFWgEA1Xn+AKXYvZQ70JT80xRWLCOyYB9Iv8Zp5uUL32NbJgi1MLU/gO4x HQPL+aqPppc1YcTbVQoYkwLIrkTJV9SYoOmZxfgMB+94p0+3GYzecanJBYq+ISxlDTVz ku7WsQWlnoMyB74bn7ehsV9tkL/6tLSMnDQpP6gQ1InYOvK7zj9Crchh/cnLv93a1CXT 7iPQ== X-Gm-Message-State: AHYfb5ijfy0sBUvYb7XlJDz6eR2m5U9Dd3fz60sWb9bEe52IiguJrfS4 oXNXsK5luhN6vQ== X-Received: by 10.98.28.78 with SMTP id c75mr8186334pfc.14.1503624731842; Thu, 24 Aug 2017 18:32:11 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t2sm8906290pgb.88.2017.08.24.18.32.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 18:32:11 -0700 (PDT) To: Mark Smith , Ole Troan Cc: "v6ops@ietf.org" , james woodyatt References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> Date: Fri, 25 Aug 2017 13:32:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 01:32:14 -0000 On 25/08/2017 12:50, Mark Smith wrote: ... > I think it should be clear in discussion and now specifications as to > whether the hosts or more generally nodes attached to the same link > are trusted or not by their link peers. That's a serious and complex issue. We are trying to tackle it for the specific case of forming an Autonomic Control Plane in ANIMA, and it needs 3 substantial drafts so far: draft-ietf-anima-voucher draft-ietf-anima-bootstrapping-keyinfra draft-ietf-anima-autonomic-control-plane At the level of basic IPv6, I don't really see how we can tackle this, except by stating that all nodes are untrustworthy until proved otherwise. ... > I think there are other benefits of using Link-Local addresses in applications: You can't avoid using them during the bootstrap phase of forming a secure network after a cold start. And they come in mighty handy when running an IPv6-only app on a LAN with no IPv6 router ;-). Brian From nobody Fri Aug 25 00:07:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA01132814 for ; Fri, 25 Aug 2017 00:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 40e4SEwd3o0E for ; Fri, 25 Aug 2017 00:07:03 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B606F13203D for ; Fri, 25 Aug 2017 00:07:03 -0700 (PDT) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 235052D5070; Fri, 25 Aug 2017 07:07:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (14G60) In-Reply-To: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> Date: Fri, 25 Aug 2017 09:06:59 +0200 Cc: Mark Smith , "v6ops@ietf.org" , james woodyatt Content-Transfer-Encoding: quoted-printable Message-Id: References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> To: Brian E Carpenter Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:07:06 -0000 > On 25 Aug 2017, at 03:32, Brian E Carpenter w= rote: >=20 >> On 25/08/2017 12:50, Mark Smith wrote: >> ... >> I think it should be clear in discussion and now specifications as to >> whether the hosts or more generally nodes attached to the same link >> are trusted or not by their link peers. >=20 > That's a serious and complex issue. We are trying to tackle it for the > specific case of forming an Autonomic Control Plane in ANIMA, and it > needs 3 substantial drafts so far: > draft-ietf-anima-voucher > draft-ietf-anima-bootstrapping-keyinfra > draft-ietf-anima-autonomic-control-plane >=20 > At the level of basic IPv6, I don't really see how we can tackle this, > except by stating that all nodes are untrustworthy until proved otherwise.= >=20 > ... >> I think there are other benefits of using Link-Local addresses in applica= tions: >=20 > You can't avoid using them during the bootstrap phase of forming a secure > network after a cold start. And they come in mighty handy when running an > IPv6-only app on a LAN with no IPv6 router ;-). If you follow the model of having IP topology follow the physical topology L= ANs are gone. You are left with a set of p2p links.=20 Ole= From nobody Fri Aug 25 00:42:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8509C132A65 for ; Fri, 25 Aug 2017 00:42:37 -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 QgZ5IMkjrDR0 for ; Fri, 25 Aug 2017 00:42:35 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 177F4132320 for ; Fri, 25 Aug 2017 00:42:34 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 51B2FE6065; Fri, 25 Aug 2017 09:42:33 +0200 (CEST) Date: Fri, 25 Aug 2017 09:42:33 +0200 (CEST) Message-Id: <20170825.094233.74747800.sthaug@nethelp.no> To: otroan@employees.org Cc: brian.e.carpenter@gmail.com, jhw@google.com, v6ops@ietf.org From: sthaug@nethelp.no In-Reply-To: References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:42:37 -0000 > If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. Agreed. However, I think this may be an even bigger change, especially for enterprises, than starting to use IPv6. As a networking guy I love p2p links, but I also see how much our IT people love their LANs :-) Steinar Haug, AS2116 From nobody Fri Aug 25 05:18:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32BD13292F for ; Fri, 25 Aug 2017 05:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HjnKuYG9f-sU for ; Fri, 25 Aug 2017 05:18:45 -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 98BAD132027 for ; Fri, 25 Aug 2017 05:18:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 002EF1BC37 for ; Fri, 25 Aug 2017 12:18:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <20170824201820.GF45648@Space.Net> Date: Fri, 25 Aug 2017 13:18:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> <937DF46E-BF31-4998-AF96-A80A32376B64@thehobsons.co.uk> <20170824201820.GF45648@Space.Net> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:18:48 -0000 Gert Doering wrote: >> So are you saying that there is a separate router port per host ? >=20 > On modern switch/router gear, the difference between "a switch port" > and "a router port" is sometimes only a config flag. No performance > difference, just looking at different parts of the header... Hmm, I respectfully disagree there as well. I suspect that some of the people here are mostly familiar with what (to = some of us) is "high end" gear - it is clear that most of you work for = larger organisations where networking kit is generally "not bargain = basement". Down at the bottom end where some of us work (small IT = services provider in my case), L3 capabilities are not something we're = used to seeing in a switch*. That means there's a disconnect between = what different people are talking about when they say "switch". If you say "switch" to me (in the networking context, I also deal with = electrical stuff just to confuse things further) then it means a L2 = device - where all ports are in the same broadcast domain, and any = device can talk directly to any other device. Obviously, once get up from the very lowest spec then VLANs come into = play, but that doesn't really semantically alter the meaning as long as = you consider "all ports in the same VLAN =3D=3D one logical switch". But as you say, many switches have L3 functions. When you talk about L3 = functions, I'd expect someone to say router - ie use the name of a = device which deals with packets at L3. So could I suggest that people be a little more precise in terminology. = If you really mean a L3 device, then don't just use the term "switch" = without qualification as that just leads to confusion - as we've seen = here. * To quantify that, right now, I don't think a single switch I am = responsible for (either internally or on client sites) has L3 functions = in it. I have managed L3 switches (or combined router/switches, or = whatever) in the past, but we don't currently have any under management. From nobody Fri Aug 25 05:48:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE8132BE6 for ; Fri, 25 Aug 2017 05:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 d8alCAOfChlU for ; Fri, 25 Aug 2017 05:47:56 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326F7132027 for ; Fri, 25 Aug 2017 05:47:55 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E286B4414D for ; Fri, 25 Aug 2017 14:47:53 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D395C4292B; Fri, 25 Aug 2017 14:47:53 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C56CF7112F; Fri, 25 Aug 2017 14:47:53 +0200 (CEST) Date: Fri, 25 Aug 2017 14:47:53 +0200 From: Gert Doering To: Simon Hobson Cc: "v6ops@ietf.org list" Message-ID: <20170825124753.GM45648@Space.Net> References: <404b75889d634fb88538498577f9e925@XCH15-06-08.nw.nos.boeing.com> <15D567D7-75C7-4802-9DA1-2F7E66A2F311@thehobsons.co.uk> <986D0DA2-F364-47F7-A643-785D89B87B15@employees.org> <937DF46E-BF31-4998-AF96-A80A32376B64@thehobsons.co.uk> <20170824201820.GF45648@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] Peer discovery for unique IPv6 prefixes per host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:47:58 -0000 Hi, On Fri, Aug 25, 2017 at 01:18:38PM +0100, Simon Hobson wrote: > Gert Doering wrote: > > > On modern switch/router gear, the difference between "a switch port" > > and "a router port" is sometimes only a config flag. No performance > > difference, just looking at different parts of the header... [..] > > So could I suggest that people be a little more precise in terminology. That's exactly why I said "switch/router gear". Most of these boxes are not smart enough to be called a "real router", but have sufficient L3 functionality to do, well, forwarding based on L3 information. Of course there's pure L2 gear out there, but as soon as you have routing functionality in the hardware, the distinction "is this a switch port or a router interface" is really just a config setting. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Aug 25 06:21:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959D1321DC for ; Fri, 25 Aug 2017 06:21:49 -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 gRnfUSNDNlAy for ; Fri, 25 Aug 2017 06:21:48 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DFB132392 for ; Fri, 25 Aug 2017 06:21:47 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A473E2D5049; Fri, 25 Aug 2017 13:21:46 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C86C8FE5E038; Fri, 25 Aug 2017 15:21:43 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_01207DE6-22F5-47CF-B482-F5097FA07E99"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 15:21:42 +0200 In-Reply-To: <20170825.094233.74747800.sthaug@nethelp.no> Cc: Brian E Carpenter , jhw@google.com, v6ops@ietf.org To: sthaug@nethelp.no References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <20170825.094233.74747800.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 13:21:49 -0000 --Apple-Mail=_01207DE6-22F5-47CF-B482-F5097FA07E99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steinar, >> If you follow the model of having IP topology follow the physical = topology LANs are gone. You are left with a set of p2p links. >=20 > Agreed. However, I think this may be an even bigger change, especially > for enterprises, than starting to use IPv6. As a networking guy I love > p2p links, but I also see how much our IT people love their LANs :-) Yes, I think this one is considered in the area of "what socks has he = been smoking now!" ;-) Got running code though: https://gerrit.fd.io/r/#/c/7224/ Ole --Apple-Mail=_01207DE6-22F5-47CF-B482-F5097FA07E99 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZoCRnAAoJEL7aWKiYQt92ypkP/2rsnm2Q9fxjdcmpMvAyHmYP c0L1vw1r3wk2fy1cnO51+g029PfPq26fi4hfn8qQqeuUx/bLeTGHmXEoSKYjJR0i tYKcsas7q68oYE4EfUbYrsP3tlIIPbt4zMD+dyiyi89R+D5cdx0xax3+uRQSCf1X KvbIWIvw2GJnc8qPtS1xAEmvlC5yXLj3VL434qBeUwJzD8GVjHY6xZ0jW08Y7rev YPlSt2rC/AP+s6VzA0G1C12TQolCSVAeMb37Lqhg6JKviPGeCtJQwEbjn+rORqLI nR/QuSgekruE1A6VO4UAgt84nDcjc6Mkao8W0ROvj5ldGGviRNfJyAbLNicLqHtt L31hPQNouhm1GkGSe/+JNS0YXNrnED1FHnVSx6+tlgkxUaSwNAr8TRWs9HM+uhU3 pwj/EQCo4Y9QhQgudcgg4PMjblNaVCB9iKgptThF2Daj4RTHoHb4CDW0hFkLT35F JukQGHKtQRuu3luMXqnMXjDqbcDX25TNiE/1dwVqid87/Gl7gww5UlgLZbzeScOr 8agHIv3tKMjrVb2rlb/fqtZiezjxmOZ67W0HWR4xK9/OFKgDiHit/w3jGD5cGetD aOCrxfAtCDprvNux4Lm9CN+EwupK2WeRB38+kcYBUVuDsJSBtfAe5X/Ra8JZXBRJ Vsi/3iRsW/LXHQFStnmE =+srp -----END PGP SIGNATURE----- --Apple-Mail=_01207DE6-22F5-47CF-B482-F5097FA07E99-- From nobody Fri Aug 25 07:53:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50281132C04 for ; Fri, 25 Aug 2017 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 0VtvTniRpXqO for ; Fri, 25 Aug 2017 07:53:16 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97E91321CB for ; Fri, 25 Aug 2017 07:53:15 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 2DE6DC4E for ; Fri, 25 Aug 2017 14:53:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz2IwY_RKoFA for ; Fri, 25 Aug 2017 09:53:14 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id DB3D354D for ; Fri, 25 Aug 2017 09:53:14 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id h16so15665vkd.4 for ; Fri, 25 Aug 2017 07:53:14 -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=lhhMo2Ho1+2mIO5wlcw0n39cle6Zdc1iQc8PRX5252I=; b=KLiF7DXHHJ36qRdQxtlu9L0VxJu0pfBJQ6+zFgvxHmtwMZZWzCW4f/OaYhBj8deS8s wvafFwGEMHmq2RxJL1x2tKmAho95yyfjgmc25FnCgbg7pbhr+BJj6pnQsN2YXJNm9s/H 5hB/C5kQ5hLJHK//2UyRRO2OWqyBhA8Oz18uAnTIFrAFX6lEpC9ibPY5epC6U0U65KR3 rTqPxsLljkyYV2j/zSLLtl0x06eSVfTsY2m//oKIf0V+qHhReg0d7BtaMwefgXquTSHv o78DcH3Xk657tVo8flXy9IRuoN55pvorbQ8uqhuo1j3ily7zOONJ3a/1pGXN+F51ohqv yosw== 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=lhhMo2Ho1+2mIO5wlcw0n39cle6Zdc1iQc8PRX5252I=; b=iU0d9+/YYoKE3HlXofOqCn/hiiph7Z/6XNwL18sblOcTjUrScSWWQDCVgwWuidkNhl 6hUZoy+eZ/3eDS8mcCYOTDYwkJaIc4v5bELZtCr6bQehGAPxDj1whar9zf+3+ELoEP9B bnlvO1vLBJqJI1HjH10uJNBxdS80fxiGCMpPnwVlJNralF+s6+bGFVbct1IIhLPKc21y cxcSH8PtyAU9swHWmk5ylRzLoEPofsRibFFFYMyRLdy+A+1jLrQJGSuxf1POndxNDy9K IJmxUamZs75nI42GcPz3qxF7JkvvDl1anfmDRuKaWA5m2AQPADz3HcijgwMxeFGH4BA/ Y+GA== X-Gm-Message-State: AHYfb5hPr0w5mo55vMYTBTzxY8zuABxleI6JriIWw88qjPJEohohSkgi iaHP8sZZoivhAuaLJUmbHHjq1t940s8eECSph1Rk8CGcSHrm6Gj+VLfDS4+jrj+zf4var2OtjSi TRRzghv38UAvNapzl X-Received: by 10.159.32.164 with SMTP id 33mr7547296uaa.123.1503672793960; Fri, 25 Aug 2017 07:53:13 -0700 (PDT) X-Received: by 10.159.32.164 with SMTP id 33mr7547284uaa.123.1503672793601; Fri, 25 Aug 2017 07:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Fri, 25 Aug 2017 07:53:13 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Fri, 25 Aug 2017 09:53:13 -0500 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114d7546b9429f0557951a4f" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:53:20 -0000 --001a114d7546b9429f0557951a4f Content-Type: text/plain; charset="UTF-8" I don't think you can just plop that in there without at least some revisions to section 4 as well. Thinking about this a bit, I think you are referring to redirects in general and your draft 'draft-templin-6man-rio-redirect' more specifically. In a current unmodified host only individual addresses and not whole prefixes can be redirected, and therefore the router would have to track individual addresses to redirect them, which again break the premise of reducing ND. Once redirects for whole prefixes are commonly available then at the discretion of the router you could do as you suggest. While I like the ideas in 'draft-templin-6man-rio-redirect' they are not generally implement in the vast majority of hosts today, and therefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' can't reasonably expect the capability to be available, and can only reasonably expect redirects for individual addresses, and implementing peer-to-peer communication on that basis is not compatible with the fundamental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host'. Once the capabilities described in 'draft-templin-6man-rio-redirect' are generally available, I think it would be reasonable to add an option for peer-to-peer communication to a future revision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based on the capabilities available today you can't implement peer-to-peer communications without violating other fundamental expectations in draft-ietf-v6ops-unique-ipv6-prefix-per-host'. Thanks. On Thu, Aug 24, 2017 at 12:37 PM, Templin, Fred L wrote: > In section 2, the document says: > > " o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router" > > Please change to say: > > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a114d7546b9429f0557951a4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I don't think you can just plop that in there without = at least some revisions to section 4 as well. =C2=A0

    Thi= nking about this a bit, I think you are referring to redirects in general a= nd your draft 'draft-templin-6man-rio-redirect' more specifically. = In a current unmodified host only individual addresses and not whole prefix= es can be redirected, and therefore the router would have to track individu= al addresses to redirect them, which again break the premise of reducing ND= .=C2=A0 Once redirects for whole prefixes are commonly available then at th= e discretion of the router you could do as you suggest.

    While I like the ideas in 'draft-templin-6man-rio-redirect' t= hey are not generally implement in the vast majority of hosts today, and th= erefore networks implementing 'draft-ietf-v6ops-unique-ipv6-prefix-per-= host' can't reasonably expect the capability to be available, and c= an only reasonably expect redirects for individual addresses, and implement= ing peer-to-peer communication on that basis is not compatible with the fun= damental expectation in 'draft-ietf-v6ops-unique-ipv6-prefix-per-host&#= 39;.=C2=A0 =C2=A0 =C2=A0=C2=A0

    Once the capabilities described in 'draft= -templin-6man-rio-redirect' are generally available, I think it would b= e reasonable to add an option for peer-to-peer communication to a future re= vision of 'draft-ietf-v6ops-unique-ipv6-prefix-per-host', but based= on the capabilities available today you can't implement peer-to-peer c= ommunications without violating other fundamental expectations in draft-iet= f-v6ops-unique-ipv6-prefix-per-host'.=C2=A0

    Thanks. =C2=A0

    On Thu, Aug 24, 2017 at 12:37 = PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrot= e:
    In section 2, the d= ocument says:

    =C2=A0 =C2=A0" o=C2=A0 Two devices (subscriber/hosts), both attached t= o the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router"

    Please change to say:

    =C2=A0 =C2=A0"o=C2=A0 Two devices (subscriber/hosts), both attached to= the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router unless the share= d network
    =C2=A0 =C2=A0 =C2=A0 explicitly permits peer-to-peer operations"

    Thanks - Fred
    fred.l.templ= in@boeing.com

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops



    --
    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Cel= l: 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
    --001a114d7546b9429f0557951a4f-- From nobody Fri Aug 25 08:19:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C0E13295E; Fri, 25 Aug 2017 08:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKMEbrTCjV2M; Fri, 25 Aug 2017 08:19:49 -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 BC3DF132351; Fri, 25 Aug 2017 08:19:49 -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 v7PFJmhP045692; Fri, 25 Aug 2017 08:19:48 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7PFJg2i045634 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 25 Aug 2017 08:19:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 25 Aug 2017 08:19:41 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 25 Aug 2017 08:19:41 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" CC: "v6ops-ads@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMA Date: Fri, 25 Aug 2017 15:19:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:19:52 -0000 Hi, To further qualify this concern, and to bring it to the attention of the chairs and ADs, this document seems to strongly discourage the use of direct peer-to-peer communications. But, that would unnecessarily limit the domain of applicability for links on which the use of Redirects provide= s an operational advantage. The text in question and proposed resolutions are as follows below. Thank you for your attention to this input. Fred Templin fred.l.templin@boeing.com --- 1) In section 2: " o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router" =20 Please change to say: =20 "o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router unless the shared network explicitly permits peer-to-peer operations" 2) In Section 4: " If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router." Please change to: "If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router unless the shared network explicitly permits peer-to-peer operations." > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, August 24, 2017 10:38 AM > To: v6ops@ietf.org > Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host= -07' >=20 > In section 2, the document says: >=20 > " o Two devices (subscriber/hosts), both attached to the same provide= r > managed shared network should only be able to communicate through > the provider managed First Hop Router" >=20 > Please change to say: >=20 > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 25 08:33:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A62132C27 for ; Fri, 25 Aug 2017 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIG9odHRVdtD for ; Fri, 25 Aug 2017 08:33:08 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80398132C21 for ; Fri, 25 Aug 2017 08:33:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7PFX8r6004544; Fri, 25 Aug 2017 08:33:08 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7PFX3uT004132 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 25 Aug 2017 08:33:03 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 25 Aug 2017 08:33:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 25 Aug 2017 08:33:02 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwA7OviAAA2xvFA= Date: Fri, 25 Aug 2017 15:33:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b73ec4e62df84b3ebe41b23699408ec6XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:33:10 -0000 --_000_b73ec4e62df84b3ebe41b23699408ec6XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClNlZWluZyB0aGlzIG5vdywgaXQgYXBwZWFycyB0aGF0IHlvdXIgcG9zdCBh cnJpdmVkIHdoaWxlIEkgd2FzIGluIHRoZSBwcm9jZXNzDQpvZiBjb21wb3NpbmcgbXkgb3duIHBv c3QuIEJ1dCwgdG8gcmVzcG9uZCB0byB5b3VyIHBvaW50czoNCg0KDQrDmCAgSSBkb24ndCB0aGlu ayB5b3UgY2FuIGp1c3QgcGxvcCB0aGF0IGluIHRoZXJlIHdpdGhvdXQgYXQgbGVhc3Qgc29tZSBy ZXZpc2lvbnMgdG8gc2VjdGlvbiA0IGFzIHdlbGwNCg0KWW91IGFyZSByaWdodCDigJMgc2VjdGlv biA0IGFsc28gbmVlZHMgdG8gc2F5IHNvbWV0aGluZyAoc2VlIG15IHBvc3QpLg0KDQoNCsOYICBU aGlua2luZyBhYm91dCB0aGlzIGEgYml0LCBJIHRoaW5rIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHJl ZGlyZWN0cyBpbiBnZW5lcmFsIGFuZCB5b3VyIGRyYWZ0ICdkcmFmdC10ZW1wbGluLTZtYW4tcmlv LXJlZGlyZWN0JyBtb3JlIHNwZWNpZmljYWxseS4NCg0KSSBhbSByZWZlcnJpbmcgdG8gUmVkaXJl Y3RzIGluIGdlbmVyYWw7IG15IGRyYWZ0IGlzIGJhc2VkIG9uIHN0YW5kYXJkIFJlZGlyZWN0cyBi dXQgc2ltcGx5DQphc2tzIHRoZW0gdG8gY2FycnkgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbi4NCg0K DQrDmCAgSW4gYSBjdXJyZW50IHVubW9kaWZpZWQgaG9zdCBvbmx5IGluZGl2aWR1YWwgYWRkcmVz c2VzIGFuZCBub3Qgd2hvbGUgcHJlZml4ZXMgY2FuIGJlIHJlZGlyZWN0ZWQNCg0KVHJ1ZS4NCg0K DQrDmCAgYW5kIHRoZXJlZm9yZSB0aGUgcm91dGVyIHdvdWxkIGhhdmUgdG8gdHJhY2sgaW5kaXZp ZHVhbCBhZGRyZXNzZXMgdG8gcmVkaXJlY3QgdGhlbSwgd2hpY2ggYWdhaW4gYnJlYWsgdGhlIHBy ZW1pc2Ugb2YgcmVkdWNpbmcgTkQuDQoNClJlZGlyZWN0cyBhcmUgaXNzdWVkIGF0IHRoZSBkaXNj cmV0aW9uIG9mIHRoZSBmaXJzdC1ob3Agcm91dGVyLiBJZiBSZWRpcmVjdHMgYXJlIG5vdCBhcHBy b3ByaWF0ZQ0KZm9yIHRoZSBsaW5rLCBvciBpZiB0aGUgZmlyc3QtaG9wIHJvdXRlciBqdXN0IHBs YWluIGRvZXNu4oCZdCB3YW50IHRvIHNlbmQgdGhlbSwgdGhlbiBpdCBuZWVkIG5vdA0Kc2VuZCB0 aGVtLiBCdXQsIHRoZXJlIHdpbGwgYmUgc29tZSBsaW5rcyAoZS5nLiwgTkJNQSkgb24gd2hpY2gg UmVkaXJlY3RzIHByb3ZpZGUgYSBzdHJvbmcNCm9wZXJhdGlvbmFsIGFkdmFudGFnZS4NCg0KDQrD mCAgT25jZSByZWRpcmVjdHMgZm9yIHdob2xlIHByZWZpeGVzIGFyZSBjb21tb25seSBhdmFpbGFi bGUgdGhlbiBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgcm91dGVyIHlvdSBjb3VsZCBkbyBhcyB5 b3Ugc3VnZ2VzdA0KDQpObywgaXQgaXMgYWJvdXQgUmVkaXJlY3RzIGluIGdlbmVyYWwgYW5kIG5v dCBqdXN0IHByZWZpeCBSZWRpcmVjdHMuDQoNCg0Kw5ggIFdoaWxlIEkgbGlrZSB0aGUgaWRlYXMg aW4gJ2RyYWZ0LXRlbXBsaW4tNm1hbi1yaW8tcmVkaXJlY3QnIHRoZXkgYXJlIG5vdCBnZW5lcmFs bHkgaW1wbGVtZW50IGluIHRoZSB2YXN0IG1ham9yaXR5IG9mIGhvc3RzIHRvZGF5LCBhbmQgdGhl cmVmb3JlIG5ldHdvcmtzIGltcGxlbWVudGluZyAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3QnIGNhbid0IHJlYXNvbmFibHkgZXhwZWN0IHRoZSBjYXBhYmlsaXR5 IHRvIGJlIGF2YWlsYWJsZSwgYW5kIGNhbiBvbmx5IHJlYXNvbmFibHkgZXhwZWN0IHJlZGlyZWN0 cyBmb3IgaW5kaXZpZHVhbCBhZGRyZXNzZXMsIGFuZCBpbXBsZW1lbnRpbmcgcGVlci10by1wZWVy IGNvbW11bmljYXRpb24gb24gdGhhdCBiYXNpcyBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBm dW5kYW1lbnRhbCBleHBlY3RhdGlvbiBpbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QnLg0KDQpPbiBzb21lIGxpbmtzLCBSZWRpcmVjdHMgZm9yIGV2ZW4gaW5k aXZpZHVhbCBhZGRyZXNzZXMgcHJvdmlkZSBhIHVzZWZ1bCBvcHRpbWl6YXRpb24NCmFuZCBzaG91 bGQgbm90IGJlIGRpc2FsbG93ZWQuIEFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGlzIGlzIHRoZSBv bmx5IHBvaW50IG9uIHdoaWNoDQrigJhkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdOKAmSB1bm5lY2Vzc2FyaWx5IGxpbWl0cyB0aGUgZG9tYWluDQpvZiBhcHBsaWNh YmlsaXR5Lg0KDQoNCsOYICBPbmNlIHRoZSBjYXBhYmlsaXRpZXMgZGVzY3JpYmVkIGluICdkcmFm dC10ZW1wbGluLTZtYW4tcmlvLXJlZGlyZWN0JyBhcmUgZ2VuZXJhbGx5IGF2YWlsYWJsZSwgSSB0 aGluayBpdCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIGFkZCBhbiBvcHRpb24gZm9yIHBlZXItdG8t cGVlciBjb21tdW5pY2F0aW9uIHRvIGEgZnV0dXJlIHJldmlzaW9uIG9mICdkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCcsIGJ1dCBiYXNlZCBvbiB0aGUgY2FwYWJp bGl0aWVzIGF2YWlsYWJsZSB0b2RheSB5b3UgY2FuJ3QgaW1wbGVtZW50IHBlZXItdG8tcGVlciBj b21tdW5pY2F0aW9ucyB3aXRob3V0IHZpb2xhdGluZyBvdGhlciBmdW5kYW1lbnRhbCBleHBlY3Rh dGlvbnMgaW4gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QnLg0K DQpUaGVyZSBpcyBubyBuZWVkIHRvIHdhaXQgZm9yIOKAmGRyYWZ0LXRlbXBsaW4tNm1hbi1yaW8t cmVkaXJlY3TigJkgaWYgd2UgY2FuIGdldCB0aGlzDQpyaWdodCBvbiB0aGUgZmlyc3QgaXRlcmF0 aW9uIG9mIOKAmGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N04oCZ LiBBcw0KeW91IGtub3csIEJDUHMgYXJlIGludGVuZGVkIGZvciB0aGUgbG9uZy10ZXJtIGFuZCBh cmUgbm90IGVhc3kgdG8gdXBkYXRlDQpvbmNlIHRoZXkgYXJlIHB1Ymxpc2hlZC4NCg0KVGhhbmtz IC0gRnJlZA0KDQoNCkZyb206IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1bW4uZWR1XQ0K U2VudDogRnJpZGF5LCBBdWd1c3QgMjUsIDIwMTcgNzo1MyBBTQ0KVG86IFRlbXBsaW4sIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDcnDQoNCkkgZG9uJ3QgdGhpbmsgeW91IGNhbiBqdXN0IHBsb3AgdGhh dCBpbiB0aGVyZSB3aXRob3V0IGF0IGxlYXN0IHNvbWUgcmV2aXNpb25zIHRvIHNlY3Rpb24gNCBh cyB3ZWxsLg0KDQpUaGlua2luZyBhYm91dCB0aGlzIGEgYml0LCBJIHRoaW5rIHlvdSBhcmUgcmVm ZXJyaW5nIHRvIHJlZGlyZWN0cyBpbiBnZW5lcmFsIGFuZCB5b3VyIGRyYWZ0ICdkcmFmdC10ZW1w bGluLTZtYW4tcmlvLXJlZGlyZWN0JyBtb3JlIHNwZWNpZmljYWxseS4gSW4gYSBjdXJyZW50IHVu bW9kaWZpZWQgaG9zdCBvbmx5IGluZGl2aWR1YWwgYWRkcmVzc2VzIGFuZCBub3Qgd2hvbGUgcHJl Zml4ZXMgY2FuIGJlIHJlZGlyZWN0ZWQsIGFuZCB0aGVyZWZvcmUgdGhlIHJvdXRlciB3b3VsZCBo YXZlIHRvIHRyYWNrIGluZGl2aWR1YWwgYWRkcmVzc2VzIHRvIHJlZGlyZWN0IHRoZW0sIHdoaWNo IGFnYWluIGJyZWFrIHRoZSBwcmVtaXNlIG9mIHJlZHVjaW5nIE5ELiAgT25jZSByZWRpcmVjdHMg Zm9yIHdob2xlIHByZWZpeGVzIGFyZSBjb21tb25seSBhdmFpbGFibGUgdGhlbiBhdCB0aGUgZGlz Y3JldGlvbiBvZiB0aGUgcm91dGVyIHlvdSBjb3VsZCBkbyBhcyB5b3Ugc3VnZ2VzdC4NCg0KV2hp bGUgSSBsaWtlIHRoZSBpZGVhcyBpbiAnZHJhZnQtdGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdCcg dGhleSBhcmUgbm90IGdlbmVyYWxseSBpbXBsZW1lbnQgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2Yg aG9zdHMgdG9kYXksIGFuZCB0aGVyZWZvcmUgbmV0d29ya3MgaW1wbGVtZW50aW5nICdkcmFmdC1p ZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCcgY2FuJ3QgcmVhc29uYWJseSBl eHBlY3QgdGhlIGNhcGFiaWxpdHkgdG8gYmUgYXZhaWxhYmxlLCBhbmQgY2FuIG9ubHkgcmVhc29u YWJseSBleHBlY3QgcmVkaXJlY3RzIGZvciBpbmRpdmlkdWFsIGFkZHJlc3NlcywgYW5kIGltcGxl bWVudGluZyBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiBvbiB0aGF0IGJhc2lzIGlzIG5vdCBj b21wYXRpYmxlIHdpdGggdGhlIGZ1bmRhbWVudGFsIGV4cGVjdGF0aW9uIGluICdkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCcuDQoNCk9uY2UgdGhlIGNhcGFiaWxp dGllcyBkZXNjcmliZWQgaW4gJ2RyYWZ0LXRlbXBsaW4tNm1hbi1yaW8tcmVkaXJlY3QnIGFyZSBn ZW5lcmFsbHkgYXZhaWxhYmxlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlYXNvbmFibGUgdG8gYWRk IGFuIG9wdGlvbiBmb3IgcGVlci10by1wZWVyIGNvbW11bmljYXRpb24gdG8gYSBmdXR1cmUgcmV2 aXNpb24gb2YgJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Jywg YnV0IGJhc2VkIG9uIHRoZSBjYXBhYmlsaXRpZXMgYXZhaWxhYmxlIHRvZGF5IHlvdSBjYW4ndCBp bXBsZW1lbnQgcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIHdpdGhvdXQgdmlvbGF0aW5nIG90 aGVyIGZ1bmRhbWVudGFsIGV4cGVjdGF0aW9ucyBpbiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdCcuDQoNClRoYW5rcy4NCg0KT24gVGh1LCBBdWcgMjQsIDIwMTcg YXQgMTI6MzcgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSW4gc2VjdGlvbiAyLCB0 aGUgZG9jdW1lbnQgc2F5czoNCg0KICAgIiBvICBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0 cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXINCiAgICAgIG1hbmFnZWQgc2hh cmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQog ICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIg0KDQpQbGVhc2UgY2hh bmdlIHRvIHNheToNCg0KICAgIm8gIFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3RzKSwgYm90 aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KICAgICAgbWFuYWdlZCBzaGFyZWQgbmV0 d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2gNCiAgICAgIHRo ZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXIgdW5sZXNzIHRoZSBzaGFyZWQgbmV0 d29yaw0KICAgICAgZXhwbGljaXRseSBwZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zIg0K DQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpmcmVkLmwu dGVtcGxpbkBib2VpbmcuY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQoNCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAgICAgICAgIEVtYWlsOmZhcm1lckB1bW4uZWR1PG1h aWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1Pg0KTmV0d29ya2luZyAmIFRlbGVjb21tdW5pY2F0 aW9uIFNlcnZpY2VzDQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neQ0KVW5pdmVyc2l0 eSBvZiBNaW5uZXNvdGENCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UgICAgICAgIFBob25lOiA2MTIt NjI2LTA4MTU8dGVsOig2MTIpJTIwNjI2LTA4MTU+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAy OSAgIENlbGw6IDYxMi04MTItOTk1Mjx0ZWw6KDYxMiklMjA4MTItOTk1Mj4NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= --_000_b73ec4e62df84b3ebe41b23699408ec6XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTY1OTQ5NjYwOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk4NjkxODEwIC01NTI2NzY4 NDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlNlZWluZyB0aGlzIG5vdywgaXQgYXBwZWFycyB0aGF0IHlvdXIgcG9zdCBh cnJpdmVkIHdoaWxlIEkgd2FzIGluIHRoZSBwcm9jZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm9mIGNv bXBvc2luZyBteSBvd24gcG9zdC4gQnV0LCB0byByZXNwb25kIHRvIHlvdXIgcG9pbnRzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Oldp bmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPkkgZG9uJ3QgdGhpbmsgeW91IGNhbiBqdXN0IHBsb3AgdGhhdCBp biB0aGVyZSB3aXRob3V0IGF0IGxlYXN0IHNvbWUgcmV2aXNpb25zIHRvIHNlY3Rpb24gNCBhcyB3 ZWxsPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91IGFyZSByaWdodCDigJMgc2VjdGlvbiA0IGFsc28gbmVl ZHMgdG8gc2F5IHNvbWV0aGluZyAoc2VlIG15IHBvc3QpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoaW5raW5nIGFib3V0IHRoaXMgYSBiaXQsIEkgdGhpbmsgeW91IGFyZSByZWZlcnJpbmcgdG8g cmVkaXJlY3RzIGluIGdlbmVyYWwgYW5kIHlvdXIgZHJhZnQgJ2RyYWZ0LXRlbXBsaW4tNm1hbi1y aW8tcmVkaXJlY3QnIG1vcmUgc3BlY2lmaWNhbGx5LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gcmVm ZXJyaW5nIHRvIFJlZGlyZWN0cyBpbiBnZW5lcmFsOyBteSBkcmFmdCBpcyBiYXNlZCBvbiBzdGFu ZGFyZCBSZWRpcmVjdHMgYnV0IHNpbXBseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hc2tzIHRoZW0gdG8g Y2FycnkgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JbiBh IGN1cnJlbnQgdW5tb2RpZmllZCBob3N0IG9ubHkgaW5kaXZpZHVhbCBhZGRyZXNzZXMgYW5kIG5v dCB3aG9sZSBwcmVmaXhlcyBjYW4gYmUgcmVkaXJlY3RlZDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRydWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+YW5kIHRoZXJlZm9yZSB0aGUgcm91dGVyIHdvdWxkIGhh dmUgdG8gdHJhY2sgaW5kaXZpZHVhbCBhZGRyZXNzZXMgdG8gcmVkaXJlY3QgdGhlbSwgd2hpY2gg YWdhaW4gYnJlYWsgdGhlIHByZW1pc2Ugb2YgcmVkdWNpbmcgTkQuPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UmVkaXJlY3RzIGFyZSBpc3N1ZWQgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGZpcnN0LWhvcCBy b3V0ZXIuIElmIFJlZGlyZWN0cyBhcmUgbm90IGFwcHJvcHJpYXRlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmZvciB0aGUgbGluaywgb3IgaWYgdGhlIGZpcnN0LWhvcCByb3V0ZXIganVzdCBwbGFpbiBkb2Vz buKAmXQgd2FudCB0byBzZW5kIHRoZW0sIHRoZW4gaXQgbmVlZCBub3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+c2VuZCB0aGVtLiBCdXQsIHRoZXJlIHdpbGwgYmUgc29tZSBsaW5rcyAoZS5nLiwgTkJNQSkg b24gd2hpY2ggUmVkaXJlY3RzIHByb3ZpZGUgYSBzdHJvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b3Bl cmF0aW9uYWwgYWR2YW50YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk9uY2UgcmVkaXJlY3Rz IGZvciB3aG9sZSBwcmVmaXhlcyBhcmUgY29tbW9ubHkgYXZhaWxhYmxlIHRoZW4gYXQgdGhlIGRp c2NyZXRpb24gb2YgdGhlIHJvdXRlciB5b3UgY291bGQgZG8gYXMgeW91IHN1Z2dlc3Q8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5ObywgaXQgaXMgYWJvdXQgUmVkaXJlY3RzIGluIGdlbmVyYWwgYW5kIG5vdCBq dXN0IHByZWZpeCBSZWRpcmVjdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2hpbGUgSSBsaWtl IHRoZSBpZGVhcyBpbiAnZHJhZnQtdGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdCcgdGhleSBhcmUg bm90IGdlbmVyYWxseSBpbXBsZW1lbnQgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgaG9zdHMgdG9k YXksIGFuZCB0aGVyZWZvcmUgbmV0d29ya3MgaW1wbGVtZW50aW5nICdkcmFmdC1pZXRmLXY2b3Bz LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCcgY2FuJ3QgcmVhc29uYWJseQ0KIGV4cGVjdCB0 aGUgY2FwYWJpbGl0eSB0byBiZSBhdmFpbGFibGUsIGFuZCBjYW4gb25seSByZWFzb25hYmx5IGV4 cGVjdCByZWRpcmVjdHMgZm9yIGluZGl2aWR1YWwgYWRkcmVzc2VzLCBhbmQgaW1wbGVtZW50aW5n IHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uIG9uIHRoYXQgYmFzaXMgaXMgbm90IGNvbXBhdGli bGUgd2l0aCB0aGUgZnVuZGFtZW50YWwgZXhwZWN0YXRpb24gaW4gJ2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Jy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbiBzb21lIGxp bmtzLCBSZWRpcmVjdHMgZm9yIGV2ZW4gaW5kaXZpZHVhbCBhZGRyZXNzZXMgcHJvdmlkZSBhIHVz ZWZ1bCBvcHRpbWl6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YW5kIHNob3VsZCBub3QgYmUgZGlz YWxsb3dlZC4gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoaXMgaXMgdGhlIG9ubHkgcG9pbnQgb24g d2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCYZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3TigJkgdW5uZWNlc3NhcmlseSBsaW1pdHMgdGhlIGRvbWFpbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5vZiBhcHBsaWNhYmlsaXR5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+T25j ZSB0aGUgY2FwYWJpbGl0aWVzIGRlc2NyaWJlZCBpbiAnZHJhZnQtdGVtcGxpbi02bWFuLXJpby1y ZWRpcmVjdCcgYXJlIGdlbmVyYWxseSBhdmFpbGFibGUsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVh c29uYWJsZSB0byBhZGQgYW4gb3B0aW9uIGZvciBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiB0 byBhIGZ1dHVyZSByZXZpc2lvbiBvZiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QnLA0KIGJ1dCBiYXNlZCBvbiB0aGUgY2FwYWJpbGl0aWVzIGF2YWlsYWJsZSB0 b2RheSB5b3UgY2FuJ3QgaW1wbGVtZW50IHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9ucyB3aXRo b3V0IHZpb2xhdGluZyBvdGhlciBmdW5kYW1lbnRhbCBleHBlY3RhdGlvbnMgaW4gZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QnLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj5UaGVyZSBpcyBubyBuZWVkIHRvIHdhaXQgZm9yIOKAmGRyYWZ0LXRlbXBsaW4t Nm1hbi1yaW8tcmVkaXJlY3TigJkgaWYgd2UgY2FuIGdldCB0aGlzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnJp Z2h0IG9uIHRoZSBmaXJzdCBpdGVyYXRpb24gb2Yg4oCYZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUt aXB2Ni1wcmVmaXgtcGVyLWhvc3TigJkuIEFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPnlvdSBrbm93LCBCQ1Bz IGFyZSBpbnRlbmRlZCBmb3IgdGhlIGxvbmctdGVybSBhbmQgYXJlIG5vdCBlYXN5IHRvIHVwZGF0 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5vbmNlIHRoZXkgYXJlIHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdDQo8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjUsIDIwMTcgNzo1MyBBTTxicj4NCjxiPlRv OjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2 Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QtMDcnPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgZG9uJ3QgdGhpbmsgeW91IGNhbiBqdXN0IHBsb3AgdGhhdCBpbiB0aGVyZSB3aXRo b3V0IGF0IGxlYXN0IHNvbWUgcmV2aXNpb25zIHRvIHNlY3Rpb24gNCBhcyB3ZWxsLiAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaW5raW5nIGFi b3V0IHRoaXMgYSBiaXQsIEkgdGhpbmsgeW91IGFyZSByZWZlcnJpbmcgdG8gcmVkaXJlY3RzIGlu IGdlbmVyYWwgYW5kIHlvdXIgZHJhZnQgJ2RyYWZ0LXRlbXBsaW4tNm1hbi1yaW8tcmVkaXJlY3Qn IG1vcmUgc3BlY2lmaWNhbGx5LiBJbiBhIGN1cnJlbnQgdW5tb2RpZmllZCBob3N0IG9ubHkgaW5k aXZpZHVhbCBhZGRyZXNzZXMgYW5kIG5vdCB3aG9sZSBwcmVmaXhlcyBjYW4gYmUgcmVkaXJlY3Rl ZCwNCiBhbmQgdGhlcmVmb3JlIHRoZSByb3V0ZXIgd291bGQgaGF2ZSB0byB0cmFjayBpbmRpdmlk dWFsIGFkZHJlc3NlcyB0byByZWRpcmVjdCB0aGVtLCB3aGljaCBhZ2FpbiBicmVhayB0aGUgcHJl bWlzZSBvZiByZWR1Y2luZyBORC4mbmJzcDsgT25jZSByZWRpcmVjdHMgZm9yIHdob2xlIHByZWZp eGVzIGFyZSBjb21tb25seSBhdmFpbGFibGUgdGhlbiBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUg cm91dGVyIHlvdSBjb3VsZCBkbyBhcyB5b3Ugc3VnZ2VzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSBsaWtlIHRoZSBpZGVhcyBp biAnZHJhZnQtdGVtcGxpbi02bWFuLXJpby1yZWRpcmVjdCcgdGhleSBhcmUgbm90IGdlbmVyYWxs eSBpbXBsZW1lbnQgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgaG9zdHMgdG9kYXksIGFuZCB0aGVy ZWZvcmUgbmV0d29ya3MgaW1wbGVtZW50aW5nICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2 LXByZWZpeC1wZXItaG9zdCcgY2FuJ3QgcmVhc29uYWJseSBleHBlY3QNCiB0aGUgY2FwYWJpbGl0 eSB0byBiZSBhdmFpbGFibGUsIGFuZCBjYW4gb25seSByZWFzb25hYmx5IGV4cGVjdCByZWRpcmVj dHMgZm9yIGluZGl2aWR1YWwgYWRkcmVzc2VzLCBhbmQgaW1wbGVtZW50aW5nIHBlZXItdG8tcGVl ciBjb21tdW5pY2F0aW9uIG9uIHRoYXQgYmFzaXMgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUg ZnVuZGFtZW50YWwgZXhwZWN0YXRpb24gaW4gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0Jy4mbmJzcDsNCiAmbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmNlIHRo ZSBjYXBhYmlsaXRpZXMgZGVzY3JpYmVkIGluICdkcmFmdC10ZW1wbGluLTZtYW4tcmlvLXJlZGly ZWN0JyBhcmUgZ2VuZXJhbGx5IGF2YWlsYWJsZSwgSSB0aGluayBpdCB3b3VsZCBiZSByZWFzb25h YmxlIHRvIGFkZCBhbiBvcHRpb24gZm9yIHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uIHRvIGEg ZnV0dXJlIHJldmlzaW9uIG9mICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdCcsDQogYnV0IGJhc2VkIG9uIHRoZSBjYXBhYmlsaXRpZXMgYXZhaWxhYmxlIHRvZGF5 IHlvdSBjYW4ndCBpbXBsZW1lbnQgcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIHdpdGhvdXQg dmlvbGF0aW5nIG90aGVyIGZ1bmRhbWVudGFsIGV4cGVjdGF0aW9ucyBpbiBkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCcuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNCwg MjAxNyBhdCAxMjozNyBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiBzZWN0aW9uIDIsIHRoZSBkb2N1bWVudCBzYXlzOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsmcXVvdDsgbyZuYnNwOyBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9o b3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXI8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgdGhyb3VnaDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBwcm92aWRl ciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXImcXVvdDs8YnI+DQo8YnI+DQpQbGVhc2UgY2hhbmdl IHRvIHNheTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7JnF1b3Q7byZuYnNwOyBUd28gZGV2aWNl cyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXI8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBv bmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IHRoZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXIgdW5sZXNzIHRoZSBzaGFy ZWQgbmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGV4cGxpY2l0bHkgcGVybWl0cyBw ZWVyLXRvLXBlZXIgb3BlcmF0aW9ucyZxdW90Ozxicj4NCjxicj4NClRoYW5rcyAtIEZyZWQ8YnI+ DQo8YSBocmVmPSJtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUz QWZhcm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwv YT48YnI+DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyPg0K T2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJzaXR5IG9mIE1pbm5l c290YSZuYnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFBob25lOiA8YSBocmVmPSJ0ZWw6KDYxMiklMjA2MjYtMDgxNSIgdGFy Z2V0PSJfYmxhbmsiPg0KNjEyLTYyNi0wODE1PC9hPjxicj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQx NC0zMDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDxhIGhyZWY9InRlbDooNjEyKSUyMDgxMi05OTUyIiB0 YXJnZXQ9Il9ibGFuayI+DQo2MTItODEyLTk5NTI8L2E+PGJyPg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b73ec4e62df84b3ebe41b23699408ec6XCH150608nwnosboeingcom_-- From nobody Fri Aug 25 12:17:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266991329B5 for ; Fri, 25 Aug 2017 12:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5El0--uhJe9 for ; Fri, 25 Aug 2017 12:17:03 -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 A5379132B9B for ; Fri, 25 Aug 2017 12:17:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7PJH2Fa004519; Fri, 25 Aug 2017 12:17:03 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7PJGw3K004080 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Fri, 25 Aug 2017 12:16:58 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 25 Aug 2017 12:16:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 25 Aug 2017 12:16:57 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: IPv6 Prefix Delegation for Hosts Thread-Index: AdMd1T8T+Pvn4zmZSjm9ScI1x15jEw== Date: Fri, 25 Aug 2017 19:16:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] IPv6 Prefix Delegation for Hosts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 19:17:05 -0000 Hi - I would like to remind the WG about this document that has been in the= system since November 2015: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ It is closely related to RFC7934 and 'draft-ietf-v6ops-unique-ipv6-prefix-p= er-host', but does not duplicate those works. The document was discussed on the list = and was also reviewed by an independent review team associated with the WG. It would be good to have folks take a look at it with fresh eyes in light o= f the discussions that have gone on in the mailing list over the past several mon= ths. I believe you will see that the document still has something to add and is = not "overcome by events". See below for the abstract. Thanks in advance for your consideration. Fred fred.l.templin@boeing.com Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. The requesting router then acts as a router between the downstream- attached hosts and the upstream provider network. The router could also act as a host under the weak end system model, and otherwise behaves as a standard router. This document considers the case when the "requesting router" is actually a host, and receives a prefix that it can use for multi-addressing purposes. The host does not connect any downstream-attached networks, and uses the prefix solely for its own multi-addressing purposes. From nobody Fri Aug 25 13:09:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27F6132C40 for ; Fri, 25 Aug 2017 13:09:33 -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 1z-Ncu0C7TND for ; Fri, 25 Aug 2017 13:09:30 -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 A3F42132396 for ; Fri, 25 Aug 2017 13:09:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 2E1E141E for ; Fri, 25 Aug 2017 20:09:30 +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 g_feLnHr26so for ; Fri, 25 Aug 2017 15:09:30 -0500 (CDT) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id D824CC81 for ; Fri, 25 Aug 2017 15:09:29 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id g11so804837uah.10 for ; Fri, 25 Aug 2017 13:09:29 -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=7XcRLzRTRoFypS5rgRPiluFGEFMVKTtPcc2p/kvcz9w=; b=P7AvcVyS+v9YK5wD3BKSC2FUoYu0nb5MjGZkCP90/pcul/cvKU5C9dKucenezZ+q2q UI8zN/kQ+6jE9QnvWNHbQh0wtJNkkOcZPTEo1hIQ9L9i1Q3Yr8xKsKljBahGwLxgVaEj WLQZGsB6ImJAA6vzahAJ2UfsoNhYUp5Th1ppaIBw9MVuXxqebDuENwtswdGuY9+b/Bao Gvof/sjHX3sUmz7qyhmvKACfd5y91ssC24u5ENY+8Op+ce7lrxlm4/PIMB/RCmnictcN NuFOZ3cEZJOaWnp4phlogXkcJKxpnN7B0gG22GMexLet3IYD19ybvSPZo8MXw8vXGze0 mBrg== 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=7XcRLzRTRoFypS5rgRPiluFGEFMVKTtPcc2p/kvcz9w=; b=Vm031QhqXUIWuSViM22du5hH87x9ugjv04HyZHsJeVcgCQY4fDppIGESFzqkwqXBWQ wYjq44iyIcwn+o54/1nfMYHxk7CnT5JEQ0A4kU66qjGLPcXHsKsQSD8cr+rAqe21H98A KFdQUeSLfDsrFgbfs3Dx6W+zyoASvF/iFSln1pbS+fJBmwVKiUxkNVvSEoGkIUCLUibf KHSDnU94OUA4x3hLJkGEVhzWukJfl30BRuynqKK5ombhoRz5xyfE+wjeK7rt/5sGO6LF PoqkGlQPA29+o1ArfcrgL+JrnEa35Dw7HPC19cdIG1XGjjKGK3tUYA/ZpoGrWZMpbJC+ Kn9g== X-Gm-Message-State: AHYfb5jnw3pQ118nQgGHeAgzRMTE6xrgnTYUhaEkkIQ67XVqFKRRe2Bs xbsyXtjQ5FI2kgAX2b7Tv7EF+dy3XLQZLdV8nDhMmNbdGeRSaU0L+Qm8bbSRT32gKBbXBEiRd8A K4j7/RVC6UOhfFL1/ X-Received: by 10.159.60.90 with SMTP id w26mr8227640uah.160.1503691768937; Fri, 25 Aug 2017 13:09:28 -0700 (PDT) X-Received: by 10.159.60.90 with SMTP id w26mr8227631uah.160.1503691768689; Fri, 25 Aug 2017 13:09:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Fri, 25 Aug 2017 13:09:28 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Fri, 25 Aug 2017 15:09:28 -0500 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="f40304364344b9e6490557998505" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:09:34 -0000 --f40304364344b9e6490557998505 Content-Type: text/plain; charset="UTF-8" Below; On Fri, Aug 25, 2017 at 10:19 AM, Templin, Fred L wrote: > Hi, > > To further qualify this concern, and to bring it to the attention of the > chairs and ADs, this document seems to strongly discourage the use of > direct peer-to-peer communications. But, that would unnecessarily limit > the domain of applicability for links on which the use of Redirects > provides > an operational advantage. The text in question and proposed resolutions > are as follows below. Thank you for your attention to this input. > > Fred Templin > fred.l.templin@boeing.com > > --- > > 1) In section 2: > > " o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router" > > Please change to say: > > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" > > 2) In Section 4: > > " If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router." > > Please change to: > > "If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router unless the shared network > explicitly permits peer-to-peer operations." > I think you need add a little bit about how peer-to-peer operations would be explicitly permitted, thought the use of redirects, and that as a consequence the addresses used buy each host would have to be tracked by the router for it to send proper redirects to other hosts to enable peer-to-peer operations . However, in some cases the trade-off could be worth the performance increase for direct peer-to-peer communications, and in others the trade-off will not be worth it. > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > > Sent: Thursday, August 24, 2017 10:38 AM > > To: v6ops@ietf.org > > Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6- > prefix-per-host-07' > > > > In section 2, the document says: > > > > " o Two devices (subscriber/hosts), both attached to the same > provider > > managed shared network should only be able to communicate through > > the provider managed First Hop Router" > > > > Please change to say: > > > > "o Two devices (subscriber/hosts), both attached to the same provider > > managed shared network should only be able to communicate through > > the provider managed First Hop Router unless the shared network > > explicitly permits peer-to-peer operations" > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== 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 =============================================== --f40304364344b9e6490557998505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Below;

    On Fri, Aug 25, 2017 at 10:19 AM, Templin, Fred L <Fred.= L.Templin@boeing.com> wrote:
    Hi,

    To further qualify this concern, and to bring it to the attention of the chairs and ADs, this document seems to strongly discourage the use of
    direct peer-to-peer communications. But, that would unnecessarily limit
    the domain of applicability for links on which the use of Redirects provide= s
    an operational advantage. The text in question and proposed resolutions
    are as follows below. Thank you for your attention to this input.

    Fred Templin
    fred.l.templin@boeing.com<= br>
    ---

    1) In section 2:

    =C2=A0 =C2=A0 " o=C2=A0 Two devices (subscriber/hosts), both attached = to the same provider
    =C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able to co= mmunicate through
    =C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router"

    Please change to say:

    =C2=A0 =C2=A0 "o=C2=A0 Two devices (subscriber/hosts), both attached t= o the same provider
    =C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able to co= mmunicate through
    =C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router unless the= shared network
    =C2=A0 =C2=A0 =C2=A0 =C2=A0explicitly permits peer-to-peer operations"=

    2) In Section 4:

    =C2=A0 " If the UE/subscriber
    =C2=A0 =C2=A0desires to send anything external including other UE/subscribe= r
    =C2=A0 =C2=A0devices (assuming device to device communications is enabled a= nd
    =C2=A0 =C2=A0supported), then, due to the L-bit set, it SHOULD send this tr= affic
    =C2=A0 =C2=A0to the First Hop Provider Router."

    Please change to:

    =C2=A0 =C2=A0 "If the UE/subscriber
    =C2=A0 =C2=A0desires to send anything external including other UE/subscribe= r
    =C2=A0 =C2=A0devices (assuming device to device communications is enabled a= nd
    =C2=A0 =C2=A0supported), then, due to the L-bit set, it SHOULD send this tr= affic
    =C2=A0 =C2=A0to the First Hop Provider Router unless the shared network
    =C2=A0 =C2=A0explicitly permits peer-to-peer operations."

    I think you need add a little bit about how peer-to= -peer operations would be explicitly permitted, thought the use of redirect= s, and that as a consequence the addresses used buy each host would have to= be tracked by the router for it to send proper redirects to other hosts to= enable peer-to-peer operations =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .=C2=A0 However, in some cases the trade-of= f could be worth the performance increase for direct peer-to-peer communica= tions, and in others the trade-off will not be worth it.

    =C2=A0
    > -----Original Message-----
    > From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of Templin, Fred L
    > Sent: Thursday, August 24, 2017 10:38 AM
    > To: v6ops@ietf.org
    > Subject: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-pre= fix-per-host-07'
    >
    > In section 2, the document says:
    >
    >=C2=A0 =C2=A0 " o=C2=A0 Two devices (subscriber/hosts), both attac= hed to the same provider
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able t= o communicate through
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router"<= br> >
    > Please change to say:
    >
    >=C2=A0 =C2=A0 "o=C2=A0 Two devices (subscriber/hosts), both attach= ed to the same provider
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able t= o communicate through
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router unless= the shared network
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0explicitly permits peer-to-peer operations&q= uot;
    >
    > Thanks - Fred
    > fred.l.templin@boeing.com=
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops=


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops



    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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
    Offic= e of Information Technology
    University of Minnesota=C2=A0=C2=A0
    2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --f40304364344b9e6490557998505-- From nobody Fri Aug 25 13:52:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37681329F3; Fri, 25 Aug 2017 13:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAcAD8y5sR89; Fri, 25 Aug 2017 13:52:37 -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 18FC413219F; Fri, 25 Aug 2017 13:52:36 -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 v7PKqZFB056929; Fri, 25 Aug 2017 13:52:35 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7PKqZ6S056920 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 25 Aug 2017 13:52:35 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 25 Aug 2017 13:52:34 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 25 Aug 2017 13:52:34 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24A== Date: Fri, 25 Aug 2017 20:52:34 +0000 Message-ID: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_36cf4673289247bba28bbd921cf9ebf8XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:52:40 -0000 --_000_36cf4673289247bba28bbd921cf9ebf8XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyDigJMgSSBpbnNlcnRlZCBmb2xs b3ctdXBzIGJlbG93Lg0KDQpGcmVkDQoNCkZyb206IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1l ckB1bW4uZWR1XQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjUsIDIwMTcgMTowOSBQTQ0KVG86IFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRm Lm9yZzsgdjZvcHMtY2hhaXJzQGlldGYub3JnOyB2Nm9wcy1hZHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LTA3Jw0KDQpCZWxvdzsNCg0KT24gRnJpLCBBdWcgMjUsIDIwMTcgYXQgMTA6 MTkgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGksDQoNClRvIGZ1cnRoZXIgcXVh bGlmeSB0aGlzIGNvbmNlcm4sIGFuZCB0byBicmluZyBpdCB0byB0aGUgYXR0ZW50aW9uIG9mIHRo ZQ0KY2hhaXJzIGFuZCBBRHMsIHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gc3Ryb25nbHkgZGlzY291 cmFnZSB0aGUgdXNlIG9mDQpkaXJlY3QgcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zLiBCdXQs IHRoYXQgd291bGQgdW5uZWNlc3NhcmlseSBsaW1pdA0KdGhlIGRvbWFpbiBvZiBhcHBsaWNhYmls aXR5IGZvciBsaW5rcyBvbiB3aGljaCB0aGUgdXNlIG9mIFJlZGlyZWN0cyBwcm92aWRlcw0KYW4g b3BlcmF0aW9uYWwgYWR2YW50YWdlLiBUaGUgdGV4dCBpbiBxdWVzdGlvbiBhbmQgcHJvcG9zZWQg cmVzb2x1dGlvbnMNCmFyZSBhcyBmb2xsb3dzIGJlbG93LiBUaGFuayB5b3UgZm9yIHlvdXIgYXR0 ZW50aW9uIHRvIHRoaXMgaW5wdXQuDQoNCkZyZWQgVGVtcGxpbg0KZnJlZC5sLnRlbXBsaW5AYm9l aW5nLmNvbTxtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbT4NCg0KLS0tDQoNCjEpIElu IHNlY3Rpb24gMjoNCg0KICAgICIgbyAgVHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBi b3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQogICAgICAgbWFuYWdlZCBzaGFyZWQg bmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2gNCiAgICAg ICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIg0KDQpQbGVhc2UgY2hhbmdl IHRvIHNheToNCg0KICAgICJvICBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGgg YXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXINCiAgICAgICBtYW5hZ2VkIHNoYXJlZCBuZXR3 b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaA0KICAgICAgIHRo ZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXIgdW5sZXNzIHRoZSBzaGFyZWQgbmV0 d29yaw0KICAgICAgIGV4cGxpY2l0bHkgcGVybWl0cyBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucyIN Cg0KMikgSW4gU2VjdGlvbiA0Og0KDQogICIgSWYgdGhlIFVFL3N1YnNjcmliZXINCiAgIGRlc2ly ZXMgdG8gc2VuZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJl cg0KICAgZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBp cyBlbmFibGVkIGFuZA0KICAgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdCBzZXQs IGl0IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRl ciBSb3V0ZXIuIg0KDQpQbGVhc2UgY2hhbmdlIHRvOg0KDQogICAgIklmIHRoZSBVRS9zdWJzY3Jp YmVyDQogICBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVy IFVFL3N1YnNjcmliZXINCiAgIGRldmljZXMgKGFzc3VtaW5nIGRldmljZSB0byBkZXZpY2UgY29t bXVuaWNhdGlvbnMgaXMgZW5hYmxlZCBhbmQNCiAgIHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0 aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMNCiAgIHRvIHRoZSBGaXJz dCBIb3AgUHJvdmlkZXIgUm91dGVyIHVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcmsNCiAgIGV4cGxp Y2l0bHkgcGVybWl0cyBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucy4iDQoNCkkgdGhpbmsgeW91IG5l ZWQgYWRkIGEgbGl0dGxlIGJpdCBhYm91dCBob3cgcGVlci10by1wZWVyIG9wZXJhdGlvbnMgd291 bGQgYmUgZXhwbGljaXRseSBwZXJtaXR0ZWQsIHRob3VnaHQgdGhlIHVzZSBvZiByZWRpcmVjdHMs IGFuZCB0aGF0IGFzIGEgY29uc2VxdWVuY2UgdGhlIGFkZHJlc3NlcyB1c2VkIGJ1eSBlYWNoIGhv c3Qgd291bGQgaGF2ZSB0byBiZSB0cmFja2VkIGJ5IHRoZSByb3V0ZXIgZm9yIGl0IHRvIHNlbmQg cHJvcGVyIHJlZGlyZWN0cyB0byBvdGhlciBob3N0cyB0byBlbmFibGUgcGVlci10by1wZWVyIG9w ZXJhdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLiAgSG93ZXZlciwgaW4gc29tZSBj YXNlcyB0aGUgdHJhZGUtb2ZmIGNvdWxkIGJlIHdvcnRoIHRoZSBwZXJmb3JtYW5jZSBpbmNyZWFz ZSBmb3IgZGlyZWN0IHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9ucywgYW5kIGluIG90aGVycyB0 aGUgdHJhZGUtb2ZmIHdpbGwgbm90IGJlIHdvcnRoIGl0Lg0KDQoNCsOYICAgIEdvb2QgcG9pbnRz LCBidXQgaWYgYW55dGhpbmcgbW9yZSBzaG91bGQgYmUgc2FpZCBJIHRoaW5rIGl0IHNob3VsZCBi ZSBrZXB0IGFzIHRlcnNlDQoNCsOYICAgIGFzIHBvc3NpYmxlLiBDYW4geW91IHN1Z2dlc3Qgc29t ZSB0ZXh0PyBBbiBpbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoZQ0KDQrDmCAgICBS ZWRpcmVjdCBpdHNlbGYgZG9lcyBub3QgcmVhbGx5IGdpdmUgcGVybWlzc2lvbiDigJMgYWxsIGl0 IGRvZXMgaXMgcHJvdmlkZXMgdGhlIHNvdXJjZQ0KDQrDmCAgICBub2RlIHdpdGggdGhlIGxpbmst bG9jYWwgYW5kIGxpbmstbGF5ZXIgYWRkcmVzc2VzIG9mIHRoZSB0YXJnZXQgbm9kZS4gSWYgdGhl IHNvdXJjZQ0KDQrDmCAgICBub2RlIGhhcyBzb21lIG90aGVyIHdheSBvZiBkZXRlcm1pbmluZyB0 aG9zZSBhZGRyZXNzZXMsIGl0IGNhbiBnbyBwZWVyLXRvLXBlZXINCg0Kw5ggICAgd2l0aG91dCBl dmVuIG5lZWRpbmcgdG8gcmVjZWl2ZSBhIFJlZGlyZWN0LiBJbiB0aGF0IGNhc2UsIHRoZSBvbmx5 IHdheSB0byBwcmV2ZW50DQoNCsOYICAgIHBlZXItdG8tcGVlciBpcyB2aWEgTDIgbWVjaGFuaXNt cy4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAy NCwgMjAxNyAxMDozOCBBTQ0KPiBUbzogdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3Jw0KPg0KPiBJbiBzZWN0aW9uIDIsIHRoZSBkb2N1 bWVudCBzYXlzOg0KPg0KPiAgICAiIG8gIFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3RzKSwg Ym90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KPiAgICAgICBtYW5hZ2VkIHNoYXJl ZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaA0KPiAg ICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIg0KPg0KPiBQbGVhc2Ug Y2hhbmdlIHRvIHNheToNCj4NCj4gICAgIm8gIFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3Rz KSwgYm90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KPiAgICAgICBtYW5hZ2VkIHNo YXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaA0K PiAgICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIHVubGVzcyB0aGUg c2hhcmVkIG5ldHdvcmsNCj4gICAgICAgZXhwbGljaXRseSBwZXJtaXRzIHBlZXItdG8tcGVlciBv cGVyYXRpb25zIg0KPg0KPiBUaGFua3MgLSBGcmVkDQo+IGZyZWQubC50ZW1wbGluQGJvZWluZy5j b208bWFpbHRvOmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0K PiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAgICAgICAgIEVtYWlsOmZhcm1l ckB1bW4uZWR1PG1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1Pg0KTmV0d29ya2luZyAmIFRl bGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzDQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9n eQ0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGENCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UgICAgICAg IFBob25lOiA2MTItNjI2LTA4MTUNCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAgQ2VsbDog NjEyLTgxMi05OTUyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0K --_000_36cf4673289247bba28bbd921cf9ebf8XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxODE0NzEzNDQ3Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5ODcwNjAzNiAtMTA0NDg5MjIy MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu a3MgZm9yIHlvdXIgY29tbWVudHMg4oCTIEkgaW5zZXJ0ZWQgZm9sbG93LXVwcyBiZWxvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBE YXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIEF1Z3VzdCAyNSwgMjAxNyAxOjA5IFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBG cmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2 Nm9wc0BpZXRmLm9yZzsgdjZvcHMtY2hhaXJzQGlldGYub3JnOyB2Nm9wcy1hZHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcnPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbG93OzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDEwOjE5IEFNLCBU ZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp LDxicj4NCjxicj4NClRvIGZ1cnRoZXIgcXVhbGlmeSB0aGlzIGNvbmNlcm4sIGFuZCB0byBicmlu ZyBpdCB0byB0aGUgYXR0ZW50aW9uIG9mIHRoZTxicj4NCmNoYWlycyBhbmQgQURzLCB0aGlzIGRv Y3VtZW50IHNlZW1zIHRvIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgdGhlIHVzZSBvZjxicj4NCmRpcmVj dCBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbnMuIEJ1dCwgdGhhdCB3b3VsZCB1bm5lY2Vzc2Fy aWx5IGxpbWl0PGJyPg0KdGhlIGRvbWFpbiBvZiBhcHBsaWNhYmlsaXR5IGZvciBsaW5rcyBvbiB3 aGljaCB0aGUgdXNlIG9mIFJlZGlyZWN0cyBwcm92aWRlczxicj4NCmFuIG9wZXJhdGlvbmFsIGFk dmFudGFnZS4gVGhlIHRleHQgaW4gcXVlc3Rpb24gYW5kIHByb3Bvc2VkIHJlc29sdXRpb25zPGJy Pg0KYXJlIGFzIGZvbGxvd3MgYmVsb3cuIFRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24gdG8g dGhpcyBpbnB1dC48YnI+DQo8YnI+DQpGcmVkIFRlbXBsaW48YnI+DQo8YSBocmVmPSJtYWlsdG86 ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTwvYT48 YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQoxKSBJbiBzZWN0aW9uIDI6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmcXVvdDsgbyZuYnNwOyBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyks IGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXI8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgdGhyb3VnaDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBw cm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXImcXVvdDs8YnI+DQo8YnI+DQpQbGVhc2Ug Y2hhbmdlIHRvIHNheTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O28mbmJzcDsgVHdv IGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHBy b3ZpZGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuYWdlZCBzaGFyZWQgbmV0 d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2g8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91 dGVyIHVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtleHBsaWNpdGx5IHBlcm1pdHMgcGVlci10by1wZWVyIG9wZXJhdGlvbnMmcXVvdDs8YnI+ DQo8YnI+DQoyKSBJbiBTZWN0aW9uIDQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZxdW90OyBJZiB0aGUg VUUvc3Vic2NyaWJlcjxicj4NCiZuYnNwOyAmbmJzcDtkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcg ZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXI8YnI+DQombmJzcDsgJm5ic3A7 ZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFi bGVkIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwt Yml0IHNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljPGJyPg0KJm5ic3A7ICZuYnNwO3Rv IHRoZSBGaXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyLiZxdW90Ozxicj4NCjxicj4NClBsZWFzZSBj aGFuZ2UgdG86PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDtJZiB0aGUgVUUvc3Vic2Ny aWJlcjxicj4NCiZuYnNwOyAmbmJzcDtkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwg aW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXI8YnI+DQombmJzcDsgJm5ic3A7ZGV2aWNlcyAo YXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZDxi cj4NCiZuYnNwOyAmbmJzcDtzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwtYml0IHNldCwg aXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljPGJyPg0KJm5ic3A7ICZuYnNwO3RvIHRoZSBGaXJz dCBIb3AgUHJvdmlkZXIgUm91dGVyIHVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcms8YnI+DQombmJz cDsgJm5ic3A7ZXhwbGljaXRseSBwZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zLiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB5b3UgbmVlZCBhZGQgYSBsaXR0bGUgYml0IGFib3V0IGhvdyBwZWVyLXRv LXBlZXIgb3BlcmF0aW9ucyB3b3VsZCBiZSBleHBsaWNpdGx5IHBlcm1pdHRlZCwgdGhvdWdodCB0 aGUgdXNlIG9mIHJlZGlyZWN0cywgYW5kIHRoYXQgYXMgYSBjb25zZXF1ZW5jZSB0aGUgYWRkcmVz c2VzIHVzZWQgYnV5IGVhY2ggaG9zdCB3b3VsZCBoYXZlIHRvIGJlIHRyYWNrZWQgYnkgdGhlIHJv dXRlciBmb3IgaXQgdG8NCiBzZW5kIHByb3BlciByZWRpcmVjdHMgdG8gb3RoZXIgaG9zdHMgdG8g ZW5hYmxlIHBlZXItdG8tcGVlciBvcGVyYXRpb25zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4mbmJzcDsgSG93ZXZlciwg aW4gc29tZSBjYXNlcyB0aGUgdHJhZGUtb2ZmIGNvdWxkIGJlIHdvcnRoIHRoZSBwZXJmb3JtYW5j ZSBpbmNyZWFzZSBmb3IgZGlyZWN0IHBlZXItdG8tcGVlcg0KIGNvbW11bmljYXRpb25zLCBhbmQg aW4gb3RoZXJzIHRoZSB0cmFkZS1vZmYgd2lsbCBub3QgYmUgd29ydGggaXQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnRzLCBidXQgaWYg YW55dGhpbmcgbW9yZSBzaG91bGQgYmUgc2FpZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBrZXB0IGFz IHRlcnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFzIHBvc3NpYmxlLiBDYW4geW91 IHN1Z2dlc3Qgc29tZSB0ZXh0PyBBbiBpbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWRpcmVjdCBpdHNlbGYgZG9lcyBub3Qg cmVhbGx5IGdpdmUgcGVybWlzc2lvbiDigJMgYWxsIGl0IGRvZXMgaXMgcHJvdmlkZXMgdGhlIHNv dXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub2RlIHdpdGggdGhlIGxpbmstbG9j YWwgYW5kIGxpbmstbGF5ZXIgYWRkcmVzc2VzIG9mIHRoZSB0YXJnZXQgbm9kZS4gSWYgdGhlIHNv dXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub2RlIGhhcyBzb21lIG90aGVyIHdh eSBvZiBkZXRlcm1pbmluZyB0aG9zZSBhZGRyZXNzZXMsIGl0IGNhbiBnbyBwZWVyLXRvLXBlZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aG91dCBldmVuIG5lZWRpbmcgdG8gcmVj ZWl2ZSBhIFJlZGlyZWN0LiBJbiB0aGF0IGNhc2UsIHRoZSBvbmx5IHdheSB0byBwcmV2ZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnBlZXItdG8tcGVlciBpcyB2aWEgTDIgbWVjaGFu aXNtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogdjZvcHMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUZW1wbGluLCBG cmVkIEw8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjQsIDIwMTcgMTA6MzggQU08 YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYu b3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogW3Y2b3BzXSBDb21tZW50IG9uICdkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNyc8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJbiBzZWN0aW9uIDIsIHRoZSBkb2N1bWVudCBzYXlzOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmcXVvdDsgbyZuYnNwOyBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyks IGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxl IHRvIGNvbW11bmljYXRlIHRocm91Z2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dGhlIHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJvdXRlciZxdW90Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IFBsZWFzZSBjaGFuZ2UgdG8gc2F5Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmcXVvdDtvJm5ic3A7IFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3RzKSwgYm90 aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgdGhyb3VnaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIHVubGVzcyB0aGUgc2hhcmVkIG5l dHdvcms8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhwbGljaXRseSBwZXJt aXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhh bmtzIC0gRnJlZDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmZyZWQubC50ZW1wbGluQGJvZWlu Zy5jb20iPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4NCjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUzQWZhcm1l ckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48YnI+ DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyPg0KT2ZmaWNl IG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290YSZu YnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFBob25lOiA2MTItNjI2LTA4MTU8YnI+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQt MzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA2MTItODEyLTk5NTI8YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_36cf4673289247bba28bbd921cf9ebf8XCH150608nwnosboeingcom_-- From nobody Fri Aug 25 16:22:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6929F1326ED for ; Fri, 25 Aug 2017 16:22:42 -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 8lHNvVj7poDT for ; Fri, 25 Aug 2017 16:22:40 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C5B13243A for ; Fri, 25 Aug 2017 16:22:40 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 63so6248699pgc.2 for ; Fri, 25 Aug 2017 16:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1cKtUs0czQFN6sW7cKRXsRkmyWhUxCyVjbxjF0q/tx8=; b=uCQbatFj2foDYHXIDc63GrFlb9YHi4YOl6diRxJ4NjuagOTjJFIU5RnP+S/hBMhPM4 fV2NhyBTi62nJz3s0mqVdQIpfYvAQu2ja3w12zvxY5UTZm0vJSZ7bs9TE6XLsgUw+8XA eUNiMROkTALgat55AKK/QHLudQIibKk/tDLm8eSACQfM3uGIO02REeI4dStNUbE1y3Cy +GV72qHd2JcBkvt89ILtzwtxbaoD94p4X46VFAT/i889FcpqUPX+iGsprMYQJV58EM1I AIZo/1irEvq0dVs22ICcnCSTHrdlykKseOE3WxbYfrtmxd61L7BPmTMcF/t2zz0oka47 2FrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1cKtUs0czQFN6sW7cKRXsRkmyWhUxCyVjbxjF0q/tx8=; b=nk6i3hwDFLFuS3qxOViD1nBMrlRaT+Ugh0XYzRiFQF5/mTS2yTzy1xi50sORv/hYEL rwJNlcx+MjhT/H59fPa1W0RdrsljJ6Jes/Z5kWdYWp1eOHbV2UGIYUcv9Sa+wwtBa2Y5 khAm6g5O4fzoUIks0+sE44zT046/iIXrSdIKpQrezRYy3jcuYzyUPVgx60Vi9+dw/MDo v5FfGzqzXLC3dKUW44Tz2wcgPHdvPtxYxjATW2Ax2OTwQS4uWtY3fvOBY2+2FztyN9YQ avZeWwm97DC7KAA8qLnu+L8J9mfG90Ytb5Nn2HiFTwPgicOJBY15icJd6/iGtfUthp92 AhOA== X-Gm-Message-State: AHYfb5i4+NFB1FHENONep+ocrHrLPdE692hLrxp0IQ3ODrPJY8ynCekT DNUFbfEUgWBhz8GE X-Received: by 10.84.209.234 with SMTP id y97mr127418plh.128.1503703360141; Fri, 25 Aug 2017 16:22:40 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v2sm13242550pfl.21.2017.08.25.16.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 16:22:39 -0700 (PDT) To: sthaug@nethelp.no, otroan@employees.org Cc: jhw@google.com, v6ops@ietf.org References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <20170825.094233.74747800.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 26 Aug 2017 11:22:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170825.094233.74747800.sthaug@nethelp.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:22:42 -0000 On 25/08/2017 19:42, sthaug@nethelp.no wrote: >> If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. > > Agreed. However, I think this may be an even bigger change, especially > for enterprises, than starting to use IPv6. As a networking guy I love > p2p links, but I also see how much our IT people love their LANs :-) Agreed. I think LANs will be a great deal harder to get rid of than IPv4. Apart from anything else, there seems to be no consistent o/s-independent model for VRFs. I don't see how to progressively hide the LAN model without that. (We are grappling with this issue in ANIMA.) Brian From nobody Fri Aug 25 17:46:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A71132328 for ; Fri, 25 Aug 2017 17:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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 hxeKYee6vjB8 for ; Fri, 25 Aug 2017 17:46:04 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2801321A2 for ; Fri, 25 Aug 2017 17:46:04 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id z187so3925600vkd.2 for ; Fri, 25 Aug 2017 17:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=deYAGuGB6D0JI/BnVcfMKw2/bGX2ipqXGNcJ+WnJn+Q=; b=bqEgSpgxVAU+3Y6tmsqX+P5bjKMH6RrkEYOeSJzcp+hmQPrTGCg5/1arOp6Q6wtEhi jPrCvR0T8aUrpCPZ4H3HBEBGX4/e5jm8D6KmtALjA35uzx44pvxpQdS4+8AvV4YVIYLH JLzZNfuSjfokV88aD00QHxIjF7aK444riqsqWM30Hky9kbNx7icT05jvlJypsNBd019g IWQi9+dnp9dshBLzkWo0K2U+lZ1/sEtHraLat1JH70AdT9t11060W2uJ6kWBNEyJvvlZ 3tllwPhi22POrMJESj/dOZt1Ja1j1+GKHb6ClKP0RuzPH07urA5sc0JZkVXuyLYCwsEU 06CQ== 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=deYAGuGB6D0JI/BnVcfMKw2/bGX2ipqXGNcJ+WnJn+Q=; b=eU0f2PsJ35jyXshI6/GxKStCTRKaT2qcrf1QEeAML7LpPQegvRNu7lvTMHBbmem7Xk pgIB/hHPNg8Ya0evX9IP+AbJu9lb8uB89AayD/RvF6+1Pmt0lTppMMh9lODtdmUpB5rc 9wdBay8xFGTfQIq2DpqpKQfgUoJQvepufHMKeeeD2c3Fwm8gC4wMOIbI3TSPtcr8gnTz P1m4sRX4OLniu5ElM+KkXhIGekNBrLkThLilwaNKgn5sSpbjkMdC6SjD2Db1QTgJDcaY h5a8bSiX8DLUbdgqU28xh04iE3K85tEZ6lJrI11zEi3oL+ltX9K2JgPF0tObcJmyYEMa 8iSw== X-Gm-Message-State: AHYfb5iha/1Wh3Bhy1c7lfSiormsWmY8ny3nOFLtkUNF6ebfQd+khmB7 U5S/gGwDN2etrYGq8oOABapCti30Cw== X-Received: by 10.31.63.5 with SMTP id m5mr139158vka.159.1503708363500; Fri, 25 Aug 2017 17:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Fri, 25 Aug 2017 17:45:33 -0700 (PDT) In-Reply-To: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> From: Mark Smith Date: Sat, 26 Aug 2017 10:45:33 +1000 Message-ID: To: Brian E Carpenter Cc: Ole Troan , "v6ops@ietf.org" , james woodyatt Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 00:46:06 -0000 Hi Brian, On 25 August 2017 at 11:32, Brian E Carpenter wrote: > On 25/08/2017 12:50, Mark Smith wrote: > ... >> I think it should be clear in discussion and now specifications as to >> whether the hosts or more generally nodes attached to the same link >> are trusted or not by their link peers. > > That's a serious and complex issue. We are trying to tackle it for the > specific case of forming an Autonomic Control Plane in ANIMA, and it > needs 3 substantial drafts so far: > draft-ietf-anima-voucher > draft-ietf-anima-bootstrapping-keyinfra > draft-ietf-anima-autonomic-control-plane > > At the level of basic IPv6, I don't really see how we can tackle this, > except by stating that all nodes are untrustworthy until proved otherwise. > I think whether hosts are allowed to send directly to each other over a link, or must go via a router, is an expression of their trustworthiness. I think the off-link default assumption for non-LL prefixes is expressing a default host distrust. Having to go via a router for all destinations creates an opportunity for the router to do more than just layer 3 forward the packets back onto the same link to their destination as it can perform security/firewall functions on the traffic. Layer 2 forwarding constraints such as Private VLANs enforce that. I don't think we could change the default on-link assumption for LLs, however I'd like it to be possible to have a router override that default (via an RA PIO for the LL prefix, with the L bit set to off), so that LL destinations are also considered "off-link" and must go through the router too. That would allow applications to use LL addresses to reach other hosts on the same link via a router, while also creating an opportunity to have that router perform more detailed traffic inspection if needed. Per RFC4007, routers are allowed to forward packets with LL addresses, as long they are forwarded back onto the link they arrived on. In combination with layer 2 enforcement, it would also be a more general purpose way of performing things such as RA guard, rather than trying to have layer 2 devices inspect layer 3 packets (parse EH chains, defragment etc.) Being able to invert the on-link LL status would then allow the on-link/off-link treatment of all prefixes to be consistent on a link. One use case I think of is a residential Wifi LAN. I have a number of devices over which I don't have administrative rights e.g., VOD devices, smartphones etc. I need them all to be on the same LAN so that MDNS etc. discovery works. However, I'd like to have them hairpin all their unicast traffic, including that over LLs, through my router, so that I can use the router as a traffic security policy enforcement point. > ... >> I think there are other benefits of using Link-Local addresses in applications: > > You can't avoid using them during the bootstrap phase of forming a secure > network after a cold start. And they come in mighty handy when running an > IPv6-only app on a LAN with no IPv6 router ;-). > Agree, requiring a router so that hosts attached to a single link can communicate may be doing no more than adding a single point of failure. Regards, Mark. From nobody Fri Aug 25 18:39:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B089E1323C9 for ; Fri, 25 Aug 2017 18:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWRuYRzYqhcC for ; Fri, 25 Aug 2017 18:39:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FFC13209C for ; Fri, 25 Aug 2017 18:39:09 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id l132so4037997vke.5 for ; Fri, 25 Aug 2017 18:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F+c+mrkVFqdJUifGth/l6JUr4KbAwFNmHoS/FKdD6lU=; b=nWpTiJMWuDxQgQt+ECn/A+lo4Yn5fe8n/xjDOl0bC+xdhM4S4bZA0OjmqHwkIg0hOz ixukFoLc/FIPRoFZDONcuN4lwWvNXE8l1hTaaw9czMUvQtM9lPdUBwRLqaWvxNP4XtcT naxGseKsoy+QhXXhWxdByecdHqbOTjp8uyzdEUxz9itp2LBkosQOKwhVENSiHEiBEuXP gY1IFGsrs54NhNhwWULzI2Zwo7xXAVF+hkaKZnyEe/jK1vEqgDOXpeFfnrXYXfu/hSGL r1d5B2z+I5Z6NTX0HRfU9RupX0Y6eIS6oJpi0TSaXAnvyPLGiHn+5JqU4+By357sV2w3 E8eA== 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=F+c+mrkVFqdJUifGth/l6JUr4KbAwFNmHoS/FKdD6lU=; b=VxOt4ARUPbb7C7bFBa0HwnOzDizw1ul3FqZQZb3v9hnhUuxVG2LmJpn3/23sSZ4bjl WAulZA+4xSmjsdUXmtix9wCXj1az2A7MJSWNc77K2BGEwqVQNCz1u6fNHkbUW899DtJM 6eMxduJyzquAgA8VdXmo6Uvf+wSPUa9PhLz8I6mS59cc6/BYGqMsKlUpOAujIM2URn+p dGWoc1Fjj/AuIUkiuD86kQhvu/hKNhFWVGPly6CclL3lHHiT/LbcRVb9QWS2B9/9bhgL FUkVp0Eb0ypwN+DB2VK13GGc05c6WzFGMckt5LWtcAktdVywJ32AKTTwZKc0UXUDf2qT t//g== X-Gm-Message-State: AHYfb5hcWh+S1ejAVpymd6Ui0QGyGlQ9Fd1MwOqc2AFWzQPUeBsk95PK NbVvAElybpoOPr4ZA0AM89pISZXYZA== X-Received: by 10.31.96.149 with SMTP id u143mr248909vkb.101.1503711548512; Fri, 25 Aug 2017 18:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Fri, 25 Aug 2017 18:38:38 -0700 (PDT) In-Reply-To: References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <20170825.094233.74747800.sthaug@nethelp.no> From: Mark Smith Date: Sat, 26 Aug 2017 11:38:38 +1000 Message-ID: To: Brian E Carpenter Cc: sthaug@nethelp.no, Ole Troan , james woodyatt , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 01:39:12 -0000 On 26 August 2017 at 09:22, Brian E Carpenter wrote: > On 25/08/2017 19:42, sthaug@nethelp.no wrote: >>> If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. >> >> Agreed. However, I think this may be an even bigger change, especially >> for enterprises, than starting to use IPv6. As a networking guy I love >> p2p links, but I also see how much our IT people love their LANs :-) > > Agreed. I think LANs will be a great deal harder to get rid of than IPv4. > +1 I think the use of subnets as a method of creating host security domains is probably where the most resistance would come from. I was surprised to find that in a recent environment I worked in, host firewalls on VMs were actively disabled and removed (I think meaning the configuration utilities removed) because the model of using subnets as security domains and having network firewalls at subnet boundaries was so ingrained (the security model wasn't mine to debate, what I wanted to use the host firewalls for was to have per-application/service e.g DNS protocol packet counters visible on the hosts) > Apart from anything else, there seems to be no consistent o/s-independent > model for VRFs. I don't see how to progressively hide the LAN model > without that. (We are grappling with this issue in ANIMA.) > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 25 18:51:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DF91321C4 for ; Fri, 25 Aug 2017 18:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62nqIxuua2uS for ; Fri, 25 Aug 2017 18:51:36 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937C9132198 for ; Fri, 25 Aug 2017 18:51:36 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id d12so4523204uag.0 for ; Fri, 25 Aug 2017 18:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RSCwbcjJeRDBywpdsqyBiVnW4GsLxjNG8OAmig7CEMg=; b=uysbkyUjKxCAIGhzWs65aPmDbocik8Rueu2pgBoH3q0udhQMCfe3sqTp7rG62WQOCf K16EPObMyD4z0Fub2QzKHD5nnpO2PZl0SaG3LeW/uOl37nvBwqqPLWFykjPmDok7MmJE J2kHxhGiygN0/oM+Md/vv8pjXRCUqV1BOn0/JryVKXyErug2TqcSom5ZuPdv+U1h78w/ OXMLTvMLney84eKVdYBhKirZV2ie81BxHCYlDwvxiGbMHR0y+bwCuh4bR9V2vWmxl6v5 JEL++4a+m94LP8UDeaZHlQpJZCMfSEbMbS1VoqM5kBb8P28BD1Izlie1Lso52HWTsaBB tQbg== 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=RSCwbcjJeRDBywpdsqyBiVnW4GsLxjNG8OAmig7CEMg=; b=ceceyRuFFy2t+9qz5OPezZ7JMKpWRneYqtCNka/itdn4+LFE77Mp0ZwCOBLg3ZSkxd wrIScngmpX/cGTURI3IWa0PBZuag/FS+EPAOqPjRhH9735GjtPNtX6+Nc/kkXkp1P3Nd fChGZtHILgzpRENWRqvKHnAUIx4p0Dqc1ytizmQ+rCOVyg9a/RI6qQ6eYyW4KKgXgbZG NDtCkBxm+35nViVsnbem0xQBeJygPUIgE3YiS4AcmZjLLRbvC8VrJpE67G/tOirErHVJ /lOXcLdiFySuFGHM4MD3mKne3LmSPsiqryr6uTOG/qEJQxYultre0MCBDxwCwoR2Fcg1 zZiA== X-Gm-Message-State: AHYfb5irPMkw8OwraOBQ4yA1KaiBoWkgMAH1bB82DYM/3ifOdR9NG+ck Mm4JhwlYRqAiI9W6IKDAZ5r9I1de8hYt X-Received: by 10.176.76.92 with SMTP id d28mr291927uag.116.1503712295597; Fri, 25 Aug 2017 18:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Fri, 25 Aug 2017 18:51:05 -0700 (PDT) In-Reply-To: <1098009C-8FCA-47A5-82E3-FA0B1F8F3857@gmail.com> References: <1098009C-8FCA-47A5-82E3-FA0B1F8F3857@gmail.com> From: Mark Smith Date: Sat, 26 Aug 2017 11:51:05 +1000 Message-ID: To: DY Kim Cc: Ole Troan , "v6ops@ietf.org" , james woodyatt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 01:51:38 -0000 On 24 August 2017 at 20:53, DY Kim wrote: > Questions for clarification: > > --- > DY > > >> On 24 Aug 2017, at 19:17, Mark Smith wrote: >> >> Per RFC5942, the link-local prefix is assumed to to be on-link, > > Do you mean, by =E2=80=98link-local prefix', specifically the prefix =E2= =80=98FE80=E2=80=99 (1111 1110 1000) as specified in Sec. 2.4.6 of RFC4291? > Yes. >> so link-local destinations are assumed to be directly reachable across >> the link > > Do you mean, by =E2=80=98link-local destination=E2=80=99, the Link-Local = IPv6 Unicast Address as defined in Sec. 2.4.6. of RFC4291? > Yes. "on-link" and "off-link" are understandable names, however they become a bit confusing when referring to the "link-local" prefix and addresses. "on-link" really means "might be directly reachable across the local link", where as "off-link" really means "ask a router", even if the destination might be on the same local link. While it isn't possible currently, a Link-Local prefix could be flagged as "off-link", meaning a host would "ask a router" for any LL destinations. Per RFC4007, "IPv6 Scoped Address Architecture" routers are allowed to forward packets with LL destinations, as long as they're forwarded back out the same interface they arrived on. This draft suggests how it could done, the thing I didn't get around to working out was how to include quotes in the title field. I'll add them here. 'Indicating Link-Local Unicast Destinations are "Off-Link"' https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt Regards, Mark. From nobody Fri Aug 25 20:28:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18F21329DA for ; Fri, 25 Aug 2017 20:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 rkeMElxQNSeI for ; Fri, 25 Aug 2017 20:28:04 -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 3A09A1329CA for ; Fri, 25 Aug 2017 20:28:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id C07C3CE6 for ; Sat, 26 Aug 2017 03:28:03 +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 ZNaiQ07gIVo6 for ; Fri, 25 Aug 2017 22:28:03 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 75C0CD0F for ; Fri, 25 Aug 2017 22:28:03 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id j189so1276477vka.0 for ; Fri, 25 Aug 2017 20:28:03 -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=WqMuZO5pN4D/w0Q51xNOvSdcUq/rF2XrL/ZjKxCsIDw=; b=YGGNG5MNsFi+IASrIaen8IznfOHXMrRtkBrJinyMApBeh8Z7Ct36CM1+sn9EDK/AiA yg/wmTLMwzRIAXXRe6dtvkZ6pz4+Zczxd6QQTVD8TMWmHfWTA11IynMfP1gMnk0mkwKZ UPIUpq15j3/cwtEX5Lsu5EZNNF+fN3VDPgqkVTMMXsnwcbAn2My+YmBAD4voXUdI3d+a eZhHJwY+WfhU+WiV092tXNu+Ionvi8rcvzGTl6VDeQYmtZvFT15njOwf0jHZk1zkgwb6 3W7YoBWHmGMK8+OAHtPOoIT00o4l+Mh1FTWnOipf6vi7bCrKNAd56S0TF7/GdCNrIni/ YQ8g== 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=WqMuZO5pN4D/w0Q51xNOvSdcUq/rF2XrL/ZjKxCsIDw=; b=fPMERdL5PtEoV9a3B7Ozmj6eLFOpWgO/N+1UIe6oLzL1Qh3yMk/TX6xI2/BcHvPruB Nq15BlqUePtYQ1kVht6CAzr6eTrygkEXGTOq1LtveQtFVpc0wbxnSbTDE8bLYLKSxIRL iNR5dQYXhRgueGi5rL6oXyT3t2QwlbF1OgkW0DVTkROvWm2eC9Yw7cnD8qou3bKZlqZV vw8mqisqBrfGpz6s0aCcGohr+o1IOW+rR1LfqD+lQ+sUIWerSs0J7iLp9AaodBsQmY6U /s5kJxn4xpF3f46Pmi7wshc3k1bYLILScpnPZUVYLVeBwhnzB1kqIwseb/wEVPii1ocP 8UtQ== X-Gm-Message-State: AHYfb5gyD53vp4VZ+auZ8FzHeyekO8c2nlBSmB7nnMiI3ScUhUeVfvtN V0faDmkHMS9WV22w2PZFkmsmW1/gWDO6+N3ydWwdZp1BJHtOXsXqyBgTQ/cfpi3eymKYeGMmQeP 0LjCa9INVk160Aeji X-Received: by 10.31.87.132 with SMTP id l126mr312398vkb.81.1503718082561; Fri, 25 Aug 2017 20:28:02 -0700 (PDT) X-Received: by 10.31.87.132 with SMTP id l126mr312394vkb.81.1503718082274; Fri, 25 Aug 2017 20:28:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Fri, 25 Aug 2017 20:28:01 -0700 (PDT) In-Reply-To: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Fri, 25 Aug 2017 22:28:01 -0500 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a114e59f42302e105579fa695" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 03:28:08 -0000 --001a114e59f42302e105579fa695 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L wrote: > Hi David, > > > > Thanks for your comments =E2=80=93 I inserted follow-ups below. > > > > Fred > > > > =C3=98 Good points, but if anything more should be said I think it sho= uld > be kept as terse > > =C3=98 as possible. Can you suggest some text? An important thing to n= ote > is that the > > =C3=98 Redirect itself does not really give permission =E2=80=93 all i= t does is > provides the source > > =C3=98 node with the link-local and link-layer addresses of the target > node. If the source > > =C3=98 node has some other way of determining those addresses, it can = go > peer-to-peer > > =C3=98 without even needing to receive a Redirect. In that case, the o= nly > way to prevent > > =C3=98 peer-to-peer is via L2 mechanisms. > Yes link-local addressing is available for peer-to-peer communication if allow by the shared network, however redirects are the only mechanism available for a node to determine the link-layer address associated with an IPv6 address from within on of the Unique Prefixes as L=3D0, other than malicious activity. If L=3D0 you are not allowed to use ND to resolve the link-layer address, and the only other way for a node to learn a link-layer address associated with an IPv6 address from the Unique Prefix is by a redirect from a router. How about something like this; If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router, unless destine to a link-local address or redirected by the router. Note: If the shared network permits peer-to-peer operations, direct UE/subscriber device to device communication will be possible using link-local addressing across the shared network. Further, if the router provides redirects, then direct UE/subscriber device to device communications is also possible using the unique IPv6 prefixes across the shared network. I think this addition is important both if you want to enable or disable direct device to device communications, if you want to enable it this tells you what you have to do, and if you want to disable it, and the shared network allows it, you are reminded to disable router redirects and that you need to do something about link-local. It might be worth adding something about this to the security considerations too. For sure it be worth noting in the security consideration that if the shared network permits peer-to-peer operations, then malicious direct device to device communications would be possible even without link-local addressing or router redirects. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114e59f42302e105579fa695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

    Hi David,

    =C2=A0

    Thanks for your comments =E2=80=93 I inserte= d follow-ups below.

    =C2=A0

    Fred

    =C2=A0

    =C3=98=C2=A0= =C2=A0=C2=A0 Good points, but if anything more shoul= d be said I think it should be kept as terse

    =C3=98=C2=A0= =C2=A0=C2=A0 as possible. Can you suggest some text?= An important thing to note is that the

    =C3=98=C2=A0= =C2=A0=C2=A0 Redirect itself does not really give pe= rmission =E2=80=93 all it does is provides the source<= /p>

    =C3=98=C2=A0= =C2=A0=C2=A0 node with the link-local and link-layer= addresses of the target node. If the source

    =C3=98=C2=A0= =C2=A0=C2=A0 node has some other way of determining = those addresses, it can go peer-to-peer

    =C3=98=C2=A0= =C2=A0=C2=A0 without even needing to receive a Redir= ect. In that case, the only way to prevent

    =C3=98=C2=A0= =C2=A0=C2=A0 peer-to-peer is via L2 mechanisms.

    Yes link-local addressing = is available for peer-to-peer communication if allow by the shared network,= however redirects are the only mechanism available for a node to determine= the link-layer address associated with an IPv6 address from within on of t= he Unique Prefixes as L=3D0, other than malicious activity.=C2=A0 If L=3D0 = you are not allowed to use ND to resolve the link-layer address, and the on= ly other way for a node to learn a link-layer address associated with an IP= v6 address from the Unique Prefix is by a redirect from a router. =C2=A0=C2= =A0

    Ho= w about something like this;

    If the UE= /subscriber desires to send anything external including other UE/subscriber= devices (assuming device to device communications is enabled and supported= ), then, due to the L-bit set, it SHOULD send this traffic to the First Hop= Provider Router, unless destine to a link-local address or redirected by t= he router.

    Note: If the shared network permits peer-to-peer operatio= ns, direct UE/subscriber device to device communication will be possible us= ing link-local addressing across the shared network. Further, if the router= provides redirects, then direct UE/subscriber device to device communicati= ons is also possible using the unique IPv6 prefixes across the shared netwo= rk.

    I think this addition is important both if you want to enable or d= isable direct device to device communications, if you want to enable it thi= s tells you what you have to do, and if you want to=C2=A0disable=C2=A0it, and the shared network allows it, yo= u are reminded to disable router redirects and that you need to do somethin= g about link-local. It might be worth adding something=C2=A0about this to t= he security=C2=A0considerations too.=C2=A0 For sure it be worth noting in t= he security consideration that if the shared=C2=A0network permits pe= er-to-peer operations, then malicious=C2=A0direct device to device communications would be possible even without link= -local addressing or router redirects.=C2=A0=C2=A0

    Thanks.

    --
    =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking &am= p; Telecommunication Services
    Office of Information Technology
    Univer= sity of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    --001a114e59f42302e105579fa695-- From nobody Fri Aug 25 23:36:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4946E132A19 for ; Fri, 25 Aug 2017 23:36:38 -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 636qFW0W7g_0 for ; Fri, 25 Aug 2017 23:36:36 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74601327FF for ; Fri, 25 Aug 2017 23:36:36 -0700 (PDT) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 701D62D5064; Sat, 26 Aug 2017 06:36:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Sat, 26 Aug 2017 08:36:30 +0200 Cc: Brian E Carpenter , "v6ops@ietf.org" , james woodyatt Content-Transfer-Encoding: 7bit Message-Id: <24CA223F-FBDE-4D18-861A-2445F93A6084@employees.org> References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 06:36:38 -0000 > On 26 Aug 2017, at 02:45, Mark Smith wrote: > > Being able to invert the on-link LL status would then allow the > on-link/off-link treatment of all prefixes to be consistent on a link. How would the host reach the default router? Ole From nobody Fri Aug 25 23:42:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54908132C7F for ; Fri, 25 Aug 2017 23:42:40 -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 28USa8PSc8hX for ; Fri, 25 Aug 2017 23:42:38 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA875132C7D for ; Fri, 25 Aug 2017 23:42:37 -0700 (PDT) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4C7AB2D506A; Sat, 26 Aug 2017 06:42:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Sat, 26 Aug 2017 08:42:34 +0200 Cc: sthaug@nethelp.no, jhw@google.com, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <20170825.094233.74747800.sthaug@nethelp.no> To: Brian E Carpenter Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 06:42:40 -0000 > On 26 Aug 2017, at 01:22, Brian E Carpenter w= rote: >=20 > On 25/08/2017 19:42, sthaug@nethelp.no wrote: >>> If you follow the model of having IP topology follow the physical topolo= gy LANs are gone. You are left with a set of p2p links.=20 >>=20 >> Agreed. However, I think this may be an even bigger change, especially >> for enterprises, than starting to use IPv6. As a networking guy I love >> p2p links, but I also see how much our IT people love their LANs :-) >=20 > Agreed. I think LANs will be a great deal harder to get rid of than IPv4. >=20 > Apart from anything else, there seems to be no consistent o/s-independent > model for VRFs. I don't see how to progressively hide the LAN model > without that. (We are grappling with this issue in ANIMA.) I am ANIMA ignorant, so bear with me. Why would hosts need to deal with VRFs= ? Ole= From nobody Sat Aug 26 01:35:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A914132CEF for ; Sat, 26 Aug 2017 01:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gmS1tunPAd3 for ; Sat, 26 Aug 2017 01:35:04 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4E1132A89 for ; Sat, 26 Aug 2017 01:35:04 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id q189so5192418vke.4 for ; Sat, 26 Aug 2017 01:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ssPw3lO/2gLWf9xCJB9xtyQMXFHNzVoJTk5nVlGB3Q0=; b=HphGpEX+HMB+YnoAQajP7G+GAVoKMBZvgszquWNASZxcghdBdOBECzB4F5mDrfHwxH t/F3mEQoaoe+Jp8xianiMwnizNFDekwTgeCjJvPcjLcdmZeFptWBdp61smhEG2MtcP2q BAhJz4OA7wLKWkzN+mLD/sxRie1dGkP1AfUZ6GAcbotFKthgr5prFTaNo3z5lzTbY2dm AmxfnwNOZ7hndkPhJGDeOaAlSww/Afn3nNvMn/H0ehJp8tdhynfGveu5F3ADC+sR/F7c gn9jPmQhhMiV7v+84SXTH55ECFMgJPtnUALeMAelTioAJVA0QnLXlhoJkwFEVC+ztHKT E21Q== 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=ssPw3lO/2gLWf9xCJB9xtyQMXFHNzVoJTk5nVlGB3Q0=; b=H9JpmJVMHZw03++ayTO6Ax5Dt4UmjN3USqMHtsE2AurDDxa1wMZloEej7B4N3jTmYB 7rAAseoqKQ1/eXIWkSAcEr6Zc/JHBJ8p9KLYDHNhrmBy67dK9wKOftj603H60Vok3vT+ eHV04Md76QyR+xeuLBr+Z433Ct+1OQoY8xTFuotb90H/s6dwJZDVEuWK6h7W0rlux45o Abtny1LzbFgeJnzETNuTVAyAsLKC03JpeI2S2juiztjaYbSnn84bHXklfNTOjpe83sOj DousBrTTsIDwSqW+GIYCy8MpWyrnk6bJKDFiwLRC602uUKlTCK9An+TEqk6KQ+z1A090 oNvQ== X-Gm-Message-State: AHYfb5jXL1dQDJBlvXLpD7gZYX1G45Swr3J9crj4nN4EzsE/krB6HrEA 8otrAsXran84RotcDoPM4qA2VvI7jA== X-Received: by 10.31.96.149 with SMTP id u143mr742593vkb.101.1503736503376; Sat, 26 Aug 2017 01:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sat, 26 Aug 2017 01:34:32 -0700 (PDT) In-Reply-To: <24CA223F-FBDE-4D18-861A-2445F93A6084@employees.org> References: <94841D7A-A916-40CB-8D44-6D3843930B63@employees.org> <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <24CA223F-FBDE-4D18-861A-2445F93A6084@employees.org> From: Mark Smith Date: Sat, 26 Aug 2017 18:34:32 +1000 Message-ID: To: Ole Troan Cc: Brian E Carpenter , "v6ops@ietf.org" , james woodyatt Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 08:35:06 -0000 On 26 August 2017 at 16:36, Ole Troan wrote: > >> On 26 Aug 2017, at 02:45, Mark Smith wrote: >> >> Being able to invert the on-link LL status would then allow the >> on-link/off-link treatment of all prefixes to be consistent on a link. > > How would the host reach the default router? > RAs provide the router's LL address. Going by RFC4861, I think it may be necessary to create a /128 entry in Prefix List for the router's LL address, with the Router's LL address being flagged as on-link. That would then create a Destination cache entry for the router when the first packet is sent to it. That would then also create a Neighbor cache entry and possibly trigger an NS/ND for the router's LL address. It may not be necessary to create a /128 entry in the Prefix List. I find the RA processing section of RFC4861 (6.3.4.) a little unclear in the area of whether a ND cache entry should always immediately be created for the router's LL address. It seems to be saying an ND cache entry for the router's LL is only created or updated if there is a Source Link-Layer Address option. If an ND cache entry is created (which may trigger an NS/ND) and the Destination cache and Neighbor cache are the same structure, then a /128 entry wouldn't need to be added to the Prefix List for the router's LL address. It would probably be good to create a /128 entry for the router's LL address in the Prefix List regardless, to make it clear that the router's LL address is considered on-link even though other destinations in the LL prefix aren't. Regards, Mark. From nobody Sat Aug 26 04:24:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30749132195 for ; Sat, 26 Aug 2017 04:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1bL4B6az3hL for ; Sat, 26 Aug 2017 04:24:50 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03AB13217D for ; Sat, 26 Aug 2017 04:24:50 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id d12so6274602uag.0 for ; Sat, 26 Aug 2017 04:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cF5LLC4eSUVwoZrWQ5KYpHgvAktou94NGnIohqSoQCU=; b=tGuK2WsxxC6E6cGe5cqoQxJsBcprbEmw8MWkPfBez7AxgIl2g96l1zvyTNLnMPTBlk 7Hm2gDF6WMOq/LIpeVhqw+Hgrau8b0VYciXtopYf+eznU305LMijhtDJISzuTaqPwbgG DiKZATtwuee8t2Vj0gSzyBPqjIYXeyfOXLtWkE6m1u4i4Cm950sUTJLEVlzC+zfHQ5Fp 1agCwVBBzUXptO84zYypEbqqv2T9XhSJixWJ9WakSauCjk2ywTa7wKbo5zrVzsIubzoA 9v49fzKoRqNZQWmjYrSO9NxdNCm/lAwJkNep8IaatN1mblGSwhDPx0tsT536rmpxb+Cg CkPQ== 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=cF5LLC4eSUVwoZrWQ5KYpHgvAktou94NGnIohqSoQCU=; b=EDycju2xFBzJjlZGLkunlybajrOE38jVoUyXeeL5XTKgK+OBq6iKieOSwaRql/tTrN L4weadeEJFJiXidFnBKonBlRj/AnMQl3XeSmZhoICZkIPN+zc31/EVqbSS3AXKOuaes3 WqxOc5nvgLWIMG0sypZHfuLw39gOSc3PKQWpBK7dArbRxc8Otoj3oZ+8HP4/rrqzUNbH NW9iJ+3L4gT/8l6LkaR/KQ+0Up3gzx5za35fjckLk6xV3FZzUDXX29O2P6oc0ec4d+/g K+JyizSOWp9l5T9SvN/QA49k/ZhWjC0Pk3mS5tbLMt9BxQFt95OBZGJw9rOXFhY54SmO sKZA== X-Gm-Message-State: AHYfb5gH2qufqZMSyi8vHtSBTnANAH2+ttOCODwZR42m7G2K+uHWraFJ GYKtCnhkGHjX5DBmwjPar/XAKb0XDA== X-Received: by 10.176.21.178 with SMTP id i47mr867631uae.120.1503746689642; Sat, 26 Aug 2017 04:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sat, 26 Aug 2017 04:24:48 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Sat, 26 Aug 2017 04:24:48 -0700 (PDT) In-Reply-To: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> From: Mark Smith Date: Sat, 26 Aug 2017 21:24:48 +1000 Message-ID: To: DY Kim Cc: james woodyatt , v6ops list , Ole Troan Content-Type: multipart/alternative; boundary="001a1145308044bc810557a64fc5" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 11:24:52 -0000 --001a1145308044bc810557a64fc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 24 Aug. 2017 21:50, "DY Kim" wrote: A typo=E2=80=A6? Did you mean to say: "LL destinations that are also on the same link are then directly reachable.=E2=80=9D No. Per RFC5942, LL destinations are on-link. Per RFC5942, all other destinations e.g. GUA default to off-link. For these other destinations, they can be switched to on-link using a RA PIO with the L bit set for the prefix. It is not currently possible via an RA PIO to switch the LL prefix to off-link. (Remember, "off-link" means "ask a router".) --- DY > On 24 Aug 2017, at 20:41, Mark Smith wrote: > > It isn't possible to invert the LL on-link assumption so that > LL destinations that are also on the same link are then reachable via > a router on the link. --001a1145308044bc810557a64fc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 24 Aug. 2017 21:50, "DY Kim" <dykim6@gmail.com> wrote:
    A typo=E2=80=A6?

    Did you mean to say:

    =C2=A0 "LL destinations that are also on the same link are then direct= ly reachable.=E2=80=9D
    =
    No.

    Per RFC5942, LL destinations are on-link.
    =
    Per RFC5942, all other destinations e.g. GUA de= fault to off-link.

    For t= hese other destinations, they can be switched to on-link using a RA PIO wit= h the L bit set for the prefix.

    It is not currently possible via an RA PIO to switch the LL prefi= x to off-link.

    (Remember= , "off-link" means "ask a router".)


    ---
    DY

    > On 24 Aug 2017, at 20:41, Mark Smith <markzzzsmith@gmail.com> wrote:
    >
    > It isn't possible to invert the LL on-link assumption so that
    > LL destinations that are also on the same link are then reachable via<= br> > a router on the link.


    --001a1145308044bc810557a64fc5-- From nobody Sat Aug 26 04:28:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77A13291B for ; Sat, 26 Aug 2017 04:28:47 -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 QJLplkEp-OzU for ; Sat, 26 Aug 2017 04:28:46 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE2213233D for ; Sat, 26 Aug 2017 04:28:46 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id r187so815869pfr.4 for ; Sat, 26 Aug 2017 04:28:46 -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=dcFQqRxFxHqCqSh8NZL+c6doBRBjrQG6SvZEdEXTJUA=; b=bym0YlU5MJPJ7BWOXaSrAnUZzQrgCGSNm4ntgCd/sfMxnR/lUWHaw1NAmxtMMQHWNE ZGE9cJfMhR+vK4W7vImUSNgw/OgeJhpWvfAGdAk+1Au9ycoRS0P+Ri1mdTJKft/8v3ln 3gcYKiPjD14mTiphAeiJffLbOXUmO62if2TDYPQKn7/NQdkakLbiQ3rnnriEHcmRrNDp 7hfZ+tySWYqApAQTSTBw5wDPzBU4XJqmQoKNpZ54KbjcJqPQgt/XqtVRY63v6cmsD4HW gf3WZnGT0JRiDKHLXEz1DDIGCp506NO/CGUlTDtol5uxYt+Z0WuGCF169UbOr4IMb/E7 lmAA== 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=dcFQqRxFxHqCqSh8NZL+c6doBRBjrQG6SvZEdEXTJUA=; b=O0a2isZ5TgBpTEmEf5mwNdTxZchH45+Za2qTTG9ARyHYzbBXo4vJ+ci5WAzInaHTlY XsxIzU2DyJKENHbu9LUp7Hq5PxrV6DwPiHo/jYKV8Q973KY/L7I1v3b+7vQAYC3i2Iwu jnJbgZd8XPrfIOwk9S7ox7Ycl5x5kAkEMqsgIt20tLC9QIsCbadEMDum/KrHSvduOyLJ 8KqY2srbQPOoINzCU0LQm9Mj758MriE2F3szATRaWeh0sVE874EN+4zLGBocom0Ny9xA zM9ceZ/Mptz+FtBgIWTmsEqhw0BybV3nh1M26uh/eQxpUTJIdU0mHIA+0LRjY6fa6GW/ qCcw== X-Gm-Message-State: AHYfb5hBGOUnMJeVrVldJY30DAPXxtVgwoF39fzg1XsjOU1bF0NzYKeq SJwBMVUp4zeb3A== X-Received: by 10.84.218.3 with SMTP id q3mr1704122pli.282.1503746925724; Sat, 26 Aug 2017 04:28:45 -0700 (PDT) Received: from [112.167.24.163] ([112.167.24.163]) by smtp.gmail.com with ESMTPSA id o18sm13827745pfe.90.2017.08.26.04.28.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Aug 2017 04:28:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: DY Kim In-Reply-To: Date: Sat, 26 Aug 2017 20:28:39 +0900 Cc: james woodyatt , v6ops list , Ole Troan Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 11:28:47 -0000 Oh=E2=80=A6 you want to route LL destinations also via the default = router, not directly=E2=80=A6 --- DY > On 26 Aug 2017, at 20:24, Mark Smith wrote: >=20 > > It isn't possible to invert the LL on-link assumption so that > > LL destinations that are also on the same link are then reachable = via > > a router on the link. From nobody Sat Aug 26 13:33:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6E113232C for ; Sat, 26 Aug 2017 13:33: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 Qq2nggKPpV09 for ; Sat, 26 Aug 2017 13:33:06 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF4C1320CF for ; Sat, 26 Aug 2017 13:33:05 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id r62so5010374pfj.0 for ; Sat, 26 Aug 2017 13:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=90ccZ9ix9a9CYHp/MrlABrkfeskU/e6qSAlrEbNAaoI=; b=L+DEQvGpk2mD0SXASnyxfkS9I7ob45CpC+URsQdlM+K+FNn2Wg9yrz7wru4nakV36O 56u1DXyRckTvr3zG0n3nNvqGDyS7BhITNIpOUR5mVtNk1xNKCKSBOcG9SQHGzzSLmfpp jYsVTSDGMStoPamiAq56V7dfx+vq8GElHVXeGPfuG+cooAF6ShtBtRWGupTg0dwk1Bcu hpV0D5dldv6CkdbWKCfes55D2iAOyiitIDxtd6v496kK4MeXUhAQeES0+hB7vLc44vdb fARvX14ROtwwsuC1bndH8D/WX5cnlrfMvVgWM9/ceEvTA7vSndOz9ZbLuWy8Kz0hdSa/ RYrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=90ccZ9ix9a9CYHp/MrlABrkfeskU/e6qSAlrEbNAaoI=; b=WiuVKnyuepub8tGTmqBT5iyFLkY8+NF6mNOPfE8MmfHjHyuolQlFepDqIeLrjh6Rtw EiDmQAav0qYVimthHFX6ODsnmQiyNtwF5wwuFlWUguXUlqifL+mw6w0ESpraLfhZxqUV TDN1hx9cH12uHRr+aqzJEFVITh5XSvUwGAdU+0ASz6wA9FjF2FluiuSOPbe4+bgkJto/ hOj9TaMZIfKQLVFlw5ISTj1GervSwM1vA+EbiVtXYja3ImhvKCNcRz77I+jm7oIbSlM+ QLK5Q2asFFnizLL8hLJ9uP5lfIE95lWLW35ZbCq+g2pBdkmQtbCVdIqiXIpG3SzBwe19 LlRA== X-Gm-Message-State: AHYfb5iIP05k7P7CWPQN2JMAI/m8JuUgw/QRB6toqMnwsHaSHN3b4GRO zMxcfNlXXQDyacRi X-Received: by 10.99.44.10 with SMTP id s10mr2627177pgs.116.1503779585268; Sat, 26 Aug 2017 13:33:05 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q5sm17198070pgn.21.2017.08.26.13.33.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Aug 2017 13:33:04 -0700 (PDT) To: Ole Troan Cc: sthaug@nethelp.no, jhw@google.com, v6ops@ietf.org References: <9c59283b-4a6e-67e6-0a42-ac41e06ea1b2@gmail.com> <20170825.094233.74747800.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 27 Aug 2017 08:32:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 20:33:07 -0000 On 26/08/2017 18:42, Ole Troan wrote: > > >> On 26 Aug 2017, at 01:22, Brian E Carpenter wrote: >> >> On 25/08/2017 19:42, sthaug@nethelp.no wrote: >>>> If you follow the model of having IP topology follow the physical topology LANs are gone. You are left with a set of p2p links. >>> >>> Agreed. However, I think this may be an even bigger change, especially >>> for enterprises, than starting to use IPv6. As a networking guy I love >>> p2p links, but I also see how much our IT people love their LANs :-) >> >> Agreed. I think LANs will be a great deal harder to get rid of than IPv4. >> >> Apart from anything else, there seems to be no consistent o/s-independent >> model for VRFs. I don't see how to progressively hide the LAN model >> without that. (We are grappling with this issue in ANIMA.) > > I am ANIMA ignorant, so bear with me. Why would hosts need to deal with VRFs? The intention is to build the autonomic control plane as a secure overlay network on top of link-local connectivity, so that it has no dependency on regular routing and addressing. So every autonomic node needs a VRF mechanism. But this is not my bit of ANIMA, so I have to refer you to draft-ietf-anima-autonomic-control-plane. Brian From nobody Sat Aug 26 23:07:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6966D1329BE for ; Sat, 26 Aug 2017 23:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FyiqIHyl72Az for ; Sat, 26 Aug 2017 23:07:50 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C855B1329BB for ; Sat, 26 Aug 2017 23:07:50 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k22so8072391iod.2 for ; Sat, 26 Aug 2017 23:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ktOQxxk4C+U0sjh5SFXBihpx4h0SLRzEpBj1S04Dki8=; b=JpUmU79Au+bXGeqLIpysnVgA2rV5Ui1F4UgWT0NrzjZ3qa0HvCig56VVKxqDPpkSjF RaZ1l/r7nOKyEvK1MQT9GaJBygQsF+6xTu16SKyHi31UbE3ZbWtOA4V1BDePFX7cJRc5 86jblrZ9sI5cjZla8wIyuxLGhu+2qut18EUDllLBvHSOHKstT/jX4oRYv384rW2xS1Ne xAyREK4twzffTTVpLTlNE6EbWQ/0AYdzY0Njw0m2U8qvv6iXJ46U8zZDEhwUpS9lNULv 3HNdyq8n6yFGe9Rznp/dVlC4OusrWPIztf5fEwzOKUcbSSv0YHfufak1F3k6ukHUpjZN WpMA== 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=ktOQxxk4C+U0sjh5SFXBihpx4h0SLRzEpBj1S04Dki8=; b=MstKYNpg85mCUk3RdBGfYAgdct6eHlaRHAxOHbZNvpOuDtGm+IbLs6Ij3p27BJyfv1 8av5RBxY6iNNWSggSd9NFnuXGXC9rP71MlYwXaI5/LXBtH1AAw6pUufvtGXz08AVbyUH QMzjQwFed/aNjz/esh0rvDUaSKbs3V1AQAkSLGSgzKVaBxzeddWH5Joh1N0z5emekHFx C1lFnL3ZNERmu4UqKAyD3ZcLsIb1VADLUC17/MjBmqtWGz1oiGmowcvLYh7BbjdKe9SZ 3UrqmszldXLQp0fHb2yMIMtrE0eiJMwyVYWEfJbbnHbKD13JqAkRft0OwYiEZte8tnN3 ikWg== X-Gm-Message-State: AHYfb5guMjiJu9WLs9UllO8he+CeDa26R+sxQoZBi9FnCAW9PlmgiaH4 fP+ZZS+YQdXN3PWRrogKA7AN7TA+Onb1 X-Google-Smtp-Source: ADKCNb400Cw8anKdBxIWWyUpDTTtWHeQnL6hM7J0e71P4XjJ3GDFEoLPDRu2c0izV1mcVt8v6hYIS0tVEHjjvELNHcc= X-Received: by 10.107.137.97 with SMTP id l94mr2871863iod.279.1503814069870; Sat, 26 Aug 2017 23:07:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sat, 26 Aug 2017 23:07:29 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sun, 27 Aug 2017 15:07:29 +0900 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113eaff471c8860557b5ff24" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 06:07:52 -0000 --001a113eaff471c8860557b5ff24 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 25, 2017 at 2:37 AM, Templin, Fred L wrote: > In section 2, the document says: > > " o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router" > > Please change to say: > > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" > No, *don't* do that. That's a fundamental change to the deployment model that this document describes, and nullifies many of its advantages. --001a113eaff471c8860557b5ff24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On F= ri, Aug 25, 2017 at 2:37 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
    In section 2= , the document says:

    =C2=A0 =C2=A0" o=C2=A0 Two devices (subscriber/hosts), both attached t= o the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router"

    Please change to say:

    =C2=A0 =C2=A0"o=C2=A0 Two devices (subscriber/hosts), both attached to= the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router unless the share= d network
    =C2=A0 =C2=A0 =C2=A0 explicitly permits peer-to-peer operations"

    No, *don't* do that. That's a fundam= ental change to the deployment model that this document describes, and null= ifies many of its advantages.
    --001a113eaff471c8860557b5ff24-- From nobody Sat Aug 26 23:22:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE11326BB for ; Sat, 26 Aug 2017 23:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTIU-_mrG1Dp for ; Sat, 26 Aug 2017 23:22:27 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E002C1200B9 for ; Sat, 26 Aug 2017 23:22:26 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id g11so9563047uah.2 for ; Sat, 26 Aug 2017 23:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0kulYr/P8q8vw+/G3qclRVKLE76UGefk4ak5mOtPOvE=; b=BaxXFLJLWAj/D0j5pUhmllXnM28yhttTNkUmpoOhdnb7r9aJK09DYNVcOgdqQ4cO6S ZCQ2C50hmJPWrlhJhe4k7H8weKd8T3CuSHYz3pLvn8aMJHYFvlhVeSg8UTKlINfRQh8X +16jdvYg2DAr99m8PgpooAPORd4NgmTX1rGtvOEiCnf6Gno8dVEI44IK/l+TX01uBGsp l4GOYQqMOijepOLVGIQnnBUWhwAzZpiI7sgy57pYRGZvZy6DuXUVHbnVPIIas0JuGoXN K+VsXaGA99Fx0+Zs4dO2pGCXZmam/7NfnFuuRKWEDeAL8kXNwCS+xp5OLubLn+uhEINo T9IQ== 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=0kulYr/P8q8vw+/G3qclRVKLE76UGefk4ak5mOtPOvE=; b=UwPsNqhW7hME40tRgTImVTujhCoaCMZAdERVSSWrHkkLJmjkdKFhvQM/ttF8TvWu95 FpGapgKjpiuEgRkI/JLIoS0i1SxG9GS/cOR37YNnCtS9mo4JswjmTsfRsFCTSRhQXO/4 ys6k4ldX+X12ABQYf3mJS0e6vuulNslx8tId1abhumbqJ5IcAUk3un1kGZfV27Qs0ibV daqu7xC3Ost0Hmd72VrgIzEdEspoHX4WQE/Ki8695jcFDyJMniGgPnCkWMS/Rg7l1Sl6 gHsn5O7/Z/MamSdHTsmfqIO8xDG1bVtffFuizDw2WCDrhAkTFoIO2Az3Vv4WiZd3ukV7 X2FQ== X-Gm-Message-State: AHYfb5hjtI6OfprjBklHhQ8+sFh19RlCo8BhAm+PL9ixBqGG0mh2t8vM T/lvwL4Zb7EXVp+MgjRpSCerjahfNQ== X-Received: by 10.159.56.10 with SMTP id p10mr2243793uad.189.1503814945991; Sat, 26 Aug 2017 23:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sat, 26 Aug 2017 23:22:25 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Sat, 26 Aug 2017 23:22:25 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> From: Mark Smith Date: Sun, 27 Aug 2017 16:22:25 +1000 Message-ID: To: DY Kim Cc: james woodyatt , Ole Troan , v6ops list Content-Type: multipart/alternative; boundary="001a11496dfca9ef9c0557b633ef" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 06:22:28 -0000 --001a11496dfca9ef9c0557b633ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 26 Aug 2017 21:28, "DY Kim" wrote: Oh=E2=80=A6 you want to route LL destinations also via the default router, = not directly=E2=80=A6 Yes. Direct is the default, and cannot currently be overridden. --- DY > On 26 Aug 2017, at 20:24, Mark Smith wrote: > > > It isn't possible to invert the LL on-link assumption so that > > LL destinations that are also on the same link are then reachable via > > a router on the link. --001a11496dfca9ef9c0557b633ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 26 Aug 2017 21:28, "DY Kim" <dykim6@gmail.com> wrote:
    Oh=E2=80=A6 you want to route LL destinations also vi= a the default router, not directly=E2=80=A6


    Yes. Direct is the default, and cannot currently be overridden.


    ---
    DY


    > On 26 Aug 2017, at 20:24, Mark Smith <markzzzsmith@gmail.com> wrote:
    >
    > > It isn't possible to invert the LL on-link assumption so that=
    > > LL destinations that are also on the same link are then reachable= via
    > > a router on the link.


    --001a11496dfca9ef9c0557b633ef-- From nobody Sun Aug 27 09:39:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FC71326ED for ; Sun, 27 Aug 2017 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 u3hH34LCgmCd for ; Sun, 27 Aug 2017 09:39:34 -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 79153132328 for ; Sun, 27 Aug 2017 09:39:34 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id ACDC6A32 for ; Sun, 27 Aug 2017 16:39:33 +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 htxbDckj4ZQv for ; Sun, 27 Aug 2017 11:39:33 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 72737A1F for ; Sun, 27 Aug 2017 11:39:33 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id j189so3762439vka.0 for ; Sun, 27 Aug 2017 09:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fHZ+jYsyaDnB+NZNTSUkqwDwwfAQT8oaUJirZcNnur0=; b=e4v4x+eaBcpfLJrpYExm6GdJ9luQPkoPSJLRAHL+5V9vPec5ZDzOvehjdJXA28Wjzt i/n6w9D0Kf5ms4LUh6wQfhWUZuGbS/0psoO6zzcdHQKj9g0j8qbYPDv3+KIdDDv28AoL 5K4DHM04+cOmxydJL7W2b/FL64kwFlYZAtqTxgAawL+6rBzAHvtolrZGM5l42Y9HH74S GmsBcO7HCND0/lkY33GH9UxQDGlYH1E56ccOyksF63ApdjRdDIMgC5XC/l4p2skowv7O GAlZkiDAp9qI0koEqXILRjP4Lo5KsbfJEP6TbaP/vEPPfvGOU0AxTlAvt9lMYLbXi9q7 23vw== 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=fHZ+jYsyaDnB+NZNTSUkqwDwwfAQT8oaUJirZcNnur0=; b=UgmoMzvKErrzKBBz9n6RuUMNQhEEzr08l1tTLU/W43uAa292yzUWfz5OmC1bLqk+pk 52/SRg8rvfCU90Y0IHaAwH+lGtRtdCeL5HXRZiP7RM9M8SerM8eUA2pHp99sOGN5FYkH QGWOVmxtmLXSeEdPiUEZpNzy9AeY5VytIwkBBoARb7fKFLt9/T5BascrsvZhrfB19WQX NWqVJb5lsStx8S0Ytvw6cpLGWj3M+cPT3lhDPAWm95CXtujAiRxLzv/H/OX/HOCIZBse U7dgQYj4BSBRkr5UCK4/hFyA2ua86WmQH+DiOT5InmSFSZzFUIP993PAiJcX10nko6e+ qtlQ== X-Gm-Message-State: AHYfb5j42xZpldWFDeuIJ8hBBYkPP5G+B8DWKxBfN0BIO30H5YxzjDDH 9RBfjjz9uLd78Avlo0DcEqPnCYFKbEtTdcG7hdTrLMIFI9bqARd8mzQnKtc37KaMyTVClHWxFGB ynlLoOob9DpDNmShR X-Received: by 10.176.80.188 with SMTP id c57mr2902192uaa.32.1503851972642; Sun, 27 Aug 2017 09:39:32 -0700 (PDT) X-Received: by 10.176.80.188 with SMTP id c57mr2902185uaa.32.1503851972420; Sun, 27 Aug 2017 09:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Sun, 27 Aug 2017 09:39:31 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Sun, 27 Aug 2017 11:39:31 -0500 Message-ID: To: Lorenzo Colitti Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19211c9c82c70557bed2e5" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 16:39:36 -0000 --94eb2c19211c9c82c70557bed2e5 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 27, 2017 at 1:07 AM, Lorenzo Colitti wrote: > On Fri, Aug 25, 2017 at 2:37 AM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > >> In section 2, the document says: >> >> " o Two devices (subscriber/hosts), both attached to the same provider >> managed shared network should only be able to communicate through >> the provider managed First Hop Router" >> >> Please change to say: >> >> "o Two devices (subscriber/hosts), both attached to the same provider >> managed shared network should only be able to communicate through >> the provider managed First Hop Router unless the shared network >> explicitly permits peer-to-peer operations" >> > > No, *don't* do that. That's a fundamental change to the deployment model > that this document describes, and nullifies many of its advantages. > > I agree, that this should not be changed, as it is an intentional part of this deployment model. However, based on this and related discussion, I think something should be added to the security considerations along the lines of the following; If the shared network permits peer-to-peer operations, a malicious device could communicate with other UE/subscriber devices across the shared network. Additionally, direct UE/subscriber device to device communication will also be possible across the shared network, without first going through the First Hop router, using link-local IPv6 addressing or using the Unique IPv6 Prefixes, if the First Hop router provides redirects for the Unique IPv6 Prefixes. This can be mitigated with access control lists limiting link-local IPv6 traffic between UE/subscriber devices to only the necessary Neighbor Discovery traffic and ensuring that the First Hop router does not provide any redirects to the UE/subscriber devices. Further, Rogue Router Advertisements SHOULD be mitigated as discussed in [RFC6104], to prevent malicious or simply misconfigured devices from impersonating a router on the shared network. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c19211c9c82c70557bed2e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Aug 27, 2017 at 1:07 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
    =
    On F= ri, Aug 25, 2017 at 2:37 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
    In section 2, the document says:

    =C2=A0 =C2=A0" o=C2=A0 Two devices (subscriber/hosts), both attached t= o the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router"

    Please change to say:

    =C2=A0 =C2=A0"o=C2=A0 Two devices (subscriber/hosts), both attached to= the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router unless the share= d network
    =C2=A0 =C2=A0 =C2=A0 explicitly permits peer-to-peer operations"

    No, *don't* do that. That's a fundam= ental change to the deployment model that this document describes, and null= ifies many of its advantages.


    I agree, that this should not be changed, as it is an = intentional part of this deployment model.

    However, based on this a= nd related discussion, I think something should be added to the security co= nsiderations along the lines of the following;

    If the shared network permits peer-= to-peer operations, a malicious device could communicate with other UE/subs= criber devices=C2=A0across the shared network. Additionally, direct UE/subs= criber device to device communication will also be possible across the shar= ed network, without first going through the First Hop router, using link-lo= cal IPv6 addressing or using the Unique IPv6 Prefixes, if the First Hop rou= ter provides redirects for the Unique IPv6 Prefixes. This can be mitigated = with access control lists limiting link-local IPv6 traffic between UE/subsc= riber devices to only the necessary Neighbor Discovery traffic and ensuring= that the First Hop router does not provide any redirects to the UE/subscri= ber devices. Further, Rogue Router Advertisements SHOULD be mitigated as di= scussed in [RFC6104], to prevent malicious or simply misconfigured devices = from impersonating a router on the shared network.
    =

    Thanks

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecommun= ication Services
    Office of Information Technology
    University of Minne= sota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 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
    --94eb2c19211c9c82c70557bed2e5-- From nobody Sun Aug 27 13:29:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A4F13208E for ; Sun, 27 Aug 2017 13:29: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 4UL3q7LvFgdT for ; Sun, 27 Aug 2017 13:29:41 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D49A126E64 for ; Sun, 27 Aug 2017 13:29:41 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id h75so10030917pfh.1 for ; Sun, 27 Aug 2017 13:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YaHiRCsUhs2yJAxhnZuDwLdMPAGz4WBwnBW1jGq2S10=; b=hhpCL06UPVAgLEkGDEIcLe5Ug2Xj8/vHX9UYhCAKZi7s8hpFo1oOD2jaxz2l0Gop+A T4tCtH+HIDMQNubC2mb7k+jK5Y7LFwc2/pbOq857BW77OgPXGD6TDhMQAN0rMasFqNq8 hW8EsK8nEYulE9wWRNuz5MIXznkhT6gLNbV40/uhNV2kZ2NCe9E7unr9v3oHXtkyLl7f x38kNLcWJfGiYsv+hwK+VKA0ynXPIMXfObDPe7AOPgC+HKYeBhZ99e3QQarMuPF5zDrR N5yBhGk3IAyG04EwL0HNRsb0MBmh/tOqtC1hbk3vE6tCIMHYWrELwTwiXHaF66t2QFg+ ICMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YaHiRCsUhs2yJAxhnZuDwLdMPAGz4WBwnBW1jGq2S10=; b=ow+y4kujHN5CmpmsS+gmF+5eYHZrARRGpAFLa42idsOmCYU5bb9ktK2BwSwcpFOyW2 HQHbBkFRUIthFCWJyTwe6MQXh5PT6Nze3Y4X7KbMdfti8sdG2YKvttnPruvU0XH8kYOG Im6haI39MtFRGGx3WWo6NYiNm3hgCMe1TMlaCL4i5DPWkpav0fJAE1jjehY/tEY6D8np 03F+g4TZ45KS+p8pWph64O+c9TL8XYlJBpJoK0nCv5gmL/acjXPyZyvsO9k5iWkxZfc4 NLlPzy92xpU1jT1jF/x2ikZEQ7aQFACX7fZ5ePyV5NlB3GuX0Z5bRSOHIA9EMC3Vu8Va dV8Q== X-Gm-Message-State: AHYfb5iggBu32t+ao0lhewoa9kze3K12FugLFf+XH3KDu7TiPXTjEUPt f8vLREKFmnCR3OEM X-Received: by 10.98.149.76 with SMTP id p73mr972215pfd.98.1503865780649; Sun, 27 Aug 2017 13:29:40 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o18sm18098145pfe.90.2017.08.27.13.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Aug 2017 13:29:39 -0700 (PDT) To: Mark Smith , DY Kim Cc: james woodyatt , v6ops list References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> Date: Mon, 28 Aug 2017 08:29:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 20:29:43 -0000 On 27/08/2017 18:22, Mark Smith wrote: > On 26 Aug 2017 21:28, "DY Kim" wrote: >>=20 >> Oh=E2=80=A6 you want to route LL destinations also via the default rou= ter, not >> directly=E2=80=A6 >=20 > Yes. Direct is the default, and cannot currently be overridden. It's more than that. It's a matter of *definition*. If X and Y are on the= same link, X can send layer 2 packets directly to Y. If you put measures in place to prevent that happening, they are no longer on the same link i= n any meaningful way. This is why most layer 2 "switches" emulate 1983-styl= e Ethernet yellow cable and why the more clever ones perform MLD snooping, so that the overhead traffic for emulated multicast is limited. If you take that away, your *only* link-local neighbour is the switch itself. You can never discover any other LL neighbour and therefore never= send packets to it, because it doesn't exist. Now you could, in theory, make my head hurt by also performing LL snoopin= g in the "switch", so that it emulates yellow cable for some addresses in fe80::/10 but not others, but why you would do that instead of just using= a VLAN beats me. Brian >=20 >> --- >> DY >> =20 >>> On 26 Aug 2017, at 20:24, Mark Smith wrote: >>> >>> It isn't possible to invert the LL on-link assumption so that >>> LL destinations that are also on the same link are then reachable via= >>> a router on the link. From nobody Sun Aug 27 15:20:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77AF13293B for ; Sun, 27 Aug 2017 15:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8B-kohwna59 for ; Sun, 27 Aug 2017 15:20:45 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11731321C9 for ; Sun, 27 Aug 2017 15:20:44 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z187so11460862vkd.2 for ; Sun, 27 Aug 2017 15:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5uYG45aOxCBMBz/LXmiNyWMVQ+zNrtBh/GbSeU811WI=; b=HShe2h/tsN7O74xi4e6TKN7xZuf5u0LeW/PVg3bmhGbqGyc9c4RIddV1vXUrhaDsEc G5rkbUQJEkpru+D29XVLl1HBqNHbXaPK8Wegd0t1ocGvakY5fSURU4YSU1a3ykP/Htch nV57vuwQJDov9HQfYZWzdsYeJrqlXQ1QRmtRzpBVZA97NcDLMJ8TgaGknJ/p62fawEqy O/4/5XPKgiQ5nkOBHKHcn1y7J48A13FBxQ3JPJo+wkUvdD0HRu19V1FK16jUM1U8Znd7 QYPejaF8drCfL6VsKAHBYgYDxpMcik4FCeznOGpbtd2vkjisyTH7vB9JX1eAnEYY7/ul V8Aw== 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=5uYG45aOxCBMBz/LXmiNyWMVQ+zNrtBh/GbSeU811WI=; b=I06eBmWpsnKPdJtHkwdtDB5IhiURripvx7U/BXyrWTViEyKc3l5RG/ZU5lP2+M9hhA UYpr7kF4+HssZOOYXPCidLiWyTHZEdKxAqSRs9Z6RtUDnoYgGWaVRmfP6pCXqR0X2V1k gEAtTF8xRB6gI4fGQlIOVxMzLZ7Y+rU93XVHiwf2MV0EOe2Nze3iveoFFPftdXTB1PrT nK06nnHoZDdpJ5jWuY6XuuxGk64vP+CpmaTtylfHwb1kWtsiIwXOabtI7hdlheOPNec1 w+gc83yAIqnXprg9C4ghVonGQgK4MbkxEVWSkjXwDpGKjDK3xs7fNZDKqzyYJiagsH74 EwzQ== X-Gm-Message-State: AHYfb5jgETGRNXPUh0jyZqAUy3unJC5fYS7UAVmTpCE+IPQa4cTYfEMn CaHzA/EbRxk9DPS7xoC+Emxh9XCNJA== X-Received: by 10.31.61.71 with SMTP id k68mr1083749vka.11.1503872443784; Sun, 27 Aug 2017 15:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 15:20:13 -0700 (PDT) In-Reply-To: <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Mark Smith Date: Mon, 28 Aug 2017 08:20:13 +1000 Message-ID: To: Brian E Carpenter Cc: DY Kim , james woodyatt , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 22:20:47 -0000 On 28 August 2017 at 06:29, Brian E Carpenter wrote: > On 27/08/2017 18:22, Mark Smith wrote: >> On 26 Aug 2017 21:28, "DY Kim" wrote: >>> >>> Oh=E2=80=A6 you want to route LL destinations also via the default rout= er, not >>> directly=E2=80=A6 >> >> Yes. Direct is the default, and cannot currently be overridden. > > It's more than that. It's a matter of *definition*. If X and Y are on the > same link, X can send layer 2 packets directly to Y. If you put measures > in place to prevent that happening, they are no longer on the same link i= n > any meaningful way. It sounds like you haven't heard of "Private VLANs" or Broadband Forum TR-101 N:1 VLANs. These LANs are more similar to NBMA or the RFC4861 "shared-media" shared media - a link that allows direct communication among a number of nodes, but attached nodes are configured in such a way that they do not have complete prefix information for all on-link destinations. That is, at the IP level, nodes on the same link may not know that they are neighbors; by default, they communicate through a router. Examples are large (switched) public data networks such as Switched Multimegabit Data Service (SMDS) and Broadband Integrated Services Digital Network (B-ISDN). Also known as "large clouds". See [SH-MEDIA]. (SH-MEDIA IS RFC1620). with the difference being that it is not possible to use or create a shortcut path between the attached nodes. That is layer 2 security being imposed on inter-node communication. So why "Private VLANs" instead of per-host physical or logical p2p links? - no need for a router interface (logical or physical) per host - no per-host router interface configuration - no per-host subnet assignment and subnet identifier management - in the case of logical p2p links e.g., VLANs, no virtual link ID manageme= nt - less likelihood of running out of virtual link IDs - For VLANs, 4094 host-VLANs in a network is a lot lower threshold than 4094 multi-host VLANs. In a broadband scenario, using VLANs limits the subscribers attached to 4094, which for a BNG is a low number. Double VLAN tagging can be used to resolve that, however that creates configuration and ID management overhead for the subscriber termination devices e.g. ADSL DSLAMs. TR-101 N:1 VLANs create subscriber separation without that overhead. - no router configuration needed to aggregate the downstream address space With p2p links, usually would aggregate those subnets into a single prefix before announcing them to upstream routers. A trivial task, however another thing to remember to do and to possibly make an error doing. - can have router redundancy, because 2 routers can be made visible to a ho= st No such thing as a "3 ended" point-to-point physical link. Could be done with per-host VLANs, however now all the above router configuration complexity is duplicated across two routers. There can be limits on how many instances of things such as VRRP that can be run on a router, which may impose a limit on how many VLANs can exist and therefore hosts that can be attached. - conceptually more similar to the way hosts have been attached to multi-access LANs for many years (Less likely today, however many people for many years would have looked at you funny if you said we're going to create a subnet and VLAN per host) IP subnets have been used for many things over the years. In this case, the fundamental advantage of placing all hosts in a single subnet, even though functionality they're closer to being attached to p2p links, is that it is effectively creating a dynamic pool of p2p links without having to perform the corresponding p2p related IP subnet and link-layer configuration and management. It's a configuration and maintenance optimisation. Regards, Mark. > This is why most layer 2 "switches" emulate 1983-style > Ethernet yellow cable and why the more clever ones perform MLD snooping, > so that the overhead traffic for emulated multicast is limited. > > If you take that away, your *only* link-local neighbour is the switch > itself. You can never discover any other LL neighbour and therefore never > send packets to it, because it doesn't exist. > > Now you could, in theory, make my head hurt by also performing LL snoopin= g > in the "switch", so that it emulates yellow cable for some addresses in > fe80::/10 but not others, but why you would do that instead of just using > a VLAN beats me. > > Brian > >> >>> --- >>> DY >>> >>>> On 26 Aug 2017, at 20:24, Mark Smith wrote: >>>> >>>> It isn't possible to invert the LL on-link assumption so that >>>> LL destinations that are also on the same link are then reachable via >>>> a router on the link. > From nobody Sun Aug 27 15:33:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6288C13235A for ; Sun, 27 Aug 2017 15:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ds7hLoxYfLp for ; Sun, 27 Aug 2017 15:33:55 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 778DA13232C for ; Sun, 27 Aug 2017 15:33:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5CBEF24028F; Sun, 27 Aug 2017 15:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1503873235; bh=nedmE8U6t84hCmGuimcHikXDnK1/wJBEA5sSEgpY7GQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lVjYiMS7uIU7uV5pihrSney+rl/FBBwantDpjc+815LCcCc1K4eW8IlrC4y6xS+Aq bb86ksq1dCvd7CPZ5Y1yrs5g3a3v4c3WkkxeQvlpfvK7ao/yoLqMcwjBSEDlx1oIf3 2yUTafnEOObLwbcSQyD+ykW/Yg2vzsAQsyJHMVX8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9E58BAE013D; Sun, 27 Aug 2017 15:33:20 -0700 (PDT) To: Mark Smith , Brian E Carpenter Cc: james woodyatt , v6ops list References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 27 Aug 2017 18:33:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 22:33:57 -0000 Mark, it sounds like you are describing a situation where, for IP purposes, none of the leaf hosts are on the same "link" as any other leaf hosts. For some other purposes, they may or may not be on the same "link". Yours, Joel On 8/27/17 6:20 PM, Mark Smith wrote: > On 28 August 2017 at 06:29, Brian E Carpenter > wrote: >> On 27/08/2017 18:22, Mark Smith wrote: >>> On 26 Aug 2017 21:28, "DY Kim" wrote: >>>> >>>> Oh… you want to route LL destinations also via the default router, not >>>> directly… >>> >>> Yes. Direct is the default, and cannot currently be overridden. >> >> It's more than that. It's a matter of *definition*. If X and Y are on the >> same link, X can send layer 2 packets directly to Y. If you put measures >> in place to prevent that happening, they are no longer on the same link in >> any meaningful way. > > It sounds like you haven't heard of "Private VLANs" or Broadband Forum > TR-101 N:1 VLANs. > > These LANs are more similar to NBMA or the RFC4861 "shared-media" > > shared media - a link that allows direct communication among a > number of nodes, but attached nodes are configured > in such a way that they do not have complete prefix > information for all on-link destinations. That is, > at the IP level, nodes on the same link may not know > that they are neighbors; by default, they > communicate through a router. Examples are large > (switched) public data networks such as Switched > Multimegabit Data Service (SMDS) and Broadband > Integrated Services Digital Network (B-ISDN). Also > known as "large clouds". See [SH-MEDIA]. > > (SH-MEDIA IS RFC1620). > > with the difference being that it is not possible to use or create a > shortcut path between the attached nodes. That is layer 2 security > being imposed on inter-node communication. > > > So why "Private VLANs" instead of per-host physical or logical p2p links? > > > - no need for a router interface (logical or physical) per host > > > - no per-host router interface configuration > > > - no per-host subnet assignment and subnet identifier management > > > - in the case of logical p2p links e.g., VLANs, no virtual link ID management > > > - less likelihood of running out of virtual link IDs - For VLANs, 4094 > host-VLANs in a network is a lot lower threshold than 4094 multi-host > VLANs. > > In a broadband scenario, using VLANs limits the subscribers attached > to 4094, which for a BNG is a low number. Double VLAN tagging can be > used to resolve that, however that creates configuration and ID > management overhead for the subscriber termination devices e.g. ADSL > DSLAMs. TR-101 N:1 VLANs create subscriber separation without that > overhead. > > > - no router configuration needed to aggregate the downstream address space > > With p2p links, usually would aggregate those subnets into a single > prefix before announcing them to upstream routers. A trivial task, > however another thing to remember to do and to possibly make an error > doing. > > > - can have router redundancy, because 2 routers can be made visible to a host > > No such thing as a "3 ended" point-to-point physical link. Could be > done with per-host VLANs, however now all the above router > configuration complexity is duplicated across two routers. > > There can be limits on how many instances of things such as VRRP that > can be run on a router, which may impose a limit on how many VLANs can > exist and therefore hosts that can be attached. > > > - conceptually more similar to the way hosts have been attached to > multi-access LANs for many years (Less likely today, however many > people for many years would have looked at you funny if you said we're > going to create a subnet and VLAN per host) > > IP subnets have been used for many things over the years. In this > case, the fundamental advantage of placing all hosts in a single > subnet, even though functionality they're closer to being attached to > p2p links, is that it is effectively creating a dynamic pool of p2p > links without having to perform the corresponding p2p related IP > subnet and link-layer configuration and management. It's a > configuration and maintenance optimisation. > > > Regards, > Mark. > > > >> This is why most layer 2 "switches" emulate 1983-style >> Ethernet yellow cable and why the more clever ones perform MLD snooping, >> so that the overhead traffic for emulated multicast is limited. >> >> If you take that away, your *only* link-local neighbour is the switch >> itself. You can never discover any other LL neighbour and therefore never >> send packets to it, because it doesn't exist. >> >> Now you could, in theory, make my head hurt by also performing LL snooping >> in the "switch", so that it emulates yellow cable for some addresses in >> fe80::/10 but not others, but why you would do that instead of just using >> a VLAN beats me. >> >> Brian >> >>> >>>> --- >>>> DY >>>> >>>>> On 26 Aug 2017, at 20:24, Mark Smith wrote: >>>>> >>>>> It isn't possible to invert the LL on-link assumption so that >>>>> LL destinations that are also on the same link are then reachable via >>>>> a router on the link. >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Aug 27 15:35:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEDD13235A for ; Sun, 27 Aug 2017 15:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihH3sDLA0gt8 for ; Sun, 27 Aug 2017 15:35:17 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE57132192 for ; Sun, 27 Aug 2017 15:35:17 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id w17so12375890uaw.5 for ; Sun, 27 Aug 2017 15:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M21Qynfp9afL+vEFCm7YShJaRpbySiRUL/baULHAbPw=; b=lOKlmRBYMxML7NqbkLNX44MNXb3lXo/kStQfeGXMcjsF5Zj1UseJENoyDNKwH26ei8 BM8STGYKj9rmaNKWZ0eXynTfGAiCei5dK+Pk6sCJVzvOd6aaHXkgYA+Q5irxaieh+nws klIpDJgdZyxV/W1+8J6RtPTnjus8H40wFJtFQkT9bhHrDQF/n/d3LCrsFVFhX1tCrNaw 8+bSgr5etjF8h42PammWEdzYEZqpBs0W/PtOtS8StZOZ4MVW/80KyRo5LHbFpiEhxcZg N7qJlsXM9cR3crgZKBJ3t3yXAqvcpDBMnA8qvJMIEpGeORyuxm/Ilv/48JgPlpy1bnWs j9nw== 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=M21Qynfp9afL+vEFCm7YShJaRpbySiRUL/baULHAbPw=; b=aGyXc9oN69v61K6bgyJGVtYW+T+9FVYJcKzfVD6S7X00diKxCx+71s5BuXVnkXpj/h u3kFgTqFzM47k6EeZrBcj4EHPVUATF3wrZxYjJgxww12RZ3FoY/H5e5rSGU346YVnVRa fbhTDnJWPZx8IMtBay4QcQHapwaWcngJdggl6bQmNTPCAgz92dAn3tG+oQ/Krn5Z0sHe 1GQ61kBkNC5sqIBInZJfPgJXAn86jwzz9y0/aCfEVadDJjbi2QnIHGLm5tKh6u940YnR qnSJ4N6eb0JWlXnYL01ldYxoJOb/vNZENaljA8sdglcjF1z4x7gJvXK6yu0CPWwlaejg leig== X-Gm-Message-State: AHYfb5he0n7E0B3Z9s55hckFcO1Sg05QKLN+gCbKw0vafU6b2IKA7a56 m4oQJ3Jrl18nfnN2ivvtffnp+z432A== X-Received: by 10.176.8.29 with SMTP id a29mr3264617uaf.13.1503873316541; Sun, 27 Aug 2017 15:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 15:34:46 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 28 Aug 2017 08:34:46 +1000 Message-ID: To: David Farmer Cc: Lorenzo Colitti , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 22:35:19 -0000 On 28 August 2017 at 02:39, David Farmer wrote: > > > On Sun, Aug 27, 2017 at 1:07 AM, Lorenzo Colitti wrote: >> >> On Fri, Aug 25, 2017 at 2:37 AM, Templin, Fred L >> wrote: >>> >>> In section 2, the document says: >>> >>> " o Two devices (subscriber/hosts), both attached to the same >>> provider >>> managed shared network should only be able to communicate through >>> the provider managed First Hop Router" >>> >>> Please change to say: >>> >>> "o Two devices (subscriber/hosts), both attached to the same provider >>> managed shared network should only be able to communicate through >>> the provider managed First Hop Router unless the shared network >>> explicitly permits peer-to-peer operations" >> >> >> No, *don't* do that. That's a fundamental change to the deployment model >> that this document describes, and nullifies many of its advantages. >> > > I agree, that this should not be changed, as it is an intentional part of > this deployment model. > > However, based on this and related discussion, I think something should be > added to the security considerations along the lines of the following; > I'd add *directly* > If the shared network permits peer-to-peer operations, a malicious device > could communicate with other UE/subscriber devices *directly* across the shared > network. Additionally, direct UE/subscriber device to device communication > will also be possible across the shared network, without first going through > the First Hop router, using link-local IPv6 addressing or using the Unique > IPv6 Prefixes, if the First Hop router provides redirects for the Unique > IPv6 Prefixes. This can be mitigated with access control lists limiting > link-local IPv6 traffic between UE/subscriber devices to only the necessary > Neighbor Discovery traffic and ensuring that the First Hop router does not > provide any redirects to the UE/subscriber devices. Further, Rogue Router > Advertisements SHOULD be mitigated as discussed in [RFC6104], to prevent > malicious or simply misconfigured devices from impersonating a router on the > shared network. > Related, yet earlier, "2. Motivation and Scope of Applicability" Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router" I'd add a statement to explicitly say that the devices are not trusted enough to be able to communicate directly between each other: "Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router. In this scenario, the subscriber/hosts are not trusted enough to be allowed to directly communicate with each other over the link." If hosts aren't trusted, then I wouldn't think Layer 3 ACLs are good enough to prevent direct inter-host communication. I think it would be worth stating in the Security Considerations section that direct inter-host communication across the link should also be prevented at layer 2, using mechanisms that may be available at layer 2, such as Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation. Regards, Mark. From nobody Sun Aug 27 16:06:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F0E1320C9 for ; Sun, 27 Aug 2017 16:06: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 nBCEXzY8iBRA for ; Sun, 27 Aug 2017 16:06:47 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DB71201F8 for ; Sun, 27 Aug 2017 16:06:47 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c15so10644368pfm.2 for ; Sun, 27 Aug 2017 16:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+dRlczoo3LbA6+74AQGsel3rB4K3xidjhuKhZpFzDtg=; b=bbRmxbQS6LmJQP4dFdGA5z2OQmq9enOl2xeNz3wKInUnSVg+RwIXMxyEu0nRhc4cGh pRhoJb5Hqir8+ZaNOvrecO+SSZlSydLp4rGNz4VWS3mIwLB7BIKmSHkxlxTWCOti+gjx yp9wl1slPAVLZPtnTGGU9q6MxCmpFzhghM9qkTfQks5+NEjbgEWuksHUfDTub9mghXjK HEVF3bpVcD5khEpxpBWqGLrIJRFoDaoj8M0Xp9NuXiIbT4CQS+T5SAW306A+BLnUhQpj IsbdNjskbcG+Z7reUyS23lAcloTzjbH4S14GXuQ4VaBiq2zuCLZ1cj8CpVUWamIlP2EJ mC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+dRlczoo3LbA6+74AQGsel3rB4K3xidjhuKhZpFzDtg=; b=ngDZ0iujlap84lMfON60NKz2Q8d2z1Txx3S8Kam8RVEvquwxQquB6/IXjCewIXtKcf MEFe0afZHwCrXu4GJJNGPXzUUdZnw9akMCcc0oNLUqna68veLLW+gClspKyZlh2lqboo 542bMef2cpSHRSitaphzIQVJBDkKlK6IMFUXaTaL8RM9XJ4Mg1tj2BXO+2iFKbYdsAU4 B1qVZgtLJwuD3e9rMdQAoaoOqWTXgFvuUCgcWsgOkdgLt/+p9D5elCxQGOEiCQGmRwxD Zu5JV0CeHZEnN45p07wTboO2Q82FwuLkgHL4+W3BJqT/bODKkiLl8f+2Dk9MqMGSSVXu NxlA== X-Gm-Message-State: AHYfb5j1DzcyRbS2xAev44/x5KuuvghUCj8QWnpZAlAIfIQgNXLUIBxx wAjjiQC3g4rK3Y2/ X-Received: by 10.84.133.44 with SMTP id 41mr6263178plf.184.1503875206345; Sun, 27 Aug 2017 16:06:46 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y63sm21207728pfa.36.2017.08.27.16.06.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Aug 2017 16:06:44 -0700 (PDT) To: Mark Smith Cc: DY Kim , james woodyatt , v6ops list References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 28 Aug 2017 11:06:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 23:06:49 -0000 On 28/08/2017 10:20, Mark Smith wrote: > On 28 August 2017 at 06:29, Brian E Carpenter > wrote: >> On 27/08/2017 18:22, Mark Smith wrote: >>> On 26 Aug 2017 21:28, "DY Kim" wrote: >>>> >>>> Oh=E2=80=A6 you want to route LL destinations also via the default r= outer, not >>>> directly=E2=80=A6 >>> >>> Yes. Direct is the default, and cannot currently be overridden. >> >> It's more than that. It's a matter of *definition*. If X and Y are on = the >> same link, X can send layer 2 packets directly to Y. If you put measur= es >> in place to prevent that happening, they are no longer on the same lin= k in >> any meaningful way. >=20 > It sounds like you haven't heard of "Private VLANs" or Broadband Forum > TR-101 N:1 VLANs. >=20 > These LANs are more similar to NBMA or the RFC4861 "shared-media" >=20 > shared media - a link that allows direct communication among a > number of nodes, but attached nodes are configured > in such a way that they do not have complete prefix= > information for all on-link destinations. That is,= > at the IP level, nodes on the same link may not kno= w > that they are neighbors; I've generally found it beneficial to ignore the BBF, but that is *exactl= y* what I'm saying - if they don't know they are neighbours, they are *not* neighbours in any meaningful sense. They can't detect each other's existe= nce, so the notion of talking to each other using link-local addresses is meaningless, and the notion of on-link determination is also meaningless,= because ND won't work anyway. So for all practical purposes they are not on the same link. Brian > ...by default, they > communicate through a router. Examples are large > (switched) public data networks such as Switched > Multimegabit Data Service (SMDS) and Broadband > Integrated Services Digital Network (B-ISDN). Also= > known as "large clouds". See [SH-MEDIA]. >=20 > (SH-MEDIA IS RFC1620). >=20 > with the difference being that it is not possible to use or create a > shortcut path between the attached nodes. That is layer 2 security > being imposed on inter-node communication. >=20 >=20 > So why "Private VLANs" instead of per-host physical or logical p2p link= s? >=20 >=20 > - no need for a router interface (logical or physical) per host >=20 >=20 > - no per-host router interface configuration >=20 >=20 > - no per-host subnet assignment and subnet identifier management >=20 >=20 > - in the case of logical p2p links e.g., VLANs, no virtual link ID mana= gement >=20 >=20 > - less likelihood of running out of virtual link IDs - For VLANs, 4094 > host-VLANs in a network is a lot lower threshold than 4094 multi-host > VLANs. >=20 > In a broadband scenario, using VLANs limits the subscribers attached > to 4094, which for a BNG is a low number. Double VLAN tagging can be > used to resolve that, however that creates configuration and ID > management overhead for the subscriber termination devices e.g. ADSL > DSLAMs. TR-101 N:1 VLANs create subscriber separation without that > overhead. >=20 >=20 > - no router configuration needed to aggregate the downstream address sp= ace >=20 > With p2p links, usually would aggregate those subnets into a single > prefix before announcing them to upstream routers. A trivial task, > however another thing to remember to do and to possibly make an error > doing. >=20 >=20 > - can have router redundancy, because 2 routers can be made visible to = a host >=20 > No such thing as a "3 ended" point-to-point physical link. Could be > done with per-host VLANs, however now all the above router > configuration complexity is duplicated across two routers. >=20 > There can be limits on how many instances of things such as VRRP that > can be run on a router, which may impose a limit on how many VLANs can > exist and therefore hosts that can be attached. >=20 >=20 > - conceptually more similar to the way hosts have been attached to > multi-access LANs for many years (Less likely today, however many > people for many years would have looked at you funny if you said we're > going to create a subnet and VLAN per host) >=20 > IP subnets have been used for many things over the years. In this > case, the fundamental advantage of placing all hosts in a single > subnet, even though functionality they're closer to being attached to > p2p links, is that it is effectively creating a dynamic pool of p2p > links without having to perform the corresponding p2p related IP > subnet and link-layer configuration and management. It's a > configuration and maintenance optimisation. >=20 >=20 > Regards, > Mark. >=20 >=20 >=20 >> This is why most layer 2 "switches" emulate 1983-style >> Ethernet yellow cable and why the more clever ones perform MLD snoopin= g, >> so that the overhead traffic for emulated multicast is limited. >> >> If you take that away, your *only* link-local neighbour is the switch >> itself. You can never discover any other LL neighbour and therefore ne= ver >> send packets to it, because it doesn't exist. >> >> Now you could, in theory, make my head hurt by also performing LL snoo= ping >> in the "switch", so that it emulates yellow cable for some addresses i= n >> fe80::/10 but not others, but why you would do that instead of just us= ing >> a VLAN beats me. >> >> Brian >> >>> >>>> --- >>>> DY >>>> >>>>> On 26 Aug 2017, at 20:24, Mark Smith wrote= : >>>>> >>>>> It isn't possible to invert the LL on-link assumption so that >>>>> LL destinations that are also on the same link are then reachable v= ia >>>>> a router on the link. >> >=20 From nobody Sun Aug 27 16:10:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D101320C9 for ; Sun, 27 Aug 2017 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCNUA6wsQEbU for ; Sun, 27 Aug 2017 16:10:47 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE4D1201F8 for ; Sun, 27 Aug 2017 16:10:47 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 105so4788858uad.3 for ; Sun, 27 Aug 2017 16:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uYdA85Yijs2PYLl0ckf7JpRDm1P3YtFGjYhHlVl59yU=; b=BNpvUAPDWJ/f7Bmq4IV33vLrVooAUomCHpgtqXne69hJ6V8++vGfR14+BCiMyCG3Pj zKQDBabjrTwCRWysbcAGvdTwKEV05KopYlm+gW8KbnML7EII7mvRDgyPy1avsuo5Gbzm nHlKXLJuWY+pUCzXNYJ+S6lu0VfqsLpUqfHrq+61UM8yxZU48TbZQXpVfsSlp5bR9uWX F62l2JnAOrHBUHrE841aQHzK4jLirnbtS4jZAu0wiHN406z7d3yQsCNnATbP9fVhASYp ZtxHPbmUz9ijRpHhSPEE838ChzA7OQhpunLGhfvrD+HxuHiyVhl9L7HcaaRCZhjsqh0u oXnA== 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=uYdA85Yijs2PYLl0ckf7JpRDm1P3YtFGjYhHlVl59yU=; b=BkZs5PxYE1CmHn0n5HOSsuDgT1WNqPO671XGTL9fY7ZU8OQFPFcrQO61626Xl4lxdX +HjppaCYsRSsXzqJlzaX8u9sNP+Udb/dckb9sUDZTWwDGH5xUTWqA6hk2BFz5obJFNXQ LRSPc+sOhoPxNsfTJ1QYtsnhPXlfoYRvJTyu+h/HvgvMRyEkD5aJzcnpMjv0V/HVeohp ogjyOid55JmleOSHCio0JeSNtoS0edoMHHKcsLJmOSh4BX32rsM7tAOByFMUYnI6h4Ig 6vz+Dn3MJBoHyKA691bPoDAdYRQGu/jrLBWo8xORzyCE6A1YLPw/flsQY2z19jOIrhZH 1LxA== X-Gm-Message-State: AHYfb5i2j8irgikbcyFHnHObThOTTilA+2Cj961vcjU5yfLCiSLIbN+V WiR1xnIzFJzPg2UKCS7kcgm4yPeIdw== X-Received: by 10.159.56.10 with SMTP id p10mr3443207uad.189.1503875445913; Sun, 27 Aug 2017 16:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 16:10:15 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Mark Smith Date: Mon, 28 Aug 2017 09:10:15 +1000 Message-ID: To: "Joel M. Halpern" Cc: Brian E Carpenter , james woodyatt , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 23:10:49 -0000 Hi Joel, On 28 August 2017 at 08:33, Joel M. Halpern wrote: > Mark, it sounds like you are describing a situation where, for IP purpose= s, > none of the leaf hosts are on the same "link" as any other leaf hosts. F= or > some other purposes, they may or may not be on the same "link". > It is certainly a matter of perspective. The perspective I think I'm taking is the IP one - if a group of hosts are members of the same subnet(-prefix per RFC4291) (explicitly, have addresses with a common subnet-prefix), and the model IP follows assigns a subnet-prefix to a link, then that group of hosts with the common subnet-prefix are attached to the same link according to IP. Sure, at layer 2 the link may be constructed of physical p2p links, and the shared nature emulated (with things like Private VLANs changing the emulation function). That physical multi-link topology isn't visible to the IP layer because the IP layer believes that hosts with a common subnet-prefix are all attached to the same one link. So if the true physical p2p link nature of the link-layer was exposed to IP, and we follow the IP model, then that means that each of those p2p links needs to have its own subnet-prefix. (Just because I looked it up to be sure, here is what RFC4291 says in the Addressing Model section: " Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link.") Regards, Mark. > Yours, > Joel > > On 8/27/17 6:20 PM, Mark Smith wrote: >> >> On 28 August 2017 at 06:29, Brian E Carpenter >> wrote: >>> >>> On 27/08/2017 18:22, Mark Smith wrote: >>>> >>>> On 26 Aug 2017 21:28, "DY Kim" wrote: >>>>> >>>>> >>>>> Oh=E2=80=A6 you want to route LL destinations also via the default ro= uter, not >>>>> directly=E2=80=A6 >>>> >>>> >>>> Yes. Direct is the default, and cannot currently be overridden. >>> >>> >>> It's more than that. It's a matter of *definition*. If X and Y are on t= he >>> same link, X can send layer 2 packets directly to Y. If you put measure= s >>> in place to prevent that happening, they are no longer on the same link >>> in >>> any meaningful way. >> >> >> It sounds like you haven't heard of "Private VLANs" or Broadband Forum >> TR-101 N:1 VLANs. >> >> These LANs are more similar to NBMA or the RFC4861 "shared-media" >> >> shared media - a link that allows direct communication among a >> number of nodes, but attached nodes are configured >> in such a way that they do not have complete prefix >> information for all on-link destinations. That is, >> at the IP level, nodes on the same link may not kno= w >> that they are neighbors; by default, they >> communicate through a router. Examples are large >> (switched) public data networks such as Switched >> Multimegabit Data Service (SMDS) and Broadband >> Integrated Services Digital Network (B-ISDN). Also >> known as "large clouds". See [SH-MEDIA]. >> >> (SH-MEDIA IS RFC1620). >> >> with the difference being that it is not possible to use or create a >> shortcut path between the attached nodes. That is layer 2 security >> being imposed on inter-node communication. >> >> >> So why "Private VLANs" instead of per-host physical or logical p2p links= ? >> >> >> - no need for a router interface (logical or physical) per host >> >> >> - no per-host router interface configuration >> >> >> - no per-host subnet assignment and subnet identifier management >> >> >> - in the case of logical p2p links e.g., VLANs, no virtual link ID >> management >> >> >> - less likelihood of running out of virtual link IDs - For VLANs, 4094 >> host-VLANs in a network is a lot lower threshold than 4094 multi-host >> VLANs. >> >> In a broadband scenario, using VLANs limits the subscribers attached >> to 4094, which for a BNG is a low number. Double VLAN tagging can be >> used to resolve that, however that creates configuration and ID >> management overhead for the subscriber termination devices e.g. ADSL >> DSLAMs. TR-101 N:1 VLANs create subscriber separation without that >> overhead. >> >> >> - no router configuration needed to aggregate the downstream address spa= ce >> >> With p2p links, usually would aggregate those subnets into a single >> prefix before announcing them to upstream routers. A trivial task, >> however another thing to remember to do and to possibly make an error >> doing. >> >> >> - can have router redundancy, because 2 routers can be made visible to a >> host >> >> No such thing as a "3 ended" point-to-point physical link. Could be >> done with per-host VLANs, however now all the above router >> configuration complexity is duplicated across two routers. >> >> There can be limits on how many instances of things such as VRRP that >> can be run on a router, which may impose a limit on how many VLANs can >> exist and therefore hosts that can be attached. >> >> >> - conceptually more similar to the way hosts have been attached to >> multi-access LANs for many years (Less likely today, however many >> people for many years would have looked at you funny if you said we're >> going to create a subnet and VLAN per host) >> >> IP subnets have been used for many things over the years. In this >> case, the fundamental advantage of placing all hosts in a single >> subnet, even though functionality they're closer to being attached to >> p2p links, is that it is effectively creating a dynamic pool of p2p >> links without having to perform the corresponding p2p related IP >> subnet and link-layer configuration and management. It's a >> configuration and maintenance optimisation. >> >> >> Regards, >> Mark. >> >> >> >>> This is why most layer 2 "switches" emulate 1983-style >>> Ethernet yellow cable and why the more clever ones perform MLD snooping= , >>> so that the overhead traffic for emulated multicast is limited. >>> >>> If you take that away, your *only* link-local neighbour is the switch >>> itself. You can never discover any other LL neighbour and therefore nev= er >>> send packets to it, because it doesn't exist. >>> >>> Now you could, in theory, make my head hurt by also performing LL >>> snooping >>> in the "switch", so that it emulates yellow cable for some addresses in >>> fe80::/10 but not others, but why you would do that instead of just usi= ng >>> a VLAN beats me. >>> >>> Brian >>> >>>> >>>>> --- >>>>> DY >>>>> >>>>>> On 26 Aug 2017, at 20:24, Mark Smith wrote: >>>>>> >>>>>> It isn't possible to invert the LL on-link assumption so that >>>>>> LL destinations that are also on the same link are then reachable vi= a >>>>>> a router on the link. >>> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Sun Aug 27 17:23:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9406E1321A8 for ; Sun, 27 Aug 2017 17:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f6RJJVb-8w1 for ; Sun, 27 Aug 2017 17:23:29 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D87E1321A7 for ; Sun, 27 Aug 2017 17:23:29 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id l132so11758568vke.5 for ; Sun, 27 Aug 2017 17:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aprutoTsczXOY8vFMDRFIPnfWmbzM1ApTA/Vb77gtv4=; b=Mu59NIL68kh0Jea8q7QdyV/qlJmy4nReF3RSkdESb4V4RTk5n1zc9cVcw3eHcUg172 3dl/S+GTCf/+MNUAy+iyl062ukwdtrSk3AaqIkBWeTQZvJw9hoX2/OxBovfEkQ9RS4sQ B2O5cltlshM4uHXxkpvJTM962SSrIZg8DF14NPyZxgXQdA25XaVp72p/q7xRFWT0FA6N xSgI7fcpvSUAo+uqbm0DiHWAGCHLVhBoSdg68C7nbpu/LnfBYKG7wAs3329CPKP32irH TM3X01EMiClFx42nO7+WH84i6b2aLLrxev/5SpJzNzY8z44pd+653etKZqnXNLpCAwmK X27g== 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=aprutoTsczXOY8vFMDRFIPnfWmbzM1ApTA/Vb77gtv4=; b=O8TzEyR1caC/9Nh95qA37IenUO0A0ckMfHJWzcR+dJ7U0y6LvZNtdO1WFW8mWOpGvb j99sGkc76BSgFAWmST6WqamHJonjVxA1xmkjsFg7+Eh+DactDqFUYiImApZLWOOz7lrc PF1HZwHwjvchlnwl/0VAfOMBHvpdn7MhbHMou1ygbOkuHr/ETdwTxFuA/WNb0wdOWS23 bGqUIJuRndMh4kscqUrFZNFImwtSpaeKnsCz7hGQRe2k5ahKt6cFy9LS6ommHP8DTDOf wP2runFSirwE6bODlB/+Jz8SkyHE28xjEJtSbTOkfCypfpgRE9hfoeR2mAah32ENvkrf PZdw== X-Gm-Message-State: AHYfb5gOxIiYPgbNQq9tYF8kWHg1hVG4jVCT7CKz8IErXqnOuCj49mfJ mMi1Uu37Yw3cdxDHG6cLZM9GEdsf0g== X-Received: by 10.31.96.149 with SMTP id u143mr3859475vkb.101.1503879808079; Sun, 27 Aug 2017 17:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 17:22:57 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Mark Smith Date: Mon, 28 Aug 2017 10:22:57 +1000 Message-ID: To: Brian E Carpenter Cc: DY Kim , james woodyatt , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 00:23:30 -0000 On 28 August 2017 at 09:06, Brian E Carpenter wrote: > On 28/08/2017 10:20, Mark Smith wrote: >> On 28 August 2017 at 06:29, Brian E Carpenter >> wrote: >>> On 27/08/2017 18:22, Mark Smith wrote: >>>> On 26 Aug 2017 21:28, "DY Kim" wrote: >>>>> >>>>> Oh=E2=80=A6 you want to route LL destinations also via the default ro= uter, not >>>>> directly=E2=80=A6 >>>> >>>> Yes. Direct is the default, and cannot currently be overridden. >>> >>> It's more than that. It's a matter of *definition*. If X and Y are on t= he >>> same link, X can send layer 2 packets directly to Y. If you put measure= s >>> in place to prevent that happening, they are no longer on the same link= in >>> any meaningful way. >> >> It sounds like you haven't heard of "Private VLANs" or Broadband Forum >> TR-101 N:1 VLANs. >> >> These LANs are more similar to NBMA or the RFC4861 "shared-media" >> >> shared media - a link that allows direct communication among a >> number of nodes, but attached nodes are configured >> in such a way that they do not have complete prefix >> information for all on-link destinations. That is, >> at the IP level, nodes on the same link may not know >> that they are neighbors; > > I've generally found it beneficial to ignore the BBF, BBF didn't invent this. Private VLANs have been around for about 15 years or more. From memory, they were created to save IPv4 address space, avoiding losing .0 and subnet broadcast addresses for each subnet/VLAN. That requirement doesn't apply to IPv6, however people are going to want to add IPv6 to their existing IPv4/Private VLANs setups, and there are some operational advantages of doing so, per my earlier list. Mirroring IPv4 and IPv6 routing operation is going to be a common goal. Support for them is already on the standards track, RFC6857, "Duplicate Address Detection Proxy" "Abstract The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address." https://tools.ietf.org/rfc/rfc6957.txt > but that is *exactly* > what I'm saying - if they don't know they are neighbours, they are *not* > neighbours in any meaningful sense. They can't detect each other's existe= nce, > so the notion of talking to each other using link-local addresses is > meaningless, and the notion of on-link determination is also meaningless, > because ND won't work anyway. So for all practical purposes they are not > on the same link. > To me, devices with the same subnet-prefix are part of the same link from the IP layer's perspective, per RFC4291, "Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link." To me, "on-link" and "off-link" flags are not statements of link membership, they are instructions for a device on how to determine the first hop for a packet, and it is possible for different devices attached to the same link to have different perspectives on the "on-link" or "off-link" status of a destination. Regards, Mark. From nobody Sun Aug 27 19:02:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA4413235C for ; Sun, 27 Aug 2017 19:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 P_TQhyo6uA6u for ; Sun, 27 Aug 2017 19:02:17 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03ADE132193 for ; Sun, 27 Aug 2017 19:02:16 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id k22so12071136iod.2 for ; Sun, 27 Aug 2017 19:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DWBsjVAnTlNGDiX6kasxWiLjFF8nPqQ/BXoqCeHPpJE=; b=Wr1T0E46GBmLlM3fFtxLSy7AAa3Y6HVa8h2BhUA6SwL46zLSQeS2QKsIYQF7st1lgF /FlMAYMdjVcvBxxd7fOeC6UpPh1hid+6QtesmXAFGUi8kBUHzXgqx4zul1TABBecSPAh SjeALqst/4y9xFcICoDTvRz0eAxmkg5lM9XlLzYSj00gVj7nhkwGqNzrEjq9FFzqf5xR 2UPGwKKhkMeqEaPmrssEPIISS2pzNDnjP1uABxYElfgHnJ9en4ClGZt+wssCZ7KOJPa0 bb/MAzhvh8i88yW7MyyaeNq4EqOS1zv2TvzE2qdRgTVR4OnTYqq11hwVDFzBsN5KMWGN CCvA== 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=DWBsjVAnTlNGDiX6kasxWiLjFF8nPqQ/BXoqCeHPpJE=; b=cETKuWrGhuPArAgQ4/ufaEIr0DkRsAEDLCKnfNdH/GInW+swVlwHz3DujQwlFVU7as GREfyNcGl76c0w1N7L4jPLxUll2IjDV3g6vLy3dwDtGW0RFvroSojyMtPn7OIZRjOH/i 3O3nb03gNqUXYpeuVTC5MnD+gR53szt3LkCIPdQ/0VPjLrO588M0VkOQR/+HhgxMSLgl JyKyIfkpZTnGq1+6bHWTp780CRgfpxUBd2cWEe0XjWqoGc0gGEg0caPCNSbko9XFp2Pd kq9S7hHXyGma3CVfIPf85pXDOeoTdsPexZkFX24SX/CMMBDogCqzgu7y/yBbIx83lqN7 kwOA== X-Gm-Message-State: AHYfb5iu1fxaZa5SQML8/J3QUjDYoKm3Kx9DzDzzWT4Zm06lNHbYmBdt LW/8Jobyw/tvVbsKrPXnUN2dbUFgxXb4 X-Google-Smtp-Source: ADKCNb6g0zfkm0/CEmv6Ul5haWakj9FUlBxUdc94lM0WioL6W1FEfdLa/ce2gkfz/n8Ban8g1m6hiPrjggr/JQNSkxk= X-Received: by 10.107.137.97 with SMTP id l94mr4837532iod.279.1503885735945; Sun, 27 Aug 2017 19:02:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sun, 27 Aug 2017 19:01:55 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 28 Aug 2017 11:01:55 +0900 Message-ID: To: David Farmer Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113eaff4137c8a0557c6af17" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 02:02:19 -0000 --001a113eaff4137c8a0557c6af17 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 1:39 AM, David Farmer wrote: > "o Two devices (subscriber/hosts), both attached to the same provider >>> managed shared network should only be able to communicate through >>> the provider managed First Hop Router unless the shared network >>> explicitly permits peer-to-peer operations" >>> >> >> No, *don't* do that. That's a fundamental change to the deployment model >> that this document describes, and nullifies many of its advantages. >> >> > I agree, that this should not be changed, as it is an intentional part of > this deployment model. > > However, based on this and related discussion, I think something should be > added to the security considerations along the lines of the following; > > If the shared network permits peer-to-peer operations, a malicious device > could communicate with other UE/subscriber devices across the shared > network. Additionally, direct UE/subscriber device to device communication > will also be possible across the shared network, without first going > through the First Hop router, using link-local IPv6 addressing or using the > Unique IPv6 Prefixes, if the First Hop router provides redirects for the > Unique IPv6 Prefixes. > > If we want to say that, we should also add: This creates a number of security issues such as the ability for hosts on different prefixes to deny IPv6 service to each other by spoofing DAD replies, target each other with ND cache exhaustion attacks, man-in-the-middle traffic by spoofing redirects, and send rogue RAs. --001a113eaff4137c8a0557c6af17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Aug 28, 2017 at 1:39 AM, David Farmer <farmer@umn.edu> wrot= e:
    =C2=A0 =C2=A0"o=C2=A0 Two devices (subscriber/hosts), both attache= d to the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router unless the share= d network
    =C2=A0 =C2=A0 =C2=A0 explicitly permits peer-to-peer operations"

    No, *don't* do that. That's a fundam= ental change to the deployment model that this document describes, and null= ifies many of its advantages.


    I agree, that this should not be changed, = as it is an intentional part of this deployment model.

    However, bas= ed on this and related discussion, I think something should be added to the= security considerations along the lines of the following;

    If the shared network p= ermits peer-to-peer operations, a malicious device could communicate with o= ther UE/subscriber devices=C2=A0across the shared network. Additionally, di= rect UE/subscriber device to device communication will also be possible acr= oss the shared network, without first going through the First Hop router, u= sing link-local IPv6 addressing or using the Unique IPv6 Prefixes, if the F= irst Hop router provides redirects for the Unique IPv6 Prefixes.

    If we want to say that= , we should also add:

    This creates a number of sec= urity issues such as the ability for hosts on different prefixes to deny IP= v6 service to each other by spoofing DAD replies, target each other with ND= cache exhaustion attacks, man-in-the-middle traffic by spoofing redirects,= and send rogue RAs.
    --001a113eaff4137c8a0557c6af17-- From nobody Sun Aug 27 19:50:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6781321A2 for ; Sun, 27 Aug 2017 19:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 K3wseNF6fyqJ for ; Sun, 27 Aug 2017 19:49:58 -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 E347A1321A0 for ; Sun, 27 Aug 2017 19:49:57 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 3EF5166F for ; Mon, 28 Aug 2017 02:49:57 +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 qTrt040ztJdC for ; Sun, 27 Aug 2017 21:49:57 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 08D5D24C for ; Sun, 27 Aug 2017 21:49:56 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id j16so4912289uai.7 for ; Sun, 27 Aug 2017 19:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wEW8Y33sX9Bx2DHlcix9s0D6boquYkoLB4iBNfDs1WM=; b=S2BxKI9Niqhhzi+YbKPxIJq+pECk+xnmHy7FsHKdUktfN9m/hMcTHOjLOjhSVL7jQK c3QTg6RK2YBfv+CUVB2eqcU8NuHD3ZGPcQZsC20ALHdwqjy9oJ/eQcHvTAeUwTRPoY72 iAYTSnLlibqgMK9tXzwG7G1BQ8YngaAMW0YffCtAWSGJbCvkn0LR+QAZu78m9fVLfkYq DNVh+854mO0pjY4FobR9r6vISKUHM1HfiSUe1ynEX1Puvor9Jna9VA4PaniQKv3D0n0N SKtRuKf86/OEDpL1wMQLy2LcBh0evziublwrCxxtsg00oO/WytuDuftZqTbgqzSRMJtF kuBQ== 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=wEW8Y33sX9Bx2DHlcix9s0D6boquYkoLB4iBNfDs1WM=; b=HHvf7JlZNqWIDa97cfjXVwiPmaZMCCvgZZbpOtgBKDYpYy//rUW6av72kbULhG0kfZ jSiCtYPz15lkWUZTuGA8jyiWQosakf2T6HTydDcjkQFqhg8CnzsMx1RKFQZTW14AAgCT USC0/k/sn9wQkbZdfyHu0tW8772sItGaiqEwhW6l379aSELqD9VjDw380IRt8d4Skm8v Q2I7tzCDvMkmrkanDPBCelqDAcQa4ZazRBzJ8dGqvzMt8NXd5t86t1bXyWLjnzKBoU1p rKN3hNKWS1E6wOBGi5rb82uU6QAJ53NxXgK6M/GinZq0Rqip+fcPQT7s3KmMkLBYE0Cs cWTA== X-Gm-Message-State: AHYfb5ghCUZVhYiIDZeHG/LAeP4j3awPaUllyAuBTYg/AI9RINhVsYts uu7Z8cFKCaPueEMwF4f950+S+UdN8eKygXrdv5rJgto0eMBsx3Yze9AY0MTa1c0wulhE95DqtlV sywpme9NDfisFrxpC X-Received: by 10.176.18.217 with SMTP id o25mr4011952uac.77.1503888596316; Sun, 27 Aug 2017 19:49:56 -0700 (PDT) X-Received: by 10.176.18.217 with SMTP id o25mr4011944uac.77.1503888596081; Sun, 27 Aug 2017 19:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Sun, 27 Aug 2017 19:49:55 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Sun, 27 Aug 2017 21:49:55 -0500 Message-ID: To: Lorenzo Colitti Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f403043613de8d3d570557c75918" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 02:50:00 -0000 --f403043613de8d3d570557c75918 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 27, 2017 at 9:01 PM, Lorenzo Colitti wrote: > On Mon, Aug 28, 2017 at 1:39 AM, David Farmer wrote: > >> "o Two devices (subscriber/hosts), both attached to the same provider >>>> managed shared network should only be able to communicate through >>>> the provider managed First Hop Router unless the shared network >>>> explicitly permits peer-to-peer operations" >>>> >>> >>> No, *don't* do that. That's a fundamental change to the deployment model >>> that this document describes, and nullifies many of its advantages. >>> >>> >> I agree, that this should not be changed, as it is an intentional part of >> this deployment model. >> >> However, based on this and related discussion, I think something should >> be added to the security considerations along the lines of the following; >> >> If the shared network permits peer-to-peer operations, a malicious device >> could communicate with other UE/subscriber devices across the shared >> network. Additionally, direct UE/subscriber device to device communication >> will also be possible across the shared network, without first going >> through the First Hop router, using link-local IPv6 addressing or using the >> Unique IPv6 Prefixes, if the First Hop router provides redirects for the >> Unique IPv6 Prefixes. >> >> > If we want to say that, we should also add: > > This creates a number of security issues such as the ability for hosts on > different prefixes to deny IPv6 service to each other by spoofing DAD > replies, target each other with ND cache exhaustion attacks, > man-in-the-middle traffic by spoofing redirects, and send rogue RAs. > Well, it doesn't explicitly say anything about the shared network preventing peer-to-peer communications, it might be implied, but it is by no means explicitly required. So, I think the draft either needs explicitly require the shared network to prevent peer-to-peer communication, such as by using Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation, or it has to discuss the consequences of the shared network allowing peer-to-peer communications. Probably even better, would be to both explicitly recommend the shared network prevent peer-to-peer communication, such as by using Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation, and discuss the consequences of the shared network allowing peer-to-peer communications, as well as the the mitigations available short of using Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolation. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403043613de8d3d570557c75918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Aug 27, 2017 at 9:01 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
    =
    On M= on, Aug 28, 2017 at 1:39 AM, David Farmer <farmer@umn.edu> wrot= e:
    =C2=A0= =C2=A0"o=C2=A0 Two devices (subscriber/hosts), both attached to the s= ame provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should only be able to communic= ate through
    =C2=A0 =C2=A0 =C2=A0 the provider managed First Hop Router unless the share= d network
    =C2=A0 =C2=A0 =C2=A0 explicitly permits peer-to-peer operations"

    No, *don't* do that. That's a fundam= ental change to the deployment model that this document describes, and null= ifies many of its advantages.


    I agree, that this should not be changed, = as it is an intentional part of this deployment model.

    However, bas= ed on this and related discussion, I think something should be added to the= security considerations along the lines of the following;

    If the shared network p= ermits peer-to-peer operations, a malicious device could communicate with o= ther UE/subscriber devices=C2=A0across the shared network. Additionally, di= rect UE/subscriber device to device communication will also be possible acr= oss the shared network, without first going through the First Hop router, u= sing link-local IPv6 addressing or using the Unique IPv6 Prefixes, if the F= irst Hop router provides redirects for the Unique IPv6 Prefixes.

    If we want to say that= , we should also add:

    This creates a number of sec= urity issues such as the ability for hosts on different prefixes to deny IP= v6 service to each other by spoofing DAD replies, target each other with ND= cache exhaustion attacks, man-in-the-middle traffic by spoofing redirects,= and send rogue RAs.

    Well, it doesn't explicitly say anything about t= he shared network preventing peer-to-peer communications, it might be impli= ed, but it is by no means explicitly required. So, I think the draft either= needs explicitly require the shared network to prevent peer-to-peer commun= ication, such as by using Private VLANs, TR-101 N:1 VLANs or Wifi Station I= solation, or it has to discuss the consequences of the shared network allow= ing peer-to-peer communications. =C2=A0=C2=A0 =C2=A0=C2=A0

    Probably even better, would be to both= explicitly recommend the shared network prevent peer-to-peer communication= , such as by using Private VLANs, TR-101 N:1 VLANs or Wifi Station Isolatio= n, and discuss the consequences of the shared network allowing peer-to-peer= communications, as well as the the mitigations available short of using Pr= ivate VLANs, TR-101 N:1 VLANs or Wifi Station Isolation.

    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:fa= rmer@umn.edu
    Networking & Telecommunication Services
    Office o= f Information Technology
    University of Minnesota=C2=A0=C2=A0
    2218 Un= iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --f403043613de8d3d570557c75918-- From nobody Sun Aug 27 20:20:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4111A1321A2 for ; Sun, 27 Aug 2017 20:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aPav8r4pv88u for ; Sun, 27 Aug 2017 20:20:54 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00B6120727 for ; Sun, 27 Aug 2017 20:20:54 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id s101so12499238ioe.0 for ; Sun, 27 Aug 2017 20:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XL5vRRWifv0rS2n9JKW+9rE8OV8zg6tWrwEPPg4y1rg=; b=Rr97LIVEvmLrVOnxoQYrmVrxlxY1NzZB9+pY6Ge66AN0CTvtvmpJDvzJ5F+nGzQuxJ VKr0LTYRAjgmBNQQdo9hnrhnfO4lAIoEwtU3wobQ3nom4sho6m87zkyTAZ9MQBSKQOaJ Yo6FhaitFEqC/wJSfmnJ+5ceRluXOmK8x4mEYzlMGjIcv42rn7x44CMbOLdspo+GoZp8 tuGIu020ctSfthvte8NgT2/3rZZcwB6emGOWpnCM+F7axRdm5inCXiZ2D6vdLyUuQcpP PgeyveuFG2QSNLxYRTV0dAp3SBBOjHtCXZA6Q+mCM4d8RWv7ycLDuT9DZ8zXcUIwFOwQ rhHQ== 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=XL5vRRWifv0rS2n9JKW+9rE8OV8zg6tWrwEPPg4y1rg=; b=QV5mlnmd8oBKvpxOE+sHXfuFvwnjInHizeioThKVReeUJAjpvp2oDIkkRQKwsmk1gg UGn6C0kIJTZKZMQ9YGIBHUjRtW6aHMTvvwUqW3Ifh5kHEVh9w6krp2/zAfeVUhgoNLrF xO45oAJo3yOmbWRXmbo8WNNqYb3qcdFIOYc7xSMNNlCy2iI6NNLJOK+FldRTo7BmMEPj 30euhRR2rcsfy8oNHHKPCFpTL8DmdH7aJgGzKs0P+YcB4mGSWekM9Jh0yC6GfIRcIV27 Lmv/zKghK8DjP6mGqJmbITth4+ek548YZj3uzKTBRPc20x5ifwPAoBF4Z/hwclsFfGfm eDYQ== X-Gm-Message-State: AHYfb5i3+0eW1bJK/crUzJKKu5Lmk7VK8RG/h71O0OSXhsuzgh7/V7aN +oANyEvY12r5IBS9tuTozw1m5a7Nmzuc X-Google-Smtp-Source: ADKCNb4Ye/9NlZK4QxXcOXlp01eL3NP4MfNy167qlK2Lg9HYmNOXtDpaB8eNuiveEpt1L9CPtgreLe66SosM2Jv6hy8= X-Received: by 10.107.48.21 with SMTP id w21mr6017901iow.12.1503890453658; Sun, 27 Aug 2017 20:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sun, 27 Aug 2017 20:20:32 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 28 Aug 2017 12:20:32 +0900 Message-ID: To: David Farmer Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114441284614cd0557c7c8c2" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 03:20:56 -0000 --001a114441284614cd0557c7c8c2 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 11:49 AM, David Farmer wrote: > Well, it doesn't explicitly say anything about the shared network > preventing peer-to-peer communications, it might be implied, but it is by > no means explicitly required. > At least *some* isolation is required because otherwise the periodic multicast RAs sent to each host would go to all hosts, and all hosts would have all the other hosts's prefixes. I agree that this should probably be stated in the document. --001a114441284614cd0557c7c8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Aug 28, 2017 at 11:49 AM, David Farmer <farmer@umn.edu> wro= te:
    Well, it doesn't explicitly say anything about the shared networ= k preventing peer-to-peer communications, it might be implied, but it is by= no means explicitly required.

    = At least *some* isolation is required because otherwise the periodic multic= ast RAs sent to each host would go to all hosts, and all hosts would have a= ll the other hosts's prefixes. I agree that this should probably be sta= ted in the document.
    --001a114441284614cd0557c7c8c2-- From nobody Sun Aug 27 20:53:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F2913209C for ; Sun, 27 Aug 2017 20:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYHGcqvmT3ic for ; Sun, 27 Aug 2017 20:53:32 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0505120727 for ; Sun, 27 Aug 2017 20:53:32 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id y50so2973528uay.4 for ; Sun, 27 Aug 2017 20:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUweQ1I8UaaHWMz0cnAelPGAghTHoiXuXzta3K08+5I=; b=NTDs8buf7tySRM6rRjY4yf+citEaGUQcjjjSYaKs4siOtSNEZt0Q1ysBbtkVn8xprX EBQfUrLMdNfYlvupQpakH6mkMT3r6DMDMA894yAwoD1a4z8GM9OK2kFZk4XbGCFWEbf5 Kr4apCH+PvR3vvIazsjQ5gU6tAbWFLlQx802EQrGbHepPMim9OrHM/aThyMvT3FYBTSn KvgE/jc8f4SWDQ/+UXAhFf0oZ4rblTTF9a2J1YvaAzrDKf+iRQeOdWiJV7CJ5/MC6Ta3 96bHKRrHkf4P4TprhgKaWj73QMDNw08dpmRwBQWpYe3DNtqeruB3U7hD1Owcn4j19yhs 8gRQ== 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=MUweQ1I8UaaHWMz0cnAelPGAghTHoiXuXzta3K08+5I=; b=WiPnoVsGVP424jiUACDmwZCh5pofUXeEZe3lwrjkHK5h+0mjZoDhuZEPf1ZPrRq4Jp EUXJ0Q5o2qPfuRaKz4vGoO1v4yYdS5ZZKTAqI+bEZUTC584T1UpoztKS1tySHdwreiJv Su9VtQtKd0CT0eHTHBNhlQ0QYJcMv0keom8QecjT+kJG70WQmQc38exfWKo1XuBS51fs 7CSS0b0qloigDrLUW+c3WeS4Mj9wy15VLHt0waRzzm/CXYqcf54Azmq1KAY0HykE6JW8 a5/CxVXjgS2TAcoqlUOTyBVb9WwKjY93falzN2wnORVWgtsZRcOu4A1ESlDsYCecXkJM Z2Ag== X-Gm-Message-State: AHYfb5hJdBruW6wDYdc2ZSQq+N7slcUcIwDfNmEyBaWNcRNebsZz1Nkd tB+0fr8J2qZTKjaYDTmJsKaa2jXljg== X-Received: by 10.176.76.92 with SMTP id d28mr4177440uag.116.1503892411618; Sun, 27 Aug 2017 20:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 20:53:31 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 20:53:31 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 28 Aug 2017 13:53:31 +1000 Message-ID: To: Lorenzo Colitti Cc: v6ops list , David Farmer Content-Type: multipart/alternative; boundary="f40304362178f99b8e0557c83cdd" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 03:53:34 -0000 --f40304362178f99b8e0557c83cdd Content-Type: text/plain; charset="UTF-8" On 28 Aug. 2017 13:21, "Lorenzo Colitti" wrote: On Mon, Aug 28, 2017 at 11:49 AM, David Farmer wrote: > Well, it doesn't explicitly say anything about the shared network > preventing peer-to-peer communications, it might be implied, but it is by > no means explicitly required. > At least *some* isolation is required because otherwise the periodic multicast RAs sent to each host would go to all hosts, and all hosts would have all the other hosts's prefixes. I agree that this should probably be stated in the document. These constrained link-layers allow mcasts and bcasts from the routers to go to all hosts, it is the host to other nodes direction that is constrained to just reaching ports where routers are attached. I would have thought all RAs in this scenario are unicast, including periodic ones. The list of nodes to unicast to periodically could either be sent using the neighbour cache or from a table built up using MLDv2 join LL source addresses. Looking though the draft, there doesn't seem to be any mention of what happens with periodic mutilcast RAs - are they switched off (meaning periodic hosts' RSes and unicast RAs keep RA information current), or unicast instead? Regards, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --f40304362178f99b8e0557c83cdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 28 Aug. 2017 13:21, "Lorenzo Colitti" <lorenzo@google.com> wr= ote:
    =
    On Mon, Aug 28, 2017 at 11:49 A= M, David Farmer <farmer@umn.edu> wrote:
    Well, it doesn't= explicitly say anything about the shared network preventing peer-to-peer c= ommunications, it might be implied, but it is by no means explicitly requir= ed.

    At least *some* isola= tion is required because otherwise the periodic multicast RAs sent to each = host would go to all hosts, and all hosts would have all the other hosts= 9;s prefixes. I agree that this should probably be stated in the document.<= /div>
    These constrained link-layers allow mcasts and bca= sts from the routers to go to all hosts, it is the host to other nodes dire= ction that is constrained to just reaching ports where routers are attached= .

    I would have thought a= ll RAs in this scenario are unicast, including periodic ones. The list of n= odes to unicast to periodically could either be sent using the neighbour ca= che or from a table built up using MLDv2 join LL source addresses. Looking = though the draft, there doesn't seem to be any mention of what happens = with periodic mutilcast RAs - are they switched off (meaning periodic hosts= ' RSes and unicast RAs keep RA information current), or unicast instead= ?

    Regards,
    Mark.


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    <= /blockquote>
    --f40304362178f99b8e0557c83cdd-- From nobody Sun Aug 27 22:23:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5013265E for ; Sun, 27 Aug 2017 22:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRdDp0JIfsAQ for ; Sun, 27 Aug 2017 22:23:41 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217211321D5 for ; Sun, 27 Aug 2017 22:23:41 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id n5so22093657itb.1 for ; Sun, 27 Aug 2017 22:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iBVa/+EYnbEJ4ISRbY4iHNucmBK45/qYRKcwATNumoA=; b=qZqztQ6XI8mW72cmVv1w6PhGYYgoYK++kl55eKGWs2Seyk2nCiHzZBthmtcH6c/h0I PiOPF0fptd9WeoISLxm/2QdpSbiL5rzVDKAzNGLq9q6wgtzGkKR1w98+KIm6JS8L+04O ELfTV0o0u9DrCYXYz9PkWYVsXKdILDgCDs5T8jQQSw5m6+cQt/vUyLqE2fDuGkmDKwwE o46wNZZoEoxGx8REMGoc70Tvaqpd9jw23yF2HjOo+Q7FGmVUGfHo78VcIUcXgc1CM8MJ DUwy31tFT+RAcNJhIahF6Zh8j5kYJ5jWEREBoQsYKXvpysLGsENawQb9IsX+kH8EyEKP AYRA== 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=iBVa/+EYnbEJ4ISRbY4iHNucmBK45/qYRKcwATNumoA=; b=dQULR1T3FqykStytBVetyLPyUD1UHBVPCUc++rojJpNkJ2bS8fNb5leW/lNntoFSpu ky+rPJojSNWQnBAzg57px90mtMRGPziMW0rtwaqm7SwRO1SxTuemJexAD1hkAlH3c2D8 1MverQXSze79mWPGauVIDuPdYdH5T02FNkyttGHcaC+DexHtmV6IM4l0e1rHLURTNJ21 GP5klt7HBuIY7RogucZFtLvJ/JETyQ93rIBHaIyUWdOqinGVOt+BH+OReqDbu+Wsrd9A P+/NLSOvNzr+XLOCncqCQAmBtC7uF70xSQzxtXMB/oGzx1CnTOwT9rmGO6OUccN8oXE2 +wrw== X-Gm-Message-State: AHYfb5hv3tmwOwqQPgpFyxYciOFzrkRZeo3dz6ErgAWQVNp/KJtY8L1p zAIxO3kWCGLhXft5LAC+1osPldjv+2XF X-Google-Smtp-Source: ADKCNb40cGGzAHRuumk8vy0pPlZ6c/p7GE8gxLMeSUDqXT0rWiijFzjdY0xN9M19jP52YLQXJ7Vcde5F7TYnQN7YGmQ= X-Received: by 10.36.5.194 with SMTP id 185mr3659165itl.101.1503897819997; Sun, 27 Aug 2017 22:23:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sun, 27 Aug 2017 22:23:19 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Lorenzo Colitti Date: Mon, 28 Aug 2017 14:23:19 +0900 Message-ID: To: Mark Smith Cc: "Joel M. Halpern" , james woodyatt , v6ops list Content-Type: multipart/alternative; boundary="001a1143eb4e5764c80557c97fdd" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 05:23:43 -0000 --001a1143eb4e5764c80557c97fdd Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 8:10 AM, Mark Smith wrote: > The perspective I think I'm taking is the IP one - if a group of hosts > are members of the same subnet(-prefix per RFC4291) (explicitly, have > addresses with a common subnet-prefix), and the model IP follows > assigns a subnet-prefix to a link, then that group of hosts with the > common subnet-prefix are attached to the same link according to IP. > > Sure, at layer 2 the link may be constructed of physical p2p links, > and the shared nature emulated (with things like Private VLANs > changing the emulation function). That physical multi-link topology > isn't visible to the IP layer because the IP layer believes that hosts > with a common subnet-prefix are all attached to the same one link. > Building such a network is generally a bad idea because it doesn't work unless all the addresses can be controlled by the network, and the network maintains state at all times on all the addresses on the subnet. Example: - If two hosts on this "subnet" form the same IPv6 address, they can't detect a collision unless the network does DAD proxying. - The network must at all times know all mappings between host addresses and link-layer addresses, because otherwise it cannot send packets to the right host. Sending a multicast NS in this situation allows hosts to steal each others' traffic. Therefore, ND cache entries cannot be allowed to expire. - If a host forms an address and the network doesn't know about it, things don't work. The result of this architecture is that the router must maintain much more state. In practice this results in the network limiting the number of addresses that hosts can use, and or requiring the use of an address registration or assignment protocol in order to use the network. A vastly superior alternative is to assign each host its own prefix, and make the link between the host and the router unnumbered. --001a1143eb4e5764c80557c97fdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Aug 28, 2017 at 8:10 AM, Mark Smith <markzzzsmith@gmail.com&g= t; wrote:
    The p= erspective I think I'm taking is the IP one - if a group of hosts
    are members of the same subnet(-prefix per RFC4291) (explicitly, have
    addresses with a common subnet-prefix), and the model IP follows
    assigns a subnet-prefix to a link, then that group of hosts with the
    common subnet-prefix are attached to the same link according to IP.

    Sure, at layer 2 the link may be constructed of physical p2p links,
    and the shared nature emulated (with things like Private VLANs
    changing the emulation function). That physical multi-link topology
    isn't visible to the IP layer because the IP layer believes that hosts<= br> with a common subnet-prefix are all attached to the same one link.

    Building such a network is generally a bad idea= because it doesn't work unless all the addresses can be controlled by = the network, and the network maintains state at all times on all the addres= ses on the subnet. Example:
    • If two hosts on this "su= bnet" form the same IPv6 address, they can't detect a collision un= less the network does DAD proxying.
    • The network must at all times k= now all mappings between host addresses and link-layer addresses, because o= therwise it cannot send packets to the right host. Sending a multicast NS i= n this situation allows hosts to steal each others' traffic. Therefore,= ND cache entries cannot be allowed to expire.
    • If a host forms an a= ddress and the network doesn't know about it, things don't work.
    The result of this architecture is that the router must maintai= n much more state. In practice this results in the network limiting the num= ber of addresses that hosts can use, and or requiring the use of an address= registration or assignment protocol in order to use the network.

    A vastly superior alternative is to assign each host = its own prefix, and make the link between the host and the router unnumbere= d.
    --001a1143eb4e5764c80557c97fdd-- From nobody Sun Aug 27 22:49:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECEC1326DF for ; Sun, 27 Aug 2017 22:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftorm0yZza_W for ; Sun, 27 Aug 2017 22:49:19 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F51132950 for ; Sun, 27 Aug 2017 22:49:17 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s199so13082616vke.1 for ; Sun, 27 Aug 2017 22:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r1hd7oBKasD7dHOLQbu+3DTJGnreJx4TIWbe61+6tLM=; b=gn2Vweyv6YdYFL4nUc24RGuoEcq3zOKnafvfgScbbH8oLBYuaE0RawMHly7sqHZSRS zcPfwtGIrd8lCJ+7niwOWVS1njn+3Fn2jg2UvwiwoFcyb/az1RKXsIKMM61hU1hGxNvN xaSrMK4yYbQHGLJuWV0sTrTXdDE+pB0uO5IcGWWFEArfvsJBN/ovqdYAMIu1k/C3aYAg B/uUsEOi+ysSkQdg7VNYYM6FUPWyFi8V0LMBwGya6XDc0t3622peLk5K8fAmeZeZT/M1 LuGf+c778HOO0e14evukm6/59RYxPHgvj8pCLc+IhbIX3iJzY2j+I/D2jqCD0ob998+p N9Vg== 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=r1hd7oBKasD7dHOLQbu+3DTJGnreJx4TIWbe61+6tLM=; b=JVE9RflahfOYsvCN8MnPraQLR0RBv20p4D2OYTjt/FxDXENMdyJQ0/0eX2OKadZG09 l12MjjeacXHX4qN9nMU0GBkIaa6f1t/A1FCNxRh9wm/dm0qCD5cHd+D+EXvztG9vCkG3 ta82X5e/HjWghnYtZktAdywnX56xQOoQk93CoHdKnRSS7bphRQ4eUxDgR7pC25blYmUX KJ5PERTNgsJsCY671+qK8GLKeDVuDg/v+EEnIHFi0vtHav9ynsaROzxLp+wgCy/nOa7W 1QqXgPKrxvh0it5tkb0uyBh7MZZmxeeA/+JsykomwIBOAy9HdqDwbREt01sf5Q5lhpOE 9ykg== X-Gm-Message-State: AHYfb5iXFIuz0rj9Ebj25uO662HEnnliBOzIE3BUAIHYk5ZQQJQt6fEF O/b1lL5XplfQikIbNetF++Yzfui0XQ== X-Received: by 10.31.96.149 with SMTP id u143mr4242047vkb.101.1503899356596; Sun, 27 Aug 2017 22:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 22:48:46 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Mark Smith Date: Mon, 28 Aug 2017 15:48:46 +1000 Message-ID: To: Lorenzo Colitti Cc: "Joel M. Halpern" , james woodyatt , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 05:49:21 -0000 On 28 August 2017 at 15:23, Lorenzo Colitti wrote: > On Mon, Aug 28, 2017 at 8:10 AM, Mark Smith wrote: >> >> The perspective I think I'm taking is the IP one - if a group of hosts >> are members of the same subnet(-prefix per RFC4291) (explicitly, have >> addresses with a common subnet-prefix), and the model IP follows >> assigns a subnet-prefix to a link, then that group of hosts with the >> common subnet-prefix are attached to the same link according to IP. >> >> Sure, at layer 2 the link may be constructed of physical p2p links, >> and the shared nature emulated (with things like Private VLANs >> changing the emulation function). That physical multi-link topology >> isn't visible to the IP layer because the IP layer believes that hosts >> with a common subnet-prefix are all attached to the same one link. > > > Building such a network is generally a bad idea because it doesn't work > unless all the addresses can be controlled by the network, and the network > maintains state at all times on all the addresses on the subnet. Example: > > If two hosts on this "subnet" form the same IPv6 address, they can't detect > a collision unless the network does DAD proxying. > The network must at all times know all mappings between host addresses and > link-layer addresses, because otherwise it cannot send packets to the right > host. Sending a multicast NS in this situation allows hosts to steal each > others' traffic. Therefore, ND cache entries cannot be allowed to expire. > If a host forms an address and the network doesn't know about it, things > don't work. > > The result of this architecture is that the router must maintain much more > state. In practice this results in the network limiting the number of > addresses that hosts can use, and or requiring the use of an address > registration or assignment protocol in order to use the network. > I don't disagree with any of that. Would a BCP saying IPv6 SHOULD NOT be implemented over Private VLANs and similar be the better answer for these reasons? Unfortunately I don't think that is going to stop people trying to do so. Actually, I'd forgotten there was a draft about this, IP over Intentionally Partially Partitioned Links https://tools.ietf.org/html/draft-ietf-intarea-ippl-00 > A vastly superior alternative is to assign each host its own prefix, and > make the link between the host and the router unnumbered. No such thing as an unnumbered link, there's always a link-local prefix, per RFC4291's required interface addresses, so the above issues will still exist for the attached host's LL addresses. There's no escaping these issues and the state to emulate them unless links are truly point-to-point links between the router and the host(/cpe) with individual links having their own subnet prefix, or multi-access links have full any-to-any connectivity. Regards, Mark. From nobody Sun Aug 27 22:55:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4672E132804 for ; Sun, 27 Aug 2017 22:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Etskc2g85mjE for ; Sun, 27 Aug 2017 22:55:06 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D5D1323B5 for ; Sun, 27 Aug 2017 22:55:06 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 81so12997377ioj.5 for ; Sun, 27 Aug 2017 22:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aXGmkG7PMbtmsy5v/wj4Lly2TChocRIyqqola/iGkLY=; b=oYUI6INxLACLiw3VlrigFfxd9XqjY0/57wwa9m4z1IhOH4Tri3rxnWzze7WdmnwXH9 ido9H12y6wOR2C5pR6dtIluApaRA/AewLDD8/98XziKludq9zYfIhSfvAQYHWlyez15b fWvgaefdWdDG3wvjU23kcZfwVTZmjs4cRkth03AEw1CL4pZZmzdM4K30Al74A5WphjK1 dIaON6omT1L9hRNnl22NNAArdS4KA236JJoZuDOSjKWgHtKMF546pbg5CHgTkiFg7PuE yp6+Wai2U0jmBbl7HVxMWz2PfOrJVBn95DFZkNjmaqN+eyiuYD8eUZrc5CgpUFEgaQsT I5Wg== 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=aXGmkG7PMbtmsy5v/wj4Lly2TChocRIyqqola/iGkLY=; b=DMIM3ODd33Iap0bO4boJhQuA+aCtBkH8q44czAuNn5XUrPwTpT9hg2KHBJ8eI+JL/C zUi62umcg7dRygTtquuQpJPgoX1XxgcZ3AS6/X1DI0Ms0JMz4+ZqZG+dvdEctcYPnvJh wrdE6LcnbIQvV6Z06pD9s5YW5kl9IeTNJlm8Nkg9ZUyHZA7dLJrWi/xIj0sHR2ldQona wvvBarbQtggOTDfwrYI66Sg7U0VxSJI6ltO1k+iWQzObMmV+x7+sey0k3FDowrkxFf2x k2+wiVimELZYLTCl8FRB+EXiZa40I2Xx68sCwKxUbPd4HNQ3Qovn42JePVeFNwByRRnn DVFQ== X-Gm-Message-State: AHYfb5iakOtdsQTaTCu9UzBikqggZOiS6no+2hmCODVKHZE6CqNK7WN8 DV6KWfpIW0HCxI3qI5T9CRbKUvqX65iW X-Google-Smtp-Source: ADKCNb6pAKN7GPme9vx9qlFAmlhrYpdBP6T3IbT77rUbJxKjHqngvi2wXIZ/hY+SsQBBA03aUG/uFnL/PSCQqTDw0+4= X-Received: by 10.107.48.11 with SMTP id w11mr248030iow.12.1503899705515; Sun, 27 Aug 2017 22:55:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sun, 27 Aug 2017 22:54:44 -0700 (PDT) In-Reply-To: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Lorenzo Colitti Date: Mon, 28 Aug 2017 14:54:44 +0900 Message-ID: To: Mark Smith Cc: "Joel M. Halpern" , james woodyatt , v6ops list Content-Type: multipart/alternative; boundary="001a1143d7d8ba34e40557c9ef5e" Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 05:55:08 -0000 --001a1143d7d8ba34e40557c9ef5e Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 2:48 PM, Mark Smith wrote: > Would a BCP saying IPv6 SHOULD NOT be implemented over Private VLANs > and similar be the better answer for these reasons? Unfortunately I > don't think that is going to stop people trying to do so. > It's definitely a good idea to document these problems, at least. > > A vastly superior alternative is to assign each host its own prefix, and > > make the link between the host and the router unnumbered. > > No such thing as an unnumbered link, there's always a link-local > prefix, per RFC4291's required interface addresses, so the above > issues will still exist for the attached host's LL addresses. > > There's no escaping these issues and the state to emulate them unless > links are truly point-to-point links between the router and the > host(/cpe) with individual links having their own subnet prefix, or > multi-access links have full any-to-any connectivity. > Agreed. What I meant was that the hosts should be isolated at layer 2 as well. The links that I am suggesting be unnumbered (i.e., link-local only) are the links between the host and the router; where there is one such link per host. --001a1143d7d8ba34e40557c9ef5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Aug 28, 2017 at 2:48 PM, Mark Smith <markzzzsmith@gmail.com&g= t; wrote:
    Would a BCP saying IPv6 SHOULD NOT be implemented over Private VLAN= s
    and similar be the better answer for these reasons? Unfortunately I
    don't think that is going to stop people trying to do so.

    It's definitely a good idea to document these pr= oblems, at least.
    =C2=A0
    > A vastly superior alternative is= to assign each host its own prefix, and
    > make the link between the host and the router unnumbered.

    No such thing as an unnumbered link, there's always a link-local=
    prefix, per RFC4291's required interface addresses, so the above
    issues will still exist for the attached host's LL addresses.

    There's no escaping these issues and the state to emulate them unless links are truly point-to-point links between the router and the
    host(/cpe) with individual links having their own subnet prefix, or
    multi-access links have full any-to-any connectivity.
    =
    Agreed. What I meant was that the hosts should be isolated a= t layer 2 as well.=C2=A0The links that I am suggesting be unnumbered (i.e.,= link-local only) are the links between the host and the router; where ther= e is one such link per host.
    --001a1143d7d8ba34e40557c9ef5e-- From nobody Sun Aug 27 23:04:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB35132703 for ; Sun, 27 Aug 2017 23:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nKIppRyOYqkh for ; Sun, 27 Aug 2017 23:04:55 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBA21323C9 for ; Sun, 27 Aug 2017 23:04:55 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id p10so7203423ite.1 for ; Sun, 27 Aug 2017 23:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zSU+eiMJTS75NHEsnDTk4CQ4wj1ShA8+MuOsrmlF7Rk=; b=QwR4Aq9j9cmEfpVCIb/dNpSa0xDEMkRn56TcFlFXj3YGdvIhnt/zTIHdFZHZjGBBRm 0PyvIYWOyuhBo+V2qFCJCLAb+vw3y0inuhfITx1b8K4arwocueVmmZBmt7566S9+yOGj EtZ0mvtKO3rmEj2sxrz5GFyI2S2AjgnS6oNqXHLnCs2KEkZn6Tw87WVmTjhPeRqS0Lj6 i0hj6DiE+jN2Bm8kvig0AfRwfb3sIFr7HuDlz2HTU8mLh8+Ib67DhCZ+pCnvbpxQ1X51 GkZG6T/AyNttMzuT8K3BhbAYydvaz+ZFsUniiUrMY1UH3deJ37WJ4FuqvdTCxaahKDgJ 98eQ== 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=zSU+eiMJTS75NHEsnDTk4CQ4wj1ShA8+MuOsrmlF7Rk=; b=WxQCUzS38cGh4k3cHc3/eR8aTY+OEmbEkEZgB12I4zY/7xDeNBtt8JZ34w3EJiihJm gZjmpjCwG9wxZQziS2fi7pYkyKkk/gUEjtGeGny+Cd/lWrcLIZcFkqULCVEfecEV6bnX XgbuOgdGS5tcZER40+VxHv+V1GUVcRsyn1i5SdbV6iB7zkEH3ISqKHftzkYteowgWCX0 1sDs/70qi7wgZ30NJzBMQ9sqs2D32aJ2sp4+Lmvdty4C3+DFafF7atVikNYIC+KqmCaM GtJKfnwmtD6uGZZ5MmVKGjtpnqo9BeDbLfAyA6Lo69yNFUI1jUypIirbcl/mOHmC+Vm7 Y8CA== X-Gm-Message-State: AHYfb5gXqwRg3NcHYoXaTE0e2d2kcWw5uLHTqZhEu8RNTRa+bFsIyjRm BQb+Bua0br+lV12jhfHr8Iu7V2vEq8Yk X-Google-Smtp-Source: ADKCNb4dduoMvsVFXHy8IQysbMnYNwDWpabaR+mtFAKD4SjWna6SO3uW+Z+b2itNqOyRG7UV3+PEkN4AevlVmZjG7MU= X-Received: by 10.36.173.3 with SMTP id c3mr177726itf.115.1503900294590; Sun, 27 Aug 2017 23:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sun, 27 Aug 2017 23:04:33 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 28 Aug 2017 15:04:33 +0900 Message-ID: To: Mark Smith Cc: v6ops list , David Farmer Content-Type: multipart/alternative; boundary="94eb2c1fc6b4d6ec9e0557ca12db" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 06:04:57 -0000 --94eb2c1fc6b4d6ec9e0557ca12db Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 12:53 PM, Mark Smith wrote: > At least *some* isolation is required because otherwise the periodic > multicast RAs sent to each host would go to all hosts, and all hosts would > have all the other hosts's prefixes. I agree that this should probably be > stated in the document. > > > These constrained link-layers allow mcasts and bcasts from the routers to > go to all hosts, it is the host to other nodes direction that is > constrained to just reaching ports where routers are attached. > > I would have thought all RAs in this scenario are unicast, including > periodic ones. The list of nodes to unicast to periodically could either be > sent using the neighbour cache or from a table built up using MLDv2 join LL > source addresses. Looking though the draft, there doesn't seem to be any > mention of what happens with periodic mutilcast RAs - are they switched off > (meaning periodic hosts' RSes and unicast RAs keep RA information current), > or unicast instead? > Periodic RAs are required, because a network without periodic RAs is a network that only works for up to 65536 seconds. There is no standard that requires hosts to send an RS if some subset of their configuration information expires. There was opposition even to documenting that hosts MAY do so. My understanding is that this document is intended to work on links that are fully isolated at layer 2 - per-host VLANs, if you will, and that it uses periodic multicast RAs on each of these links. That is a much more robust approach than tracking the host's address, because: 1. The address might change 2. It is legal to send an RS from the unspecified address 3. NUD sends a lot of packets and keeps a lot of state. There's no need keep that state if you already have L2 isolation and a strong signal from L2 that tells you when a host has disconnected. 802.11 happens to be able to do both of these things. I agree that these points are non-obvious to readers, though. --94eb2c1fc6b4d6ec9e0557ca12db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On M= on, Aug 28, 2017 at 12:53 PM, Mark Smith <markzzzsmith@gmail.com&= gt; wrote:
    =
    At l= east *some* isolation is required because otherwise the periodic multicast = RAs sent to each host would go to all hosts, and all hosts would have all t= he other hosts's prefixes. I agree that this should probably be stated = in the document.

    These constrained lin= k-layers allow mcasts and bcasts from the routers to go to all hosts, it is= the host to other nodes direction that is constrained to just reaching por= ts where routers are attached.

    I would have thought all RAs in this scenario are unicast, including= periodic ones. The list of nodes to unicast to periodically could either b= e sent using the neighbour cache or from a table built up using MLDv2 join = LL source addresses. Looking though the draft, there doesn't seem to be= any mention of what happens with periodic mutilcast RAs - are they switche= d off (meaning periodic hosts' RSes and unicast RAs keep RA information= current), or unicast instead?

    = Periodic RAs are required, because a network without periodic RAs is a netw= ork that only works for up to 65536 seconds. There is no standard that requ= ires hosts to send an RS if some subset of their configuration information = expires. There was opposition even to documenting that hosts MAY do so.

    My understanding is that this document is intended to= work on links that are fully isolated at layer 2 - per-host VLANs, if you = will, and that it uses periodic multicast RAs on each of these links. That = is a much more robust approach than tracking the host's address, becaus= e:
    1. The address might change
    2. It is legal to send a= n RS from the unspecified address
    3. NUD sends a lot of packets and ke= eps a lot of state. There's no need keep that state if you already have= L2 isolation and a strong signal from L2 that tells you when a host has di= sconnected. 802.11 happens to be able to do both of these things.
      4. <= /ol>
      I agree that these points are non-obvious to readers, though.
    --94eb2c1fc6b4d6ec9e0557ca12db-- From nobody Sun Aug 27 23:05:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23EE132804 for ; Sun, 27 Aug 2017 23:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 lrEnidVeatKZ for ; Sun, 27 Aug 2017 23:05:11 -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 AB00E132BCB for ; Sun, 27 Aug 2017 23:05:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 3721978A for ; Mon, 28 Aug 2017 06:05:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie-ZqH0guPc4 for ; Mon, 28 Aug 2017 01:05:08 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id E9B2C668 for ; Mon, 28 Aug 2017 01:05:07 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id u135so4929916vkd.8 for ; Sun, 27 Aug 2017 23:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iYQKIyaewRCHD3sG5Gh3EwAs5OLxugj9qRFOFVGUXNE=; b=bBSYdhhAMIEhl566G4l4oE0GXUI88GNnxZd3geVjJXKcS4RzGA/Y974DPG4wvs/hcb 1C/zoi9a+F0/i9bdsyk64oKKvn3ylj/zQxCC1zlNa/+U2heue2euencMUVUyxJJbtr5J WnWxDweuoYPeDR4eXxXsf3yhzv8NtbKk1l+exqkOFBrWlkxwQ8kfR0876xKys8cij2PM DxvLHWjCBtTDtxitgdJNoKifZOPS7zXj8oKqICu0BKbQO62f0CQcAvYPer/7NkdsbHrf M9af+Aad/snk8JyZbPi/xf5YIuz8dfI1ou7DraRIz60NqaGwG8w92ptutoaT+zy2qfkn Fffw== 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=iYQKIyaewRCHD3sG5Gh3EwAs5OLxugj9qRFOFVGUXNE=; b=iIEo7qvgNPdzobuxag4AVPVvRHNsPjTK0gt0iJZJr2AMcDj5apZJ5bkNd8bnS+xOYS cUqRXnDdE2D1UHTmwD1dhz1JSJMrTHoxj0YXPvlo8qzjdXRepoYuewLdAE65qGm67Hf0 C/tnM649woslGDak0GErCYmgFkp07kEE3YmvCxU4s06P9A2/d3f0DqvwRBsTnhhdNeg5 NsoBjt4DerTwwS2Ka03zPAW4fEHLj8xUIXVPwkrHFpQBDsueMSH1ODnA3+z9e3o89sWJ SKvGE0FFgdDB75Gk3SobGKvedcyAgKoB+UluW/5LU4Ncsq9bwkTgGP2c/A7bbSVA0cXI Qogw== X-Gm-Message-State: AHYfb5gi3YqTwzWP44K0XgtNnzGDKospH2FoebCW3BZNZCOMoBNjN4Iw 4HrOR5EaUCFkj8v3FSSTuhpJfwXT8MYohOPN9+IJP5fDuqTkL0/A8iK7hZ/E2JBDwPcNObZob5i BQwjScDsMg6Ekb4Fy X-Received: by 10.31.136.196 with SMTP id k187mr3651267vkd.85.1503900307176; Sun, 27 Aug 2017 23:05:07 -0700 (PDT) X-Received: by 10.31.136.196 with SMTP id k187mr3651260vkd.85.1503900306905; Sun, 27 Aug 2017 23:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Sun, 27 Aug 2017 23:05:06 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 28 Aug 2017 01:05:06 -0500 Message-ID: To: Mark Smith Cc: Lorenzo Colitti , v6ops list Content-Type: multipart/alternative; boundary="001a11440eae923af90557ca13ab" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 06:05:14 -0000 --001a11440eae923af90557ca13ab Content-Type: text/plain; charset="UTF-8" On Sun, Aug 27, 2017 at 10:53 PM, Mark Smith wrote: > > > On 28 Aug. 2017 13:21, "Lorenzo Colitti" wrote: > > On Mon, Aug 28, 2017 at 11:49 AM, David Farmer wrote: > >> Well, it doesn't explicitly say anything about the shared network >> preventing peer-to-peer communications, it might be implied, but it is by >> no means explicitly required. >> > > At least *some* isolation is required because otherwise the periodic > multicast RAs sent to each host would go to all hosts, and all hosts would > have all the other hosts's prefixes. I agree that this should probably be > stated in the document. > > > These constrained link-layers allow mcasts and bcasts from the routers to > go to all hosts, it is the host to other nodes direction that is > constrained to just reaching ports where routers are attached. > That's my understanding as well. > I would have thought all RAs in this scenario are unicast, including > periodic ones. The list of nodes to unicast to periodically could either be > sent using the neighbour cache or from a table built up using MLDv2 join LL > source addresses. Looking though the draft, there doesn't seem to be any > mention of what happens with periodic mutilcast RAs - are they switched off > (meaning periodic hosts' RSes and unicast RAs keep RA information current), > or unicast instead? > Yep that needs to be discussed too. I'll note in at least most enterprise class WiFi systems it is a fairly common to include ARP an ND proxies and consume those broadcasts and multicasts within the AP and not forwarding them. An answer is then provided from the AP's cached information, it seems obvious to me to hack the ND proxy in the AP to provide the desired ND isolation for this deployment model. Further, most enterprise class WiFi systems have some kind of proxy for mDNS and sometimes other service discovery protocols too. Once more consuming those broadcasts and multicasts within the AP, providing a customized answer scoped for the requesting device. Some of the really fancy systems are even location aware, and scope the responses based on the devices location. Again, I can think of some really interesting hacks for these capabilities to provide the desired isolation in this deployment model. Finally, other broadcast and multicast traffic, that is not proxied, is either simply dropped or emulated by sending it as unicasts to each of the interested endpoints. Which because multicast and broadcast traffic are sent at the 802.11 base rate, which can be as low at 1Mb, it is frequently more efficient to to replicate and send the multicast as multiple unicasts. Again, I can think of some really interesting hacks for this capability to provide the desired isolation in this deployment model. 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 =============================================== --001a11440eae923af90557ca13ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Aug 27, 2017 at 10:53 PM, Mark Smith <markzzzsmith@gmail.= com> wrote:


    On 28 Aug. 2017 13:21, "Lorenzo Colitti" <lorenzo@google.com>= ; wrote:
    On Mon, Aug 28, 2017 at 11:= 49 AM, David Farmer <farmer@umn.edu> wrote:
    Well, it doesn't explicitly say anything about the shared network pr= eventing peer-to-peer communications, it might be implied, but it is by no = means explicitly required.

    At least *some* isolation is required because otherwise the periodic mult= icast RAs sent to each host would go to all hosts, and all hosts would have= all the other hosts's prefixes. I agree that this should probably be s= tated in the document.

    These constrained link-laye= rs allow mcasts and bcasts from the routers to go to all hosts, it is the h= ost to other nodes direction that is constrained to just reaching ports whe= re routers are attached.

    That&#= 39;s my understanding as well.
    =C2=A0
    I would hav= e thought all RAs in this scenario are unicast, including periodic ones. Th= e list of nodes to unicast to periodically could either be sent using the n= eighbour cache or from a table built up using MLDv2 join LL source addresse= s. Looking though the draft, there doesn't seem to be any mention of wh= at happens with periodic mutilcast RAs - are they switched off (meaning per= iodic hosts' RSes and unicast RAs keep RA information current), or unic= ast instead?

    Yep that needs to = be discussed too.

    I'll note in at least most e= nterprise class WiFi systems it is a fairly common to include ARP an ND pro= xies and consume those broadcasts and multicasts within the AP and not forw= arding them.=C2=A0 An answer is then provided from the AP's cached info= rmation, it seems obvious to me to hack the ND proxy in the AP to provide t= he desired ND isolation for this deployment model.

    Further, most enterprise class WiFi systems have some kind of proxy for mD= NS and sometimes other service discovery protocols too.=C2=A0 Once more con= suming those broadcasts and multicasts within the AP, providing a customize= d answer scoped for the requesting device. Some of the really fancy systems= are even location aware, and scope the responses based on the devices loca= tion.=C2=A0 Again, I can think of some really interesting hacks for these c= apabilities to provide the desired isolation in this deployment model.=C2= =A0

    Finally, other broadcast and multicast t= raffic, that is not proxied, is either simply dropped or emulated by sendin= g it as unicasts to each of the interested endpoints. Which because multica= st and broadcast traffic are sent at the 802.11 base rate, which can be as = low at 1Mb, it is frequently more efficient to to replicate and send the mu= lticast as multiple unicasts. Again, I can think of some really interesting= hacks for this capability to provide the desired isolation in this deploym= ent model.

    Thanks
    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
    Networking & Telecommunication Services
    Office of I= nformation Technology
    University of Minnesota=C2=A0=C2=A0
    2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    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
    --001a11440eae923af90557ca13ab-- From nobody Sun Aug 27 23:24:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC41323C6 for ; Sun, 27 Aug 2017 23:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7alCNDgWQy6 for ; Sun, 27 Aug 2017 23:24:46 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA77F1323B6 for ; Sun, 27 Aug 2017 23:24:46 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d124so13210502vkf.3 for ; Sun, 27 Aug 2017 23:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mCKAkNdmTSQzuXcL/F1vGzOVqhPOf7VfHlfJxqoeMD8=; b=sRTtJ+TasjffF2MF+vkSjPphTEKrfdCq1U3TpWpCv1NaiWxF7z96Wo44T9gyrjtCBI Pt6kpXQLn/Pvr1wWNscUE9y+ILivaMI9ntUEmEbI60wncPZ5BFxgQ7pmaks2EkJe8h8B 3opRdUQzuXuREozlNuitqzqbF8MDjrTfIREfJGqKtnRpEa6OPvtkaODOXsO6bTRaTASs rWvnqiNH7xSQfO6rP5xiBQu/G1EeItz24EPYR1aWMmtRaJet/Zr3/GetT+vDb8EEGQbG pBQ7+qkurKd2OAQYqv/P3p6JtO3qttaeYqLrGy5vVi2MFtRLwieBjenwX0GpqV95hUjA 6paA== 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=mCKAkNdmTSQzuXcL/F1vGzOVqhPOf7VfHlfJxqoeMD8=; b=eOhHBudH5OmWzf1Y+69raEm/bkVRXdhThqJ/fc9oFASk/Jvm693gFijA0+qESlMAKe QZlGi8FpQsFoBjlu7NmkLh3QYMY2WHlSgg3f/CCctlOXNkCOcgu2E0vQIfmoQr9fVJcN tIslvkE4dp6iTz5mS6tY/xSwY3dUW5ncyyN+zbunZ6Nik+KmVHbu9/wYPc5u3+V5dntP Tt5yUdtmY3j4vFxUTal1uCNN2ZKMATpoUIomRwuQJtvhNiV/wlyCaqKeBPxWK6tK+zc1 uUwDQP8+esZNtaO6We2Y5nB3z0J4DvsLEMImFNsHIJLYdQpqjoY4YQt+nPq77c+4ATBH UeRQ== X-Gm-Message-State: AHYfb5gkyYSs9EgKOPz08zmfvXr9i97mjCRnJB46xkgIshbkDJfzWfo0 KmxAk6qrZSHWmAUButlhLoLEmpcdlQ== X-Received: by 10.31.208.134 with SMTP id h128mr3615267vkg.93.1503901485657; Sun, 27 Aug 2017 23:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Sun, 27 Aug 2017 23:24:14 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Mon, 28 Aug 2017 16:24:14 +1000 Message-ID: To: Lorenzo Colitti Cc: v6ops list , David Farmer Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 06:24:48 -0000 On 28 August 2017 at 16:04, Lorenzo Colitti wrote: > On Mon, Aug 28, 2017 at 12:53 PM, Mark Smith wrote: >> >> At least *some* isolation is required because otherwise the periodic >> multicast RAs sent to each host would go to all hosts, and all hosts would >> have all the other hosts's prefixes. I agree that this should probably be >> stated in the document. >> >> >> These constrained link-layers allow mcasts and bcasts from the routers to >> go to all hosts, it is the host to other nodes direction that is constrained >> to just reaching ports where routers are attached. >> >> I would have thought all RAs in this scenario are unicast, including >> periodic ones. The list of nodes to unicast to periodically could either be >> sent using the neighbour cache or from a table built up using MLDv2 join LL >> source addresses. Looking though the draft, there doesn't seem to be any >> mention of what happens with periodic mutilcast RAs - are they switched off >> (meaning periodic hosts' RSes and unicast RAs keep RA information current), >> or unicast instead? > > > Periodic RAs are required, because a network without periodic RAs is a > network that only works for up to 65536 seconds. There is no standard that > requires hosts to send an RS if some subset of their configuration > information expires. There was opposition even to documenting that hosts MAY > do so. > I couldn't remember one, just thought that hosts might issue an RS as a "last resort" if an RA is going to expire, and that could have been an alternative to periodic RAs. Was the objection because RSes are multicast? It' seems there is a little bit of room in RFC4861 that could allow RSes to be unicast to an already known router, that would/could solicit a unicast RA response. " Destination Address Typically the all-routers multicast address." > My understanding is that this document is intended to work on links that are > fully isolated at layer 2 - per-host VLANs, if you will, and that it uses > periodic multicast RAs on each of these links. That is a much more robust > approach than tracking the host's address, because: > > The address might change > It is legal to send an RS from the unspecified address > NUD sends a lot of packets and keeps a lot of state. There's no need keep > that state if you already have L2 isolation and a strong signal from L2 that > tells you when a host has disconnected. 802.11 happens to be able to do both > of these things. > > I agree that these points are non-obvious to readers, though. Agree. My thought was the link between the hosts and router was a single shared one with the "Private VLAN"/Wifi Isolated Station type constraints we've been discussing in the other thread. Regards, Mark. From nobody Mon Aug 28 00:05:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6721323B6 for ; Mon, 28 Aug 2017 00:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 bFq0AkFVVr24 for ; Mon, 28 Aug 2017 00:05:46 -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 008CA132804 for ; Mon, 28 Aug 2017 00:05:45 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 55DC573A for ; Mon, 28 Aug 2017 07:05:45 +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 zthtC9qAWznb for ; Mon, 28 Aug 2017 02:05:45 -0500 (CDT) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 0C62B737 for ; Mon, 28 Aug 2017 02:05:44 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id w84so5017935vkd.6 for ; Mon, 28 Aug 2017 00:05:44 -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=P9tz6joZowF0r9zuR6YweNqDpS6OcmC/s9Ti7dxb8kI=; b=Xl0SMYGtKFO7Wfr28QgPnufliMdClIY3Jrcu6ZpP1vwjJCLEGqfKPuYnf69iyxd9gF ZUgmXV882Dmp3MW4UcOyPOlymBPajxvTQTSIxpOzA+SHbQdLIChkK3v40mfy5bhpJdcn LAeZzAGJwvDTIl2XV0Wz9ukjrLrf7ejD/1ZfvB4/JR22XSo5NRW8zw0RFpGAmhpgiriO ovq+wtRtixDBfR37ZmmjcUyP3oN0+5hO5Rb99kLiBy2E4GGuqPnn1fTRsHo3eAvRTOrW EmqvKRpGUuy4+iyLEIRqjJUHO3yDbhLx87xZVGvQp5PAMlwiDlFCPQu6p0GA8w2DDn3Y wc6g== 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=P9tz6joZowF0r9zuR6YweNqDpS6OcmC/s9Ti7dxb8kI=; b=mnbG5rlaIL0zCkfOaRYocX1pRkuye7OgYjt896BMHhX+iFWhKyFuQjr0WNL4qp5xm7 17NtCylICjg+29XsMy3ZWZvQMjSigvG144Y0pamqdhRiN/dy2NP9x8+BsUi4Y+ofuEFu gEOH1IHuQ3EKmFMUM+Ph4QTVy42A5hUHPgcxk++m2p3H6b2XYFWxpTumIyjQKmX3bBfe Wj+WWlZ5oJfAoVPqat4NVivcuvfeG8IlyfEqHPxNNOSWK2m5hMwVWPr3CcU1hjVbYyIT vOQwr01OUcRcWomrN54Gk+kgenFKFDEx88oFMGSfnP7m43B9uvD5Q0YYuX+jxq5J/A9V fNkQ== X-Gm-Message-State: AHYfb5jOkrgdfDwcZ3ijnGQzncCrFoW5zUTN/SErBfGdFlKHfERcIKfx eNBoJiVcCknpoNCflUaL5rVpu286TVpqkhhOVPViUdlRRa2ZvqmI7fZUYUeSS3fgh84GD3Tc8Wz FyAUjJzMBZj5djoll X-Received: by 10.176.80.188 with SMTP id c57mr3908308uaa.32.1503903944022; Mon, 28 Aug 2017 00:05:44 -0700 (PDT) X-Received: by 10.176.80.188 with SMTP id c57mr3908305uaa.32.1503903943781; Mon, 28 Aug 2017 00:05:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Mon, 28 Aug 2017 00:05:42 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 28 Aug 2017 02:05:42 -0500 Message-ID: To: Lorenzo Colitti Cc: Mark Smith , v6ops list Content-Type: multipart/alternative; boundary="94eb2c19211c5888b70557caecff" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 07:05:48 -0000 --94eb2c19211c5888b70557caecff Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 1:04 AM, Lorenzo Colitti wrote: > On Mon, Aug 28, 2017 at 12:53 PM, Mark Smith > wrote: > >> At least *some* isolation is required because otherwise the periodic >> multicast RAs sent to each host would go to all hosts, and all hosts would >> have all the other hosts's prefixes. I agree that this should probably be >> stated in the document. >> >> >> These constrained link-layers allow mcasts and bcasts from the routers to >> go to all hosts, it is the host to other nodes direction that is >> constrained to just reaching ports where routers are attached. >> >> I would have thought all RAs in this scenario are unicast, including >> periodic ones. The list of nodes to unicast to periodically could either be >> sent using the neighbour cache or from a table built up using MLDv2 join LL >> source addresses. Looking though the draft, there doesn't seem to be any >> mention of what happens with periodic mutilcast RAs - are they switched off >> (meaning periodic hosts' RSes and unicast RAs keep RA information current), >> or unicast instead? >> > > Periodic RAs are required, because a network without periodic RAs is a > network that only works for up to 65536 seconds. There is no standard that > requires hosts to send an RS if some subset of their configuration > information expires. There was opposition even to documenting that hosts > MAY do so. > In a WiFi environment that may not be much of an issue, 18 hours is a long time for most WiFi environments. Nodes usually go to sleep in a lot less time then that, and frequently send a RS when they wake up. And even if they don't go to sleep there are frequently many other 802.11 layer events that cause a node to send an RS to ensure to it's sill on the same network after the event, roaming, forced re-associations, re-authentication timers, etc... I'd be seriously shocked to see a WiFi node make it 18 hours without sending a RS of its own volition for one reason or another. Even if it did, the WiFi system just has to force a re-associations on any node attached for more than 18 hours. You must think WiFi is a whole lot more stable than it really is. > My understanding is that this document is intended to work on links that > are fully isolated at layer 2 - per-host VLANs, if you will, and that it > uses periodic multicast RAs on each of these links. That is a much more > robust approach than tracking the host's address, because: > > 1. The address might change > 2. It is legal to send an RS from the unspecified address > 3. NUD sends a lot of packets and keeps a lot of state. There's no > need keep that state if you already have L2 isolation and a strong signal > from L2 that tells you when a host has disconnected. 802.11 happens to be > able to do both of these things. > > I agree that these points are non-obvious to readers, though. > I'm not aware of that level of isolation in any of WiFi systems short of separate VLANs and a host per-vlan, which would limit you to about 4000 hosts, or require multi layer 802.1q tagging and I'm not aware of any WiFi system doing multiple Q tags. Also, I've never heard of any of the WiFi system even getting to 4000 usable VLANs, they usually top out at a few hundred VLANs. I've talk to most of them about ideas like VLAN per user, they thought I was NUTS! They pushed me toward Wifi Station Isolation, which is not the level of isolation your talking about. If that is truly the intent it needs a lot more discussion, and I don't see how this could be BCP then, where is the running code? -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c19211c5888b70557caecff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Mon, Aug 28, 2017 at 1:04 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
    =
    On M= on, Aug 28, 2017 at 12:53 PM, Mark Smith <markzzzsmith@gmail.com&= gt; wrote:
    =
    At leas= t *some* isolation is required because otherwise the periodic multicast RAs= sent to each host would go to all hosts, and all hosts would have all the = other hosts's prefixes. I agree that this should probably be stated in = the document.

    These constrained link-l= ayers allow mcasts and bcasts from the routers to go to all hosts, it is th= e host to other nodes direction that is constrained to just reaching ports = where routers are attached.

    I would have thought all RAs in this scenario are unicast, including pe= riodic ones. The list of nodes to unicast to periodically could either be s= ent using the neighbour cache or from a table built up using MLDv2 join LL = source addresses. Looking though the draft, there doesn't seem to be an= y mention of what happens with periodic mutilcast RAs - are they switched o= ff (meaning periodic hosts' RSes and unicast RAs keep RA information cu= rrent), or unicast instead?

    Per= iodic RAs are required, because a network without periodic RAs is a network= that only works for up to 65536 seconds. There is no standard that require= s hosts to send an RS if some subset of their configuration information exp= ires. There was opposition even to documenting that hosts MAY do so.
    <= /div>

    In a WiFi environment tha= t may not be much of an issue, 18 hours is a long time for most WiFi enviro= nments.=C2=A0 Nodes usually go to sleep in a lot less time then that, and f= requently send a RS when they wake up.=C2=A0 And even if they don't go = to sleep there are frequently many other 802.11 layer events that cause a n= ode to send an RS to ensure to it's sill on the same network after the = event, roaming, forced re-associations, re-authentication timers, etc...=C2= =A0 I'd be seriously shocked to see a WiFi node make it 18 hours withou= t sending a RS of its own volition for one reason or another. Even if it di= d, the WiFi system just has to force a re-associations on any node attached= for more than 18 hours. You must think WiFi is a whole lot more stable tha= n it really is.
    =C2=A0
    My understanding is that this document is intended to work on= links that are fully isolated at layer 2 - per-host VLANs, if you will, an= d that it uses periodic multicast RAs on each of these links. That is a muc= h more robust approach than tracking the host's address, because:
    =
    1. The address might change
    2. It is legal to send an RS fro= m the unspecified address
    3. NUD sends a lot of packets and keeps a lo= t of state. There's no need keep that state if you already have L2 isol= ation and a strong signal from L2 that tells you when a host has disconnect= ed. 802.11 happens to be able to do both of these things.
    I agree that these points are non-obvious to readers, though.
    <= /div>

    I'm not aware of that level of isolation in any = of WiFi systems short of separate VLANs and a host per-vlan, which would li= mit you to about 4000 hosts, or require multi layer 802.1q tagging and I= 9;m not aware of any WiFi system doing multiple Q tags. Also, I've neve= r heard of any of the WiFi system even getting to 4000 usable VLANs, they u= sually top out at a few hundred VLANs.=C2=A0 I've talk to most of them = about ideas like VLAN per user, they thought I was NUTS! They pushed me tow= ard=C2=A0Wifi Station Isolation, which is = not the level of isolation your talking about.

    If that is truly the intent it needs a lot more discussion,= and I don't see how this could be BCP then, where is the running code?=
    --
    =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Dav= id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.eduNetworking & Telecommunication Services
    Office of Information Tech= nology
    University of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --94eb2c19211c5888b70557caecff-- From nobody Mon Aug 28 01:09:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF188132025 for ; Mon, 28 Aug 2017 01:09:22 -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=fit.vutbr.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTmuvraV2hSH for ; Mon, 28 Aug 2017 01:09:20 -0700 (PDT) Received: from kazi.fit.vutbr.cz (kazi6.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (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 4E5C0132C23 for ; Mon, 28 Aug 2017 01:09:20 -0700 (PDT) Received: from [147.229.13.162] (pcpolcak.fit.vutbr.cz [147.229.13.162]) (authenticated bits=0) by kazi.fit.vutbr.cz (8.15.2/8.15.2) with ESMTPSA id v7S89FLH035453 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Aug 2017 10:09:16 +0200 (CEST) To: Tim Chown , Timothy Winters Cc: Simon Hobson , v6ops list References: <6FF0E188-7F66-4494-A6D2-59DDAAB2B92B@jisc.ac.uk> From: =?UTF-8?B?TGlib3IgUG9sxI3DoWs=?= Message-ID: <016385ff-61f0-c14d-1369-a229bde80d80@fit.vutbr.cz> Date: Mon, 28 Aug 2017 10:09:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 MIME-Version: 1.0 In-Reply-To: <6FF0E188-7F66-4494-A6D2-59DDAAB2B92B@jisc.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fit.vutbr.cz; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=mx1; bh=FIJ7fLfa6iVizqFWjzgnHdCgRH9aST5rQlEbFcjiQi0=; b=cZkXRd194xe488ccsU/GQ5UJ3WZlzk5lZBHglL1mPERJLdcwNKed81EEGLIMew4UWSS+xYC5YwHzKRx6hq8d977b+LSu/s8ZJ5rCF+sktNqrZ+IR81nmDq8LjhziPMhW+14OU9k1/YZEJkavtFGoWTO8619D6ABjIhFJe5iILCo= X-Scanned-By: MIMEDefang 2.78 on 147.229.8.12 Archived-At: Subject: Re: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 08:09:23 -0000 Tim Chown napsal(a): > Hi, > >> On 17 Aug 2017, at 11:47, Timothy Winters wrote: >> >> Most operating systems give up if they fail DAD. > > For SLAAC, RFC7127 includes a DAD counter in the IID generation algorithm, and specifies how to use that in https://tools.ietf.org/html/rfc7217#section-6, but has anyone tested whether existing implementations are doing that? Hello, We tested the number of retries performed by different OS for RFC4941 addresses several years ago http://6lab.cz/behaviour-of-various-operating-systems-during-slaac-dad-and-nd/. See the last column in the table. In summary, Linux, Solaris, and Windows tried different RFC4941 addresses. FreeBSD, OpenBSD, MAC OS X tried only a single RFC4941 address. Regards, Libor From nobody Mon Aug 28 08:38:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE00132C4D; Mon, 28 Aug 2017 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJBCpx4AAlOp; Mon, 28 Aug 2017 08:38:53 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2F5132027; Mon, 28 Aug 2017 08:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7SFcqUY042581; Mon, 28 Aug 2017 08:38:52 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7SFckaj042528 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 28 Aug 2017 08:38:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 28 Aug 2017 08:38:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 28 Aug 2017 08:38:45 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrA= Date: Mon, 28 Aug 2017 15:38:45 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b4677b2f8b0b499b95b94e0bd9ec2d54XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:38:56 -0000 --_000_b4677b2f8b0b499b95b94e0bd9ec2d54XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBtb3JlLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQg c2F5ICpsZXNzKiB0aGFuIHdoYXQNCml0IGlzIGN1cnJlbnRseSBzYXlpbmcuIEluIHBhcnRpY3Vs YXIsIGluIHNlY3Rpb24gMiwgc2ltcGx5IHJlbW92ZSB0aGUgYnVsbGV0Og0KDQogICDigJxvICBU d28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUg cHJvdmlkZXINCiAgICAgIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkgYmUgYWJs ZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQogICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJz dCBIb3AgUm91dGVy4oCdDQoNCmFuZCwgaW4gU2VjdGlvbiA0LCBzaW1wbHkgcmVtb3ZlIHRoZSBz ZW50ZW5jZToNCg0KICAg4oCcSWYgdGhlIFVFL3N1YnNjcmliZXINCiAgIGRlc2lyZXMgdG8gc2Vu ZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlcg0KICAgZGV2 aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVk IGFuZA0KICAgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0IFNIT1VM RCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIu 4oCdDQoNClRoZSBvbmx5IHRoaW5nIHRoYXQgY2FuIHByZXZlbnQgdHdvIHN1YnNjcmliZXIgZGV2 aWNlcyBmcm9tIGNvbW11bmljYXRpbmcNCmRpcmVjdGx5IHdpdGhvdXQgZ29pbmcgdGhyb3VnaCB0 aGUgZmlyc3QgaG9wIHJvdXRlciB3b3VsZCBiZSBMMiBtZWNoYW5pc21zIGJ1dA0Kbm90IGFsbCBu ZXR3b3JrcyBhcmUgZ29pbmcgdG8gd2FudCB0byBwcmV2ZW50IGRpcmVjdCBjb21tdW5pY2F0aW9u cy4NCg0KVGhlcmVmb3JlLCBsZWF2aW5nIHRoZXNlIHR3byBzdGF0ZW1lbnRzIGluIHdvdWxkIHVu bmVjZXNzYXJpbHkgcmVzdHJpY3QgdGhlDQpkb21haW4gb2YgYXBwbGljYWJpbGl0eS4NCg0KVGhh bmtzIC0gRnJlZA0KDQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0N ClNlbnQ6IEZyaWRheSwgQXVndXN0IDI1LCAyMDE3IDg6MjggUE0NClRvOiBUZW1wbGluLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmc7IHY2b3Bz LWNoYWlyc0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBDb21tZW50IG9uICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dC0wNycNCg0KDQoNCk9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDM6NTIgUE0sIFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4+IHdyb3RlOg0KSGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyDi gJMgSSBpbnNlcnRlZCBmb2xsb3ctdXBzIGJlbG93Lg0KDQpGcmVkDQoNCg0KPiAgICBHb29kIHBv aW50cywgYnV0IGlmIGFueXRoaW5nIG1vcmUgc2hvdWxkIGJlIHNhaWQgSSB0aGluayBpdCBzaG91 bGQgYmUga2VwdCBhcyB0ZXJzZQ0KDQo+ICAgIGFzIHBvc3NpYmxlLiBDYW4geW91IHN1Z2dlc3Qg c29tZSB0ZXh0PyBBbiBpbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoZQ0KDQo+ICAg IFJlZGlyZWN0IGl0c2VsZiBkb2VzIG5vdCByZWFsbHkgZ2l2ZSBwZXJtaXNzaW9uIOKAkyBhbGwg aXQgZG9lcyBpcyBwcm92aWRlcyB0aGUgc291cmNlDQoNCj4gICAgbm9kZSB3aXRoIHRoZSBsaW5r LWxvY2FsIGFuZCBsaW5rLWxheWVyIGFkZHJlc3NlcyBvZiB0aGUgdGFyZ2V0IG5vZGUuIElmIHRo ZSBzb3VyY2UNCg0KPiAgICBub2RlIGhhcyBzb21lIG90aGVyIHdheSBvZiBkZXRlcm1pbmluZyB0 aG9zZSBhZGRyZXNzZXMsIGl0IGNhbiBnbyBwZWVyLXRvLXBlZXINCg0KPiAgICB3aXRob3V0IGV2 ZW4gbmVlZGluZyB0byByZWNlaXZlIGEgUmVkaXJlY3QuIEluIHRoYXQgY2FzZSwgdGhlIG9ubHkg d2F5IHRvIHByZXZlbnQNCg0KPiAgICBwZWVyLXRvLXBlZXIgaXMgdmlhIEwyIG1lY2hhbmlzbXMu DQpZZXMgbGluay1sb2NhbCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZSBmb3IgcGVlci10by1wZWVy IGNvbW11bmljYXRpb24gaWYgYWxsb3cgYnkgdGhlIHNoYXJlZCBuZXR3b3JrLCBob3dldmVyIHJl ZGlyZWN0cyBhcmUgdGhlIG9ubHkgbWVjaGFuaXNtIGF2YWlsYWJsZSBmb3IgYSBub2RlIHRvIGRl dGVybWluZSB0aGUgbGluay1sYXllciBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhbiBJUHY2IGFk ZHJlc3MgZnJvbSB3aXRoaW4gb24gb2YgdGhlIFVuaXF1ZSBQcmVmaXhlcyBhcyBMPTAsIG90aGVy IHRoYW4gbWFsaWNpb3VzIGFjdGl2aXR5LiAgSWYgTD0wIHlvdSBhcmUgbm90IGFsbG93ZWQgdG8g dXNlIE5EIHRvIHJlc29sdmUgdGhlIGxpbmstbGF5ZXIgYWRkcmVzcywgYW5kIHRoZSBvbmx5IG90 aGVyIHdheSBmb3IgYSBub2RlIHRvIGxlYXJuIGEgbGluay1sYXllciBhZGRyZXNzIGFzc29jaWF0 ZWQgd2l0aCBhbiBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgVW5pcXVlIFByZWZpeCBpcyBieSBhIHJl ZGlyZWN0IGZyb20gYSByb3V0ZXIuDQoNCkhvdyBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOw0K DQpJZiB0aGUgVUUvc3Vic2NyaWJlciBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwg aW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXIgZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRv IGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBwb3J0ZWQpLCB0aGVuLCBk dWUgdG8gdGhlIEwtYml0IHNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBG aXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyLCB1bmxlc3MgZGVzdGluZSB0byBhIGxpbmstbG9jYWwg YWRkcmVzcyBvciByZWRpcmVjdGVkIGJ5IHRoZSByb3V0ZXIuDQoNCk5vdGU6IElmIHRoZSBzaGFy ZWQgbmV0d29yayBwZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zLCBkaXJlY3QgVUUvc3Vi c2NyaWJlciBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb24gd2lsbCBiZSBwb3NzaWJsZSB1 c2luZyBsaW5rLWxvY2FsIGFkZHJlc3NpbmcgYWNyb3NzIHRoZSBzaGFyZWQgbmV0d29yay4gRnVy dGhlciwgaWYgdGhlIHJvdXRlciBwcm92aWRlcyByZWRpcmVjdHMsIHRoZW4gZGlyZWN0IFVFL3N1 YnNjcmliZXIgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBhbHNvIHBvc3NpYmxl IHVzaW5nIHRoZSB1bmlxdWUgSVB2NiBwcmVmaXhlcyBhY3Jvc3MgdGhlIHNoYXJlZCBuZXR3b3Jr Lg0KSSB0aGluayB0aGlzIGFkZGl0aW9uIGlzIGltcG9ydGFudCBib3RoIGlmIHlvdSB3YW50IHRv IGVuYWJsZSBvciBkaXNhYmxlIGRpcmVjdCBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25z LCBpZiB5b3Ugd2FudCB0byBlbmFibGUgaXQgdGhpcyB0ZWxscyB5b3Ugd2hhdCB5b3UgaGF2ZSB0 byBkbywgYW5kIGlmIHlvdSB3YW50IHRvIGRpc2FibGUgaXQsIGFuZCB0aGUgc2hhcmVkIG5ldHdv cmsgYWxsb3dzIGl0LCB5b3UgYXJlIHJlbWluZGVkIHRvIGRpc2FibGUgcm91dGVyIHJlZGlyZWN0 cyBhbmQgdGhhdCB5b3UgbmVlZCB0byBkbyBzb21ldGhpbmcgYWJvdXQgbGluay1sb2NhbC4gSXQg bWlnaHQgYmUgd29ydGggYWRkaW5nIHNvbWV0aGluZyBhYm91dCB0aGlzIHRvIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyB0b28uICBGb3Igc3VyZSBpdCBiZSB3b3J0aCBub3RpbmcgaW4gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gdGhhdCBpZiB0aGUgc2hhcmVkIG5ldHdvcmsgcGVybWl0 cyBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucywgdGhlbiBtYWxpY2lvdXMgZGlyZWN0IGRldmljZSB0 byBkZXZpY2UgY29tbXVuaWNhdGlvbnMgd291bGQgYmUgcG9zc2libGUgZXZlbiB3aXRob3V0IGxp bmstbG9jYWwgYWRkcmVzc2luZyBvciByb3V0ZXIgcmVkaXJlY3RzLg0KDQpUaGFua3MuDQoNCi0t DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KRGF2aWQg RmFybWVyICAgICAgICAgICAgICAgRW1haWw6ZmFybWVyQHVtbi5lZHU8bWFpbHRvOkVtYWlsJTNB ZmFybWVyQHVtbi5lZHU+DQpOZXR3b3JraW5nICYgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXMN Ck9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290 YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgUGhvbmU6IDYxMi02MjYtMDgxNTx0ZWw6 KDYxMiklMjA2MjYtMDgxNT4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAgQ2VsbDogNjEy LTgxMi05OTUyPHRlbDooNjEyKSUyMDgxMi05OTUyPg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg== --_000_b4677b2f8b0b499b95b94e0bd9ec2d54XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuZ21h aWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlz dHBhcmFncmFwaCwgbGkuZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2 OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tNzM3MDAyODI4MjA4OTg0 OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWwtbV8tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW1fLTI0NDc2NjY5NDg5 NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBtb3JlLCBJIHRoaW5rIHRo ZSBkb2N1bWVudCBzaG91bGQgc2F5ICo8Yj5sZXNzPC9iPiogdGhhbiB3aGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPml0IGlzIGN1cnJlbnRseSBzYXlpbmcuIEluIHBhcnRpY3VsYXIsIGluIHNlY3Rpb24g Miwgc2ltcGx5IHJlbW92ZSB0aGUgYnVsbGV0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnG8mbmJzcDsgVHdvIGRldmljZXMgKHN1YnNj cmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2VkIHNoYXJlZCBu ZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHByb3ZpZGVyIG1h bmFnZWQgRmlyc3QgSG9wIFJvdXRlcuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+YW5kLCBpbiBTZWN0aW9uIDQsIHNpbXBseSByZW1vdmUgdGhlIHNlbnRlbmNl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IOKAnElmIHRoZSBVRS9zdWJzY3JpYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBk ZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVyIFVFL3N1YnNj cmliZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGRldmljZXMgKGFzc3VtaW5nIGRl dmljZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMgaXMgZW5hYmxlZCBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0aGUgTC1iaXQgc2V0 LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IHRvIHRoZSBGaXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIG9ubHkgdGhpbmcgdGhhdCBjYW4gcHJldmVu dCB0d28gc3Vic2NyaWJlciBkZXZpY2VzIGZyb20gY29tbXVuaWNhdGluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5kaXJlY3RseSB3aXRob3V0IGdvaW5nIHRocm91Z2ggdGhlIGZpcnN0IGhvcCByb3V0ZXIg d291bGQgYmUgTDIgbWVjaGFuaXNtcyBidXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bm90IGFsbCBuZXR3 b3JrcyBhcmUgZ29pbmcgdG8gd2FudCB0byBwcmV2ZW50IGRpcmVjdCBjb21tdW5pY2F0aW9ucy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlZm9yZSwgbGVh dmluZyB0aGVzZSB0d28gc3RhdGVtZW50cyBpbiB3b3VsZCB1bm5lY2Vzc2FyaWx5IHJlc3RyaWN0 IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kb21haW4gb2YgYXBwbGljYWJpbGl0eS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEF1Z3VzdCAyNSwgMjAxNyA4OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGlu LCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiB2Nm9wc0BpZXRmLm9yZzsgdjZvcHMtY2hhaXJzQGlldGYub3JnOyB2Nm9wcy1hZHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcnPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDM6NTIgUE0s IFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBEYXZpZCw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9y IHlvdXIgY29tbWVudHMg4oCTIEkgaW5zZXJ0ZWQgZm9sbG93LXVwcyBiZWxvdy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GcmVkPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0y NDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R29vZCBwb2ludHMs IGJ1dCBpZiBhbnl0aGluZyBtb3JlIHNob3VsZCBiZSBzYWlkIEkgdGhpbmsgaXQgc2hvdWxkIGJl IGtlcHQgYXMgdGVyc2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS03 MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFn cmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+YXMgcG9zc2libGUuIENhbiB5b3Ugc3VnZ2VzdCBzb21lIHRleHQ/IEFu IGltcG9ydGFudCB0aGluZyB0byBub3RlIGlzIHRoYXQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0 ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZGlyZWN0IGl0c2VsZiBkb2Vz IG5vdCByZWFsbHkgZ2l2ZSBwZXJtaXNzaW9uIOKAkyBhbGwgaXQgZG9lcyBpcyBwcm92aWRlcyB0 aGUgc291cmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzM3MDAy ODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv bG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPm5vZGUgd2l0aCB0aGUgbGluay1sb2NhbCBhbmQgbGluay1sYXllciBhZGRyZXNz ZXMgb2YgdGhlIHRhcmdldCBub2RlLiBJZiB0aGUgc291cmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0 ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5vZGUgaGFzIHNvbWUgb3RoZXIg d2F5IG9mIGRldGVybWluaW5nIHRob3NlIGFkZHJlc3NlcywgaXQgY2FuIGdvIHBlZXItdG8tcGVl cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTczNzAwMjgyODIwODk4 NDk4NjdnbWFpbC1tLTI0NDc2NjY5NDg5NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij53aXRob3V0IGV2ZW4gbmVlZGluZyB0byByZWNlaXZlIGEgUmVkaXJlY3QuIEluIHRoYXQgY2Fz ZSwgdGhlIG9ubHkgd2F5IHRvIHByZXZlbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUw bXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cGVlci10by1wZWVyIGlzIHZpYSBMMiBtZWNoYW5p c21zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgbGluay1s b2NhbCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZSBmb3IgcGVlci10by1wZWVyIGNvbW11bmljYXRp b24gaWYgYWxsb3cgYnkgdGhlIHNoYXJlZCBuZXR3b3JrLCBob3dldmVyIHJlZGlyZWN0cyBhcmUg dGhlIG9ubHkgbWVjaGFuaXNtIGF2YWlsYWJsZSBmb3IgYSBub2RlIHRvIGRldGVybWluZSB0aGUg bGluay1sYXllciBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhbiBJUHY2IGFkZHJlc3MgZnJvbQ0K IHdpdGhpbiBvbiBvZiB0aGUgVW5pcXVlIFByZWZpeGVzIGFzIEw9MCwgb3RoZXIgdGhhbiBtYWxp Y2lvdXMgYWN0aXZpdHkuJm5ic3A7IElmIEw9MCB5b3UgYXJlIG5vdCBhbGxvd2VkIHRvIHVzZSBO RCB0byByZXNvbHZlIHRoZSBsaW5rLWxheWVyIGFkZHJlc3MsIGFuZCB0aGUgb25seSBvdGhlciB3 YXkgZm9yIGEgbm9kZSB0byBsZWFybiBhIGxpbmstbGF5ZXIgYWRkcmVzcyBhc3NvY2lhdGVkIHdp dGggYW4gSVB2NiBhZGRyZXNzIGZyb20gdGhlIFVuaXF1ZQ0KIFByZWZpeCBpcyBieSBhIHJlZGly ZWN0IGZyb20gYSByb3V0ZXIuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgc29tZXRoaW5nIGxpa2UgdGhp czs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JZiB0aGUgVUUvc3Vic2NyaWJlciBkZXNpcmVzIHRvIHNl bmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXIgZGV2aWNl cyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFu ZCBzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwtYml0IHNldCwgaXQgU0hPVUxEIHNlbmQg dGhpcw0KIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIsIHVubGVzcyBk ZXN0aW5lIHRvIGEgbGluay1sb2NhbCBhZGRyZXNzIG9yIHJlZGlyZWN0ZWQgYnkgdGhlIHJvdXRl ci48YnI+DQo8YnI+DQpOb3RlOiBJZiB0aGUgc2hhcmVkIG5ldHdvcmsgcGVybWl0cyBwZWVyLXRv LXBlZXIgb3BlcmF0aW9ucywgZGlyZWN0IFVFL3N1YnNjcmliZXIgZGV2aWNlIHRvIGRldmljZSBj b21tdW5pY2F0aW9uIHdpbGwgYmUgcG9zc2libGUgdXNpbmcgbGluay1sb2NhbCBhZGRyZXNzaW5n IGFjcm9zcyB0aGUgc2hhcmVkIG5ldHdvcmsuIEZ1cnRoZXIsIGlmIHRoZSByb3V0ZXIgcHJvdmlk ZXMgcmVkaXJlY3RzLCB0aGVuIGRpcmVjdCBVRS9zdWJzY3JpYmVyIGRldmljZQ0KIHRvIGRldmlj ZSBjb21tdW5pY2F0aW9ucyBpcyBhbHNvIHBvc3NpYmxlIHVzaW5nIHRoZSB1bmlxdWUgSVB2NiBw cmVmaXhlcyBhY3Jvc3MgdGhlIHNoYXJlZCBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQiPkkgdGhpbmsgdGhpcyBhZGRpdGlvbiBpcyBpbXBvcnRhbnQgYm90aCBpZiB5b3Ug d2FudCB0byBlbmFibGUgb3IgZGlzYWJsZSBkaXJlY3QgZGV2aWNlIHRvIGRldmljZSBjb21tdW5p Y2F0aW9ucywgaWYgeW91IHdhbnQgdG8gZW5hYmxlIGl0IHRoaXMgdGVsbHMgeW91IHdoYXQgeW91 IGhhdmUgdG8gZG8sIGFuZCBpZiB5b3Ugd2FudCB0byZuYnNwO2Rpc2FibGUmbmJzcDtpdCwgYW5k DQogdGhlIHNoYXJlZCBuZXR3b3JrIGFsbG93cyBpdCwgeW91IGFyZSByZW1pbmRlZCB0byBkaXNh YmxlIHJvdXRlciByZWRpcmVjdHMgYW5kIHRoYXQgeW91IG5lZWQgdG8gZG8gc29tZXRoaW5nIGFi b3V0IGxpbmstbG9jYWwuIEl0IG1pZ2h0IGJlIHdvcnRoIGFkZGluZyBzb21ldGhpbmcmbmJzcDth Ym91dCB0aGlzIHRvIHRoZSBzZWN1cml0eSZuYnNwO2NvbnNpZGVyYXRpb25zIHRvby4mbmJzcDsg Rm9yIHN1cmUgaXQgYmUgd29ydGggbm90aW5nIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u DQogdGhhdCBpZiB0aGUgc2hhcmVkPC9zcGFuPiZuYnNwO25ldHdvcmsgcGVybWl0cyBwZWVyLXRv LXBlZXIgb3BlcmF0aW9ucywgdGhlbiBtYWxpY2lvdXMmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0Ij5kaXJlY3QgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyB3b3VsZCBi ZSBwb3NzaWJsZSBldmVuIHdpdGhvdXQgbGluay1sb2NhbCBhZGRyZXNzaW5nIG9yIHJvdXRlciBy ZWRpcmVjdHMuPC9zcGFuPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5U aGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCkRh dmlkIEZhcm1lciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyA8YSBocmVmPSJtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdSIgdGFyZ2V0PSJf YmxhbmsiPg0KRW1haWw6ZmFybWVyQHVtbi5lZHU8L2E+PGJyPg0KTmV0d29ya2luZyAmYW1wOyBU ZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlczxicj4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNo bm9sb2d5PGJyPg0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEmbmJzcDsmbmJzcDsgPGJyPg0KMjIx OCBVbml2ZXJzaXR5IEF2ZSBTRSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaG9uZTogPGEg aHJlZj0idGVsOig2MTIpJTIwNjI2LTA4MTUiIHRhcmdldD0iX2JsYW5rIj4NCjYxMi02MjYtMDgx NTwvYT48YnI+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA8 YSBocmVmPSJ0ZWw6KDYxMiklMjA4MTItOTk1MiIgdGFyZ2V0PSJfYmxhbmsiPg0KNjEyLTgxMi05 OTUyPC9hPjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b4677b2f8b0b499b95b94e0bd9ec2d54XCH150608nwnosboeingcom_-- From nobody Mon Aug 28 09:39:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9881321DC for ; Mon, 28 Aug 2017 09:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 Eq-hQgfQRriz for ; Mon, 28 Aug 2017 09:39:48 -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 621C2132355 for ; Mon, 28 Aug 2017 09:39:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id ACC0419B for ; Mon, 28 Aug 2017 16:39:45 +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 m0Wy0rQhIm81 for ; Mon, 28 Aug 2017 11:39:45 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 57518862 for ; Mon, 28 Aug 2017 11:39:45 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id j189so482903vka.0 for ; Mon, 28 Aug 2017 09:39:45 -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=y+PqrwK0BDJC2g93C7VxqO8sdVU9fhXWbs8b7cEiFm4=; b=icR+kfLZ8zwDCbbNOAPtdE3KWWE9sb+qMhyFWOMSTX/tFJexeo8dYbK6ixny/l/91Q EM55SvGkvm2z+YMsKPKoJxlaKdbbcpjPzaJU4bUtJsnKuDQbF7xM15eudTqQ7wey7G7a k4My1okRJDVX4WiggWgUamO6CjFLCvHhDmrH8FjH66/Hi8pdP7W29datlbxRwDIFWufv zp47Jl8ZI7+Mz9HjCJ5wDf4YauK6FWhdycPPLhAw6ISA6h1apVuBwitbnnNWdmNFmx45 Io0MIfNh+UbS/StRS+84c0MX6uVs9bgXfYAhSBmkNZ3E94z6yhwBVV+L0rwuZMe2Rh04 oJEw== 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=y+PqrwK0BDJC2g93C7VxqO8sdVU9fhXWbs8b7cEiFm4=; b=aZt9kEzTvyCHq5hlZ39nz218CVU4TiakCWPi/C2r8XjqGyWrXt6+DPJY0o9xaXt8/j w4b1igmRhqGOedVKx9XODrIPYsOlxNq01BhKpTJ8Mki/6hiW7C+yU6vgwQkW47fZiKdK LYri4X2YiSHOE1zuZSJXdZ+Muiu6h2Zv3LYxx5QlCPRYanH7k+G35vnfqfzYysqtQeLV PzsjKhM/LI2P7SGUy+W+SMJuyjONHcE7Y70q4eNmGD84azoEpwTPeybOiFTsjll3x6Z7 Tq6cYtbFLKxfYxz80cx1KRcVkV6bTzHte1RuQ1MFRATLRx/b7P7dVTe9HUriGtded8/k 6g6w== X-Gm-Message-State: AHYfb5jdRFfcEpp5rEEEGj2NUMSM8kN3Apgos1HDGHILro7dVXyh7kmM +IPYI5c+R93TxSfe8QSvXE0srEDhoQsWbFuMHYXXWKVNUp85wYnwuXTgWOzt5HZeH8JBLTjGvsh N+R2OPmzy+FULlPS+ X-Received: by 10.31.135.72 with SMTP id j69mr677573vkd.140.1503938383686; Mon, 28 Aug 2017 09:39:43 -0700 (PDT) X-Received: by 10.31.135.72 with SMTP id j69mr677564vkd.140.1503938383475; Mon, 28 Aug 2017 09:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Mon, 28 Aug 2017 09:39:42 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Mon, 28 Aug 2017 11:39:42 -0500 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a1145a0061c97bb0557d2f1d9" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 16:39:51 -0000 --001a1145a0061c97bb0557d2f1d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Mark has been talking about in the other thread, if you use an L2 mechanism then you can't ensure you won't duplicated an IID without a ND proxy along with the L2 mechanism. So I have to disagree, we seem to have several different interpretations of the current text, to me that usually means we are missing something important in the text, and people are filling in with there own imaginations, and coming to different conclusions. I think there are important details that need more discussion in the text, not less, or in other word I can't support removing text, at least yet. While I'm skeptical of Lorenzo's description, with more details of how you put each host in its own VLAN, I could see how what he is talking about could work. So, I'd like to here what more about how the authors think this is suppose to work. Thanks On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L wrote: > In thinking about this more, I think the document should say **less** > than what > > it is currently saying. In particular, in section 2, simply remove the > bullet: > > > > =E2=80=9Co Two devices (subscriber/hosts), both attached to the same = provider > > managed shared network should only be able to communicate through > > the provider managed First Hop Router=E2=80=9D > > > > and, in Section 4, simply remove the sentence: > > > > =E2=80=9CIf the UE/subscriber > > desires to send anything external including other UE/subscriber > > devices (assuming device to device communications is enabled and > > supported), then, due to the L-bit set, it SHOULD send this traffic > > to the First Hop Provider Router.=E2=80=9D > > > > The only thing that can prevent two subscriber devices from communicating > > directly without going through the first hop router would be L2 mechanism= s > but > > not all networks are going to want to prevent direct communications. > > > > Therefore, leaving these two statements in would unnecessarily restrict t= he > > domain of applicability. > > > > Thanks - Fred > > > > *From:* David Farmer [mailto:farmer@umn.edu] > *Sent:* Friday, August 25, 2017 8:28 PM > *To:* Templin, Fred L > *Cc:* v6ops@ietf.org; v6ops-chairs@ietf.org; v6ops-ads@ietf.org > *Subject:* Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6- > prefix-per-host-07' > > > > > > > > On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > Hi David, > > > > Thanks for your comments =E2=80=93 I inserted follow-ups below. > > > > Fred > > > > =C3=98 Good points, but if anything more should be said I think it sho= uld > be kept as terse > > =C3=98 as possible. Can you suggest some text? An important thing to n= ote > is that the > > =C3=98 Redirect itself does not really give permission =E2=80=93 all i= t does is > provides the source > > =C3=98 node with the link-local and link-layer addresses of the target > node. If the source > > =C3=98 node has some other way of determining those addresses, it can = go > peer-to-peer > > =C3=98 without even needing to receive a Redirect. In that case, the o= nly > way to prevent > > =C3=98 peer-to-peer is via L2 mechanisms. > > Yes link-local addressing is available for peer-to-peer communication if > allow by the shared network, however redirects are the only mechanism > available for a node to determine the link-layer address associated with = an > IPv6 address from within on of the Unique Prefixes as L=3D0, other than > malicious activity. If L=3D0 you are not allowed to use ND to resolve th= e > link-layer address, and the only other way for a node to learn a link-lay= er > address associated with an IPv6 address from the Unique Prefix is by a > redirect from a router. > > > > How about something like this; > > > > If the UE/subscriber desires to send anything external including other > UE/subscriber devices (assuming device to device communications is enable= d > and supported), then, due to the L-bit set, it SHOULD send this traffic t= o > the First Hop Provider Router, unless destine to a link-local address or > redirected by the router. > > Note: If the shared network permits peer-to-peer operations, direct > UE/subscriber device to device communication will be possible using > link-local addressing across the shared network. Further, if the router > provides redirects, then direct UE/subscriber device to device > communications is also possible using the unique IPv6 prefixes across the > shared network. > > I think this addition is important both if you want to enable or disable > direct device to device communications, if you want to enable it this tel= ls > you what you have to do, and if you want to disable it, and the shared > network allows it, you are reminded to disable router redirects and that > you need to do something about link-local. It might be worth adding > something about this to the security considerations too. For sure it be > worth noting in the security consideration that if the shared network > permits peer-to-peer operations, then malicious direct device to device > communications would be possible even without link-local addressing or > router redirects. > > > > Thanks. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1145a0061c97bb0557d2f1d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    As Mark has been talking about in the other thread, if you= use an L2 mechanism then you can't ensure you won't duplicated an = IID without a ND proxy along with the L2 mechanism.

    So I= have to disagree, we seem to have several different interpretations of the= current text, to me that usually means we are missing something important = in the text, and people are filling in with there own imaginations, and com= ing to different conclusions.=C2=A0 I think there are important details tha= t need more discussion in the text, not less, or in other word I can't = support removing text, at least yet.

    While I'm= skeptical of Lorenzo's description, with more details of how you put e= ach host in its own VLAN, I could see how what he is talking about could wo= rk.

    So, I'd like to here what more about how t= he authors think this is suppose to work. =C2=A0 =C2=A0=C2=A0

    Thanks

    On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

    In thinking about this more, I think = the document should say *less* than what

    it is currently saying. In particular= , in section 2, simply remove the bullet:

    =C2=A0

    =C2=A0=C2=A0 =E2=80=9Co=C2=A0 Two dev= ices (subscriber/hosts), both attached to the same provider

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 manage= d shared network should only be able to communicate through

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the pr= ovider managed First Hop Router=E2=80=9D

    =C2=A0

    and, in Section 4, simply remove the = sentence:

    =C2=A0

    =C2=A0=C2=A0 =E2=80=9CIf the UE/subsc= riber

    =C2=A0=C2=A0 desires to send anything= external including other UE/subscriber

    =C2=A0=C2=A0 devices (assuming device= to device communications is enabled and

    =C2=A0=C2=A0 supported), then, due to= the L-bit set, it SHOULD send this traffic

    =C2=A0=C2=A0 to the First Hop Provide= r Router.=E2=80=9D

    =C2=A0

    The only thing that can prevent two s= ubscriber devices from communicating

    directly without going through the fi= rst hop router would be L2 mechanisms but

    not all networks are going to want to= prevent direct communications.

    =C2=A0

    Therefore, leaving these two statemen= ts in would unnecessarily restrict the

    domain of applicability.

    =C2=A0

    Thanks - Fred

    =C2=A0

    From: David Farmer [mailto:farmer@umn.edu]
    Sent: Friday, August 25, 2017 8:28 PM
    To: Templin, Fred L <Fred.L.Templin@boeing.com>
    Cc: v6ops@ietf.o= rg; v6ops-ch= airs@ietf.org; = v6ops-ads@ietf.org
    Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

    =C2=A0

    =C2=A0

    =C2=A0

    On Fri, Aug 25, 2017 at 3:52 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

    Hi David,

    =C2=A0

    Thanks for your comments =E2=80=93 I = inserted follow-ups below.

    =C2=A0

    Fred

    =C2=A0

    =C3=98= =C2=A0=C2=A0=C2=A0 Good points, but if anything more should be said I th= ink it should be kept as terse

    =C3=98= =C2=A0=C2=A0=C2=A0 as possible. Can you suggest some text? An important = thing to note is that the

    =C3=98= =C2=A0=C2=A0=C2=A0 Redirect itself does not really give permission =E2= =80=93 all it does is provides the source

    =C3=98= =C2=A0=C2=A0=C2=A0 node with the link-local and link-layer addresses of = the target node. If the source

    =C3=98= =C2=A0=C2=A0=C2=A0 node has some other way of determining those addresse= s, it can go peer-to-peer

    =C3=98= =C2=A0=C2=A0=C2=A0 without even needing to receive a Redirect. In that c= ase, the only way to prevent

    =C3=98= =C2=A0=C2=A0=C2=A0 peer-to-peer is via L2 mechanisms.

    Yes link-local addressing is available for peer-to-p= eer communication if allow by the shared network, however redirects are the= only mechanism available for a node to determine the link-layer address as= sociated with an IPv6 address from within on of the Unique Prefixes as L=3D0, other than malicious activity.= =C2=A0 If L=3D0 you are not allowed to use ND to resolve the link-layer add= ress, and the only other way for a node to learn a link-layer address assoc= iated with an IPv6 address from the Unique Prefix is by a redirect from a router. =C2=A0=C2=A0

    =C2=A0

    How about something like this;

    =C2=A0

    If the UE/subscriber = desires to send anything external including other UE/subscriber devices (as= suming device to device communications is enabled and supported), then, due= to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router, unless destine to a link-local a= ddress or redirected by the router.

    Note: If the shared network permits peer-to-peer operations, direct UE/subs= criber device to device communication will be possible using link-local add= ressing across the shared network. Further, if the router provides redirect= s, then direct UE/subscriber device to device communications is also possible using the unique IPv6 prefixes a= cross the shared network.

    I think this additio= n is important both if you want to enable or disable direct device to devic= e communications, if you want to enable it this tells you what you have to = do, and if you want to=C2=A0disable=C2=A0it, and the shared network allows it, you are reminded to disable router redirects= and that you need to do something about link-local. It might be worth addi= ng something=C2=A0about this to the security=C2=A0considerations too.=C2=A0= For sure it be worth noting in the security consideration that if the shared=C2=A0network permits peer-to-peer operations, th= en malicious=C2=A0direct device to device c= ommunications would be possible even without link-local addressing or route= r redirects.=C2=A0=C2=A0

    =C2=A0

    Thanks.

    =C2=A0

    --

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




    --
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
    --001a1145a0061c97bb0557d2f1d9-- From nobody Mon Aug 28 09:40:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC58132355 for ; Mon, 28 Aug 2017 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYq9Kg6Cv4QL for ; Mon, 28 Aug 2017 09:40:25 -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 4BE1E1321DC for ; Mon, 28 Aug 2017 09:40:25 -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 v7SGeOEK020798; Mon, 28 Aug 2017 09:40:24 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7SGeI2u020768 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 28 Aug 2017 09:40:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 28 Aug 2017 09:40:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 28 Aug 2017 09:40:17 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Mark Smith CC: v6ops list Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwCNc8GAABYS0oAAE6Q/gAABrSeAAAERvAAAASblgAAEk4iAAAdX+kA= Date: Mon, 28 Aug 2017 16:40:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_f7f26a61a6584b9b9274ff098cc7ee35XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 16:40:27 -0000 --_000_f7f26a61a6584b9b9274ff098cc7ee35XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0Kw5ggIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIGRvY3VtZW50IGlzIGlu dGVuZGVkIHRvIHdvcmsgb24gbGlua3MgdGhhdCBhcmUgZnVsbHkgaXNvbGF0ZWQgYXQgbGF5ZXIg MiAtIHBlci1ob3N0IFZMQU5zLCBpZiB5b3Ugd2lsbA0KDQpJIGRvbuKAmXQgc2VlIGFueSBwcmVz Y3JpcHRpb25zIG9mIFZMQU5zIGFuZC9vciBhbnkgb3RoZXIgTDIgbWVjaGFuaXNtcyBhbnl3aGVy ZQ0KaW4gdGhlIGRvY3VtZW50LCBhbmQgSSB0aGluayBhbnkgc3VjaCBjb25zaWRlcmF0aW9ucyBh cmUgb3V0IG9mIHNjb3BlLiBUaGVzZSBzYW1lDQptZWNoYW5pc21zIHNob3VsZCBiZSB1c2VmdWwg b24gYW55IHNoYXJlZCBtZWRpYSB0eXBlIChFdGhlcm5ldCwgV2lmaSwgTkJNQSwgZXRjLikuDQoN ClRoYXQgc2FpZCwgSSB3b3VsZCBub3QgYmUgb3Bwb3NlZCB0byBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB0ZXh0IHRoYXQgZGlzY3VzcyB0aGUNCnRocmVhdHMuIEJ1dCwgSSB3b3VsZCBub3Qgc3Vw cG9ydCB0ZXh0IHRoYXQgdW5uZWNlc3NhcmlseSByZXN0cmljdHMgdGhlIGRvbWFpbiBvZg0KYXBw bGljYWJpbGl0eS4NCg0KVGhhbmtzIC0gRnJlZA0KDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDog U3VuZGF5LCBBdWd1c3QgMjcsIDIwMTcgMTE6MDUgUE0NClRvOiBNYXJrIFNtaXRoIDxtYXJrenp6 c21pdGhAZ21haWwuY29tPg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDcnDQoNCk9uIE1vbiwgQXVnIDI4LCAyMDE3IGF0IDEyOjUzIFBNLCBN YXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21h aWwuY29tPj4gd3JvdGU6DQpBdCBsZWFzdCAqc29tZSogaXNvbGF0aW9uIGlzIHJlcXVpcmVkIGJl Y2F1c2Ugb3RoZXJ3aXNlIHRoZSBwZXJpb2RpYyBtdWx0aWNhc3QgUkFzIHNlbnQgdG8gZWFjaCBo b3N0IHdvdWxkIGdvIHRvIGFsbCBob3N0cywgYW5kIGFsbCBob3N0cyB3b3VsZCBoYXZlIGFsbCB0 aGUgb3RoZXIgaG9zdHMncyBwcmVmaXhlcy4gSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIHByb2Jh Ymx5IGJlIHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNClRoZXNlIGNvbnN0cmFpbmVkIGxpbmst bGF5ZXJzIGFsbG93IG1jYXN0cyBhbmQgYmNhc3RzIGZyb20gdGhlIHJvdXRlcnMgdG8gZ28gdG8g YWxsIGhvc3RzLCBpdCBpcyB0aGUgaG9zdCB0byBvdGhlciBub2RlcyBkaXJlY3Rpb24gdGhhdCBp cyBjb25zdHJhaW5lZCB0byBqdXN0IHJlYWNoaW5nIHBvcnRzIHdoZXJlIHJvdXRlcnMgYXJlIGF0 dGFjaGVkLg0KDQpJIHdvdWxkIGhhdmUgdGhvdWdodCBhbGwgUkFzIGluIHRoaXMgc2NlbmFyaW8g YXJlIHVuaWNhc3QsIGluY2x1ZGluZyBwZXJpb2RpYyBvbmVzLiBUaGUgbGlzdCBvZiBub2RlcyB0 byB1bmljYXN0IHRvIHBlcmlvZGljYWxseSBjb3VsZCBlaXRoZXIgYmUgc2VudCB1c2luZyB0aGUg bmVpZ2hib3VyIGNhY2hlIG9yIGZyb20gYSB0YWJsZSBidWlsdCB1cCB1c2luZyBNTER2MiBqb2lu IExMIHNvdXJjZSBhZGRyZXNzZXMuIExvb2tpbmcgdGhvdWdoIHRoZSBkcmFmdCwgdGhlcmUgZG9l c24ndCBzZWVtIHRvIGJlIGFueSBtZW50aW9uIG9mIHdoYXQgaGFwcGVucyB3aXRoIHBlcmlvZGlj IG11dGlsY2FzdCBSQXMgLSBhcmUgdGhleSBzd2l0Y2hlZCBvZmYgKG1lYW5pbmcgcGVyaW9kaWMg aG9zdHMnIFJTZXMgYW5kIHVuaWNhc3QgUkFzIGtlZXAgUkEgaW5mb3JtYXRpb24gY3VycmVudCks IG9yIHVuaWNhc3QgaW5zdGVhZD8NCg0KUGVyaW9kaWMgUkFzIGFyZSByZXF1aXJlZCwgYmVjYXVz ZSBhIG5ldHdvcmsgd2l0aG91dCBwZXJpb2RpYyBSQXMgaXMgYSBuZXR3b3JrIHRoYXQgb25seSB3 b3JrcyBmb3IgdXAgdG8gNjU1MzYgc2Vjb25kcy4gVGhlcmUgaXMgbm8gc3RhbmRhcmQgdGhhdCBy ZXF1aXJlcyBob3N0cyB0byBzZW5kIGFuIFJTIGlmIHNvbWUgc3Vic2V0IG9mIHRoZWlyIGNvbmZp Z3VyYXRpb24gaW5mb3JtYXRpb24gZXhwaXJlcy4gVGhlcmUgd2FzIG9wcG9zaXRpb24gZXZlbiB0 byBkb2N1bWVudGluZyB0aGF0IGhvc3RzIE1BWSBkbyBzby4NCg0KTXkgdW5kZXJzdGFuZGluZyBp cyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gd29yayBvbiBsaW5rcyB0aGF0IGFy ZSBmdWxseSBpc29sYXRlZCBhdCBsYXllciAyIC0gcGVyLWhvc3QgVkxBTnMsIGlmIHlvdSB3aWxs LCBhbmQgdGhhdCBpdCB1c2VzIHBlcmlvZGljIG11bHRpY2FzdCBSQXMgb24gZWFjaCBvZiB0aGVz ZSBsaW5rcy4gVGhhdCBpcyBhIG11Y2ggbW9yZSByb2J1c3QgYXBwcm9hY2ggdGhhbiB0cmFja2lu ZyB0aGUgaG9zdCdzIGFkZHJlc3MsIGJlY2F1c2U6DQoNCiAgMS4gIFRoZSBhZGRyZXNzIG1pZ2h0 IGNoYW5nZQ0KICAyLiAgSXQgaXMgbGVnYWwgdG8gc2VuZCBhbiBSUyBmcm9tIHRoZSB1bnNwZWNp ZmllZCBhZGRyZXNzDQogIDMuICBOVUQgc2VuZHMgYSBsb3Qgb2YgcGFja2V0cyBhbmQga2VlcHMg YSBsb3Qgb2Ygc3RhdGUuIFRoZXJlJ3Mgbm8gbmVlZCBrZWVwIHRoYXQgc3RhdGUgaWYgeW91IGFs cmVhZHkgaGF2ZSBMMiBpc29sYXRpb24gYW5kIGEgc3Ryb25nIHNpZ25hbCBmcm9tIEwyIHRoYXQg dGVsbHMgeW91IHdoZW4gYSBob3N0IGhhcyBkaXNjb25uZWN0ZWQuIDgwMi4xMSBoYXBwZW5zIHRv IGJlIGFibGUgdG8gZG8gYm90aCBvZiB0aGVzZSB0aGluZ3MuDQpJIGFncmVlIHRoYXQgdGhlc2Ug cG9pbnRzIGFyZSBub24tb2J2aW91cyB0byByZWFkZXJzLCB0aG91Z2guDQo= --_000_f7f26a61a6584b9b9274ff098cc7ee35XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTk4MzUwMjY1Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTIyMzk0MzMwIDIxNDUwMjE1 OTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTQ4MzAyNjE1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNzUyNzIyNTU2O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBkb2N1bWVudCBp cyBpbnRlbmRlZCB0byB3b3JrIG9uIGxpbmtzIHRoYXQgYXJlIGZ1bGx5IGlzb2xhdGVkIGF0IGxh eWVyIDIgLSBwZXItaG9zdCBWTEFOcywgaWYgeW91IHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBzZWUgYW55IHByZXNjcmlwdGlvbnMgb2Yg VkxBTnMgYW5kL29yIGFueSBvdGhlciBMMiBtZWNoYW5pc21zIGFueXdoZXJlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmluIHRoZSBkb2N1bWVudCwgYW5kIEkgdGhpbmsgYW55IHN1Y2ggY29uc2lkZXJhdGlv bnMgYXJlIG91dCBvZiBzY29wZS4gVGhlc2Ugc2FtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5tZWNoYW5p c21zIHNob3VsZCBiZSB1c2VmdWwgb24gYW55IHNoYXJlZCBtZWRpYSB0eXBlIChFdGhlcm5ldCwg V2lmaSwgTkJNQSwgZXRjLikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxicj4NClRoYXQgc2FpZCwgSSB3 b3VsZCBub3QgYmUgb3Bwb3NlZCB0byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0IHRoYXQg ZGlzY3VzcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhyZWF0cy4gQnV0LCBJIHdvdWxkIG5vdCBz dXBwb3J0IHRleHQgdGhhdCB1bm5lY2Vzc2FyaWx5IHJlc3RyaWN0cyB0aGUgZG9tYWluIG9mPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmFwcGxpY2FiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXVn dXN0IDI3LCAyMDE3IDExOjA1IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJrIFNtaXRoICZsdDttYXJr enp6c21pdGhAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdjZvcHMgbGlzdCAmbHQ7djZv cHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQg b24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3JzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgQXVnIDI4LCAyMDE3IGF0IDEyOjUzIFBNLCBNYXJrIFNtaXRoICZsdDs8 YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h cmt6enpzbWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0 IGxlYXN0ICpzb21lKiBpc29sYXRpb24gaXMgcmVxdWlyZWQgYmVjYXVzZSBvdGhlcndpc2UgdGhl IHBlcmlvZGljIG11bHRpY2FzdCBSQXMgc2VudCB0byBlYWNoIGhvc3Qgd291bGQgZ28gdG8gYWxs IGhvc3RzLCBhbmQgYWxsIGhvc3RzIHdvdWxkIGhhdmUgYWxsIHRoZSBvdGhlciBob3N0cydzIHBy ZWZpeGVzLiBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgcHJvYmFibHkgYmUgc3RhdGVkIGluIHRo ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGNvbnN0cmFpbmVkIGxpbmstbGF5 ZXJzIGFsbG93IG1jYXN0cyBhbmQgYmNhc3RzIGZyb20gdGhlIHJvdXRlcnMgdG8gZ28gdG8gYWxs IGhvc3RzLCBpdCBpcyB0aGUgaG9zdCB0byBvdGhlciBub2RlcyBkaXJlY3Rpb24gdGhhdCBpcyBj b25zdHJhaW5lZCB0byBqdXN0IHJlYWNoaW5nIHBvcnRzIHdoZXJlIHJvdXRlcnMgYXJlIGF0dGFj aGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHdvdWxkIGhhdmUgdGhvdWdodCBhbGwgUkFzIGluIHRoaXMgc2NlbmFyaW8gYXJlIHVuaWNh c3QsIGluY2x1ZGluZyBwZXJpb2RpYyBvbmVzLiBUaGUgbGlzdCBvZiBub2RlcyB0byB1bmljYXN0 IHRvIHBlcmlvZGljYWxseSBjb3VsZCBlaXRoZXIgYmUgc2VudCB1c2luZyB0aGUgbmVpZ2hib3Vy IGNhY2hlIG9yIGZyb20gYSB0YWJsZSBidWlsdCB1cCB1c2luZyBNTER2MiBqb2luIExMIHNvdXJj ZSBhZGRyZXNzZXMuDQogTG9va2luZyB0aG91Z2ggdGhlIGRyYWZ0LCB0aGVyZSBkb2Vzbid0IHNl ZW0gdG8gYmUgYW55IG1lbnRpb24gb2Ygd2hhdCBoYXBwZW5zIHdpdGggcGVyaW9kaWMgbXV0aWxj YXN0IFJBcyAtIGFyZSB0aGV5IHN3aXRjaGVkIG9mZiAobWVhbmluZyBwZXJpb2RpYyBob3N0cycg UlNlcyBhbmQgdW5pY2FzdCBSQXMga2VlcCBSQSBpbmZvcm1hdGlvbiBjdXJyZW50KSwgb3IgdW5p Y2FzdCBpbnN0ZWFkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmlvZGljIFJBcyBhcmUgcmVxdWly ZWQsIGJlY2F1c2UgYSBuZXR3b3JrIHdpdGhvdXQgcGVyaW9kaWMgUkFzIGlzIGEgbmV0d29yayB0 aGF0IG9ubHkgd29ya3MgZm9yIHVwIHRvIDY1NTM2IHNlY29uZHMuIFRoZXJlIGlzIG5vIHN0YW5k YXJkIHRoYXQgcmVxdWlyZXMgaG9zdHMgdG8gc2VuZCBhbiBSUyBpZiBzb21lIHN1YnNldCBvZiB0 aGVpciBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGV4cGlyZXMuIFRoZXJlDQogd2FzIG9wcG9z aXRpb24gZXZlbiB0byBkb2N1bWVudGluZyB0aGF0IGhvc3RzIE1BWSBkbyBzby48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gd29yayBvbiBsaW5rcyB0 aGF0IGFyZSBmdWxseSBpc29sYXRlZCBhdCBsYXllciAyIC0gcGVyLWhvc3QgVkxBTnMsIGlmIHlv dSB3aWxsLCBhbmQgdGhhdCBpdCB1c2VzIHBlcmlvZGljIG11bHRpY2FzdCBSQXMgb24gZWFjaCBv ZiB0aGVzZSBsaW5rcy4gVGhhdCBpcyBhIG11Y2ggbW9yZSByb2J1c3QgYXBwcm9hY2ggdGhhbg0K IHRyYWNraW5nIHRoZSBob3N0J3MgYWRkcmVzcywgYmVjYXVzZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NClRoZSBhZGRyZXNzIG1pZ2h0IGNoYW5nZTxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBs Zm8xIj4NCkl0IGlzIGxlZ2FsIHRvIHNlbmQgYW4gUlMgZnJvbSB0aGUgdW5zcGVjaWZpZWQgYWRk cmVzczxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8xIj4NCk5VRCBzZW5kcyBhIGxvdCBvZiBwYWNrZXRzIGFuZCBrZWVwcyBhIGxvdCBv ZiBzdGF0ZS4gVGhlcmUncyBubyBuZWVkIGtlZXAgdGhhdCBzdGF0ZSBpZiB5b3UgYWxyZWFkeSBo YXZlIEwyIGlzb2xhdGlvbiBhbmQgYSBzdHJvbmcgc2lnbmFsIGZyb20gTDIgdGhhdCB0ZWxscyB5 b3Ugd2hlbiBhIGhvc3QgaGFzIGRpc2Nvbm5lY3RlZC4gODAyLjExIGhhcHBlbnMgdG8gYmUgYWJs ZSB0byBkbyBib3RoIG9mIHRoZXNlIHRoaW5ncy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlc2UgcG9pbnRzIGFyZSBub24t b2J2aW91cyB0byByZWFkZXJzLCB0aG91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_f7f26a61a6584b9b9274ff098cc7ee35XCH150608nwnosboeingcom_-- From nobody Mon Aug 28 09:46:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E45132C67; Mon, 28 Aug 2017 09:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0m7k6yiFTXx; Mon, 28 Aug 2017 09:46:07 -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 0B777132C48; Mon, 28 Aug 2017 09:46:07 -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 v7SGk6DZ030610; Mon, 28 Aug 2017 09:46:06 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7SGk5a2030601 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 28 Aug 2017 09:46:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 28 Aug 2017 09:46:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 28 Aug 2017 09:46:04 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKA Date: Mon, 28 Aug 2017 16:46:04 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_ed263a8fc90543e3950087c25bfc9184XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 16:46:09 -0000 --_000_ed263a8fc90543e3950087c25bfc9184XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCkkgZmxpcHBlZCB0aHJvdWdoIHRoZSBkaXNjdXNzaW9uIHRoYXQgdHJhbnNw aXJlZCBvdmVyIHRoZSB3ZWVrZW5kLCBidXQgdGhlIHRyZW5kDQpvZiB0aGF0IGRpc2N1c3Npb24g c2VlbXMgdG8gYmUgaW1wbHlpbmcgbW9yZSBhbmQgbW9yZSByZXN0cmljdGlvbnMgb24gdGhlIGRv bWFpbg0Kb2YgYXBwbGljYWJpbGl0eS4gVGhlc2UgbWVjaGFuaXNtcyBzaG91bGQgYmUgYXBwbGlj YWJsZSBvbiBhbnkgbGluayB0eXBlLCBhbmQgbm90DQpqdXN0IHRob3NlIHRoYXQgZW1wbG95IFZM QU5zIG9yIG90aGVyIEwyIG1pdGlnYXRpb25zLiBJdCBpcyBubyBkaWZmZXJlbnQgdGhhbg0KUkZD NDg2MSBpbiB0aGF0IHJlZ2FyZC4NCg0KQWdhaW4sICBJIHdvdWxkIG5vdCBiZSBvcHBvc2VkIHRv IGEgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIGluIHRoZSBTZWN1cml0eQ0KQ29uc2lkZXJhdGlv bnMgc2VjdGlvbi4gQnV0LCBJIGRpc2FncmVlIHdpdGggdGV4dCB0aGF0IHdvdWxkIHVubmVjZXNz YXJpbHkNCnJlc3RyaWN0IHRoZSBkb21haW4gb2YgYXBwbGljYWJpbGl0eS4NCg0KVGhhbmtzIC0g RnJlZA0KDQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NClNlbnQ6 IE1vbmRheSwgQXVndXN0IDI4LCAyMDE3IDk6NDAgQU0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWly c0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb21t ZW50IG9uICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNycN Cg0KQXMgTWFyayBoYXMgYmVlbiB0YWxraW5nIGFib3V0IGluIHRoZSBvdGhlciB0aHJlYWQsIGlm IHlvdSB1c2UgYW4gTDIgbWVjaGFuaXNtIHRoZW4geW91IGNhbid0IGVuc3VyZSB5b3Ugd29uJ3Qg ZHVwbGljYXRlZCBhbiBJSUQgd2l0aG91dCBhIE5EIHByb3h5IGFsb25nIHdpdGggdGhlIEwyIG1l Y2hhbmlzbS4NCg0KU28gSSBoYXZlIHRvIGRpc2FncmVlLCB3ZSBzZWVtIHRvIGhhdmUgc2V2ZXJh bCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIG9mIHRoZSBjdXJyZW50IHRleHQsIHRvIG1lIHRo YXQgdXN1YWxseSBtZWFucyB3ZSBhcmUgbWlzc2luZyBzb21ldGhpbmcgaW1wb3J0YW50IGluIHRo ZSB0ZXh0LCBhbmQgcGVvcGxlIGFyZSBmaWxsaW5nIGluIHdpdGggdGhlcmUgb3duIGltYWdpbmF0 aW9ucywgYW5kIGNvbWluZyB0byBkaWZmZXJlbnQgY29uY2x1c2lvbnMuICBJIHRoaW5rIHRoZXJl IGFyZSBpbXBvcnRhbnQgZGV0YWlscyB0aGF0IG5lZWQgbW9yZSBkaXNjdXNzaW9uIGluIHRoZSB0 ZXh0LCBub3QgbGVzcywgb3IgaW4gb3RoZXIgd29yZCBJIGNhbid0IHN1cHBvcnQgcmVtb3Zpbmcg dGV4dCwgYXQgbGVhc3QgeWV0Lg0KDQpXaGlsZSBJJ20gc2tlcHRpY2FsIG9mIExvcmVuem8ncyBk ZXNjcmlwdGlvbiwgd2l0aCBtb3JlIGRldGFpbHMgb2YgaG93IHlvdSBwdXQgZWFjaCBob3N0IGlu IGl0cyBvd24gVkxBTiwgSSBjb3VsZCBzZWUgaG93IHdoYXQgaGUgaXMgdGFsa2luZyBhYm91dCBj b3VsZCB3b3JrLg0KDQpTbywgSSdkIGxpa2UgdG8gaGVyZSB3aGF0IG1vcmUgYWJvdXQgaG93IHRo ZSBhdXRob3JzIHRoaW5rIHRoaXMgaXMgc3VwcG9zZSB0byB3b3JrLg0KDQpUaGFua3MNCg0KT24g TW9uLCBBdWcgMjgsIDIwMTcgYXQgMTA6MzggQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3Rl Og0KSW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBtb3JlLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91 bGQgc2F5ICpsZXNzKiB0aGFuIHdoYXQNCml0IGlzIGN1cnJlbnRseSBzYXlpbmcuIEluIHBhcnRp Y3VsYXIsIGluIHNlY3Rpb24gMiwgc2ltcGx5IHJlbW92ZSB0aGUgYnVsbGV0Og0KDQogICDigJxv ICBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNh bWUgcHJvdmlkZXINCiAgICAgIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkgYmUg YWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQogICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBG aXJzdCBIb3AgUm91dGVy4oCdDQoNCmFuZCwgaW4gU2VjdGlvbiA0LCBzaW1wbHkgcmVtb3ZlIHRo ZSBzZW50ZW5jZToNCg0KICAg4oCcSWYgdGhlIFVFL3N1YnNjcmliZXINCiAgIGRlc2lyZXMgdG8g c2VuZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlcg0KICAg ZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFi bGVkIGFuZA0KICAgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0IFNI T1VMRCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0 ZXIu4oCdDQoNClRoZSBvbmx5IHRoaW5nIHRoYXQgY2FuIHByZXZlbnQgdHdvIHN1YnNjcmliZXIg ZGV2aWNlcyBmcm9tIGNvbW11bmljYXRpbmcNCmRpcmVjdGx5IHdpdGhvdXQgZ29pbmcgdGhyb3Vn aCB0aGUgZmlyc3QgaG9wIHJvdXRlciB3b3VsZCBiZSBMMiBtZWNoYW5pc21zIGJ1dA0Kbm90IGFs bCBuZXR3b3JrcyBhcmUgZ29pbmcgdG8gd2FudCB0byBwcmV2ZW50IGRpcmVjdCBjb21tdW5pY2F0 aW9ucy4NCg0KVGhlcmVmb3JlLCBsZWF2aW5nIHRoZXNlIHR3byBzdGF0ZW1lbnRzIGluIHdvdWxk IHVubmVjZXNzYXJpbHkgcmVzdHJpY3QgdGhlDQpkb21haW4gb2YgYXBwbGljYWJpbGl0eS4NCg0K VGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVk dTxtYWlsdG86ZmFybWVyQHVtbi5lZHU+XQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjUsIDIwMTcg ODoyOCBQTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+DQpDYzogdjZvcHNAaWV0Zi5vcmc8bWFp bHRvOnY2b3BzQGlldGYub3JnPjsgdjZvcHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1j aGFpcnNAaWV0Zi5vcmc+OyB2Nm9wcy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWFkc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3Jw0KDQoNCg0KT24gRnJpLCBBdWcgMjUsIDIw MTcgYXQgMzo1MiBQTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t PG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpIaSBEYXZpZCwNCg0K VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIOKAkyBJIGluc2VydGVkIGZvbGxvdy11cHMgYmVsb3cu DQoNCkZyZWQNCg0KDQo+ICAgIEdvb2QgcG9pbnRzLCBidXQgaWYgYW55dGhpbmcgbW9yZSBzaG91 bGQgYmUgc2FpZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBrZXB0IGFzIHRlcnNlDQoNCj4gICAgYXMg cG9zc2libGUuIENhbiB5b3Ugc3VnZ2VzdCBzb21lIHRleHQ/IEFuIGltcG9ydGFudCB0aGluZyB0 byBub3RlIGlzIHRoYXQgdGhlDQoNCj4gICAgUmVkaXJlY3QgaXRzZWxmIGRvZXMgbm90IHJlYWxs eSBnaXZlIHBlcm1pc3Npb24g4oCTIGFsbCBpdCBkb2VzIGlzIHByb3ZpZGVzIHRoZSBzb3VyY2UN Cg0KPiAgICBub2RlIHdpdGggdGhlIGxpbmstbG9jYWwgYW5kIGxpbmstbGF5ZXIgYWRkcmVzc2Vz IG9mIHRoZSB0YXJnZXQgbm9kZS4gSWYgdGhlIHNvdXJjZQ0KDQo+ICAgIG5vZGUgaGFzIHNvbWUg b3RoZXIgd2F5IG9mIGRldGVybWluaW5nIHRob3NlIGFkZHJlc3NlcywgaXQgY2FuIGdvIHBlZXIt dG8tcGVlcg0KDQo+ICAgIHdpdGhvdXQgZXZlbiBuZWVkaW5nIHRvIHJlY2VpdmUgYSBSZWRpcmVj dC4gSW4gdGhhdCBjYXNlLCB0aGUgb25seSB3YXkgdG8gcHJldmVudA0KDQo+ICAgIHBlZXItdG8t cGVlciBpcyB2aWEgTDIgbWVjaGFuaXNtcy4NClllcyBsaW5rLWxvY2FsIGFkZHJlc3NpbmcgaXMg YXZhaWxhYmxlIGZvciBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiBpZiBhbGxvdyBieSB0aGUg c2hhcmVkIG5ldHdvcmssIGhvd2V2ZXIgcmVkaXJlY3RzIGFyZSB0aGUgb25seSBtZWNoYW5pc20g YXZhaWxhYmxlIGZvciBhIG5vZGUgdG8gZGV0ZXJtaW5lIHRoZSBsaW5rLWxheWVyIGFkZHJlc3Mg YXNzb2NpYXRlZCB3aXRoIGFuIElQdjYgYWRkcmVzcyBmcm9tIHdpdGhpbiBvbiBvZiB0aGUgVW5p cXVlIFByZWZpeGVzIGFzIEw9MCwgb3RoZXIgdGhhbiBtYWxpY2lvdXMgYWN0aXZpdHkuICBJZiBM PTAgeW91IGFyZSBub3QgYWxsb3dlZCB0byB1c2UgTkQgdG8gcmVzb2x2ZSB0aGUgbGluay1sYXll ciBhZGRyZXNzLCBhbmQgdGhlIG9ubHkgb3RoZXIgd2F5IGZvciBhIG5vZGUgdG8gbGVhcm4gYSBs aW5rLWxheWVyIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIGFuIElQdjYgYWRkcmVzcyBmcm9tIHRo ZSBVbmlxdWUgUHJlZml4IGlzIGJ5IGEgcmVkaXJlY3QgZnJvbSBhIHJvdXRlci4NCg0KSG93IGFi b3V0IHNvbWV0aGluZyBsaWtlIHRoaXM7DQoNCklmIHRoZSBVRS9zdWJzY3JpYmVyIGRlc2lyZXMg dG8gc2VuZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlciBk ZXZpY2VzIChhc3N1bWluZyBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zIGlzIGVuYWJs ZWQgYW5kIHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQg c2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIsIHVubGVz cyBkZXN0aW5lIHRvIGEgbGluay1sb2NhbCBhZGRyZXNzIG9yIHJlZGlyZWN0ZWQgYnkgdGhlIHJv dXRlci4NCg0KTm90ZTogSWYgdGhlIHNoYXJlZCBuZXR3b3JrIHBlcm1pdHMgcGVlci10by1wZWVy IG9wZXJhdGlvbnMsIGRpcmVjdCBVRS9zdWJzY3JpYmVyIGRldmljZSB0byBkZXZpY2UgY29tbXVu aWNhdGlvbiB3aWxsIGJlIHBvc3NpYmxlIHVzaW5nIGxpbmstbG9jYWwgYWRkcmVzc2luZyBhY3Jv c3MgdGhlIHNoYXJlZCBuZXR3b3JrLiBGdXJ0aGVyLCBpZiB0aGUgcm91dGVyIHByb3ZpZGVzIHJl ZGlyZWN0cywgdGhlbiBkaXJlY3QgVUUvc3Vic2NyaWJlciBkZXZpY2UgdG8gZGV2aWNlIGNvbW11 bmljYXRpb25zIGlzIGFsc28gcG9zc2libGUgdXNpbmcgdGhlIHVuaXF1ZSBJUHY2IHByZWZpeGVz IGFjcm9zcyB0aGUgc2hhcmVkIG5ldHdvcmsuDQpJIHRoaW5rIHRoaXMgYWRkaXRpb24gaXMgaW1w b3J0YW50IGJvdGggaWYgeW91IHdhbnQgdG8gZW5hYmxlIG9yIGRpc2FibGUgZGlyZWN0IGRldmlj ZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMsIGlmIHlvdSB3YW50IHRvIGVuYWJsZSBpdCB0aGlz IHRlbGxzIHlvdSB3aGF0IHlvdSBoYXZlIHRvIGRvLCBhbmQgaWYgeW91IHdhbnQgdG8gZGlzYWJs ZSBpdCwgYW5kIHRoZSBzaGFyZWQgbmV0d29yayBhbGxvd3MgaXQsIHlvdSBhcmUgcmVtaW5kZWQg dG8gZGlzYWJsZSByb3V0ZXIgcmVkaXJlY3RzIGFuZCB0aGF0IHlvdSBuZWVkIHRvIGRvIHNvbWV0 aGluZyBhYm91dCBsaW5rLWxvY2FsLiBJdCBtaWdodCBiZSB3b3J0aCBhZGRpbmcgc29tZXRoaW5n IGFib3V0IHRoaXMgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRvby4gIEZvciBzdXJl IGl0IGJlIHdvcnRoIG5vdGluZyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB0aGF0IGlm IHRoZSBzaGFyZWQgbmV0d29yayBwZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zLCB0aGVu IG1hbGljaW91cyBkaXJlY3QgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyB3b3VsZCBi ZSBwb3NzaWJsZSBldmVuIHdpdGhvdXQgbGluay1sb2NhbCBhZGRyZXNzaW5nIG9yIHJvdXRlciBy ZWRpcmVjdHMuDQoNClRoYW5rcy4NCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJt ZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBU ZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xv Z3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAg ICBQaG9uZTogNjEyLTYyNi0wODE1PHRlbDooNjEyKSUyMDYyNi0wODE1Pg0KTWlubmVhcG9saXMs IE1OIDU1NDE0LTMwMjkgICBDZWxsOiA2MTItODEyLTk5NTI8dGVsOig2MTIpJTIwODEyLTk5NTI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0K LS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEYXZp ZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwl M0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNl cw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVz b3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpN aW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENlbGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== --_000_ed263a8fc90543e3950087c25bfc9184XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubTMy NzY5ODMyNjUwMzEwMDM1MDFnbWFpbC1tLTczNzAwMjgyODIwODk4NDk4NjdnbWFpbC1tLTI0NDc2 NjY5NDg5NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoLCBsaS5tMzI3Njk4MzI2NTAzMTAwMzUwMWdt YWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xp c3RwYXJhZ3JhcGgsIGRpdi5tMzI3Njk4MzI2NTAzMTAwMzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4 OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6bV8zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5 ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGZsaXBwZWQgdGhyb3VnaCB0aGUgZGlzY3Vzc2lvbiB0 aGF0IHRyYW5zcGlyZWQgb3ZlciB0aGUgd2Vla2VuZCwgYnV0IHRoZSB0cmVuZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5vZiB0aGF0IGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgaW1wbHlpbmcgbW9yZSBhbmQg bW9yZSByZXN0cmljdGlvbnMgb24gdGhlIGRvbWFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5vZiBhcHBs aWNhYmlsaXR5LiBUaGVzZSBtZWNoYW5pc21zIHNob3VsZCBiZSBhcHBsaWNhYmxlIG9uIGFueSBs aW5rIHR5cGUsIGFuZCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+anVzdCB0aG9zZSB0aGF0IGVtcGxv eSBWTEFOcyBvciBvdGhlciBMMiBtaXRpZ2F0aW9ucy4gSXQgaXMgbm8gZGlmZmVyZW50IHRoYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UkZDNDg2MSBpbiB0aGF0IHJlZ2FyZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFnYWluLCZuYnNwOyBJIHdvdWxkIG5vdCBiZSBv cHBvc2VkIHRvIGEgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIGluIHRoZSBTZWN1cml0eTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Db25zaWRlcmF0aW9ucyBzZWN0aW9uLiBCdXQsIEkgZGlzYWdyZWUgd2l0 aCB0ZXh0IHRoYXQgd291bGQgdW5uZWNlc3NhcmlseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5yZXN0cmlj dCB0aGUgZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFtt YWlsdG86ZmFybWVyQHVtbi5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3Qg MjgsIDIwMTcgOTo0MCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc7 IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0LTA3JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBNYXJrIGhhcyBiZWVuIHRhbGtpbmcgYWJvdXQgaW4gdGhl IG90aGVyIHRocmVhZCwgaWYgeW91IHVzZSBhbiBMMiBtZWNoYW5pc20gdGhlbiB5b3UgY2FuJ3Qg ZW5zdXJlIHlvdSB3b24ndCBkdXBsaWNhdGVkIGFuIElJRCB3aXRob3V0IGEgTkQgcHJveHkgYWxv bmcgd2l0aCB0aGUgTDIgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U28gSSBoYXZlIHRvIGRpc2FncmVlLCB3ZSBzZWVtIHRvIGhhdmUgc2V2 ZXJhbCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIG9mIHRoZSBjdXJyZW50IHRleHQsIHRvIG1l IHRoYXQgdXN1YWxseSBtZWFucyB3ZSBhcmUgbWlzc2luZyBzb21ldGhpbmcgaW1wb3J0YW50IGlu IHRoZSB0ZXh0LCBhbmQgcGVvcGxlIGFyZSBmaWxsaW5nIGluIHdpdGggdGhlcmUgb3duIGltYWdp bmF0aW9ucywgYW5kIGNvbWluZyB0bw0KIGRpZmZlcmVudCBjb25jbHVzaW9ucy4mbmJzcDsgSSB0 aGluayB0aGVyZSBhcmUgaW1wb3J0YW50IGRldGFpbHMgdGhhdCBuZWVkIG1vcmUgZGlzY3Vzc2lv biBpbiB0aGUgdGV4dCwgbm90IGxlc3MsIG9yIGluIG90aGVyIHdvcmQgSSBjYW4ndCBzdXBwb3J0 IHJlbW92aW5nIHRleHQsIGF0IGxlYXN0IHlldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSdtIHNrZXB0aWNhbCBvZiBMb3Jlbnpv J3MgZGVzY3JpcHRpb24sIHdpdGggbW9yZSBkZXRhaWxzIG9mIGhvdyB5b3UgcHV0IGVhY2ggaG9z dCBpbiBpdHMgb3duIFZMQU4sIEkgY291bGQgc2VlIGhvdyB3aGF0IGhlIGlzIHRhbGtpbmcgYWJv dXQgY291bGQgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U28sIEknZCBsaWtlIHRvIGhlcmUgd2hhdCBtb3JlIGFib3V0IGhvdyB0aGUg YXV0aG9ycyB0aGluayB0aGlzIGlzIHN1cHBvc2UgdG8gd29yay4gJm5ic3A7ICZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBBdWcgMjgsIDIwMTcgYXQgMTA6MzggQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5r Ij5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGlua2luZyBhYm91dCB0aGlzIG1vcmUsIEkg dGhpbmsgdGhlIGRvY3VtZW50IHNob3VsZCBzYXkgKjxiPmxlc3M8L2I+KiB0aGFuIHdoYXQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5pdCBpcyBjdXJyZW50bHkgc2F5aW5nLiBJbiBwYXJ0aWN1bGFyLCBp biBzZWN0aW9uIDIsIHNpbXBseSByZW1vdmUgdGhlIGJ1bGxldDo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg4oCcbyZuYnNwOyBUd28g ZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJv dmlkZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRl IHRocm91Z2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJvdXRlcuKAnTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCwgaW4gU2VjdGlvbiA0LCBzaW1w bHkgcmVtb3ZlIHRoZSBzZW50ZW5jZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg4oCcSWYgdGhlIFVFL3N1YnNjcmliZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZGVzaXJlcyB0byBzZW5kIGFueXRoaW5nIGV4dGVy bmFsIGluY2x1ZGluZyBvdGhlciBVRS9zdWJzY3JpYmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IGRldmljZXMgKGFzc3VtaW5nIGRldmljZSB0byBkZXZpY2UgY29tbXVuaWNhdGlv bnMgaXMgZW5hYmxlZCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgc3VwcG9y dGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0IFNIT1VMRCBzZW5kIHRoaXMgdHJh ZmZpYzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0byB0aGUgRmlyc3QgSG9wIFBy b3ZpZGVyIFJvdXRlci7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGUgb25seSB0aGluZyB0aGF0IGNhbiBwcmV2ZW50IHR3byBzdWJzY3JpYmVyIGRl dmljZXMgZnJvbSBjb21tdW5pY2F0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGlyZWN0bHkgd2l0 aG91dCBnb2luZyB0aHJvdWdoIHRoZSBmaXJzdCBob3Agcm91dGVyIHdvdWxkIGJlIEwyIG1lY2hh bmlzbXMgYnV0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bm90IGFsbCBuZXR3b3JrcyBhcmUgZ29pbmcg dG8gd2FudCB0byBwcmV2ZW50IGRpcmVjdCBjb21tdW5pY2F0aW9ucy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVyZWZvcmUsIGxlYXZpbmcgdGhlc2Ug dHdvIHN0YXRlbWVudHMgaW4gd291bGQgdW5uZWNlc3NhcmlseSByZXN0cmljdCB0aGU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5kb21haW4gb2YgYXBwbGljYWJpbGl0eS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IERhdmlkIEZhcm1lciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpmYXJtZXJAdW1uLmVkdSIgdGFy Z2V0PSJfYmxhbmsiPmZhcm1lckB1bW4uZWR1PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEF1Z3VzdCAyNSwgMjAxNyA4OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVk IEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9 Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0Bp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzp2Nm9wcy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCnY2b3BzLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzp2 Nm9wcy1hZHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wcy1hZHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYt djZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3Jzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDM6 NTIgUE0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRGF2aWQsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz IOKAkyBJIGluc2VydGVkIGZvbGxvdy11cHMgYmVsb3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Im0zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21h aWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R29vZCBw b2ludHMsIGJ1dCBpZiBhbnl0aGluZyBtb3JlIHNob3VsZCBiZSBzYWlkIEkgdGhpbmsgaXQgc2hv dWxkIGJlIGtlcHQgYXMgdGVyc2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTMy NzY5ODMyNjUwMzEwMDM1MDFnbWFpbC1tLTczNzAwMjgyODIwODk4NDk4NjdnbWFpbC1tLTI0NDc2 NjY5NDg5NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcyBwb3NzaWJsZS4gQ2Fu IHlvdSBzdWdnZXN0IHNvbWUgdGV4dD8gQW4gaW1wb3J0YW50IHRoaW5nIHRvIG5vdGUgaXMgdGhh dCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTMyNzY5ODMyNjUwMzEwMDM1 MDFnbWFpbC1tLTczNzAwMjgyODIwODk4NDk4NjdnbWFpbC1tLTI0NDc2NjY5NDg5NzcyNjUyNTBt c29saXN0cGFyYWdyYXBoIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWRpcmVjdCBpdHNlbGYgZG9lcyBub3QgcmVhbGx5 IGdpdmUgcGVybWlzc2lvbiDigJMgYWxsIGl0IGRvZXMgaXMgcHJvdmlkZXMgdGhlIHNvdXJjZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMzI3Njk4MzI2NTAzMTAwMzUwMWdtYWls LW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3Rw YXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPm5vZGUgd2l0aCB0aGUgbGluay1sb2NhbCBhbmQgbGluay1sYXll ciBhZGRyZXNzZXMgb2YgdGhlIHRhcmdldCBub2RlLiBJZiB0aGUgc291cmNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4 MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+bm9kZSBoYXMgc29tZSBvdGhlciB3YXkgb2YgZGV0ZXJtaW5pbmcgdGhvc2UgYWRk cmVzc2VzLCBpdCBjYW4gZ28gcGVlci10by1wZWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21h aWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aG91 dCBldmVuIG5lZWRpbmcgdG8gcmVjZWl2ZSBhIFJlZGlyZWN0LiBJbiB0aGF0IGNhc2UsIHRoZSBv bmx5IHdheSB0byBwcmV2ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0zMjc2 OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2 OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cGVlci10by1wZWVyIGlzIHZp YSBMMiBtZWNoYW5pc21zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlllcyBsaW5rLWxvY2FsIGFkZHJlc3NpbmcgaXMgYXZhaWxhYmxlIGZvciBwZWVyLXRvLXBl ZXIgY29tbXVuaWNhdGlvbiBpZiBhbGxvdyBieSB0aGUgc2hhcmVkIG5ldHdvcmssIGhvd2V2ZXIg cmVkaXJlY3RzIGFyZSB0aGUgb25seSBtZWNoYW5pc20gYXZhaWxhYmxlIGZvciBhIG5vZGUgdG8g ZGV0ZXJtaW5lDQogdGhlIGxpbmstbGF5ZXIgYWRkcmVzcyBhc3NvY2lhdGVkIHdpdGggYW4gSVB2 NiBhZGRyZXNzIGZyb20gd2l0aGluIG9uIG9mIHRoZSBVbmlxdWUgUHJlZml4ZXMgYXMgTD0wLCBv dGhlciB0aGFuIG1hbGljaW91cyBhY3Rpdml0eS4mbmJzcDsgSWYgTD0wIHlvdSBhcmUgbm90IGFs bG93ZWQgdG8gdXNlIE5EIHRvIHJlc29sdmUgdGhlIGxpbmstbGF5ZXIgYWRkcmVzcywgYW5kIHRo ZSBvbmx5IG90aGVyIHdheSBmb3IgYSBub2RlIHRvIGxlYXJuIGEgbGluay1sYXllcg0KIGFkZHJl c3MgYXNzb2NpYXRlZCB3aXRoIGFuIElQdjYgYWRkcmVzcyBmcm9tIHRoZSBVbmlxdWUgUHJlZml4 IGlzIGJ5IGEgcmVkaXJlY3QgZnJvbSBhIHJvdXRlci4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgYWJvdXQg c29tZXRoaW5nIGxpa2UgdGhpczs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JZiB0aGUgVUUv c3Vic2NyaWJlciBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90 aGVyIFVFL3N1YnNjcmliZXIgZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21t dW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwt Yml0DQogc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhvcCBQ cm92aWRlciBSb3V0ZXIsIHVubGVzcyBkZXN0aW5lIHRvIGEgbGluay1sb2NhbCBhZGRyZXNzIG9y IHJlZGlyZWN0ZWQgYnkgdGhlIHJvdXRlci48YnI+DQo8YnI+DQpOb3RlOiBJZiB0aGUgc2hhcmVk IG5ldHdvcmsgcGVybWl0cyBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucywgZGlyZWN0IFVFL3N1YnNj cmliZXIgZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9uIHdpbGwgYmUgcG9zc2libGUgdXNp bmcgbGluay1sb2NhbCBhZGRyZXNzaW5nIGFjcm9zcyB0aGUgc2hhcmVkIG5ldHdvcmsuIEZ1cnRo ZXIsIGlmIHRoZSByb3V0ZXIgcHJvdmlkZXMgcmVkaXJlY3RzLCB0aGVuIGRpcmVjdCBVRS9zdWJz Y3JpYmVyIGRldmljZQ0KIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBhbHNvIHBvc3NpYmxl IHVzaW5nIHRoZSB1bmlxdWUgSVB2NiBwcmVmaXhlcyBhY3Jvc3MgdGhlIHNoYXJlZCBuZXR3b3Jr LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SSB0aGluayB0aGlzIGFkZGl0aW9u IGlzIGltcG9ydGFudCBib3RoIGlmIHlvdSB3YW50IHRvIGVuYWJsZSBvciBkaXNhYmxlIGRpcmVj dCBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zLCBpZiB5b3Ugd2FudCB0byBlbmFibGUg aXQgdGhpcyB0ZWxscw0KIHlvdSB3aGF0IHlvdSBoYXZlIHRvIGRvLCBhbmQgaWYgeW91IHdhbnQg dG8mbmJzcDtkaXNhYmxlJm5ic3A7aXQsIGFuZCB0aGUgc2hhcmVkIG5ldHdvcmsgYWxsb3dzIGl0 LCB5b3UgYXJlIHJlbWluZGVkIHRvIGRpc2FibGUgcm91dGVyIHJlZGlyZWN0cyBhbmQgdGhhdCB5 b3UgbmVlZCB0byBkbyBzb21ldGhpbmcgYWJvdXQgbGluay1sb2NhbC4gSXQgbWlnaHQgYmUgd29y dGggYWRkaW5nIHNvbWV0aGluZyZuYnNwO2Fib3V0IHRoaXMgdG8gdGhlIHNlY3VyaXR5Jm5ic3A7 Y29uc2lkZXJhdGlvbnMNCiB0b28uJm5ic3A7IEZvciBzdXJlIGl0IGJlIHdvcnRoIG5vdGluZyBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB0aGF0IGlmIHRoZSBzaGFyZWQ8L3NwYW4+Jm5i c3A7bmV0d29yayBwZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zLCB0aGVuIG1hbGljaW91 cyZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmRpcmVjdCBkZXZpY2UgdG8gZGV2 aWNlIGNvbW11bmljYXRpb25zIHdvdWxkIGJlIHBvc3NpYmxlIGV2ZW4gd2l0aG91dCBsaW5rLWxv Y2FsDQogYWRkcmVzc2luZyBvciByb3V0ZXIgcmVkaXJlY3RzLjwvc3Bhbj4mbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoYW5rcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj49PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCkRhdmlkIEZhcm1lciZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyA8YSBocmVmPSJt YWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPg0KRW1haWw6ZmFy bWVyQHVtbi5lZHU8L2E+PGJyPg0KTmV0d29ya2luZyAmYW1wOyBUZWxlY29tbXVuaWNhdGlvbiBT ZXJ2aWNlczxicj4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5PGJyPg0KVW5pdmVy c2l0eSBvZiBNaW5uZXNvdGEmbmJzcDsmbmJzcDsgPGJyPg0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBT RSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaG9uZTogPGEgaHJlZj0idGVsOig2MTIpJTIw NjI2LTA4MTUiIHRhcmdldD0iX2JsYW5rIj4NCjYxMi02MjYtMDgxNTwvYT48YnI+DQpNaW5uZWFw b2xpcywgTU4gNTU0MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA8YSBocmVmPSJ0ZWw6KDYxMikl MjA4MTItOTk1MiIgdGFyZ2V0PSJfYmxhbmsiPg0KNjEyLTgxMi05OTUyPC9hPjxicj4NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRv OkVtYWlsJTNBZmFybWVyQHVtbi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1 bW4uZWR1PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmljYXRpb24gU2Vydmlj ZXM8YnI+DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkg b2YgTWlubmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDYxMi02MjYtMDgxNTxicj4NCk1pbm5lYXBv bGlzLCBNTiA1NTQxNC0zMDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDYxMi04MTItOTk1Mjxicj4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ed263a8fc90543e3950087c25bfc9184XCH150608nwnosboeingcom_-- From nobody Mon Aug 28 11:31:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4E126B7E; Mon, 28 Aug 2017 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRee8qPG-lek; Mon, 28 Aug 2017 11:31:11 -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 E1747132153; Mon, 28 Aug 2017 11:31:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7SIV9nc017527; Mon, 28 Aug 2017 11:31:09 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7SIV6Ar017513 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 28 Aug 2017 11:31:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 28 Aug 2017 11:31:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 28 Aug 2017 11:31:05 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKAABmowzA= Date: Mon, 28 Aug 2017 18:31:05 +0000 Message-ID: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_4aeb64fd8f6945868ca2a42312b7e15aXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 18:31:13 -0000 --_000_4aeb64fd8f6945868ca2a42312b7e15aXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGluIGdlbmVyYWwgSSB3b25kZXIgaWYgd2Ugc2hvdWxkIHN0b3AgYW5kIGNvbnNpZGVyIHdo YXQgaXQgaXMgd2UgYXJlIGRvaW5nIGhlcmUuDQpBRkFJQ1QsIHRoZSBCQ1AgdGhpcyBkb2N1bWVu dCBpcyBzZWVraW5nIGlzIHRvIHJlY29tbWVuZCBhIHByYWN0aWNlIHdoZXJlIHJvdXRlcnMNCnNl bmQgdW5pY2FzdCBSQXMgd2l0aCBQSU9zIHdpdGggQT0xIGFuZCBMPTAgd2l0aCBlYWNoIGhvc3Qg cmVjZWl2aW5nIGEgdW5pcXVlIFBJTy4NClRoZXJlIGFyZSBubyBCQ1AgcmVjb21tZW5kYXRpb25z IGZvciBob3N0cyBoZXJlLCBiZWNhdXNlIGhvc3RzIHdpbGwgZG8gd2hhdCB0aGV5DQpoYXZlIGFs d2F5cyBkb25lIGFjY29yZGluZyB0byBSRkM0ODYxIGFuZCBSRkM0ODYyLiBGb3Igc3VyZSwgdGhl IEJDUCBkb2VzIG5vdA0KcHJvdmlkZSBhbnkgd2F5IGZvciBob3N0cyB0byBrbm93IHRoYXQgdGhl IHByZWZpeCBiZWluZyBvZmZlcmVkIGluIHRoZSBSQSBpcyBhDQp1bmlxdWUgcHJlZml4IG9yIGEg c2hhcmVkIHByZWZpeC4gRm9yIHRoYXQsIHdlIHdvdWxkIG5lZWQgc29tZXRoaW5nIHZlcnkgbXVj aA0KbGlrZSB0aGUgUElPLVggZHJhZnQuDQoNClNvLCBJIHNlZSB0aGlzIGJlaW5nIGEgdmVyeSBz aW1wbGUgZG9jdW1lbnQgdGhhdCB3cmFwcyBpdHNlbGYgYXJvdW5kIFJGQzQ4NjEuDQpSRkM0ODYx IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFsc28gYXBwbHkgKGluY2x1ZGluZyBSRkMzNzU2KSBh bmQgdGhpcyBkb2MNCnNob3VsZCBub3QgYmUgaW4gdGhlIGJ1c2luZXNzIG9mIHVubmVjZXNzYXJp bHkgcmVzdHJpY3RpbmcgdGhlIGRvbWFpbiBvZg0KYXBwbGljYWJpbGl0eS4NCg0KVGhhbmtzIC0g RnJlZA0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNClNlbnQ6IE1vbmRheSwgQXVndXN0IDI4LCAyMDE3IDk6 NDYgQU0NClRvOiBEYXZpZCBGYXJtZXIgPGZhcm1lckB1bW4uZWR1Pg0KQ2M6IHY2b3BzQGlldGYu b3JnOyB2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc7IHY2b3BzLWFkc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QtMDcnDQoNCkhpIERhdmlkLA0KDQpJIGZsaXBwZWQgdGhyb3VnaCB0aGUgZGlz Y3Vzc2lvbiB0aGF0IHRyYW5zcGlyZWQgb3ZlciB0aGUgd2Vla2VuZCwgYnV0IHRoZSB0cmVuZA0K b2YgdGhhdCBkaXNjdXNzaW9uIHNlZW1zIHRvIGJlIGltcGx5aW5nIG1vcmUgYW5kIG1vcmUgcmVz dHJpY3Rpb25zIG9uIHRoZSBkb21haW4NCm9mIGFwcGxpY2FiaWxpdHkuIFRoZXNlIG1lY2hhbmlz bXMgc2hvdWxkIGJlIGFwcGxpY2FibGUgb24gYW55IGxpbmsgdHlwZSwgYW5kIG5vdA0KanVzdCB0 aG9zZSB0aGF0IGVtcGxveSBWTEFOcyBvciBvdGhlciBMMiBtaXRpZ2F0aW9ucy4gSXQgaXMgbm8g ZGlmZmVyZW50IHRoYW4NClJGQzQ4NjEgaW4gdGhhdCByZWdhcmQuDQoNCkFnYWluLCAgSSB3b3Vs ZCBub3QgYmUgb3Bwb3NlZCB0byBhIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBpbiB0aGUgU2Vj dXJpdHkNCkNvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEJ1dCwgSSBkaXNhZ3JlZSB3aXRoIHRleHQg dGhhdCB3b3VsZCB1bm5lY2Vzc2FyaWx5DQpyZXN0cmljdCB0aGUgZG9tYWluIG9mIGFwcGxpY2Fi aWxpdHkuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFy bWVyQHVtbi5lZHVdDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyOCwgMjAxNyA5OjQwIEFNDQpUbzog VGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPj4NCkNjOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0 Zi5vcmc+OyB2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWNoYWlyc0BpZXRmLm9y Zz47IHY2b3BzLWFkc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYWRzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDcnDQoNCkFzIE1hcmsgaGFzIGJlZW4gdGFsa2luZyBhYm91dCBpbiB0 aGUgb3RoZXIgdGhyZWFkLCBpZiB5b3UgdXNlIGFuIEwyIG1lY2hhbmlzbSB0aGVuIHlvdSBjYW4n dCBlbnN1cmUgeW91IHdvbid0IGR1cGxpY2F0ZWQgYW4gSUlEIHdpdGhvdXQgYSBORCBwcm94eSBh bG9uZyB3aXRoIHRoZSBMMiBtZWNoYW5pc20uDQoNClNvIEkgaGF2ZSB0byBkaXNhZ3JlZSwgd2Ug c2VlbSB0byBoYXZlIHNldmVyYWwgZGlmZmVyZW50IGludGVycHJldGF0aW9ucyBvZiB0aGUgY3Vy cmVudCB0ZXh0LCB0byBtZSB0aGF0IHVzdWFsbHkgbWVhbnMgd2UgYXJlIG1pc3Npbmcgc29tZXRo aW5nIGltcG9ydGFudCBpbiB0aGUgdGV4dCwgYW5kIHBlb3BsZSBhcmUgZmlsbGluZyBpbiB3aXRo IHRoZXJlIG93biBpbWFnaW5hdGlvbnMsIGFuZCBjb21pbmcgdG8gZGlmZmVyZW50IGNvbmNsdXNp b25zLiAgSSB0aGluayB0aGVyZSBhcmUgaW1wb3J0YW50IGRldGFpbHMgdGhhdCBuZWVkIG1vcmUg ZGlzY3Vzc2lvbiBpbiB0aGUgdGV4dCwgbm90IGxlc3MsIG9yIGluIG90aGVyIHdvcmQgSSBjYW4n dCBzdXBwb3J0IHJlbW92aW5nIHRleHQsIGF0IGxlYXN0IHlldC4NCg0KV2hpbGUgSSdtIHNrZXB0 aWNhbCBvZiBMb3JlbnpvJ3MgZGVzY3JpcHRpb24sIHdpdGggbW9yZSBkZXRhaWxzIG9mIGhvdyB5 b3UgcHV0IGVhY2ggaG9zdCBpbiBpdHMgb3duIFZMQU4sIEkgY291bGQgc2VlIGhvdyB3aGF0IGhl IGlzIHRhbGtpbmcgYWJvdXQgY291bGQgd29yay4NCg0KU28sIEknZCBsaWtlIHRvIGhlcmUgd2hh dCBtb3JlIGFib3V0IGhvdyB0aGUgYXV0aG9ycyB0aGluayB0aGlzIGlzIHN1cHBvc2UgdG8gd29y ay4NCg0KVGhhbmtzDQoNCk9uIE1vbiwgQXVnIDI4LCAyMDE3IGF0IDEwOjM4IEFNLCBUZW1wbGlu LCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+PiB3cm90ZToNCkluIHRoaW5raW5nIGFib3V0IHRoaXMgbW9yZSwgSSB0aGlu ayB0aGUgZG9jdW1lbnQgc2hvdWxkIHNheSAqbGVzcyogdGhhbiB3aGF0DQppdCBpcyBjdXJyZW50 bHkgc2F5aW5nLiBJbiBwYXJ0aWN1bGFyLCBpbiBzZWN0aW9uIDIsIHNpbXBseSByZW1vdmUgdGhl IGJ1bGxldDoNCg0KICAg4oCcbyAgVHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3Ro IGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQogICAgICBtYW5hZ2VkIHNoYXJlZCBuZXR3 b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaA0KICAgICAgdGhl IHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJvdXRlcuKAnQ0KDQphbmQsIGluIFNlY3Rpb24g NCwgc2ltcGx5IHJlbW92ZSB0aGUgc2VudGVuY2U6DQoNCiAgIOKAnElmIHRoZSBVRS9zdWJzY3Jp YmVyDQogICBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVy IFVFL3N1YnNjcmliZXINCiAgIGRldmljZXMgKGFzc3VtaW5nIGRldmljZSB0byBkZXZpY2UgY29t bXVuaWNhdGlvbnMgaXMgZW5hYmxlZCBhbmQNCiAgIHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0 aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMNCiAgIHRvIHRoZSBGaXJz dCBIb3AgUHJvdmlkZXIgUm91dGVyLuKAnQ0KDQpUaGUgb25seSB0aGluZyB0aGF0IGNhbiBwcmV2 ZW50IHR3byBzdWJzY3JpYmVyIGRldmljZXMgZnJvbSBjb21tdW5pY2F0aW5nDQpkaXJlY3RseSB3 aXRob3V0IGdvaW5nIHRocm91Z2ggdGhlIGZpcnN0IGhvcCByb3V0ZXIgd291bGQgYmUgTDIgbWVj aGFuaXNtcyBidXQNCm5vdCBhbGwgbmV0d29ya3MgYXJlIGdvaW5nIHRvIHdhbnQgdG8gcHJldmVu dCBkaXJlY3QgY29tbXVuaWNhdGlvbnMuDQoNClRoZXJlZm9yZSwgbGVhdmluZyB0aGVzZSB0d28g c3RhdGVtZW50cyBpbiB3b3VsZCB1bm5lY2Vzc2FyaWx5IHJlc3RyaWN0IHRoZQ0KZG9tYWluIG9m IGFwcGxpY2FiaWxpdHkuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogRGF2aWQgRmFybWVyIFtt YWlsdG86ZmFybWVyQHVtbi5lZHU8bWFpbHRvOmZhcm1lckB1bW4uZWR1Pl0NClNlbnQ6IEZyaWRh eSwgQXVndXN0IDI1LCAyMDE3IDg6MjggUE0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+Pg0KQ2M6 IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz47IHY2b3BzLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86djZvcHMtY2hhaXJzQGlldGYub3JnPjsgdjZvcHMtYWRzQGlldGYub3JnPG1h aWx0bzp2Nm9wcy1hZHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb21tZW50IG9u ICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNycNCg0KDQoN Ck9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDM6NTIgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdy b3RlOg0KSGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyDigJMgSSBpbnNlcnRl ZCBmb2xsb3ctdXBzIGJlbG93Lg0KDQpGcmVkDQoNCg0KPiAgICBHb29kIHBvaW50cywgYnV0IGlm IGFueXRoaW5nIG1vcmUgc2hvdWxkIGJlIHNhaWQgSSB0aGluayBpdCBzaG91bGQgYmUga2VwdCBh cyB0ZXJzZQ0KDQo+ICAgIGFzIHBvc3NpYmxlLiBDYW4geW91IHN1Z2dlc3Qgc29tZSB0ZXh0PyBB biBpbXBvcnRhbnQgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoZQ0KDQo+ICAgIFJlZGlyZWN0IGl0 c2VsZiBkb2VzIG5vdCByZWFsbHkgZ2l2ZSBwZXJtaXNzaW9uIOKAkyBhbGwgaXQgZG9lcyBpcyBw cm92aWRlcyB0aGUgc291cmNlDQoNCj4gICAgbm9kZSB3aXRoIHRoZSBsaW5rLWxvY2FsIGFuZCBs aW5rLWxheWVyIGFkZHJlc3NlcyBvZiB0aGUgdGFyZ2V0IG5vZGUuIElmIHRoZSBzb3VyY2UNCg0K PiAgICBub2RlIGhhcyBzb21lIG90aGVyIHdheSBvZiBkZXRlcm1pbmluZyB0aG9zZSBhZGRyZXNz ZXMsIGl0IGNhbiBnbyBwZWVyLXRvLXBlZXINCg0KPiAgICB3aXRob3V0IGV2ZW4gbmVlZGluZyB0 byByZWNlaXZlIGEgUmVkaXJlY3QuIEluIHRoYXQgY2FzZSwgdGhlIG9ubHkgd2F5IHRvIHByZXZl bnQNCg0KPiAgICBwZWVyLXRvLXBlZXIgaXMgdmlhIEwyIG1lY2hhbmlzbXMuDQpZZXMgbGluay1s b2NhbCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZSBmb3IgcGVlci10by1wZWVyIGNvbW11bmljYXRp b24gaWYgYWxsb3cgYnkgdGhlIHNoYXJlZCBuZXR3b3JrLCBob3dldmVyIHJlZGlyZWN0cyBhcmUg dGhlIG9ubHkgbWVjaGFuaXNtIGF2YWlsYWJsZSBmb3IgYSBub2RlIHRvIGRldGVybWluZSB0aGUg bGluay1sYXllciBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhbiBJUHY2IGFkZHJlc3MgZnJvbSB3 aXRoaW4gb24gb2YgdGhlIFVuaXF1ZSBQcmVmaXhlcyBhcyBMPTAsIG90aGVyIHRoYW4gbWFsaWNp b3VzIGFjdGl2aXR5LiAgSWYgTD0wIHlvdSBhcmUgbm90IGFsbG93ZWQgdG8gdXNlIE5EIHRvIHJl c29sdmUgdGhlIGxpbmstbGF5ZXIgYWRkcmVzcywgYW5kIHRoZSBvbmx5IG90aGVyIHdheSBmb3Ig YSBub2RlIHRvIGxlYXJuIGEgbGluay1sYXllciBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhbiBJ UHY2IGFkZHJlc3MgZnJvbSB0aGUgVW5pcXVlIFByZWZpeCBpcyBieSBhIHJlZGlyZWN0IGZyb20g YSByb3V0ZXIuDQoNCkhvdyBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOw0KDQpJZiB0aGUgVUUv c3Vic2NyaWJlciBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90 aGVyIFVFL3N1YnNjcmliZXIgZGV2aWNlcyAoYXNzdW1pbmcgZGV2aWNlIHRvIGRldmljZSBjb21t dW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwt Yml0IHNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBGaXJzdCBIb3AgUHJv dmlkZXIgUm91dGVyLCB1bmxlc3MgZGVzdGluZSB0byBhIGxpbmstbG9jYWwgYWRkcmVzcyBvciBy ZWRpcmVjdGVkIGJ5IHRoZSByb3V0ZXIuDQoNCk5vdGU6IElmIHRoZSBzaGFyZWQgbmV0d29yayBw ZXJtaXRzIHBlZXItdG8tcGVlciBvcGVyYXRpb25zLCBkaXJlY3QgVUUvc3Vic2NyaWJlciBkZXZp Y2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb24gd2lsbCBiZSBwb3NzaWJsZSB1c2luZyBsaW5rLWxv Y2FsIGFkZHJlc3NpbmcgYWNyb3NzIHRoZSBzaGFyZWQgbmV0d29yay4gRnVydGhlciwgaWYgdGhl IHJvdXRlciBwcm92aWRlcyByZWRpcmVjdHMsIHRoZW4gZGlyZWN0IFVFL3N1YnNjcmliZXIgZGV2 aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBhbHNvIHBvc3NpYmxlIHVzaW5nIHRoZSB1 bmlxdWUgSVB2NiBwcmVmaXhlcyBhY3Jvc3MgdGhlIHNoYXJlZCBuZXR3b3JrLg0KSSB0aGluayB0 aGlzIGFkZGl0aW9uIGlzIGltcG9ydGFudCBib3RoIGlmIHlvdSB3YW50IHRvIGVuYWJsZSBvciBk aXNhYmxlIGRpcmVjdCBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zLCBpZiB5b3Ugd2Fu dCB0byBlbmFibGUgaXQgdGhpcyB0ZWxscyB5b3Ugd2hhdCB5b3UgaGF2ZSB0byBkbywgYW5kIGlm IHlvdSB3YW50IHRvIGRpc2FibGUgaXQsIGFuZCB0aGUgc2hhcmVkIG5ldHdvcmsgYWxsb3dzIGl0 LCB5b3UgYXJlIHJlbWluZGVkIHRvIGRpc2FibGUgcm91dGVyIHJlZGlyZWN0cyBhbmQgdGhhdCB5 b3UgbmVlZCB0byBkbyBzb21ldGhpbmcgYWJvdXQgbGluay1sb2NhbC4gSXQgbWlnaHQgYmUgd29y dGggYWRkaW5nIHNvbWV0aGluZyBhYm91dCB0aGlzIHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB0b28uICBGb3Igc3VyZSBpdCBiZSB3b3J0aCBub3RpbmcgaW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb24gdGhhdCBpZiB0aGUgc2hhcmVkIG5ldHdvcmsgcGVybWl0cyBwZWVyLXRvLXBl ZXIgb3BlcmF0aW9ucywgdGhlbiBtYWxpY2lvdXMgZGlyZWN0IGRldmljZSB0byBkZXZpY2UgY29t bXVuaWNhdGlvbnMgd291bGQgYmUgcG9zc2libGUgZXZlbiB3aXRob3V0IGxpbmstbG9jYWwgYWRk cmVzc2luZyBvciByb3V0ZXIgcmVkaXJlY3RzLg0KDQpUaGFua3MuDQoNCi0tDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KRGF2aWQgRmFybWVyICAgICAg ICAgICAgICAgRW1haWw6ZmFybWVyQHVtbi5lZHU8bWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5l ZHU+DQpOZXR3b3JraW5nICYgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXMNCk9mZmljZSBvZiBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290YQ0KMjIxOCBVbml2 ZXJzaXR5IEF2ZSBTRSAgICAgICAgUGhvbmU6IDYxMi02MjYtMDgxNTx0ZWw6KDYxMiklMjA2MjYt MDgxNT4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAgQ2VsbDogNjEyLTgxMi05OTUyPHRl bDooNjEyKSUyMDgxMi05OTUyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCg0KDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KRGF2aWQgRmFybWVyICAgICAgICAgICAgICAgRW1haWw6ZmFybWVyQHVt bi5lZHU8bWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHU+DQpOZXR3b3JraW5nICYgVGVsZWNv bW11bmljYXRpb24gU2VydmljZXMNCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpV bml2ZXJzaXR5IG9mIE1pbm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgUGhv bmU6IDYxMi02MjYtMDgxNQ0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkgICBDZWxsOiA2MTIt ODEyLTk5NTINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo= --_000_4aeb64fd8f6945868ca2a42312b7e15aXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubTMy NzY5ODMyNjUwMzEwMDM1MDFnbWFpbC1tLTczNzAwMjgyODIwODk4NDk4NjdnbWFpbC1tLTI0NDc2 NjY5NDg5NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoLCBsaS5tMzI3Njk4MzI2NTAzMTAwMzUwMWdt YWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xp c3RwYXJhZ3JhcGgsIGRpdi5tMzI3Njk4MzI2NTAzMTAwMzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4 OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6bV8zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5 ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp LCBpbiBnZW5lcmFsIEkgd29uZGVyIGlmIHdlIHNob3VsZCBzdG9wIGFuZCBjb25zaWRlciB3aGF0 IGl0IGlzIHdlIGFyZSBkb2luZyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BRkFJQ1QsIHRoZSBC Q1AgdGhpcyBkb2N1bWVudCBpcyBzZWVraW5nIGlzIHRvIHJlY29tbWVuZCBhIHByYWN0aWNlIHdo ZXJlIHJvdXRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c2VuZCB1bmljYXN0IFJBcyB3aXRoIFBJT3Mg d2l0aCBBPTEgYW5kIEw9MCB3aXRoIGVhY2ggaG9zdCByZWNlaXZpbmcgYSB1bmlxdWUgUElPLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGVyZSBhcmUgbm8gQkNQIHJlY29tbWVuZGF0aW9ucyBmb3IgaG9z dHMgaGVyZSwgYmVjYXVzZSBob3N0cyB3aWxsIGRvIHdoYXQgdGhleTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5oYXZlIGFsd2F5cyBkb25lIGFjY29yZGluZyB0byBSRkM0ODYxIGFuZCBSRkM0ODYyLiBGb3Ig c3VyZSwgdGhlIEJDUCBkb2VzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5wcm92aWRlIGFueSB3YXkg Zm9yIGhvc3RzIHRvIGtub3cgdGhhdCB0aGUgcHJlZml4IGJlaW5nIG9mZmVyZWQgaW4gdGhlIFJB IGlzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dW5pcXVlIHByZWZpeCBvciBhIHNoYXJlZCBwcmVmaXgu IEZvciB0aGF0LCB3ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyB2ZXJ5IG11Y2g8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+bGlrZSB0aGUgUElPLVggZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5TbywgSSBzZWUgdGhpcyBiZWluZyBhIHZlcnkgc2ltcGxlIGRvY3VtZW50 IHRoYXQgd3JhcHMgaXRzZWxmIGFyb3VuZCBSRkM0ODYxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SRkM0 ODYxIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFsc28gYXBwbHkgKGluY2x1ZGluZyBSRkMzNzU2 KSBhbmQgdGhpcyBkb2M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c2hvdWxkIG5vdCBiZSBpbiB0aGUgYnVz aW5lc3Mgb2YgdW5uZWNlc3NhcmlseSByZXN0cmljdGluZyB0aGUgZG9tYWluIG9mPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPmFwcGxpY2FiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZW1wbGluLCBGcmVkIEw8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMjgsIDIwMTcgOTo0NiBBTTxicj4NCjxiPlRv OjwvYj4gRGF2aWQgRmFybWVyICZsdDtmYXJtZXJAdW1uLmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+ IHY2b3BzQGlldGYub3JnOyB2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc7IHY2b3BzLWFkc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb21tZW50IG9uICdkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNyc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IGZsaXBwZWQgdGhyb3VnaCB0aGUgZGlzY3Vzc2lvbiB0aGF0IHRyYW5zcGlyZWQgb3ZlciB0aGUg d2Vla2VuZCwgYnV0IHRoZSB0cmVuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5vZiB0aGF0IGRpc2N1c3Np b24gc2VlbXMgdG8gYmUgaW1wbHlpbmcgbW9yZSBhbmQgbW9yZSByZXN0cmljdGlvbnMgb24gdGhl IGRvbWFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5vZiBhcHBsaWNhYmlsaXR5LiBUaGVzZSBtZWNoYW5p c21zIHNob3VsZCBiZSBhcHBsaWNhYmxlIG9uIGFueSBsaW5rIHR5cGUsIGFuZCBub3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+anVzdCB0aG9zZSB0aGF0IGVtcGxveSBWTEFOcyBvciBvdGhlciBMMiBtaXRp Z2F0aW9ucy4gSXQgaXMgbm8gZGlmZmVyZW50IHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UkZDNDg2 MSBpbiB0aGF0IHJlZ2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFnYWluLCZuYnNwOyBJIHdvdWxkIG5vdCBiZSBvcHBvc2VkIHRvIGEgbW9yZSBkZXRhaWxl ZCBkaXNjdXNzaW9uIGluIHRoZSBTZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25zaWRlcmF0 aW9ucyBzZWN0aW9uLiBCdXQsIEkgZGlzYWdyZWUgd2l0aCB0ZXh0IHRoYXQgd291bGQgdW5uZWNl c3NhcmlseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5yZXN0cmljdCB0aGUgZG9tYWluIG9mIGFwcGxpY2Fi aWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg LSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFs8YSBocmVmPSJtYWlsdG86ZmFybWVyQHVt bi5lZHUiPm1haWx0bzpmYXJtZXJAdW1uLmVkdTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBBdWd1c3QgMjgsIDIwMTcgOTo0MCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJl ZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnY2 b3BzLWNoYWlyc0BpZXRmLm9yZyI+DQp2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86djZvcHMtYWRzQGlldGYub3JnIj52Nm9wcy1hZHNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBNYXJrIGhhcyBiZWVuIHRhbGtpbmcgYWJv dXQgaW4gdGhlIG90aGVyIHRocmVhZCwgaWYgeW91IHVzZSBhbiBMMiBtZWNoYW5pc20gdGhlbiB5 b3UgY2FuJ3QgZW5zdXJlIHlvdSB3b24ndCBkdXBsaWNhdGVkIGFuIElJRCB3aXRob3V0IGEgTkQg cHJveHkgYWxvbmcgd2l0aCB0aGUgTDIgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSBoYXZlIHRvIGRpc2FncmVlLCB3ZSBzZWVtIHRv IGhhdmUgc2V2ZXJhbCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIG9mIHRoZSBjdXJyZW50IHRl eHQsIHRvIG1lIHRoYXQgdXN1YWxseSBtZWFucyB3ZSBhcmUgbWlzc2luZyBzb21ldGhpbmcgaW1w b3J0YW50IGluIHRoZSB0ZXh0LCBhbmQgcGVvcGxlIGFyZSBmaWxsaW5nIGluIHdpdGggdGhlcmUg b3duIGltYWdpbmF0aW9ucywgYW5kIGNvbWluZyB0bw0KIGRpZmZlcmVudCBjb25jbHVzaW9ucy4m bmJzcDsgSSB0aGluayB0aGVyZSBhcmUgaW1wb3J0YW50IGRldGFpbHMgdGhhdCBuZWVkIG1vcmUg ZGlzY3Vzc2lvbiBpbiB0aGUgdGV4dCwgbm90IGxlc3MsIG9yIGluIG90aGVyIHdvcmQgSSBjYW4n dCBzdXBwb3J0IHJlbW92aW5nIHRleHQsIGF0IGxlYXN0IHlldC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSdtIHNrZXB0aWNhbCBv ZiBMb3JlbnpvJ3MgZGVzY3JpcHRpb24sIHdpdGggbW9yZSBkZXRhaWxzIG9mIGhvdyB5b3UgcHV0 IGVhY2ggaG9zdCBpbiBpdHMgb3duIFZMQU4sIEkgY291bGQgc2VlIGhvdyB3aGF0IGhlIGlzIHRh bGtpbmcgYWJvdXQgY291bGQgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIEknZCBsaWtlIHRvIGhlcmUgd2hhdCBtb3JlIGFib3V0 IGhvdyB0aGUgYXV0aG9ycyB0aGluayB0aGlzIGlzIHN1cHBvc2UgdG8gd29yay4gJm5ic3A7ICZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgMjgsIDIwMTcgYXQgMTA6MzggQU0sIFRlbXBsaW4sIEZy ZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdl dD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBtb3JlLCBJIHRoaW5rIHRoZSBk b2N1bWVudCBzaG91bGQgc2F5ICo8Yj5sZXNzPC9iPiogdGhhbiB3aGF0PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+aXQgaXMgY3VycmVudGx5IHNheWluZy4gSW4gcGFydGljdWxhciwgaW4gc2VjdGlvbiAy LCBzaW1wbHkgcmVtb3ZlIHRoZSBidWxsZXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnG8mbmJzcDsgVHdvIGRldmljZXMgKHN1 YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmFnZWQgc2hh cmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBwcm92 aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXLigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQsIGluIFNlY3Rpb24gNCwgc2ltcGx5IHJlbW92ZSB0 aGUgc2VudGVuY2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7IOKAnElmIHRoZSBVRS9zdWJzY3JpYmVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7IGRlc2lyZXMgdG8gc2VuZCBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRp bmcgb3RoZXIgVUUvc3Vic2NyaWJlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBk ZXZpY2VzIChhc3N1bWluZyBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zIGlzIGVuYWJs ZWQgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCksIHRoZW4s IGR1ZSB0byB0aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0 ZXIu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl IG9ubHkgdGhpbmcgdGhhdCBjYW4gcHJldmVudCB0d28gc3Vic2NyaWJlciBkZXZpY2VzIGZyb20g Y29tbXVuaWNhdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmRpcmVjdGx5IHdpdGhvdXQgZ29pbmcg dGhyb3VnaCB0aGUgZmlyc3QgaG9wIHJvdXRlciB3b3VsZCBiZSBMMiBtZWNoYW5pc21zIGJ1dDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPm5vdCBhbGwgbmV0d29ya3MgYXJlIGdvaW5nIHRvIHdhbnQgdG8g cHJldmVudCBkaXJlY3QgY29tbXVuaWNhdGlvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmVmb3JlLCBsZWF2aW5nIHRoZXNlIHR3byBzdGF0ZW1l bnRzIGluIHdvdWxkIHVubmVjZXNzYXJpbHkgcmVzdHJpY3QgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+ZG9tYWluIG9mIGFwcGxpY2FiaWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEYXZpZCBGYXJt ZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFybWVyQHVtbi5lZHUiIHRhcmdldD0iX2JsYW5r Ij5mYXJtZXJAdW1uLmVkdTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3Qg MjUsIDIwMTcgODoyOCBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBo cmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86djZvcHMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQp2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86djZvcHMtYWRzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHMtYWRzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBDb21tZW50IG9uICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1 ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNyc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEF1ZyAyNSwgMjAxNyBhdCAzOjUyIFBNLCBUZW1w bGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t IiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cyDigJMgSSBpbnNl cnRlZCBmb2xsb3ctdXBzIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJtMzI3 Njk4MzI2NTAzMTAwMzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2 Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnRzLCBidXQg aWYgYW55dGhpbmcgbW9yZSBzaG91bGQgYmUgc2FpZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBrZXB0 IGFzIHRlcnNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0zMjc2OTgzMjY1MDMx MDAzNTAxZ21haWwtbS03MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1 MjUwbXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YXMgcG9zc2libGUuIENhbiB5b3Ugc3VnZ2Vz dCBzb21lIHRleHQ/IEFuIGltcG9ydGFudCB0aGluZyB0byBub3RlIGlzIHRoYXQgdGhlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0zMjc2OTgzMjY1MDMxMDAzNTAxZ21haWwtbS03 MzcwMDI4MjgyMDg5ODQ5ODY3Z21haWwtbS0yNDQ3NjY2OTQ4OTc3MjY1MjUwbXNvbGlzdHBhcmFn cmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UmVkaXJlY3QgaXRzZWxmIGRvZXMgbm90IHJlYWxseSBnaXZlIHBlcm1p c3Npb24g4oCTIGFsbCBpdCBkb2VzIGlzIHByb3ZpZGVzIHRoZSBzb3VyY2U8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTMyNzY5ODMyNjUwMzEwMDM1MDFnbWFpbC1tLTczNzAwMjgy ODIwODk4NDk4NjdnbWFpbC1tLTI0NDc2NjY5NDg5NzcyNjUyNTBtc29saXN0cGFyYWdyYXBoIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5ub2RlIHdpdGggdGhlIGxpbmstbG9jYWwgYW5kIGxpbmstbGF5ZXIgYWRkcmVzc2Vz IG9mIHRoZSB0YXJnZXQgbm9kZS4gSWYgdGhlIHNvdXJjZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMzI3Njk4MzI2NTAzMTAwMzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2 N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0Qi PsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5v ZGUgaGFzIHNvbWUgb3RoZXIgd2F5IG9mIGRldGVybWluaW5nIHRob3NlIGFkZHJlc3NlcywgaXQg Y2FuIGdvIHBlZXItdG8tcGVlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMzI3 Njk4MzI2NTAzMTAwMzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2 Njk0ODk3NzI2NTI1MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndpdGhvdXQgZXZlbiBuZWVk aW5nIHRvIHJlY2VpdmUgYSBSZWRpcmVjdC4gSW4gdGhhdCBjYXNlLCB0aGUgb25seSB3YXkgdG8g cHJldmVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMzI3Njk4MzI2NTAzMTAw MzUwMWdtYWlsLW0tNzM3MDAyODI4MjA4OTg0OTg2N2dtYWlsLW0tMjQ0NzY2Njk0ODk3NzI2NTI1 MG1zb2xpc3RwYXJhZ3JhcGgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnBlZXItdG8tcGVlciBpcyB2aWEgTDIgbWVjaGFu aXNtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMgbGlu ay1sb2NhbCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZSBmb3IgcGVlci10by1wZWVyIGNvbW11bmlj YXRpb24gaWYgYWxsb3cgYnkgdGhlIHNoYXJlZCBuZXR3b3JrLCBob3dldmVyIHJlZGlyZWN0cyBh cmUgdGhlIG9ubHkgbWVjaGFuaXNtIGF2YWlsYWJsZSBmb3IgYSBub2RlIHRvIGRldGVybWluZQ0K IHRoZSBsaW5rLWxheWVyIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIGFuIElQdjYgYWRkcmVzcyBm cm9tIHdpdGhpbiBvbiBvZiB0aGUgVW5pcXVlIFByZWZpeGVzIGFzIEw9MCwgb3RoZXIgdGhhbiBt YWxpY2lvdXMgYWN0aXZpdHkuJm5ic3A7IElmIEw9MCB5b3UgYXJlIG5vdCBhbGxvd2VkIHRvIHVz ZSBORCB0byByZXNvbHZlIHRoZSBsaW5rLWxheWVyIGFkZHJlc3MsIGFuZCB0aGUgb25seSBvdGhl ciB3YXkgZm9yIGEgbm9kZSB0byBsZWFybiBhIGxpbmstbGF5ZXINCiBhZGRyZXNzIGFzc29jaWF0 ZWQgd2l0aCBhbiBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgVW5pcXVlIFByZWZpeCBpcyBieSBhIHJl ZGlyZWN0IGZyb20gYSByb3V0ZXIuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93IGFib3V0IHNvbWV0aGluZyBs aWtlIHRoaXM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgdGhlIFVFL3N1YnNjcmliZXIg ZGVzaXJlcyB0byBzZW5kIGFueXRoaW5nIGV4dGVybmFsIGluY2x1ZGluZyBvdGhlciBVRS9zdWJz Y3JpYmVyIGRldmljZXMgKGFzc3VtaW5nIGRldmljZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMg aXMgZW5hYmxlZCBhbmQgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdA0KIHNldCwg aXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBGaXJzdCBIb3AgUHJvdmlkZXIgUm91 dGVyLCB1bmxlc3MgZGVzdGluZSB0byBhIGxpbmstbG9jYWwgYWRkcmVzcyBvciByZWRpcmVjdGVk IGJ5IHRoZSByb3V0ZXIuPGJyPg0KPGJyPg0KTm90ZTogSWYgdGhlIHNoYXJlZCBuZXR3b3JrIHBl cm1pdHMgcGVlci10by1wZWVyIG9wZXJhdGlvbnMsIGRpcmVjdCBVRS9zdWJzY3JpYmVyIGRldmlj ZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbiB3aWxsIGJlIHBvc3NpYmxlIHVzaW5nIGxpbmstbG9j YWwgYWRkcmVzc2luZyBhY3Jvc3MgdGhlIHNoYXJlZCBuZXR3b3JrLiBGdXJ0aGVyLCBpZiB0aGUg cm91dGVyIHByb3ZpZGVzIHJlZGlyZWN0cywgdGhlbiBkaXJlY3QgVUUvc3Vic2NyaWJlciBkZXZp Y2UNCiB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMgaXMgYWxzbyBwb3NzaWJsZSB1c2luZyB0aGUg dW5pcXVlIElQdjYgcHJlZml4ZXMgYWNyb3NzIHRoZSBzaGFyZWQgbmV0d29yay48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPkkgdGhpbmsgdGhpcyBhZGRpdGlvbiBpcyBpbXBvcnRh bnQgYm90aCBpZiB5b3Ugd2FudCB0byBlbmFibGUgb3IgZGlzYWJsZSBkaXJlY3QgZGV2aWNlIHRv IGRldmljZSBjb21tdW5pY2F0aW9ucywgaWYgeW91IHdhbnQgdG8gZW5hYmxlIGl0IHRoaXMgdGVs bHMNCiB5b3Ugd2hhdCB5b3UgaGF2ZSB0byBkbywgYW5kIGlmIHlvdSB3YW50IHRvJm5ic3A7ZGlz YWJsZSZuYnNwO2l0LCBhbmQgdGhlIHNoYXJlZCBuZXR3b3JrIGFsbG93cyBpdCwgeW91IGFyZSBy ZW1pbmRlZCB0byBkaXNhYmxlIHJvdXRlciByZWRpcmVjdHMgYW5kIHRoYXQgeW91IG5lZWQgdG8g ZG8gc29tZXRoaW5nIGFib3V0IGxpbmstbG9jYWwuIEl0IG1pZ2h0IGJlIHdvcnRoIGFkZGluZyBz b21ldGhpbmcmbmJzcDthYm91dCB0aGlzIHRvIHRoZSBzZWN1cml0eSZuYnNwO2NvbnNpZGVyYXRp b25zDQogdG9vLiZuYnNwOyBGb3Igc3VyZSBpdCBiZSB3b3J0aCBub3RpbmcgaW4gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gdGhhdCBpZiB0aGUgc2hhcmVkPC9zcGFuPiZuYnNwO25ldHdvcmsg cGVybWl0cyBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucywgdGhlbiBtYWxpY2lvdXMmbmJzcDs8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5kaXJlY3QgZGV2aWNlIHRvIGRldmljZSBjb21tdW5p Y2F0aW9ucyB3b3VsZCBiZSBwb3NzaWJsZSBldmVuIHdpdGhvdXQgbGluay1sb2NhbA0KIGFkZHJl c3Npbmcgb3Igcm91dGVyIHJlZGlyZWN0cy48L3NwYW4+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij5UaGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWls JTNBZmFybWVyQHVtbi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1 PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+ DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlu bmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDxhIGhyZWY9InRlbDooNjEyKSUyMDYyNi0wODE1IiB0 YXJnZXQ9Il9ibGFuayI+DQo2MTItNjI2LTA4MTU8L2E+PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1 NDE0LTMwMjkmbmJzcDsmbmJzcDsgQ2VsbDogPGEgaHJlZj0idGVsOig2MTIpJTIwODEyLTk5NTIi IHRhcmdldD0iX2JsYW5rIj4NCjYxMi04MTItOTk1MjwvYT48YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUzQWZh cm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48 YnI+DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyPg0KT2Zm aWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290 YSZuYnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBob25lOiA2MTItNjI2LTA4MTU8YnI+DQpNaW5uZWFwb2xpcywgTU4gNTU0 MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA2MTItODEyLTk5NTI8YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4aeb64fd8f6945868ca2a42312b7e15aXCH150608nwnosboeingcom_-- From nobody Mon Aug 28 13:34:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C05132964 for ; Mon, 28 Aug 2017 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 C2zYBtLIn4XM for ; Mon, 28 Aug 2017 13:34:22 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11BC13295E for ; Mon, 28 Aug 2017 13:34:21 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id g13so4316331pfm.2 for ; Mon, 28 Aug 2017 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T0cq7uv9qFwNfGYc+rkgq/A6NADz2Mul6MzhI8fGq3Y=; b=vE/xGC8kuCyxDFkXMBmZr8wiNeRAwozTI2cfRAWsxLL0Zj1JdUQ5wmSO1gP8qwWWUP KhfLdG066vnQrDO/6aoknPFoqAQ/iFzcG42faKY2GgWwB13bCmOGffgAYQrCT2bmUKW0 HhWrZBBBU1nJSq4U2ThqX3WPRKQQ3gWOyRroeL3mK9eO0r2SHOVgJQ/UxtWLQIP+lSFd B1SMBLJiAZV8J6rkTfsoSJdZKJisoanLg6FXisWOtT6sCXMvRqUZTBiiL7Jmk8fR9bL2 wNR2KAcfyzwdxTwmdizIJSrPxVcJ/orYJzgk6Wnvp1UVfVnexmh58vDO5OhdVOxPNdt5 2Plw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=T0cq7uv9qFwNfGYc+rkgq/A6NADz2Mul6MzhI8fGq3Y=; b=O113iHGaRZa3rwAreYrDa+VEqGKlPTn2ycTSPSuXwJ+XsBkmGhi8jgYOdTacaRSLDB biLdtFv7wfcMIJYrDePKYEqg26t9NpMPpIAYjVBaEhXR2niNUs1c+uN4L1AkxlapTp82 y0ENi5+1LPmnf5swsYGmRdEWYNfWsc34lcl+Yn1ZdeDBxS8jIpV6TmtAMz9iAPkUZdMg A460lluPGjkB7gg+w5PZyIQwXIfnepu+Rq8FVlVQx8zfFLN2JGAHO7I+C3lXS8E/+9JF Uvq96L52qObpVdldFVLF/iN2J7zSBRsxLcJnQssWfqD9LH9HUfqlLbYo//fJWumFJi9J ycgg== X-Gm-Message-State: AHYfb5ikRjIQWvPGZWwIwIbviIoVIcBerK9qk3HFcV3atw+GcZQIiC/I gaLrU60P7sE2f+v3 X-Received: by 10.98.77.70 with SMTP id a67mr1632868pfb.343.1503952461202; Mon, 28 Aug 2017 13:34:21 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d184sm1879862pfa.9.2017.08.28.13.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 13:34:20 -0700 (PDT) To: Lorenzo Colitti , Mark Smith Cc: james woodyatt , v6ops list References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 29 Aug 2017 08:34:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 20:34:24 -0000 On 28/08/2017 17:54, Lorenzo Colitti wrote: > On Mon, Aug 28, 2017 at 2:48 PM, Mark Smith wrote: > >> Would a BCP saying IPv6 SHOULD NOT be implemented over Private VLANs >> and similar be the better answer for these reasons? Unfortunately I >> don't think that is going to stop people trying to do so. >> > > It's definitely a good idea to document these problems, at least. > > >>> A vastly superior alternative is to assign each host its own prefix, and >>> make the link between the host and the router unnumbered. >> >> No such thing as an unnumbered link, there's always a link-local >> prefix, per RFC4291's required interface addresses, so the above >> issues will still exist for the attached host's LL addresses. >> >> There's no escaping these issues and the state to emulate them unless >> links are truly point-to-point links between the router and the >> host(/cpe) with individual links having their own subnet prefix, or >> multi-access links have full any-to-any connectivity. >> > > Agreed. What I meant was that the hosts should be isolated at layer 2 as > well. The links that I am suggesting be unnumbered (i.e., link-local only) > are the links between the host and the router; where there is one such link > per host. That sounds about right. Whatever the electrical connection might be, there is a virtual point-to-point link between each host and the router. The other nodes are not neighbours in any way that IPv6 can recognise. The only link-local neighbour is the router. ND to ff02::1 won't reach the other hosts, so the router had better not send a PIO with an L flag. The nodes will all listen to ff02::1 anyway. But the RAs need to be tailored so that each host only hears about the prefix(es) that are relevant to it. Each host is in its own separate world. The router needs to keep track of them, but it can't treat them as a bunch of hosts on the same LAN, because they aren't. However it keeps track of them, it is not a normal neighbour cache for a LAN interface. The hosts may well issue MLDv2 joins, but that's going to be a no-op for LL multicast, because the router isn't going to replicate LL multicast packets anyway. Brian From nobody Tue Aug 29 11:25:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354B0132351 for ; Tue, 29 Aug 2017 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_aRrNgE2q_K for ; Tue, 29 Aug 2017 11:25:47 -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 BF2221321AF for ; Tue, 29 Aug 2017 11:25:47 -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 v7TIPkqO037737; Tue, 29 Aug 2017 11:25:47 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7TIPZXV037557 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 29 Aug 2017 11:25:36 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 29 Aug 2017 11:25:35 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 29 Aug 2017 11:25:35 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMg== Date: Tue, 29 Aug 2017 18:25:35 +0000 Message-ID: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:25:49 -0000 Hi, it seems like recent works and discussions have postulated a means for = delegating IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there really = isn't any L3 protocol defined for clients to control their prefix delegations using R= S/RA whereas DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebind, = Release). So, for clients to control and manage their prefix delegations it seems lik= e DHCPv6 gives the clients the most flexibility and control in terms of L3 messaging= , whereas for RS/RA there would need to be either a new L3 protocol or some form of a= djunct L2 messaging. What am I missing? Thanks - Fred From nobody Tue Aug 29 12:39:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3CD1321D8 for ; Tue, 29 Aug 2017 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhJH_IagD58B for ; Tue, 29 Aug 2017 12:39:47 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30A1252BA for ; Tue, 29 Aug 2017 12:39:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EE1E3AF; Tue, 29 Aug 2017 21:39:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504035583; bh=hT3p9ZO2kA6EZ9U7cx5HWuHDBgvHIjvsV5Dk2OdJ030=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=jUpRFw60oglGnv4LYKu8Mxb1SMz8/4wr5iT0K7IS6KPS7BA1U+V+v+6UG1Nny8kF0 yBzzU1L9KX+roaSCaf7KFdUN2qMg5vCSNwy2t5KPmawLPKjy+DMAl5p8fnyk8VrMvh LheswnQVyOQaZHBUTivUtcohTSrP7DtqFJag3urg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EB75E84; Tue, 29 Aug 2017 21:39:43 +0200 (CEST) Date: Tue, 29 Aug 2017 21:39:43 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: "v6ops@ietf.org" In-Reply-To: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:39:49 -0000 On Tue, 29 Aug 2017, Templin, Fred L wrote: > Hi, it seems like recent works and discussions have postulated a means for delegating > IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there really isn't any > L3 protocol defined for clients to control their prefix delegations using RS/RA whereas > DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebind, Release). > > So, for clients to control and manage their prefix delegations it seems like DHCPv6 > gives the clients the most flexibility and control in terms of L3 messaging, whereas > for RS/RA there would need to be either a new L3 protocol or some form of adjunct > L2 messaging. What am I missing? DHCP is fundamentally a polling protocol and if a lease has been handed out, it's not yours and you can keep it until it times out. I would like us to find a solution where the network can revoke a resource it has "leased". Right now we don't have a full solution for this. DHCPv6 and RS/RA are basically ships in the night and it's not clear how messages sent using one protocol, would affect the other. A minimum would be some kind of coupling between a DHCPv6 relay router and what it puts in the RA and how this affects the DHCPv6 information. Perferrably I'd like to be able to do everything without DHCPv6 at all. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 29 13:00:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A28132A89 for ; Tue, 29 Aug 2017 13:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZuDaJLlHs4m for ; Tue, 29 Aug 2017 13:00:25 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E7F1321B0 for ; Tue, 29 Aug 2017 13:00:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7TK0ONR032718; Tue, 29 Aug 2017 13:00:24 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7TK0Opo032704 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 13:00:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 29 Aug 2017 13:00:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 29 Aug 2017 13:00:23 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgARjqyAAA5VXnA= Date: Tue, 29 Aug 2017 20:00:23 +0000 Message-ID: <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:00:27 -0000 Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, August 29, 2017 12:40 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >=20 > On Tue, 29 Aug 2017, Templin, Fred L wrote: >=20 > > Hi, it seems like recent works and discussions have postulated a means = for delegating > > IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there rea= lly isn't any > > L3 protocol defined for clients to control their prefix delegations usi= ng RS/RA whereas > > DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebi= nd, Release). > > > > So, for clients to control and manage their prefix delegations it seems= like DHCPv6 > > gives the clients the most flexibility and control in terms of L3 messa= ging, whereas > > for RS/RA there would need to be either a new L3 protocol or some form = of adjunct > > L2 messaging. What am I missing? >=20 > DHCP is fundamentally a polling protocol and if a lease has been handed > out, it's not yours and you can keep it until it times out. In DHCPv6, the client is responsible for reliability. It asks the server fo= r a PD and keeps asking until it gets a Reply. The client is also responsible for = managing its own leases and renewing them before they time out. > I would like us to find a solution where the network can revoke a > resource it has "leased". Right now we don't have a full solution for > this. DHCPv6 Reconfigure (the fifth "R"). > DHCPv6 and RS/RA are basically ships in the night and it's not clear > how messages sent using one protocol, would affect the other. A minimum > would be some kind of coupling between a DHCPv6 relay router and what it > puts in the RA and how this affects the DHCPv6 information. >=20 > Perferrably I'd like to be able to do everything without DHCPv6 at all. In DHCPv6, the PD activity is client-directed. In the RS/RA based schemes, the PD activity is network-directed. That is a marked difference and needs to be examined according to the use cases.=20 Thanks - Fred fred.l.templin@boeing.com > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 29 13:14:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE8132D85 for ; Tue, 29 Aug 2017 13:14:11 -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 KzTl55RB_v4X for ; Tue, 29 Aug 2017 13:14:10 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11117132D8C for ; Tue, 29 Aug 2017 13:14:10 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id r133so13772108pgr.3 for ; Tue, 29 Aug 2017 13:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hFP0Bpe0z2iYuofCVb1LNMoFyAPPSNRyC62370FlQNo=; b=N8o31QuD+Clo83h0J4t4ZlVeECEzRLuWDG+stB+2zIlKgi4iT0/OInqE3QNIx7L789 b4PdYuE5K+DMhRda03EEw6HSqRL38D/zUNo1UACPsHYlYJvOzgQD8b/8uzyCeb2MEYJl Btr1KhXiPwuPObm6Az+jQij9rRwsjJMgJSzKwGNK7bSa08wzHaMy85N4vuB37nvrBmSh jkauvPdwp2Vt8CJl6CiiQd6thS9vXl4+y9hE639mSvrnoQ8DwApjReO89ygisAfUzfgE /PUw694RLjrio36o4lhaI31IlT3Qx8RdOZdkES/usVbuEvri8IUZRHJ9iUx4SSOTtK9e SpBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hFP0Bpe0z2iYuofCVb1LNMoFyAPPSNRyC62370FlQNo=; b=BccBRX1FbQdIBi/YmTZ5C/GMoy7FsZ8E612+p8F/+va/T61b7VrwY5iIrj5QlqumF9 Qa+asZ/75Sc3JtmWEY2ulkH4s2nZDCYu7AO3ie+NXznRnmgJGNMqxO62VPo2RrzY4ifV M8v64qjBRF5G51m8EkUmcsBthJrtzgD8GNGNB+s2Kder2kWq34Hw9g9V3B7vjPDR8rk4 7n0dg2h7gkRItOr89GgisQSzjXgbbXe/m1VdNK8AL3eRN1LuVfQcNOLIislC6aqwcq7o hm5526nO7a/+oNuSiIIgZ3fTnfsAQaqRdIquaWGUwH9F8vvg2pdNnev1r8aEmIvH+lKs mNCA== X-Gm-Message-State: AHYfb5hKx51HSMc+HAaknaFLuwCiARLnJQi8gxRaOlDENLVA4PRgDR6E KffmMjgBneVt7xhU X-Received: by 10.84.234.16 with SMTP id m16mr1829756plk.389.1504037649225; Tue, 29 Aug 2017 13:14:09 -0700 (PDT) Received: from ?IPv6:2406:e007:560e:1:28cc:dc4c:9703:6781? ([2406:e007:560e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e188sm6027248pgc.17.2017.08.29.13.14.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 13:14:08 -0700 (PDT) To: "Templin, Fred L" , Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 30 Aug 2017 08:14:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:14:12 -0000 On 30/08/2017 08:00, Templin, Fred L wrote: > Hi Mikael, > >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >> Sent: Tuesday, August 29, 2017 12:40 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >> >> On Tue, 29 Aug 2017, Templin, Fred L wrote: >> >>> Hi, it seems like recent works and discussions have postulated a means for delegating >>> IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there really isn't any >>> L3 protocol defined for clients to control their prefix delegations using RS/RA whereas >>> DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebind, Release). >>> >>> So, for clients to control and manage their prefix delegations it seems like DHCPv6 >>> gives the clients the most flexibility and control in terms of L3 messaging, whereas >>> for RS/RA there would need to be either a new L3 protocol or some form of adjunct >>> L2 messaging. What am I missing? >> >> DHCP is fundamentally a polling protocol and if a lease has been handed >> out, it's not yours and you can keep it until it times out. > > In DHCPv6, the client is responsible for reliability. It asks the server for a PD > and keeps asking until it gets a Reply. The client is also responsible for managing > its own leases and renewing them before they time out. > >> I would like us to find a solution where the network can revoke a >> resource it has "leased". Right now we don't have a full solution for >> this. > > DHCPv6 Reconfigure (the fifth "R"). > >> DHCPv6 and RS/RA are basically ships in the night and it's not clear >> how messages sent using one protocol, would affect the other. A minimum >> would be some kind of coupling between a DHCPv6 relay router and what it >> puts in the RA and how this affects the DHCPv6 information. >> >> Perferrably I'd like to be able to do everything without DHCPv6 at all. > > In DHCPv6, the PD activity is client-directed. In the RS/RA based schemes, > the PD activity is network-directed. That is a marked difference and needs > to be examined according to the use cases. Shouldn't you add HNCP to this discussion? Or even draft-ietf-anima-prefix-management, at a stretch. In any case, there are many ways to tackle this topic. Brian Brian From nobody Tue Aug 29 14:57:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FA126DD9 for ; Tue, 29 Aug 2017 14:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RoLzfP8nxth for ; Tue, 29 Aug 2017 14:56:54 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6E11321B9 for ; Tue, 29 Aug 2017 14:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7TLuqsh020220; Tue, 29 Aug 2017 14:56:53 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7TLukvc019655 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 14:56:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 29 Aug 2017 14:56:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 29 Aug 2017 14:56:45 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Mikael Abrahamsson CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgARjqyAAA5VXnD//5byAIAAWYhw Date: Tue, 29 Aug 2017 21:56:45 +0000 Message-ID: <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:56:56 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIEF1Z3VzdCAyOSwgMjAxNyAxOjE0IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBz d20ucHAuc2U+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQ cmVmaXggRGVsZWdhdGlvbiBSUy9SQSB2cyBESENQdjYNCj4gDQo+IE9uIDMwLzA4LzIwMTcgMDg6 MDAsIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBIaSBNaWthZWwsDQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTWlrYWVsIEFicmFoYW1zc29uIFtt YWlsdG86c3dtaWtlQHN3bS5wcC5zZV0NCj4gPj4gU2VudDogVHVlc2RheSwgQXVndXN0IDI5LCAy MDE3IDEyOjQwIFBNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQo+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBQcmVmaXggRGVsZWdhdGlvbiBSUy9SQSB2cyBESENQdjYNCj4gPj4NCj4gPj4gT24gVHVl LCAyOSBBdWcgMjAxNywgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSGksIGl0 IHNlZW1zIGxpa2UgcmVjZW50IHdvcmtzIGFuZCBkaXNjdXNzaW9ucyBoYXZlIHBvc3R1bGF0ZWQg YSBtZWFucyBmb3IgZGVsZWdhdGluZw0KPiA+Pj4gSVB2NiBwcmVmaXhlcyB0byBub2RlcyB1c2lu ZyBSUy9SQSBpbnN0ZWFkIG9mIERIQ1B2NiBQRC4gQnV0LCB0aGVyZSByZWFsbHkgaXNuJ3QgYW55 DQo+ID4+PiBMMyBwcm90b2NvbCBkZWZpbmVkIGZvciBjbGllbnRzIHRvIGNvbnRyb2wgdGhlaXIg cHJlZml4IGRlbGVnYXRpb25zIHVzaW5nIFJTL1JBIHdoZXJlYXMNCj4gPj4+IERIQ1B2NiBQRCBw cm92aWRlcyB0aGUgY2xpZW50IHdpdGggdGhlICJmb3VyIFIncyIgKFJlcXVlc3QsIFJlbmV3LCBS ZWJpbmQsIFJlbGVhc2UpLg0KPiA+Pj4NCj4gPj4+IFNvLCBmb3IgY2xpZW50cyB0byBjb250cm9s IGFuZCBtYW5hZ2UgdGhlaXIgcHJlZml4IGRlbGVnYXRpb25zIGl0IHNlZW1zIGxpa2UgREhDUHY2 DQo+ID4+PiBnaXZlcyB0aGUgY2xpZW50cyB0aGUgbW9zdCBmbGV4aWJpbGl0eSBhbmQgY29udHJv bCBpbiB0ZXJtcyBvZiBMMyBtZXNzYWdpbmcsIHdoZXJlYXMNCj4gPj4+IGZvciBSUy9SQSB0aGVy ZSB3b3VsZCBuZWVkIHRvIGJlIGVpdGhlciBhIG5ldyBMMyBwcm90b2NvbCBvciBzb21lIGZvcm0g b2YgYWRqdW5jdA0KPiA+Pj4gTDIgbWVzc2FnaW5nLiBXaGF0IGFtIEkgbWlzc2luZz8NCj4gPj4N Cj4gPj4gREhDUCBpcyBmdW5kYW1lbnRhbGx5IGEgcG9sbGluZyBwcm90b2NvbCBhbmQgaWYgYSBs ZWFzZSBoYXMgYmVlbiBoYW5kZWQNCj4gPj4gb3V0LCBpdCdzIG5vdCB5b3VycyBhbmQgeW91IGNh biBrZWVwIGl0IHVudGlsIGl0IHRpbWVzIG91dC4NCj4gPg0KPiA+IEluIERIQ1B2NiwgdGhlIGNs aWVudCBpcyByZXNwb25zaWJsZSBmb3IgcmVsaWFiaWxpdHkuIEl0IGFza3MgdGhlIHNlcnZlciBm b3IgYSBQRA0KPiA+IGFuZCBrZWVwcyBhc2tpbmcgdW50aWwgaXQgZ2V0cyBhIFJlcGx5LiBUaGUg Y2xpZW50IGlzIGFsc28gcmVzcG9uc2libGUgZm9yIG1hbmFnaW5nDQo+ID4gaXRzIG93biBsZWFz ZXMgYW5kIHJlbmV3aW5nIHRoZW0gYmVmb3JlIHRoZXkgIHRpbWUgb3V0Lg0KPiA+DQo+ID4+IEkg d291bGQgbGlrZSB1cyB0byBmaW5kIGEgc29sdXRpb24gd2hlcmUgdGhlIG5ldHdvcmsgY2FuIHJl dm9rZSBhDQo+ID4+IHJlc291cmNlIGl0IGhhcyAibGVhc2VkIi4gUmlnaHQgbm93IHdlIGRvbid0 IGhhdmUgYSBmdWxsIHNvbHV0aW9uIGZvcg0KPiA+PiB0aGlzLg0KPiA+DQo+ID4gREhDUHY2IFJl Y29uZmlndXJlICh0aGUgZmlmdGggIlIiKS4NCj4gPg0KPiA+PiBESENQdjYgYW5kIFJTL1JBIGFy ZSBiYXNpY2FsbHkgc2hpcHMgaW4gdGhlIG5pZ2h0IGFuZCBpdCdzIG5vdCBjbGVhcg0KPiA+PiBo b3cgbWVzc2FnZXMgc2VudCB1c2luZyBvbmUgcHJvdG9jb2wsIHdvdWxkIGFmZmVjdCB0aGUgb3Ro ZXIuIEEgbWluaW11bQ0KPiA+PiB3b3VsZCBiZSBzb21lIGtpbmQgb2YgY291cGxpbmcgYmV0d2Vl biBhIERIQ1B2NiByZWxheSByb3V0ZXIgYW5kIHdoYXQgaXQNCj4gPj4gcHV0cyBpbiB0aGUgUkEg YW5kIGhvdyB0aGlzIGFmZmVjdHMgdGhlIERIQ1B2NiBpbmZvcm1hdGlvbi4NCj4gPj4NCj4gPj4g UGVyZmVycmFibHkgSSdkIGxpa2UgdG8gYmUgYWJsZSB0byBkbyBldmVyeXRoaW5nIHdpdGhvdXQg REhDUHY2IGF0IGFsbC4NCj4gPg0KPiA+IEluIERIQ1B2NiwgdGhlIFBEIGFjdGl2aXR5IGlzIGNs aWVudC1kaXJlY3RlZC4gSW4gdGhlIFJTL1JBIGJhc2VkIHNjaGVtZXMsDQo+ID4gdGhlIFBEIGFj dGl2aXR5IGlzIG5ldHdvcmstZGlyZWN0ZWQuIFRoYXQgaXMgYSBtYXJrZWQgZGlmZmVyZW5jZSBh bmQgbmVlZHMNCj4gPiB0byBiZSBleGFtaW5lZCBhY2NvcmRpbmcgdG8gdGhlIHVzZSBjYXNlcy4N Cj4gDQo+IFNob3VsZG4ndCB5b3UgYWRkIEhOQ1AgdG8gdGhpcyBkaXNjdXNzaW9uPw0KDQpJbnRl cmVzdGluZy4gSXQgbG9va3MgbGlrZSBpdCBkb2VzIERIQ1B2NiBQRCBhY2NvcmRpbmcgdG8gUkZD Nzc4OD8NCg0KPiBPciBldmVuIGRyYWZ0LWlldGYtYW5pbWEtcHJlZml4LW1hbmFnZW1lbnQsIGF0 IGEgc3RyZXRjaC4NCg0KQ2FuIGl0IHVzZSBESENQdjYgUEQgb3IgUElPLVggaW5zdGVhZD8NCg0K PiBJbiBhbnkgY2FzZSwgdGhlcmUgYXJlIG1hbnkgd2F5cyB0byB0YWNrbGUgdGhpcyB0b3BpYy4N Cg0KUHJvYmFibHksIGJ1dCBJIHRoaW5rIHRoZXJlIGFyZSB0d28gcHJpbWFyeSBjYXRlZ29yaWVz OiAxKSBuZXR3b3JrLWRpcmVjdGVkDQphbmQgMikgY2xpZW50LWRpcmVjdGVkLiBXaGljaCBpcyBt b3JlIGFwcHJvcHJpYXRlIHByb2JhYmx5IG5lZWRzIHRvIGJlDQpleGFtaW5lZCBvbiBhIGNhc2Ut YnktY2FzZSBiYXNpcy4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+ICAgICAgQnJpYW4NCj4gDQo+ICAg ICBCcmlhbg0KDQo= From nobody Tue Aug 29 15:35:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30C132AA6 for ; Tue, 29 Aug 2017 15:35:49 -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 Z01FCKsyMHld for ; Tue, 29 Aug 2017 15:35:45 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A161326BB for ; Tue, 29 Aug 2017 15:35:45 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id z87so14034315pfi.3 for ; Tue, 29 Aug 2017 15:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yoXLa3e8eRJJgT0WWLYP6k+iFiOc26VxHoDhrajHmRg=; b=h5Suwq6MUSJBwC/p+VQHCpP/kFEcqc/MkoMMb7wNRWG9Xnjhw61mrbshzXOEkHlvrA kFlp0IgywHjtGkhZ61nwjLjdEWSwpzJ1aWLgQHuxCd6c8iJMahLSmrNHE+DK2c9qTRzP Xk0x25fP5UxJB+xLMRWgvSv98tKxbNJXouaJgy8ijOfyhp5PkvpG+OBjiahEztR0oYzT zLmvZPCfjFTPTAPkl2Oq9TninlRQ3tmQ/HhxoptxqjRn7sag7XgLSTjOcxbwUNkf70dc N0VZtdNrtwZyD5MKRGi0XI62SSBP2loujfJJj9XNczTTaIPFeW66dxyCzkyx5Hn7JEYl 4a+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yoXLa3e8eRJJgT0WWLYP6k+iFiOc26VxHoDhrajHmRg=; b=txB0WqHwsU9AnnZhyHnYJzzm+e0IvjPkS/Ur9Ebz8Ul6n02AmFwaej6UvJZWHc1zbO EFVJxH1TuhbYarWCQLra6gBTPpIBIoy3z+OZ0F/LF9l8KW1sDDqMDctIYbMV2JXzLnVh P8YLwb0y0y1osQAECwRk0G6DpDo15Eb7zwGStDRfSikgh28kD/lAyVRCgmy5In0c5rJm b5p4351NTjMXV3q7eDv2j/5sobn3W6pM2Jquq3IW6uVdE9VSFm3vM0cqFmOm7vwrZTQt 99dtZPKlBg1ARUnf9C3JWxUAr/06+zrDPnWBlJtQeP2PPqQqIsWbqkGdTyQqJr7F3mct W0Vg== X-Gm-Message-State: AHYfb5hAwNuhaO9mW9EJ9jfJPYgKFWjz5ksgEmDafzL/hzXjm4NLXTem 0kmCNROtTvi+JQQN X-Received: by 10.98.28.215 with SMTP id c206mr1931292pfc.212.1504046144909; Tue, 29 Aug 2017 15:35:44 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id t29sm7004063pgo.4.2017.08.29.15.35.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 15:35:44 -0700 (PDT) To: "Templin, Fred L" , Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 30 Aug 2017 10:35:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:35:49 -0000 On 30/08/2017 09:56, Templin, Fred L wrote: > Hi Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Tuesday, August 29, 2017 1:14 PM >> To: Templin, Fred L ; Mikael Abrahamsson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >> >> On 30/08/2017 08:00, Templin, Fred L wrote: >>> Hi Mikael, >>> >>>> -----Original Message----- >>>> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >>>> Sent: Tuesday, August 29, 2017 12:40 PM >>>> To: Templin, Fred L >>>> Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >>>> >>>> On Tue, 29 Aug 2017, Templin, Fred L wrote: >>>> >>>>> Hi, it seems like recent works and discussions have postulated a means for delegating >>>>> IPv6 prefixes to nodes using RS/RA instead of DHCPv6 PD. But, there really isn't any >>>>> L3 protocol defined for clients to control their prefix delegations using RS/RA whereas >>>>> DHCPv6 PD provides the client with the "four R's" (Request, Renew, Rebind, Release). >>>>> >>>>> So, for clients to control and manage their prefix delegations it seems like DHCPv6 >>>>> gives the clients the most flexibility and control in terms of L3 messaging, whereas >>>>> for RS/RA there would need to be either a new L3 protocol or some form of adjunct >>>>> L2 messaging. What am I missing? >>>> >>>> DHCP is fundamentally a polling protocol and if a lease has been handed >>>> out, it's not yours and you can keep it until it times out. >>> >>> In DHCPv6, the client is responsible for reliability. It asks the server for a PD >>> and keeps asking until it gets a Reply. The client is also responsible for managing >>> its own leases and renewing them before they time out. >>> >>>> I would like us to find a solution where the network can revoke a >>>> resource it has "leased". Right now we don't have a full solution for >>>> this. >>> >>> DHCPv6 Reconfigure (the fifth "R"). >>> >>>> DHCPv6 and RS/RA are basically ships in the night and it's not clear >>>> how messages sent using one protocol, would affect the other. A minimum >>>> would be some kind of coupling between a DHCPv6 relay router and what it >>>> puts in the RA and how this affects the DHCPv6 information. >>>> >>>> Perferrably I'd like to be able to do everything without DHCPv6 at all. >>> >>> In DHCPv6, the PD activity is client-directed. In the RS/RA based schemes, >>> the PD activity is network-directed. That is a marked difference and needs >>> to be examined according to the use cases. >> >> Shouldn't you add HNCP to this discussion? > > Interesting. It looks like it does DHCPv6 PD according to RFC7788? As a tool, yes. In your sense, it's network-directed, because the decisions are made by the network (HNCP being a distributed decsion-making protocol). >> Or even draft-ietf-anima-prefix-management, at a stretch. > > Can it use DHCPv6 PD or PIO-X instead? So far we've assumed that it will be PD to the ultimate client router. But actually that isn't required - a router that obtains a prefix this way could just start using it. >> In any case, there are many ways to tackle this topic. > > Probably, but I think there are two primary categories: 1) network-directed > and 2) client-directed. Which is more appropriate probably needs to be > examined on a case-by-case basis. The client can't invent a routable prefix, though: that always has to managed from "above", as far as I can see. Brian From nobody Tue Aug 29 19:13:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A6B13235A for ; Tue, 29 Aug 2017 19:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 BpI2dOHq6eOZ for ; Tue, 29 Aug 2017 19:13:29 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E522D1323C0 for ; Tue, 29 Aug 2017 19:13:27 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id y15so15993600pgc.1 for ; Tue, 29 Aug 2017 19:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPQAi98cK6Ski0+X8HJkwqTk7BRx7JUEw4y3MeLxdiw=; b=neM7ahwekcKlv0gygpjHN8CRyO/TcZ9mEX+Ok+K1dLjFPpwRHsO+QkSWwmU2eYxMmq vYeRhzBdvpPJARlYG3Wb36JOk/yYMOfMvAIl/ixlBBq821vZpSlzVE245Q8KkfeKXgzG g3hdz89sVW5jEy2jiYv/M0ToKyWPeuqVDs8L6pBl0T1sZ+swjaj+bWXVADNAyr/10Y/J NcMTSckM0dKpKtNMCUG8CcCeo/av65CnFYivtutvJJccTM0CO2IslVaOaYMU7sKEaj4d AZA9ucIVxIOXqgEMPJ1bVM53mSs21lgwxZe/bXTeTPH0KBBMk6+vQI8D8yhTTPAocrTu 63/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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wPQAi98cK6Ski0+X8HJkwqTk7BRx7JUEw4y3MeLxdiw=; b=pvRqXf15CwC+TLQk2ToWodcWu0FzI+A930R9XjAmrgp0DZ3XyGOhuzsGRj45vF76iT YyTQ0NRH0WuAayORWGGPuI5XVIS9WtiYA2rXW7GqFQ9wIuzmd+JomE3hFsuv+F0qbAxS ZjleLgPnf1uBuRmLFIiQ8LX9HzPkyRb/VZYc3W8tsZlVqfEPVJsI4+CQQphFYq12jo58 TyxmxHDmKkp4D/G0j9FmiolaykxL/RKkhsbU019SPLN6chAWa6/eVW7Tqog1HXqPA/Yr dIcUqdXhYsgIiG2MA9bXCm5Vu7aP9DTViv3yPpUDln6z6d3n3XCzOdPy6kUbfc6wYVy6 prnQ== X-Gm-Message-State: AHYfb5g5OpmvR4YX4zsfq0TlUWUT8N7QYdS/Hl7mjLe+eA+HxE+BmyrS DGDwaqDd+/pSwAP4tTTV/w== X-Google-Smtp-Source: ADKCNb5AO1Q1JYy/8oDR9RKGmL1zSepDW9eSQYo3yntbJoqe2n2zbtW+HPtMTiIePbcGvI+VWu45jA== X-Received: by 10.99.127.2 with SMTP id a2mr20618pgd.196.1504059206990; Tue, 29 Aug 2017 19:13:26 -0700 (PDT) Received: from ?IPv6:2001:5a8:4:2290:c91f:c37d:5b13:1409? ([2001:5a8:4:2290:c91f:c37d:5b13:1409]) by smtp.gmail.com with ESMTPSA id 141sm6286959pfa.126.2017.08.29.19.13.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 19:13:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: james woodyatt In-Reply-To: Date: Tue, 29 Aug 2017 19:13:25 -0700 Cc: "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 02:13:31 -0000 On Aug 28, 2017, at 09:39, David Farmer wrote: > On Mon, Aug 28, 2017 at 10:38 AM, Templin, Fred L = wrote: >>=20 >> In thinking about this more, I think the document should say *less* = than what it is currently saying. [=E2=80=A6] The only thing that can = prevent two subscriber devices from communicating directly without going = through the first hop router would be L2 mechanisms but not all networks = are going to want to prevent direct communications. >>=20 >> Therefore, leaving these two statements in would unnecessarily = restrict the domain of applicability. >=20 > As Mark has been talking about in the other thread, if you use an L2 = mechanism then you can't ensure you won't duplicated an IID without a ND = proxy along with the L2 mechanism. >=20 > So I have to disagree, we seem to have several different = interpretations of the current text, to me that usually means we are = missing something important in the text, and people are filling in with = there own imaginations, and coming to different conclusions. I think = there are important details that need more discussion in the text, not = less, or in other word I can't support removing text, at least yet. >=20 > While I'm skeptical of Lorenzo's description, with more details of how = you put each host in its own VLAN, I could see how what he is talking = about could work. >=20 > So, I'd like to here what more about how the authors think this is = suppose to work. =20 If I-D.ietf-v6ops-unique-ipv6-prefix-per-host is meant as BCP for *only* = those networks where layer-2 isolates hosts from direct communication = with one another, then it really needs to say so more clearly, to = expressly advise practitioners continue using shared prefixes, and *not* = to use unique-prefix-per-host, on IPv6 networks where layer-2 does not = isolate hosts from direct communication with one another. It doesn=E2=80=99= t currently contain a MUST for that. Until now, it was unclear to me that the authors intend for this BCP not = to apply more widely than certain specific networks where this might be = of private benefit, which leaves me scratching my head, and asking out = loud: why is this an IETF document again? On the other hand, if the intent is that unique-prefix-per-host MAY be = applicable also on networks where layer-2 does not isolate hosts from = direct communication with one another, then I think it should go into = significantly more detail about how that should be made to work. In either case, I don=E2=80=99t think the current draft is adequate. --james woodyatt From nobody Tue Aug 29 22:07:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA671321BF for ; Tue, 29 Aug 2017 22:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2JKK6MAcqHP for ; Tue, 29 Aug 2017 22:07:45 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8EE132144 for ; Tue, 29 Aug 2017 22:07:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C3FA5AF; Wed, 30 Aug 2017 07:07:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504069662; bh=hCaCv52uk9vB/JsckrGGoIWk7oyQBwS/NSh66bcNU5U=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QtCxRRZpKt9jx+T1BO7tzHYc3h/Wi4EtKIepVCjKTc3HQKj+VUBvJj/F4ln5qYf7P JuFGaovVO0Fg+TdcHMNdA44FWIcDCG/9BpzLcUJ9UV3/tTw/bPuABFOzmrl7Z8O0Sw TascqOuFayIZc+R9C10Yzx5T1pIcGGH15dpyCzuw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BFB7984; Wed, 30 Aug 2017 07:07:42 +0200 (CEST) Date: Wed, 30 Aug 2017 07:07:42 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: Brian E Carpenter , "v6ops@ietf.org" In-Reply-To: <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 05:07:47 -0000 On Tue, 29 Aug 2017, Templin, Fred L wrote: > Probably, but I think there are two primary categories: 1) > network-directed and 2) client-directed. Which is more appropriate > probably needs to be examined on a case-by-case basis. I think whatever we come up with needs to support all of them. Client needs to be able to release resources, it needs to indicate that "I don't want this anymore, permanently" but also "I am disconnecting for a while, I am still interested in this resource" and also perhaps "hello, I am now here, can I please have my resource that I had over there" (in case of for instance wifi handover). The network in turn needs to be able to tell the device "sorry, this resource is or will soon no longer available, stop using it within X seconds" -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 30 01:52:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DE3132705 for ; Wed, 30 Aug 2017 01:52:12 -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 9lVgxKzc42bH for ; Wed, 30 Aug 2017 01:52:10 -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 AC46D1323B5 for ; Wed, 30 Aug 2017 01:52:09 -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 v7U8q7iB000770 for ; Wed, 30 Aug 2017 10:52:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D259620337B for ; Wed, 30 Aug 2017 10:52:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C92E720321D for ; Wed, 30 Aug 2017 10:52:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7U8q7gg028644 for ; Wed, 30 Aug 2017 10:52:07 +0200 To: v6ops@ietf.org References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <3bc0a0b9-0aab-75ce-90b3-0522acc97f81@gmail.com> Date: Wed, 30 Aug 2017 10:52:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 08:52:12 -0000 Le 29/08/2017 à 22:00, Templin, Fred L a écrit : > Hi Mikael, > >> -----Original Message----- From: Mikael Abrahamsson >> [mailto:swmike@swm.pp.se] Sent: Tuesday, August 29, 2017 12:40 PM >> To: Templin, Fred L Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >> >> On Tue, 29 Aug 2017, Templin, Fred L wrote: >> >>> Hi, it seems like recent works and discussions have postulated a >>> means for delegating IPv6 prefixes to nodes using RS/RA instead >>> of DHCPv6 PD. But, there really isn't any L3 protocol defined >>> for clients to control their prefix delegations using RS/RA >>> whereas DHCPv6 PD provides the client with the "four R's" >>> (Request, Renew, Rebind, Release). >>> >>> So, for clients to control and manage their prefix delegations >>> it seems like DHCPv6 gives the clients the most flexibility and >>> control in terms of L3 messaging, whereas for RS/RA there would >>> need to be either a new L3 protocol or some form of adjunct L2 >>> messaging. What am I missing? >> >> DHCP is fundamentally a polling protocol and if a lease has been >> handed out, it's not yours and you can keep it until it times out. > > In DHCPv6, the client is responsible for reliability. It asks the > server for a PD and keeps asking until it gets a Reply. The client > is also responsible for managing its own leases and renewing them > before they time out. > >> I would like us to find a solution where the network can revoke a >> resource it has "leased". Right now we don't have a full solution >> for this. > > DHCPv6 Reconfigure (the fifth "R"). > >> DHCPv6 and RS/RA are basically ships in the night and it's not >> clear how messages sent using one protocol, would affect the >> other. A minimum would be some kind of coupling between a DHCPv6 >> relay router and what it puts in the RA and how this affects the >> DHCPv6 information. >> >> Perferrably I'd like to be able to do everything without DHCPv6 at >> all. > > In DHCPv6, the PD activity is client-directed. In the RS/RA based > schemes, the PD activity is network-directed. That is a marked > difference and needs to be examined according to the use cases. In some use-cases on cellular network it may be preferable to use DHCPv6-PD to delegate prefixes, instead of PIO-X. An INFORMATIONAL RFC6653 "PD on LTE" Figure 3 "Stateful Addr Conf Following PD" illustrates such use-case. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> -- Mikael Abrahamsson email: swmike@swm.pp.se > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Aug 30 01:57:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20A21323B5 for ; Wed, 30 Aug 2017 01:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ohJaBvZe7qO for ; Wed, 30 Aug 2017 01:57:24 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230F11321C4 for ; Wed, 30 Aug 2017 01:57:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v7U8vM2D169760 for ; Wed, 30 Aug 2017 10:57:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05F5E20347F for ; Wed, 30 Aug 2017 10:57:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ED823203464 for ; Wed, 30 Aug 2017 10:57:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7U8vL6c000676 for ; Wed, 30 Aug 2017 10:57:21 +0200 To: v6ops@ietf.org References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Wed, 30 Aug 2017 10:57:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 08:57:26 -0000 Le 29/08/2017 à 21:39, Mikael Abrahamsson a écrit : > On Tue, 29 Aug 2017, Templin, Fred L wrote: > >> Hi, it seems like recent works and discussions have postulated a >> means for delegating IPv6 prefixes to nodes using RS/RA instead of >> DHCPv6 PD. But, there really isn't any L3 protocol defined for >> clients to control their prefix delegations using RS/RA whereas >> DHCPv6 PD provides the client with the "four R's" (Request, Renew, >> Rebind, Release). >> >> So, for clients to control and manage their prefix delegations it >> seems like DHCPv6 gives the clients the most flexibility and >> control in terms of L3 messaging, whereas for RS/RA there would >> need to be either a new L3 protocol or some form of adjunct L2 >> messaging. What am I missing? > > DHCP is fundamentally a polling protocol and if a lease has been > handed out, it's not yours and you can keep it until it times out. > > I would like us to find a solution where the network can revoke a > resource it has "leased". Right now we don't have a full solution > for this. DHCPv6 and RS/RA are basically ships in the night What is 'ships in the night'? > and it's not clear how messages sent using one protocol, would > affect the other. It may be that there is little relationship between these protocols. An Access Router may put two very distinct prefixes (down to only 3 common leftmost bits) in an RA and in the PD Advertise, provided these two prefixes are routed correctly. > A minimum would be some kind of coupling between a DHCPv6 relay > router and what it puts in the RA and how this affects the DHCPv6 > information. Some coordination may be advantageous, but it could also work without. What would be the advantage? Alex > > Perferrably I'd like to be able to do everything without DHCPv6 at > all. > From nobody Wed Aug 30 02:34:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8D13235C for ; Wed, 30 Aug 2017 02:34:38 -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 tZaoEdyD_FXX for ; Wed, 30 Aug 2017 02:34:36 -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 B0DAA1321A0 for ; Wed, 30 Aug 2017 02:34:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9FF081BC37 for ; Wed, 30 Aug 2017 09:34:17 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 30 Aug 2017 10:34:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20896C8D-008C-43DF-8A2D-A75302ADF3F1@thehobsons.co.uk> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:34:39 -0000 Alexandre Petrescu wrote: >> for this. DHCPv6 and RS/RA are basically ships in the night >=20 > What is 'ships in the night'? https://en.wiktionary.org/wiki/ships_that_pass_in_the_night Etymology =46rom a poetic metaphor by Henry Wadsworth Longfellow (1807-1882): Ships that pass in the night, and speak each other in passing, Only a signal shown and a distant voice in the darkness; So on the ocean of life we pass and speak one another, Only a look and a voice, then darkness again and a silence. Noun ... =95 (idiomatic, by extension) Things which have no significant = connection or commonality. It's a saying that's probably only familiar to english speaking and/or = seafaring nationalities. Basically it refers to two strangers who meet = briefly by chance, but never again. A bit like, two ships might pass in = the night, and at best exchange a few signals of greeting (which would = have been light signals when the phrase first came into use), before = they disappear in their different directions. In this case, I think what Mikael Abrahamsson is suggesting that these = are different, unconnected processes/protocols with no common connection = other than that the packets share the same wire. From nobody Wed Aug 30 06:50:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2040132A0D for ; Wed, 30 Aug 2017 06:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU2g0_Frjmio for ; Wed, 30 Aug 2017 06:50:08 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E182C13292E for ; Wed, 30 Aug 2017 06:50:07 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f1so6249388ith.0 for ; Wed, 30 Aug 2017 06:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yfkrG5Y1sr6gToA8ra7jgRNaJl8OJlZ+4QJACLQR8ZU=; b=p3zjKJTyhQ40eOGjt+EYN+DhMHsnqhY7vmXwijmRVcg6Qoul5fLAu3TeQ/ZKkhiZSg 57LuRkZV49anHdgibvpMdc6xmopS1TcsbtIpXg5KtRmXHpDKrB8kkFDUt0B/JTUL+8/9 tLHmJEFgsKaadZcWFKsOmFSwBesOWyVcfTblm9Lc5tdarCQ9VG0g82sjatrXrBGBvmok 9SWVzBvVjedJHvq6xRkKapacnkMRcZVJmPYXbo8Y+5FODM7t8ObNxeP9TD5g52HQQwgC Bi/V6k8ZNLreQ6aBRYG4WTMo7nWjc7YOUkDNxlA2Ozc8A5H/a9nkd4fL2OI/MRDhAg0E r85g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yfkrG5Y1sr6gToA8ra7jgRNaJl8OJlZ+4QJACLQR8ZU=; b=TGEuZz3eff81HjLSUnMKyJ9CfqCFl3W+OtjFun9pb4adozCKdva4rLm4VbBmB2DtmG pKu8q/ynvhBTfKSfZSdw0kGyeig2sm0/bmL+StgvZywxCbI3CLPeBgrLZB9d9imfdpM+ gUlMf7fb1ceb3vG/Bt2SmDmERrOofdn75OHn4fXuz3v1B59nHaNWnkZgz2znDJ1xo1Y+ oUyzyTM0xGyyZmzWt820fqAOI/teJ9PgBi6oJK8ZDP59dVbYB5ZRboKJoT4Is95DR/So MlAL3ZEEFUL3p1lp2I8UMPN6qXE6r9IzYG3RiESOAIu49o33c5desXt3QPw2917K3oWK 35QA== X-Gm-Message-State: AHYfb5jIXbroTf+yeVLelLmTL+4MkgTAdOguP0iVjj2KvX5qnqx7rQNl Sfp2JvbCcuzYkoeLlvOIyGQ8WJbz6Q== X-Received: by 10.36.39.80 with SMTP id g77mr1747222ita.79.1504101007129; Wed, 30 Aug 2017 06:50:07 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.79.35.39 with HTTP; Wed, 30 Aug 2017 06:50:06 -0700 (PDT) Received: by 10.79.35.39 with HTTP; Wed, 30 Aug 2017 06:50:06 -0700 (PDT) In-Reply-To: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> From: Erik Nygren Date: Wed, 30 Aug 2017 09:50:06 -0400 X-Google-Sender-Auth: 4Y7Wv4JbCR-ocGvzMRIx4Xae7Ic Message-ID: To: Mikael Abrahamsson Cc: v6ops@ietf.org, "Templin, Fred L" Content-Type: multipart/alternative; boundary="001a1147478a3c8b500557f8ce02" Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 13:50:14 -0000 --001a1147478a3c8b500557f8ce02 Content-Type: text/plain; charset="UTF-8" A specific use-case I'd love to see a better solution for is data center scenario where individual nodes want to request a specific prefix for providing a service from, especially if those nodes are collaborating and want to be able to hand off the prefix between eachother as part of an HA setup. Examples might include a pair of active/standby NAT64 servers, a web server that needs huge numbers of IPs, or a VM hosting server for a test environment that has a huge number of IPs within a given prefix. Currently BGP with a next hop service address seems to the best and most universal way to configure this, but it brings another protocol family into the mix. In these cases the nodes generally have configured prefixes they are requesting, often configured through an out-of-band config management or orchestration system. - Erik On Aug 30, 2017 1:07 AM, "Mikael Abrahamsson" wrote: > On Tue, 29 Aug 2017, Templin, Fred L wrote: > > Probably, but I think there are two primary categories: 1) >> network-directed and 2) client-directed. Which is more appropriate probably >> needs to be examined on a case-by-case basis. >> > > I think whatever we come up with needs to support all of them. Client > needs to be able to release resources, it needs to indicate that "I don't > want this anymore, permanently" but also "I am disconnecting for a while, I > am still interested in this resource" and also perhaps "hello, I am now > here, can I please have my resource that I had over there" (in case of for > instance wifi handover). The network in turn needs to be able to tell the > device "sorry, this resource is or will soon no longer available, stop > using it within X seconds" > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1147478a3c8b500557f8ce02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    A specific use-case I'd love to see a better solution for is data cent= er scenario where individual nodes want to request a specific prefix for pr= oviding a service from, especially if those nodes are collaborating and wan= t to be able to hand off the prefix between eachother as part of an HA setu= p.=C2=A0 Examples might include a pair of active/standby NAT64 servers, a w= eb server that needs huge numbers of IPs, or a VM hosting server for a test= environment that has a huge number of IPs within a given prefix.
    Cur= rently BGP with a next hop service address seems to the best and most unive= rsal way to configure this, but it brings another protocol family into the = mix.

    In these cases the nodes generally have configured prefixes they = are requesting, often configured through an out-of-band config management o= r orchestration system.

    - = Erik

    =C2=A0 =C2=A0 =C2=A0

    =
    On Aug 30, 2017 1:07 AM, "Mikael Abrahamsso= n" <swmike@swm.pp.se> wr= ote:
    On Tue, 29 Aug = 2017, Templin, Fred L wrote:

    Probably, but I think there are two primary categories: 1) network-directed= and 2) client-directed. Which is more appropriate probably needs to be exa= mined on a case-by-case basis.

    I think whatever we come up with needs to support all of them. Client needs= to be able to release resources, it needs to indicate that "I don'= ;t want this anymore, permanently" but also "I am disconnecting f= or a while, I am still interested in this resource" and also perhaps &= quot;hello, I am now here, can I please have my resource that I had over th= ere" (in case of for instance wifi handover). The network in turn need= s to be able to tell the device "sorry, this resource is or will soon = no longer available, stop using it within X seconds"

    --
    Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    --001a1147478a3c8b500557f8ce02-- From nobody Wed Aug 30 08:08:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17F3132D58 for ; Wed, 30 Aug 2017 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 t4Hqn6cGzVXA for ; Wed, 30 Aug 2017 08:08:16 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB74132A80 for ; Wed, 30 Aug 2017 08:08:15 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 81so5879120ioj.5 for ; Wed, 30 Aug 2017 08:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q9vI3UpUi1TxVD3/fVAWjcewRrDsArxabqIXcTkUbqI=; b=uSPBtNDuFwVxE916gJj7g5bE8rusPo9qBSo+3jv2wZKGfRxIOMy/JSZc+tVTZWDVSE QulCWj4tdOM5pkJfM0BzHEL/1DISLYReKrLsQJ1zao0ry0bcotEiRXDsE2XRJpd9HsNE DyamzLpPU22q1vyeX794cl2EzrHshvhKnz6LxAT879v2SL0SD6qjwQmzc5XK+iQfGABm SRNg1a7+2Gnem8YqgoaULlQxEnDN7A1uNzHSz0izuJbSEWXCkFLEVM7fC/QZhEGLAmya h0+0KnE5anvVfQhrpDgW3x/o2n6jh4k25eAqS+4cRRtwR8Q6appF4myO6lr+v7Ix0oU6 J6kg== 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=Q9vI3UpUi1TxVD3/fVAWjcewRrDsArxabqIXcTkUbqI=; b=mjm66QMqxus/DBC5gTLHMwcaciD32lDkjThCUYFAsiAQDTWheOXed5EM1RjlyLmw6r MfjsO38A27733qfz3UyyqWyzh/fz+E37uPfENaqxEcFCaryeeEDoQn5tZ2wKZoMZtzVS GUHYAXegVX90tuhJXTDpvqBe78lnRenxZz20Y7oo5CsMheLo4zKCX7tkHB8h/0Jfk2GW A4d+uErdQBcGAH1S05JQxE+h6hQC8hy4Qegqp4XewjMgv6XlpC/SolBmR3MR1/XbhG66 qLP45kJGBAlZsO+cAGewyShPlJnAViKqdiPKLZhM8Z1ABR1VncI/3dS2JCfFa1NkJD27 fqUA== X-Gm-Message-State: AHPjjUgv0SF2w2zEH1bGfVp+XaatswVckPtxyRNCOpDF5dkxTafI7oY8 K0yNn84tCeR6KPbzNHO/VPVZ841cyL2Jfrnghw== X-Google-Smtp-Source: ADKCNb7T3qX2VClJaAUtq7Vocp9JRkavpflETsIViFk0TosErjGDF9JAFd//6cHeIAwn4rho7BlkRdW3ovj+VTT5/XE= X-Received: by 10.107.35.213 with SMTP id j204mr1752155ioj.279.1504105693961; Wed, 30 Aug 2017 08:08:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 30 Aug 2017 08:07:53 -0700 (PDT) In-Reply-To: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 31 Aug 2017 00:07:53 +0900 Message-ID: To: "Templin, Fred L" Cc: David Farmer , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a1140b85a98bd7a0557f9e580" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:08:18 -0000 --001a1140b85a98bd7a0557f9e580 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L wrote: > So, I see this being a very simple document that wraps itself around > RFC4861. > > RFC4861 security considerations also apply (including RFC3756) and this doc > > should not be in the business of unnecessarily restricting the domain of > > applicability. > I think you're entirely missing the goal of this document. It's written clearly in the applicability statement section that the text applies to situations where: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router This is an extremely desirable security property in any environment where trust between devices is limited. In such environments, standard SLAAC on shared links cannot be made reliable in the presence of buggy or malicious hosts without brittle hacks that don't scale, and is thus a non-starter from a an operational point of view unless the devices are tightly controlled. Thus, there are very solid operational reasons to limit the scope of applicability to such networks. If you can convincingly argue that security or reliability would not be lessened by allowing direct peer-to-peer communication, then sure, the scope of applicability of this draft can be expanded. I don't think you'll be able to convincingly argue that. Saying "it's no worse than standard SLAAC" is not a convincing argument, because standard SLAAC has known security and reliability issues in this sort of environment. --001a1140b85a98bd7a0557f9e580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= ue, Aug 29, 2017 at 3:31 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

    So, I see this being a very simple document = that wraps itself around RFC4861.

    RFC4861 security considerations also apply (= including RFC3756) and this doc

    should not be in the business of unnecessari= ly restricting the domain of

    applicability.


    I think you're entirely missing the goal of t= his document. It's written clearly in the applicability statement secti= on that the text applies to situations where:

    =C2=A0 =C2=A0o=C2=A0 Two devices (subscriber/hosts), both attached to the = same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared network should = only be able to communicate through
    =C2=A0 =C2=A0 =C2=A0 the prov= ider managed First Hop Router

    This is an ext= remely desirable security property in any environment where trust between d= evices is limited. In such environments, standard SLAAC on shared links can= not be made reliable in the presence of buggy or malicious hosts without br= ittle hacks that don't scale, and is thus a non-starter from a an opera= tional point of view unless the devices are tightly controlled. Thus, there= are very solid operational reasons to limit the scope of applicability to = such networks.

    If you can convincingly argue that = security or reliability would not be lessened by allowing direct peer-to-pe= er communication, then sure, the scope of applicability of this draft can b= e expanded. I don't think you'll be able to convincingly argue that= . Saying "it's no worse than standard SLAAC" is not a convinc= ing argument, because standard=C2=A0SLAAC has known security and reliabilit= y issues in this sort of environment.
    --001a1140b85a98bd7a0557f9e580-- From nobody Wed Aug 30 08:10:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00320132196 for ; Wed, 30 Aug 2017 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WCvYG7QcFiTs for ; Wed, 30 Aug 2017 08:10:54 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ABF132C2C for ; Wed, 30 Aug 2017 08:10:51 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id g33so5930160ioj.3 for ; Wed, 30 Aug 2017 08:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sw5AZU5g6hn+5RVLIqzsXfp4Rr0ug4RBT3ZWkE5W8bo=; b=H7NAla0fujVBVN2RZRGFlsptNcc2NPGkFeVLaSeaYiioY/iLiwM9HAMQb54IuHX8Ov y1shSFEv648EPthjsRe7PbZRvwIYlZboL4PnD6ohCLOAvzEuzklXrgWixR2MNLA2W+S3 e2Z+W6vNZQ8jCr6lCSlDhvjB9WS0+xzTkrw9/ZrkXq/cGoJy1bxb26QpqyWdIsptit4C xPnEe7qgQicrpbKRfcyRjncmL/HW1XnXMBY9vzXDoSVmDnfeeE0f6XEEDKD82A+Jp7hh l073FsMAI2bW7BnlyFq2SmgUrc6413260YElrVYjDT0cZErna4llsFkXjt3UXwtNve/k ZaCQ== 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=sw5AZU5g6hn+5RVLIqzsXfp4Rr0ug4RBT3ZWkE5W8bo=; b=T9h6rz2KUmwTw0OTQEl0G/rUxrpqxy2+7917ieVTgwqB6XzluGvtO6rHOaPwOANgwh uwFgGHGy6bHN/u2+wWupmVw8pUEK4TbAnB4V+l6KRYlfr4yKeBcJMPRUrvQ96wQVBOWT a0kFAGUI+mdwzM0Wh+xl/LYN45mu6fJgDUrHU6sX8zsHwBhqp/qy3g4zzvU6yfwPI6UD QQw7Jeh1LbWhH1iqcJ6BNkSFbQxi94I+syE0OVwht9m6HIXQC0+pm5Ss5tqnpfGznSA5 /l7tigx3a/poryJvGeXoT1/1Mmrm4fz/1/vi+h2FHckapJbrIi7OOm9kZ6MwEB9LuW8V DWgA== X-Gm-Message-State: AHPjjUheS5WtKhmyAc4QElDMBh3pYmGN8CDv+Wo3qPzxVHE8eZaeUsJF Y64Gg8W1WeVKDDH9EhaqTuVGUoraJKlQ X-Google-Smtp-Source: ADKCNb7k+apAKd5GMBoGseZamgM+hNkhLEZwGd3v8Yxqe72hF7GqeeK1sOFBsQMzPOCTzHmMph2Gq9NoitAXLSjppsI= X-Received: by 10.107.39.84 with SMTP id n81mr1669335ion.118.1504105850637; Wed, 30 Aug 2017 08:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 30 Aug 2017 08:10:29 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 31 Aug 2017 00:10:29 +0900 Message-ID: To: james woodyatt Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a11407d4aef59990557f9ee5a" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:10:56 -0000 --001a11407d4aef59990557f9ee5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2017 at 11:13 AM, james woodyatt wrote: > If I-D.ietf-v6ops-unique-ipv6-prefix-per-host is meant as BCP for *only* > those networks where layer-2 isolates hosts from direct communication wit= h > one another, then it really needs to say so more clearly, to expressly > advise practitioners continue using shared prefixes, and *not* to use > unique-prefix-per-host, on IPv6 networks where layer-2 does not isolate > hosts from direct communication with one another. It doesn=E2=80=99t curr= ently > contain a MUST for that. > Personally I think it says so pretty clearly. The applicability statement contains the words: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router Until now, it was unclear to me that the authors intend for this BCP not to > apply more widely than certain specific networks where this might be of > private benefit, which leaves me scratching my head, and asking out loud: > why is this an IETF document again? > I think the scenarios above are actually very common. For example, this is the only reasonable way I see to deploy a public wifi access point using SLAAC without artificially limiting the number of addresses that each host can use. --001a11407d4aef59990557f9ee5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On W= ed, Aug 30, 2017 at 11:13 AM, james woodyatt <jhw@google.com> = wrote:
    If I-D.ietf-v6o= ps-unique-ipv6-prefix-per-host is meant as BCP for *only* those networ= ks where layer-2 isolates hosts from direct communication with one another,= then it really needs to say so more clearly, to expressly advise practitio= ners continue using shared prefixes, and *not* to use unique-prefix-per-hos= t, on IPv6 networks where layer-2 does not isolate hosts from direct commun= ication with one another. It doesn=E2=80=99t currently contain a MUST for t= hat.

    Personally I think it says so pret= ty clearly. The applicability statement contains the words:

    <= /div>
    =C2=A0 =C2=A0o=C2=A0 Two devices (subscriber/hosts), both at= tached to the same provider
    =C2=A0 =C2=A0 =C2=A0 managed shared n= etwork should only be able to communicate through
    =C2=A0 =C2=A0 = =C2=A0 the provider managed First Hop Router

    Until now, it was unclear to = me that the authors intend for this BCP not to apply more widely than certa= in specific networks where this might be of private benefit, which leaves m= e scratching my head, and asking out loud: why is this an IETF document aga= in?

    I think the scenarios above are act= ually very common. For example, this is the only reasonable way I see to de= ploy a public wifi access point using SLAAC without artificially limiting t= he number of addresses that each host can use.
    --001a11407d4aef59990557f9ee5a-- From nobody Wed Aug 30 08:15:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127B9132DFB for ; Wed, 30 Aug 2017 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2guv3yzWyOZ for ; Wed, 30 Aug 2017 08:15:45 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5AB132CF8 for ; Wed, 30 Aug 2017 08:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1504106132; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=2j0kZ4Cqp7FWb0cWzqqC1kr0OV+BS913OueSqDQxsdg=; b=LFwZh3m6YEWgyGmjYFlMA32ZjFm2N+iGb/Umac7+r0SI/2YYjdvgYBwLRWruWB0gHaiUVUcjSOTIcFyTBevuC51ZohlQcZM2QAZwbz1boXCOWSl9V5mf3eIURsjJe1cAjKrxrZMAs4c3fh+lgU9lIjnc9Be6q1Cb4zRTpApLWeY= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0212.outbound.protection.outlook.com [213.199.154.212]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-117-3SKLKH01NkWml1wUWsQQqQ-1; Wed, 30 Aug 2017 16:15:28 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0600.eurprd07.prod.outlook.com (10.160.3.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Wed, 30 Aug 2017 15:15:27 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::9447:453:3e6d:c99a%13]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 15:15:26 +0000 From: Tim Chown To: Lorenzo Colitti CC: "Templin, Fred L" , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AQHTIaHASphDIqrT5U6YvRBgUld6eaKdAlaA Date: Wed, 30 Aug 2017 15:15:26 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0600; 20:aGt/j7SemnSa02Ua3fNb56c5N17pkUhj/BxKIKAgNTxMwZ2+rH5pIhdPzQgIVM8zWmneqqD5bvPQKDRT3EUB81tJ9KAciCGSGfVfpCQjirEzaBcE1jRK3DVDZn0ejaA33GlUX40kUzQUBi4qbFRcywUVqbOH7yDqf28Upfgskbo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e5540e84-b0f4-4407-dc47-08d4efb9f1a8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0600; x-ms-traffictypediagnostic: AM3PR07MB0600: x-exchange-antispam-report-test: UriScan:(192374486261705)(39337521807258)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(920507026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0600; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0600; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(377454003)(24454002)(50226002)(6506006)(72206003)(14454004)(36756003)(34040400001)(93886005)(5660300001)(5890100001)(3660700001)(101416001)(106356001)(105586002)(57306001)(68736007)(7736002)(8676002)(189998001)(86362001)(97736004)(53546010)(4326008)(229853002)(6486002)(305945005)(8936002)(3846002)(81166006)(81156014)(102836003)(6116002)(3280700002)(6916009)(83716003)(8666007)(2950100002)(2906002)(42882006)(2900100001)(54906002)(99286003)(33656002)(82746002)(230783001)(66066001)(478600001)(74482002)(6436002)(110136004)(76176999)(6246003)(53936002)(5250100002)(6512007)(25786009)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0600; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <314B02AA6653094E90C98F1C98D93079@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 15:15:26.7821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0600 X-MC-Unique: 3SKLKH01NkWml1wUWsQQqQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:15:48 -0000 > On 30 Aug 2017, at 16:07, Lorenzo Colitti wrote: >=20 > On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L wrote: > So, I see this being a very simple document that wraps itself around RFC4= 861. >=20 > RFC4861 security considerations also apply (including RFC3756) and this d= oc >=20 > should not be in the business of unnecessarily restricting the domain of >=20 > applicability. >=20 > I think you're entirely missing the goal of this document. It's written c= learly in the applicability statement section that the text applies to situ= ations where: >=20 > o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router >=20 > This is an extremely desirable security property in any environment where= trust between devices is limited. In such environments, standard SLAAC on = shared links cannot be made reliable in the presence of buggy or malicious = hosts without brittle hacks that don't scale, and is thus a non-starter fro= m a an operational point of view unless the devices are tightly controlled.= Thus, there are very solid operational reasons to limit the scope of appli= cability to such networks. >=20 > If you can convincingly argue that security or reliability would not be l= essened by allowing direct peer-to-peer communication, then sure, the scope= of applicability of this draft can be expanded. I don't think you'll be ab= le to convincingly argue that. Saying "it's no worse than standard SLAAC" i= s not a convincing argument, because standard SLAAC has known security and = reliability issues in this sort of environment. Indeed; the isolation property is one of the key attractions of the draft. Tim From nobody Wed Aug 30 10:51:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916B132710 for ; Wed, 30 Aug 2017 10:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 FaaxlmV7QGWX for ; Wed, 30 Aug 2017 10:51:03 -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 AA1D8132320 for ; Wed, 30 Aug 2017 10:51:03 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id F0BCEA7B for ; Wed, 30 Aug 2017 17:51:02 +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 1_aE4-tS7w9d for ; Wed, 30 Aug 2017 12:51:02 -0500 (CDT) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id AA78E5ED for ; Wed, 30 Aug 2017 12:51:02 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id c82so2297644vkd.9 for ; Wed, 30 Aug 2017 10:51:02 -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=HneEMQY644pYvwqZ5t5G7OnVq65Z4On/ZwlTBa/S5HE=; b=JjKFhas1CTncvJa5QNeyyFw7oIvRsW3kFnpEUz9YUitrFJdUIsWqNEOUg4/RgnsA1N C9rrwUyEWIii96T64UTY1C677ZAhGOxDVs7snOm0dS3pqjl5VD8NDx+n2WYiaSd5i6eE J9NWzO7NcKEjpBfYXMAammUffnDDOqi1Bp2q9yKOYJW5Khx5DsqzXrfrsGCJWI5Mdtdp hkOVpBWiursa92lAGEfrsLer/DzKPg1IwDzianTJ5Dfg4/fpA+H9DHl8tVqlWqWuy6Qy kXe/OkSEK9vcwjXhofptew02jpCfL5j0sP84jCZ+xjhcpl+ny39GNOHcOjMR03OIBU6Y HULg== 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=HneEMQY644pYvwqZ5t5G7OnVq65Z4On/ZwlTBa/S5HE=; b=Kj/praRUPtSYn6oVU+5OTtGQKejdauXXF08BMjrZ8YeOj6H2dNDmvT9JUndNJ8VyKL fmJ42SYhdiip4Cw8nO5+MqyD3czKdyJhHb45adk9aoiTClZl+3X18Wu9X4wxnynBoY87 eI9Eggbwvr7dzpukrPmCMY/AmTrAJo75O+MdOVmXZXnJK6B0VqshzEw/ecJAlLi2YKZW DCYAgHvTzhEB95BU40lCrt39Q8cILDSJfvoUIS9TJ9N6Sz7hMn6jDqQMI3bziFl11D10 gJh1TkS8o0dW2s85kdW8geT67Sf9A4g7e/MSE3agDuTj4zijjoQp+Wvftuuwah7SEWt7 uiWQ== X-Gm-Message-State: AHYfb5jPmNPOm/gMwg/NENNDuh2m8PQO+PgGdaJu0UTPZWc4AlUdPKy3 4Mo2LuTpCzKsnlR8vgSDLqZaF0lAGomEVARg3GNTpMGBJWAtuDpzVGqGr0aD0dlYRZUxBir9AkT 4KzMvJyLijdWp+ZrO X-Received: by 10.159.38.82 with SMTP id 76mr1661441uag.160.1504115461771; Wed, 30 Aug 2017 10:51:01 -0700 (PDT) X-Received: by 10.159.38.82 with SMTP id 76mr1661429uag.160.1504115461412; Wed, 30 Aug 2017 10:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Wed, 30 Aug 2017 10:51:00 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Wed, 30 Aug 2017 12:51:00 -0500 Message-ID: To: Tim Chown Cc: Lorenzo Colitti , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a113cf852c79d6c0557fc2bf8" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:51:06 -0000 --001a113cf852c79d6c0557fc2bf8 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 10:15 AM, Tim Chown wrote: > > On 30 Aug 2017, at 16:07, Lorenzo Colitti wrote: > > > > On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > So, I see this being a very simple document that wraps itself around > RFC4861. > > > > RFC4861 security considerations also apply (including RFC3756) and this > doc > > > > should not be in the business of unnecessarily restricting the domain of > > > > applicability. > > > > I think you're entirely missing the goal of this document. It's written > clearly in the applicability statement section that the text applies to > situations where: > > > > o Two devices (subscriber/hosts), both attached to the same provider > > managed shared network should only be able to communicate through > > the provider managed First Hop Router > > > > This is an extremely desirable security property in any environment > where trust between devices is limited. In such environments, standard > SLAAC on shared links cannot be made reliable in the presence of buggy or > malicious hosts without brittle hacks that don't scale, and is thus a > non-starter from a an operational point of view unless the devices are > tightly controlled. Thus, there are very solid operational reasons to limit > the scope of applicability to such networks. > > > > If you can convincingly argue that security or reliability would not be > lessened by allowing direct peer-to-peer communication, then sure, the > scope of applicability of this draft can be expanded. I don't think you'll > be able to convincingly argue that. Saying "it's no worse than standard > SLAAC" is not a convincing argument, because standard SLAAC has known > security and reliability issues in this sort of environment. > > Indeed; the isolation property is one of the key attractions of the draft. > Furthermore, it is this desirable and key security property that justifies what would otherwise seem to be a wasteful use of number resources. With the applicability limited to situation where if it was practical for security reasons, you would have put each host on it own physical interface and therefore it's subnet anyway, then the there is an argument to be made that this practice isn't wasteful. However, if there is no additional security provided over that of the normal multiple host per subnet model, then what justifies the use of a 1000 /64s for a 1000 hosts when one prefix would have easily been sufficient? Fred, you seem to want to make this generally applicable to almost any situation. If that the case, then you have to answer the question of what justifies that level of number resource utilization, if its not the security advantage of separating hosts. One of the reasons we justify /64 subnets in the first place, is to ensure there is no practical limit, based on addressing, to how many hosts you put in a subnet. There is a limit, but it has nothing to do with the IPv6 addressing architecture. Security architecture is one of the limits on how many and what hosts you put in any particular subnet. So, I will repeat myself; The subnet per host model is not a generalized or universal replacement for the multiple host per subnet model. And I will add to that; The subnet per host model is only justified by the desirable and key security property of host separation provided in the scope of applicability. That said, the details of how this security property of host separation is intended to be implemented needs a better description in the draft, and the consequences of not or only partly implementing it needs to be discussed in the security considerations. 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 =============================================== --001a113cf852c79d6c0557fc2bf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Wed, Aug 30, 2017 at 10:15 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
    &= gt; On 30 Aug 2017, at 16:07, Lorenzo Colitti <lorenzo@google.com> wrote:
    >
    > On Tue, Aug 29, 2017 at 3:31 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
    > So, I see this being a very simple document that wraps itself around R= FC4861.
    >
    > RFC4861 security considerations also apply (including RFC3756) and thi= s doc
    >
    > should not be in the business of unnecessarily restricting the domain = of
    >
    > applicability.
    >
    > I think you're entirely missing the goal of this document. It'= s written clearly in the applicability statement section that the text appl= ies to situations where:
    >
    >=C2=A0 =C2=A0 o=C2=A0 Two devices (subscriber/hosts), both attached to = the same provider
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able t= o communicate through
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router
    >
    > This is an extremely desirable security property in any environment wh= ere trust between devices is limited. In such environments, standard SLAAC = on shared links cannot be made reliable in the presence of buggy or malicio= us hosts without brittle hacks that don't scale, and is thus a non-star= ter from a an operational point of view unless the devices are tightly cont= rolled. Thus, there are very solid operational reasons to limit the scope o= f applicability to such networks.
    >
    > If you can convincingly argue that security or reliability would not b= e lessened by allowing direct peer-to-peer communication, then sure, the sc= ope of applicability of this draft can be expanded. I don't think you&#= 39;ll be able to convincingly argue that. Saying "it's no worse th= an standard SLAAC" is not a convincing argument, because standard SLAA= C has known security and reliability issues in this sort of environment.
    Indeed; the isolation property is one of the key attractions of the draft.<= br>
    =C2=A0
    Furthermo= re, it is this desirable and key security property that justifies what woul= d otherwise seem to be a wasteful use of number resources. With the applica= bility limited to situation where if it was practical for security reasons,= you would have put each host on it own physical interface and therefore it= 's subnet anyway, then the there is an argument to be made that this pr= actice isn't wasteful.=C2=A0 However, if there is no additional securit= y provided over that of the normal multiple host per subnet model, then wha= t justifies the use of a 1000 /64s for a 1000 hosts when one prefix would h= ave easily been sufficient?=C2=A0

    Fred, you seem to want to make this generally a= pplicable to almost any situation. If that the case, then you have to answe= r the question of what justifies that level of number resource utilization,= if its not the security advantage of separating hosts.=C2=A0

    One of the reasons = we justify /64 subnets in the first place, is to ensure there is no practic= al limit, based on addressing, to how many hosts you put in a subnet.=C2=A0= There is a limit, but it has nothing to do with the IPv6 addressing archit= ecture. Security architecture is one of the limits on how many and what hos= ts you put in any particular subnet.
    <= br>
    So, I will repeat myself; =C2=A0The subnet per host model=C2= =A0is not a generalized or universal replacement for the multiple host per = subnet model.

    And I will add to that; The subnet p= er host model is only justified by the desirable and key security property = of host separation provided=C2=A0in the scope of applicability.=C2=A0
    =

    That said, the details of how this security property of= host separation is intended to be implemented needs a better description i= n the draft, and the consequences of not or only partly implementing it nee= ds to be discussed in the security considerations. =C2=A0=C2=A0
    <= 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 <= 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
    --001a113cf852c79d6c0557fc2bf8-- From nobody Wed Aug 30 13:57:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB7F1321B0 for ; Wed, 30 Aug 2017 13:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uEcj_hmQYSmp for ; Wed, 30 Aug 2017 13:57:06 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD2F1321D8 for ; Wed, 30 Aug 2017 13:57:06 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id r62so22477470pfj.0 for ; Wed, 30 Aug 2017 13:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=c5xtApkSRKp1YoH0caUgnKOfFC92mEl6y5SfifuXda0=; b=giPfd+ZoeG/4ZNHMkN0MBODoJN7NlVUy86323onnEMZyeQa2TBYsHwOzQvcY6Os1zd friqzg56GBQpoACGEL6xKYuyOT17UoCcZbm2bfiLQGZ8ATAbjrv7Gw8124ZWbOR6KR6M t1RLYoeKLFfqjohWSs5VuLGZ04bS1rNHyaNhlMHQjC+jpgTTgU+bLQDs9Rqmg/jzZXva TMoo4rNMJKaMTvaZT4MDmY2MLMzntqxSz90Lq+MuFaTxJ9ZQq3t1n4TS9W1u0+2fGo1m j6oOaXdVe8eMBkw5FH4/0TILEcemMIHeix0Ezs55s/VInoOrJ7mUZFMKLfi+qRO7NaQC L3Kg== 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=c5xtApkSRKp1YoH0caUgnKOfFC92mEl6y5SfifuXda0=; b=SB/EezGVF3/tsOefRNYjIoAyvsThLnb9YM+uBDoWHPKOWfeQ7aMvuUCBYGQl1nZSAd wcUzH+7WJgqEapxj+FJS1LWdQiBpE5GYxA2rSWM9/7PIcsOXUqOuTr3VWSxTkdwE3ANc JB0cThFchYnUJHZ2DayquWNz95z8cuhJIeeD3qp/7gl71b2MXyxGglZr+0LGtB/wh5ez l3m8qEJxHsVyQzuhs4NqjM3ZFjHyw2g5YEA9+PnV0Q1U3YXkvG7tW6F6mdRC4a17AoBA xz0vXEkeUBVUYN9sYu4wZjtFNxWQL0OCkBXBSNskTYHVfKyKitdSS3ictdUChezvx2dU SrqQ== X-Gm-Message-State: AHYfb5gzauwJ+2grkUOXYhwfzgteyNaiDafmG0Fdl3HAPha6bqxE6GtG ZKOmLipmJXbXe/ExYnzYDA== X-Google-Smtp-Source: ADKCNb6rzYsHsNStEs6tbcd7emAz20yU7g3kwQWGvHejujubV9eKLy+Wp5I35DzV4PEN/ezECDTJ6A== X-Received: by 10.99.95.131 with SMTP id t125mr2941416pgb.344.1504126625424; Wed, 30 Aug 2017 13:57:05 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:e01f:d6da:2112:387b? ([2620:0:10e7:10:e01f:d6da:2112:387b]) by smtp.gmail.com with ESMTPSA id 13sm10301227pfr.166.2017.08.30.13.57.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 13:57:04 -0700 (PDT) From: james woodyatt Message-Id: <11208AD4-084B-4A56-AC79-ECC81FD027CC@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0ACF20A3-239D-4531-BF86-C31FD89240D5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 13:57:04 -0700 In-Reply-To: Cc: "v6ops@ietf.org" To: David Farmer References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:57:08 -0000 --Apple-Mail=_0ACF20A3-239D-4531-BF86-C31FD89240D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 30, 2017, at 10:51, David Farmer wrote: >=20 > [=E2=80=A6] And I will add to that; The subnet per host model is only = justified by the desirable and key security property of host separation = provided in the scope of applicability.=20 >=20 > That said, the details of how this security property of host = separation is intended to be implemented needs a better description in = the draft, and the consequences of not or only partly implementing it = needs to be discussed in the security considerations. Then I=E2=80=99m in agreement. Please add appropriate language in = section 5 to make clear that this draft documents a Best Current = Practice for use ONLY in networks where individual UE/subscriber hosts = are isolated at layer-2 and IPv6 Neighbor Discovery is blocked between = them. Please also add further additional language in the Security = Consideration section that details the risks and hazards of failing to = do so. --james woodyatt > --Apple-Mail=_0ACF20A3-239D-4531-BF86-C31FD89240D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 30, 2017, at 10:51, David Farmer <farmer@umn.edu> = wrote:

    [=E2=80=A6] And I will add to that; The subnet per host model = is only justified by the desirable and key security property of host = separation provided in the scope of applicability. 
    That said, the details of = how this security property of host separation is intended to be = implemented needs a better description in the draft, and the = consequences of not or only partly implementing it needs to be discussed = in the security considerations.

    Then I=E2=80=99m in = agreement. Please add appropriate language in section 5 to make clear = that this draft documents a Best Current Practice for use ONLY in = networks where individual UE/subscriber hosts are isolated at layer-2 = and IPv6 Neighbor Discovery is blocked between them. Please also add = further additional language in the Security Consideration section that = details the risks and hazards of failing to do so.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_0ACF20A3-239D-4531-BF86-C31FD89240D5-- From nobody Wed Aug 30 14:22:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3AA132A05; Wed, 30 Aug 2017 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuUZWhzE943J; Wed, 30 Aug 2017 14:22:34 -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 8908813240D; Wed, 30 Aug 2017 14:22:33 -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 v7ULMWol030330; Wed, 30 Aug 2017 14:22:32 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7ULMSqM030300 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 30 Aug 2017 14:22:28 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 30 Aug 2017 14:22:28 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 30 Aug 2017 14:22:28 -0700 From: "Templin, Fred L" To: David Farmer , Tim Chown CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKAABmowzAAMCdaBQAHEcpA Date: Wed, 30 Aug 2017 21:22:27 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b54c31f113444e5c84a9c69c308c2562XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:22:38 -0000 --_000_b54c31f113444e5c84a9c69c308c2562XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFnYWluIHRoaXMgZG9jdW1lbnQgaXMgbm90aGluZyBtb3JlIHRoYW4gYW4gZXhwcmVzc2lv biBvZiB3aGF0IGlzIGFscmVhZHkNCmluIFJGQzQ4NjEsIGJ1dCB0aGVuIGl0IGFkZHMgY29uc3Ry YWludHMgdGhhdCBkb27igJl0IG5lZWQgdG8gYmUgdGhlcmUuIElmIHRoZQ0KUElPIGhhcyBBPTEs IEw9MCB0aGVuIGJ5IFJGQzQ4NjEgdGhlIGhvc3Qgd2lsbCBhdXRvY29uZmlndXJlIG9uZSBvciBt b3JlDQphZGRyZXNzZXMgYW5kIHNlbmQgcGFja2V0cyB2aWEgdGhlIGRlZmF1bHQgcm91dGVyIChz aW5jZSDigJhM4oCZIGlzIDApIHVubGVzcw0KdGhlcmUgaXMgYSBtb3JlLXNwZWNpZmljIHJvdXRl Lg0KDQpCdXQsIHRoZSByb3V0ZXIgbWF5IHNlbmQgYSBSZWRpcmVjdCBhbmQgdGhlcmVmb3JlIHN1 YnNlcXVlbnQgcGFja2V0cyBjb3VsZA0KZ28gZnJvbSBwZWVyLXRvLXBlZXIgd2l0aG91dCBoYXZp bmcgdG8gZ28gdGhyb3VnaCB0aGUgcm91dGVyLiBUaGlzIGRvY3VtZW50DQpzaG91bGQgbm90IGJl IGluIHRoZSBidXNpbmVzcyBvZiBkaXNhYmxpbmcgb3IgZGlzYWxsb3dpbmcgdGhlIFJlZGlyZWN0 IGZ1bmN0aW9uLA0Kd2hpY2ggaXMgYSBjb3JlIGVsZW1lbnQgb2YgSVB2NiBORCBhbmQgbmVjZXNz YXJ5IGZvciBzb21lIGxpbmsgdHlwZXMuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgRmFybWVy DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyAxMDo1MSBBTQ0KVG86IFRpbSBDaG93 biA8VGltLkNob3duQGppc2MuYWMudWs+DQpDYzogdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWly c0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb21t ZW50IG9uICdkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNycN Cg0KDQoNCk9uIFdlZCwgQXVnIDMwLCAyMDE3IGF0IDEwOjE1IEFNLCBUaW0gQ2hvd24gPFRpbS5D aG93bkBqaXNjLmFjLnVrPG1haWx0bzpUaW0uQ2hvd25AamlzYy5hYy51az4+IHdyb3RlOg0KPiBP biAzMCBBdWcgMjAxNywgYXQgMTY6MDcsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUu Y29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNCj4NCj4gT24gVHVlLCBBdWcg MjksIDIwMTcgYXQgMzozMSBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQo+IFNvLCBJ IHNlZSB0aGlzIGJlaW5nIGEgdmVyeSBzaW1wbGUgZG9jdW1lbnQgdGhhdCB3cmFwcyBpdHNlbGYg YXJvdW5kIFJGQzQ4NjEuDQo+DQo+IFJGQzQ4NjEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYWxz byBhcHBseSAoaW5jbHVkaW5nIFJGQzM3NTYpIGFuZCB0aGlzIGRvYw0KPg0KPiBzaG91bGQgbm90 IGJlIGluIHRoZSBidXNpbmVzcyBvZiB1bm5lY2Vzc2FyaWx5IHJlc3RyaWN0aW5nIHRoZSBkb21h aW4gb2YNCj4NCj4gYXBwbGljYWJpbGl0eS4NCj4NCj4gSSB0aGluayB5b3UncmUgZW50aXJlbHkg bWlzc2luZyB0aGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50LiBJdCdzIHdyaXR0ZW4gY2xlYXJseSBp biB0aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2VjdGlvbiB0aGF0IHRoZSB0ZXh0IGFwcGxp ZXMgdG8gc2l0dWF0aW9ucyB3aGVyZToNCj4NCj4gICAgbyAgVHdvIGRldmljZXMgKHN1YnNjcmli ZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQo+ICAgICAgIG1h bmFnZWQgc2hhcmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0 aHJvdWdoDQo+ICAgICAgIHRoZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXINCj4N Cj4gVGhpcyBpcyBhbiBleHRyZW1lbHkgZGVzaXJhYmxlIHNlY3VyaXR5IHByb3BlcnR5IGluIGFu eSBlbnZpcm9ubWVudCB3aGVyZSB0cnVzdCBiZXR3ZWVuIGRldmljZXMgaXMgbGltaXRlZC4gSW4g c3VjaCBlbnZpcm9ubWVudHMsIHN0YW5kYXJkIFNMQUFDIG9uIHNoYXJlZCBsaW5rcyBjYW5ub3Qg YmUgbWFkZSByZWxpYWJsZSBpbiB0aGUgcHJlc2VuY2Ugb2YgYnVnZ3kgb3IgbWFsaWNpb3VzIGhv c3RzIHdpdGhvdXQgYnJpdHRsZSBoYWNrcyB0aGF0IGRvbid0IHNjYWxlLCBhbmQgaXMgdGh1cyBh IG5vbi1zdGFydGVyIGZyb20gYSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3IHVubGVzcyB0 aGUgZGV2aWNlcyBhcmUgdGlnaHRseSBjb250cm9sbGVkLiBUaHVzLCB0aGVyZSBhcmUgdmVyeSBz b2xpZCBvcGVyYXRpb25hbCByZWFzb25zIHRvIGxpbWl0IHRoZSBzY29wZSBvZiBhcHBsaWNhYmls aXR5IHRvIHN1Y2ggbmV0d29ya3MuDQo+DQo+IElmIHlvdSBjYW4gY29udmluY2luZ2x5IGFyZ3Vl IHRoYXQgc2VjdXJpdHkgb3IgcmVsaWFiaWxpdHkgd291bGQgbm90IGJlIGxlc3NlbmVkIGJ5IGFs bG93aW5nIGRpcmVjdCBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiwgdGhlbiBzdXJlLCB0aGUg c2NvcGUgb2YgYXBwbGljYWJpbGl0eSBvZiB0aGlzIGRyYWZ0IGNhbiBiZSBleHBhbmRlZC4gSSBk b24ndCB0aGluayB5b3UnbGwgYmUgYWJsZSB0byBjb252aW5jaW5nbHkgYXJndWUgdGhhdC4gU2F5 aW5nICJpdCdzIG5vIHdvcnNlIHRoYW4gc3RhbmRhcmQgU0xBQUMiIGlzIG5vdCBhIGNvbnZpbmNp bmcgYXJndW1lbnQsIGJlY2F1c2Ugc3RhbmRhcmQgU0xBQUMgaGFzIGtub3duIHNlY3VyaXR5IGFu ZCByZWxpYWJpbGl0eSBpc3N1ZXMgaW4gdGhpcyBzb3J0IG9mIGVudmlyb25tZW50Lg0KDQpJbmRl ZWQ7IHRoZSBpc29sYXRpb24gcHJvcGVydHkgaXMgb25lIG9mIHRoZSBrZXkgYXR0cmFjdGlvbnMg b2YgdGhlIGRyYWZ0Lg0KDQpGdXJ0aGVybW9yZSwgaXQgaXMgdGhpcyBkZXNpcmFibGUgYW5kIGtl eSBzZWN1cml0eSBwcm9wZXJ0eSB0aGF0IGp1c3RpZmllcyB3aGF0IHdvdWxkIG90aGVyd2lzZSBz ZWVtIHRvIGJlIGEgd2FzdGVmdWwgdXNlIG9mIG51bWJlciByZXNvdXJjZXMuIFdpdGggdGhlIGFw cGxpY2FiaWxpdHkgbGltaXRlZCB0byBzaXR1YXRpb24gd2hlcmUgaWYgaXQgd2FzIHByYWN0aWNh bCBmb3Igc2VjdXJpdHkgcmVhc29ucywgeW91IHdvdWxkIGhhdmUgcHV0IGVhY2ggaG9zdCBvbiBp dCBvd24gcGh5c2ljYWwgaW50ZXJmYWNlIGFuZCB0aGVyZWZvcmUgaXQncyBzdWJuZXQgYW55d2F5 LCB0aGVuIHRoZSB0aGVyZSBpcyBhbiBhcmd1bWVudCB0byBiZSBtYWRlIHRoYXQgdGhpcyBwcmFj dGljZSBpc24ndCB3YXN0ZWZ1bC4gIEhvd2V2ZXIsIGlmIHRoZXJlIGlzIG5vIGFkZGl0aW9uYWwg c2VjdXJpdHkgcHJvdmlkZWQgb3ZlciB0aGF0IG9mIHRoZSBub3JtYWwgbXVsdGlwbGUgaG9zdCBw ZXIgc3VibmV0IG1vZGVsLCB0aGVuIHdoYXQganVzdGlmaWVzIHRoZSB1c2Ugb2YgYSAxMDAwIC82 NHMgZm9yIGEgMTAwMCBob3N0cyB3aGVuIG9uZSBwcmVmaXggd291bGQgaGF2ZSBlYXNpbHkgYmVl biBzdWZmaWNpZW50Pw0KDQpGcmVkLCB5b3Ugc2VlbSB0byB3YW50IHRvIG1ha2UgdGhpcyBnZW5l cmFsbHkgYXBwbGljYWJsZSB0byBhbG1vc3QgYW55IHNpdHVhdGlvbi4gSWYgdGhhdCB0aGUgY2Fz ZSwgdGhlbiB5b3UgaGF2ZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uIG9mIHdoYXQganVzdGlmaWVz IHRoYXQgbGV2ZWwgb2YgbnVtYmVyIHJlc291cmNlIHV0aWxpemF0aW9uLCBpZiBpdHMgbm90IHRo ZSBzZWN1cml0eSBhZHZhbnRhZ2Ugb2Ygc2VwYXJhdGluZyBob3N0cy4NCg0KT25lIG9mIHRoZSBy ZWFzb25zIHdlIGp1c3RpZnkgLzY0IHN1Ym5ldHMgaW4gdGhlIGZpcnN0IHBsYWNlLCBpcyB0byBl bnN1cmUgdGhlcmUgaXMgbm8gcHJhY3RpY2FsIGxpbWl0LCBiYXNlZCBvbiBhZGRyZXNzaW5nLCB0 byBob3cgbWFueSBob3N0cyB5b3UgcHV0IGluIGEgc3VibmV0LiAgVGhlcmUgaXMgYSBsaW1pdCwg YnV0IGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIElQdjYgYWRkcmVzc2luZyBhcmNoaXRl Y3R1cmUuIFNlY3VyaXR5IGFyY2hpdGVjdHVyZSBpcyBvbmUgb2YgdGhlIGxpbWl0cyBvbiBob3cg bWFueSBhbmQgd2hhdCBob3N0cyB5b3UgcHV0IGluIGFueSBwYXJ0aWN1bGFyIHN1Ym5ldC4NCg0K U28sIEkgd2lsbCByZXBlYXQgbXlzZWxmOyAgVGhlIHN1Ym5ldCBwZXIgaG9zdCBtb2RlbCBpcyBu b3QgYSBnZW5lcmFsaXplZCBvciB1bml2ZXJzYWwgcmVwbGFjZW1lbnQgZm9yIHRoZSBtdWx0aXBs ZSBob3N0IHBlciBzdWJuZXQgbW9kZWwuDQoNCkFuZCBJIHdpbGwgYWRkIHRvIHRoYXQ7IFRoZSBz dWJuZXQgcGVyIGhvc3QgbW9kZWwgaXMgb25seSBqdXN0aWZpZWQgYnkgdGhlIGRlc2lyYWJsZSBh bmQga2V5IHNlY3VyaXR5IHByb3BlcnR5IG9mIGhvc3Qgc2VwYXJhdGlvbiBwcm92aWRlZCBpbiB0 aGUgc2NvcGUgb2YgYXBwbGljYWJpbGl0eS4NCg0KVGhhdCBzYWlkLCB0aGUgZGV0YWlscyBvZiBo b3cgdGhpcyBzZWN1cml0eSBwcm9wZXJ0eSBvZiBob3N0IHNlcGFyYXRpb24gaXMgaW50ZW5kZWQg dG8gYmUgaW1wbGVtZW50ZWQgbmVlZHMgYSBiZXR0ZXIgZGVzY3JpcHRpb24gaW4gdGhlIGRyYWZ0 LCBhbmQgdGhlIGNvbnNlcXVlbmNlcyBvZiBub3Qgb3Igb25seSBwYXJ0bHkgaW1wbGVtZW50aW5n IGl0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu DQoNClRoYW5rcy4NCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVk dTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVu aWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZl cnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTog NjEyLTYyNi0wODE1DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENlbGw6IDYxMi04MTIt OTk1Mg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== --_000_b54c31f113444e5c84a9c69c308c2562XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBhZ2FpbiB0aGlzIGRvY3VtZW50IGlz IG5vdGhpbmcgbW9yZSB0aGFuIGFuIGV4cHJlc3Npb24gb2Ygd2hhdCBpcyBhbHJlYWR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmluIFJGQzQ4NjEsIGJ1dCB0aGVuIGl0IGFkZHMgY29uc3RyYWludHMgdGhh dCBkb27igJl0IG5lZWQgdG8gYmUgdGhlcmUuIElmIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QSU8g aGFzIEE9MSwgTD0wIHRoZW4gYnkgUkZDNDg2MSB0aGUgaG9zdCB3aWxsIGF1dG9jb25maWd1cmUg b25lIG9yIG1vcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YWRkcmVzc2VzIGFuZCBzZW5kIHBhY2tldHMg dmlhIHRoZSBkZWZhdWx0IHJvdXRlciAoc2luY2Ug4oCYTOKAmSBpcyAwKSB1bmxlc3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+dGhlcmUgaXMgYSBtb3JlLXNwZWNpZmljIHJvdXRlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnV0LCB0aGUgcm91dGVyIG1heSBzZW5kIGEg UmVkaXJlY3QgYW5kIHRoZXJlZm9yZSBzdWJzZXF1ZW50IHBhY2tldHMgY291bGQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Z28gZnJvbSBwZWVyLXRvLXBlZXIgd2l0aG91dCBoYXZpbmcgdG8gZ28gdGhyb3Vn aCB0aGUgcm91dGVyLiBUaGlzIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNob3VsZCBub3Qg YmUgaW4gdGhlIGJ1c2luZXNzIG9mIGRpc2FibGluZyBvciBkaXNhbGxvd2luZyB0aGUgUmVkaXJl Y3QgZnVuY3Rpb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndoaWNoIGlzIGEgY29yZSBlbGVtZW50IG9m IElQdjYgTkQgYW5kIG5lY2Vzc2FyeSBmb3Igc29tZSBsaW5rIHR5cGVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ RGF2aWQgRmFybWVyPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3 IDEwOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBUaW0gQ2hvd24gJmx0O1RpbS5DaG93bkBqaXNjLmFj LnVrJmd0Ozxicj4NCjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWlyc0BpZXRm Lm9yZzsgdjZvcHMtYWRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNd IENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTA3JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1 ZyAzMCwgMjAxNyBhdCAxMDoxNSBBTSwgVGltIENob3duICZsdDs8YSBocmVmPSJtYWlsdG86VGlt LkNob3duQGppc2MuYWMudWsiIHRhcmdldD0iX2JsYW5rIj5UaW0uQ2hvd25AamlzYy5hYy51azwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgT24gMzAgQXVnIDIwMTcsIGF0IDE2OjA3LCBMb3JlbnpvIENvbGl0dGkgJmx0 OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0 IDM6MzEgQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1w bGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IFNvLCBJIHNlZSB0aGlzIGJlaW5nIGEgdmVyeSBzaW1wbGUgZG9jdW1lbnQgdGhh dCB3cmFwcyBpdHNlbGYgYXJvdW5kIFJGQzQ4NjEuPGJyPg0KJmd0Ozxicj4NCiZndDsgUkZDNDg2 MSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbHNvIGFwcGx5IChpbmNsdWRpbmcgUkZDMzc1Nikg YW5kIHRoaXMgZG9jPGJyPg0KJmd0Ozxicj4NCiZndDsgc2hvdWxkIG5vdCBiZSBpbiB0aGUgYnVz aW5lc3Mgb2YgdW5uZWNlc3NhcmlseSByZXN0cmljdGluZyB0aGUgZG9tYWluIG9mPGJyPg0KJmd0 Ozxicj4NCiZndDsgYXBwbGljYWJpbGl0eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIHlv dSdyZSBlbnRpcmVseSBtaXNzaW5nIHRoZSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQuIEl0J3Mgd3Jp dHRlbiBjbGVhcmx5IGluIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzZWN0aW9uIHRoYXQg dGhlIHRleHQgYXBwbGllcyB0byBzaXR1YXRpb25zIHdoZXJlOjxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyBvJm5ic3A7IFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3RzKSwgYm90 aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgdGhyb3VnaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhpcyBpcyBhbiBleHRyZW1lbHkgZGVzaXJhYmxlIHNlY3VyaXR5IHByb3BlcnR5IGluIGFueSBl bnZpcm9ubWVudCB3aGVyZSB0cnVzdCBiZXR3ZWVuIGRldmljZXMgaXMgbGltaXRlZC4gSW4gc3Vj aCBlbnZpcm9ubWVudHMsIHN0YW5kYXJkIFNMQUFDIG9uIHNoYXJlZCBsaW5rcyBjYW5ub3QgYmUg bWFkZSByZWxpYWJsZSBpbiB0aGUgcHJlc2VuY2Ugb2YgYnVnZ3kgb3IgbWFsaWNpb3VzIGhvc3Rz IHdpdGhvdXQgYnJpdHRsZSBoYWNrcyB0aGF0DQogZG9uJ3Qgc2NhbGUsIGFuZCBpcyB0aHVzIGEg bm9uLXN0YXJ0ZXIgZnJvbSBhIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcgdW5sZXNzIHRo ZSBkZXZpY2VzIGFyZSB0aWdodGx5IGNvbnRyb2xsZWQuIFRodXMsIHRoZXJlIGFyZSB2ZXJ5IHNv bGlkIG9wZXJhdGlvbmFsIHJlYXNvbnMgdG8gbGltaXQgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxp dHkgdG8gc3VjaCBuZXR3b3Jrcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB5b3UgY2FuIGNvbnZp bmNpbmdseSBhcmd1ZSB0aGF0IHNlY3VyaXR5IG9yIHJlbGlhYmlsaXR5IHdvdWxkIG5vdCBiZSBs ZXNzZW5lZCBieSBhbGxvd2luZyBkaXJlY3QgcGVlci10by1wZWVyIGNvbW11bmljYXRpb24sIHRo ZW4gc3VyZSwgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgb2YgdGhpcyBkcmFmdCBjYW4gYmUg ZXhwYW5kZWQuIEkgZG9uJ3QgdGhpbmsgeW91J2xsIGJlIGFibGUgdG8gY29udmluY2luZ2x5IGFy Z3VlIHRoYXQuIFNheWluZw0KICZxdW90O2l0J3Mgbm8gd29yc2UgdGhhbiBzdGFuZGFyZCBTTEFB QyZxdW90OyBpcyBub3QgYSBjb252aW5jaW5nIGFyZ3VtZW50LCBiZWNhdXNlIHN0YW5kYXJkIFNM QUFDIGhhcyBrbm93biBzZWN1cml0eSBhbmQgcmVsaWFiaWxpdHkgaXNzdWVzIGluIHRoaXMgc29y dCBvZiBlbnZpcm9ubWVudC48YnI+DQo8YnI+DQpJbmRlZWQ7IHRoZSBpc29sYXRpb24gcHJvcGVy dHkgaXMgb25lIG9mIHRoZSBrZXkgYXR0cmFjdGlvbnMgb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5GdXJ0aGVybW9yZSwgaXQgaXMgdGhpcyBkZXNpcmFibGUgYW5kIGtleSBzZWN1cml0eSBwcm9w ZXJ0eSB0aGF0IGp1c3RpZmllcyB3aGF0IHdvdWxkIG90aGVyd2lzZSBzZWVtIHRvIGJlIGEgd2Fz dGVmdWwgdXNlIG9mIG51bWJlciByZXNvdXJjZXMuIFdpdGggdGhlIGFwcGxpY2FiaWxpdHkgbGlt aXRlZCB0byBzaXR1YXRpb24gd2hlcmUgaWYgaXQgd2FzIHByYWN0aWNhbCBmb3Igc2VjdXJpdHkg cmVhc29ucywgeW91DQogd291bGQgaGF2ZSBwdXQgZWFjaCBob3N0IG9uIGl0IG93biBwaHlzaWNh bCBpbnRlcmZhY2UgYW5kIHRoZXJlZm9yZSBpdCdzIHN1Ym5ldCBhbnl3YXksIHRoZW4gdGhlIHRo ZXJlIGlzIGFuIGFyZ3VtZW50IHRvIGJlIG1hZGUgdGhhdCB0aGlzIHByYWN0aWNlIGlzbid0IHdh c3RlZnVsLiZuYnNwOyBIb3dldmVyLCBpZiB0aGVyZSBpcyBubyBhZGRpdGlvbmFsIHNlY3VyaXR5 IHByb3ZpZGVkIG92ZXIgdGhhdCBvZiB0aGUgbm9ybWFsIG11bHRpcGxlIGhvc3QNCiBwZXIgc3Vi bmV0IG1vZGVsLCB0aGVuIHdoYXQganVzdGlmaWVzIHRoZSB1c2Ugb2YgYSAxMDAwIC82NHMgZm9y IGEgMTAwMCBob3N0cyB3aGVuIG9uZSBwcmVmaXggd291bGQgaGF2ZSBlYXNpbHkgYmVlbiBzdWZm aWNpZW50PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5GcmVkLCB5b3Ugc2VlbSB0byB3YW50IHRvIG1ha2UgdGhpcyBnZW5lcmFsbHkg YXBwbGljYWJsZSB0byBhbG1vc3QgYW55IHNpdHVhdGlvbi4gSWYgdGhhdCB0aGUgY2FzZSwgdGhl biB5b3UgaGF2ZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uIG9mIHdoYXQganVzdGlmaWVzIHRoYXQg bGV2ZWwgb2YgbnVtYmVyIHJlc291cmNlIHV0aWxpemF0aW9uLCBpZiBpdHMgbm90IHRoZSBzZWN1 cml0eSBhZHZhbnRhZ2Ugb2Ygc2VwYXJhdGluZw0KIGhvc3RzLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgb2YgdGhlIHJlYXNv bnMgd2UganVzdGlmeSAvNjQgc3VibmV0cyBpbiB0aGUgZmlyc3QgcGxhY2UsIGlzIHRvIGVuc3Vy ZSB0aGVyZSBpcyBubyBwcmFjdGljYWwgbGltaXQsIGJhc2VkIG9uIGFkZHJlc3NpbmcsIHRvIGhv dyBtYW55IGhvc3RzIHlvdSBwdXQgaW4gYSBzdWJuZXQuJm5ic3A7IFRoZXJlIGlzIGEgbGltaXQs IGJ1dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBJUHY2IGFkZHJlc3NpbmcgYXJjaGl0 ZWN0dXJlLg0KIFNlY3VyaXR5IGFyY2hpdGVjdHVyZSBpcyBvbmUgb2YgdGhlIGxpbWl0cyBvbiBo b3cgbWFueSBhbmQgd2hhdCBob3N0cyB5b3UgcHV0IGluIGFueSBwYXJ0aWN1bGFyIHN1Ym5ldC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvLCBJIHdpbGwgcmVwZWF0IG15c2VsZjsgJm5ic3A7VGhlIHN1Ym5ldCBwZXIgaG9zdCBt b2RlbCZuYnNwO2lzIG5vdCBhIGdlbmVyYWxpemVkIG9yIHVuaXZlcnNhbCByZXBsYWNlbWVudCBm b3IgdGhlIG11bHRpcGxlIGhvc3QgcGVyIHN1Ym5ldCBtb2RlbC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIEkgd2lsbCBhZGQgdG8gdGhh dDsgVGhlIHN1Ym5ldCBwZXIgaG9zdCBtb2RlbCBpcyBvbmx5IGp1c3RpZmllZCBieSB0aGUgZGVz aXJhYmxlIGFuZCBrZXkgc2VjdXJpdHkgcHJvcGVydHkgb2YgaG9zdCBzZXBhcmF0aW9uIHByb3Zp ZGVkJm5ic3A7aW4gdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc2FpZCwgdGhl IGRldGFpbHMgb2YgaG93IHRoaXMgc2VjdXJpdHkgcHJvcGVydHkgb2YgaG9zdCBzZXBhcmF0aW9u IGlzIGludGVuZGVkIHRvIGJlIGltcGxlbWVudGVkIG5lZWRzIGEgYmV0dGVyIGRlc2NyaXB0aW9u IGluIHRoZSBkcmFmdCwgYW5kIHRoZSBjb25zZXF1ZW5jZXMgb2Ygbm90IG9yIG9ubHkgcGFydGx5 IGltcGxlbWVudGluZyBpdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5DQog Y29uc2lkZXJhdGlvbnMuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxicj4NCkRhdmlkIEZhcm1lciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86RW1haWwlM0FmYXJt ZXJAdW1uLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPg0KRW1haWw6ZmFybWVyQHVtbi5lZHU8L2E+PGJy Pg0KTmV0d29ya2luZyAmYW1wOyBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlczxicj4NCk9mZmlj ZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5PGJyPg0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEm bmJzcDsmbmJzcDsgPGJyPg0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBQaG9uZTogNjEyLTYyNi0wODE1PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1NDE0 LTMwMjkmbmJzcDsmbmJzcDsgQ2VsbDogNjEyLTgxMi05OTUyPGJyPg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b54c31f113444e5c84a9c69c308c2562XCH150608nwnosboeingcom_-- From nobody Wed Aug 30 14:28:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA313239A for ; Wed, 30 Aug 2017 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7vojg7yzbZ4 for ; Wed, 30 Aug 2017 14:28:33 -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 5533F1321F1 for ; Wed, 30 Aug 2017 14:28:33 -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 v7ULSWgZ050459; Wed, 30 Aug 2017 14:28:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7ULSMDp050387 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 30 Aug 2017 14:28:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 30 Aug 2017 14:28:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 30 Aug 2017 14:28:21 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgARjqyAAA5VXnD//5byAIAAWYhwgAA7jAD//2QhwA== Date: Wed, 30 Aug 2017 21:28:21 +0000 Message-ID: <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:28:35 -0000 Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, August 29, 2017 10:08 PM > To: Templin, Fred L > Cc: Brian E Carpenter ; v6ops@ietf.org > Subject: RE: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >=20 > On Tue, 29 Aug 2017, Templin, Fred L wrote: >=20 > > Probably, but I think there are two primary categories: 1) > > network-directed and 2) client-directed. Which is more appropriate > > probably needs to be examined on a case-by-case basis. >=20 > I think whatever we come up with needs to support all of them. Client > needs to be able to release resources, it needs to indicate that "I don't > want this anymore, permanently" but also "I am disconnecting for a while, > I am still interested in this resource" and also perhaps "hello, I am now > here, can I please have my resource that I had over there" (in case of fo= r > instance wifi handover). The network in turn needs to be able to tell the > device "sorry, this resource is or will soon no longer available, stop > using it within X seconds" Right, and that is what DHCPv6 PD already does. IPv6 ND could probably be made to do it too, but there would need to be a new protocol and possibly also new message types (in addition to what is already in PIO-X). Thanks - Fred > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 30 15:05:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920C132C36 for ; Wed, 30 Aug 2017 15:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 WmPO0rGwbicl for ; Wed, 30 Aug 2017 15:05:05 -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 78F4E132CEE for ; Wed, 30 Aug 2017 15:04:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 1655B718 for ; Wed, 30 Aug 2017 22:04:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKd89_uQVf08 for ; Wed, 30 Aug 2017 17:04:45 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id CCE29615 for ; Wed, 30 Aug 2017 17:04:45 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id 105so4447760uad.11 for ; Wed, 30 Aug 2017 15:04:45 -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=8pJszhPq32XEx2MsugwlcgwXcXODECaovJ9gG9EiVs4=; b=dzGQlvNyx6gVDsRvIh1JwWlM8Bc8HqEguWHNGL3xZU27IFHg1PNW0dXybzgIIuqyFk Ul0OxvLTeJJdm3BoeDGsYw2jzTqUPKGx2kPw88ZtR+mjL4ttvo3gIGxP6ELLEm/o0+yO 29v9HPa7l4+429xlAF2V3l2F29H/M1cAfzS6UEDpCkHQv0Fe+YrKsPmqnSjQOBqeCInN y9sH0dDIaDcHAoG99kSLJA2F7zHLCAJ+fCLOiwrm9UIJtTJqYBVc/m6vUcdecJ4e9eFa srv7LpIMs3MdCJqy2fFoJgs3q5zlRRk3AiyjRN+lU3fTXv5iePTJDssLYiXpkfEYL+8r xt9w== 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=8pJszhPq32XEx2MsugwlcgwXcXODECaovJ9gG9EiVs4=; b=Y2aR/0FoUXLuLTJJeRS/hPNqGwZe4afvXAgILaNcMqxyqic4nvfJbHYMm7L+5gVE2R NT3NVixz1OdTXcdIG/EN2qTxjBdQ+zOABNVFL4Yp6rkmbddOopHmXX2gVlWJBQ6yPV9G iZ467afWP4/CQYN++01grBrT8Dpjjof2XaEvkhHvqj7m3Zsa8bJK1BafAJCVKGWdkx3p 9RQiG9UHR3dWH+bGo7Egh7Va11J73JV1YLryAQ7unAVmgb1MHxeQQCOPmIjkgmtRmk57 Nk0kqoI27gwSEgSpALYqP00hnTdVOcj9TYoywBeEcJekvAPaEQbjP9H3WRGwsDygqGSE 6qKA== X-Gm-Message-State: AHYfb5i2BbV2PHuVJLhkAj2OkFq93sC5Djsrv9k9ySkg44q6AAQG0ISk xCNzcXW9NGlh9y/EtTqjd5sgMSk7urCc4R4NP7Js9hcGzIvG922lJvI0epwTdC0nqm88ku0HOQ3 v/yUKlbKEU1JvHBSD X-Received: by 10.176.91.85 with SMTP id v21mr1733506uae.21.1504130684584; Wed, 30 Aug 2017 15:04:44 -0700 (PDT) X-Received: by 10.176.91.85 with SMTP id v21mr1733493uae.21.1504130684310; Wed, 30 Aug 2017 15:04:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.15 with HTTP; Wed, 30 Aug 2017 15:04:43 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Wed, 30 Aug 2017 17:04:43 -0500 Message-ID: To: "Templin, Fred L" Cc: Tim Chown , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8d3a22cd2b0557ffb759" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 22:05:07 -0000 --f403045f8d3a22cd2b0557ffb759 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L wrote: > Hi, again this document is nothing more than an expression of what is > already > > in RFC4861, but then it adds constraints that don=E2=80=99t need to be th= ere. If > the > > PIO has A=3D1, L=3D0 then by RFC4861 the host will autoconfigure one or m= ore > > addresses and send packets via the default router (since =E2=80=98L=E2=80= =99 is 0) unless > > there is a more-specific route. > > > > But, the router may send a Redirect and therefore subsequent packets coul= d > > go from peer-to-peer without having to go through the router. This docume= nt > > should not be in the business of disabling or disallowing the Redirect > function, > > which is a core element of IPv6 ND and necessary for some link types. > > > > Thanks - Fred > And you can do just that with one /64 subnet for how many every hosts you want too on the same subnet. However, if you have 1000 hosts all on the same link, and there is subnet prefix per host, what prevents all 1000 hosts from forming SLAAC addresses on each of the prefixes? Something has to prevent Host1 from knowing about the prefixes for the other 999 hosts. Otherwise per RFC4861, Host1 would form an address on those other 999 prefixes as well. This implies some kind of separation of the hosts is already required if a host is going to use only it's prefix. And if that separation is only applied to the RAs, and the hosts can communicate directly with each other over the shared network then what is the advantage of doing that over 1 subnet for the 1000 hosts? You are making thinks more complicate without any seeming advantage. Now if the hosts can't communicate with each other then there is an advantage provided by segregating the RAs for the other 999 prefixes from Host1. Therefore some level of host segregation is a fundamental property of this whole technique, and it makes no sense to limit it per host advertisement of RAs. 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 --f403045f8d3a22cd2b0557ffb759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

    Hi, again this document is nothing mo= re than an expression of what is already

    in RFC4861, but then it adds constrai= nts that don=E2=80=99t need to be there. If the

    PIO has A=3D1, L=3D0 then by RFC4861 = the host will autoconfigure one or more

    addresses and send packets via the de= fault router (since =E2=80=98L=E2=80=99 is 0) unless

    there is a more-specific route.

    =C2=A0

    But, the router may send a Redirect a= nd therefore subsequent packets could

    go from peer-to-peer without having t= o go through the router. This document

    should not be in the business of disa= bling or disallowing the Redirect function,

    which is a core element of IPv6 ND an= d necessary for some link types.

    =C2=A0

    Thanks - Fred

    <= /blockquote>

    And you can do just that with one /64 subne= t for how many every hosts you want too on the same subnet. =C2=A0

    However, if you have 1000 hosts all on the same link, and = there is subnet prefix per host, what prevents all 1000 hosts from forming = SLAAC addresses on each of the prefixes? Something has to prevent Host1 fro= m knowing about the prefixes for the other 999 hosts. Otherwise per RFC4861= , Host1 would form an address on those other 999 prefixes as well.=C2=A0 Th= is implies some kind of separation of the hosts is already required if a ho= st is going to use only it's prefix.

    And if th= at separation is only applied to the RAs, and the hosts can communicate dir= ectly with each other over the shared network then what is the advantage of= doing that over 1 subnet for the 1000 hosts? You are making thinks more co= mplicate without any seeming advantage. Now if the hosts can't communic= ate with each other then there is an advantage provided by segregating the = RAs for the other 999 prefixes from Host1.

    Therefo= re some level of host segregation is a fundamental property of this whole t= echnique, and it makes no sense to limit it per host advertisement of RAs.<= /div>

    Thanks

    =C2=A0
    <= br>
    =C2=A0=C2=A0

    --
    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecom= munication Services
    Office of Information Technology
    University of Mi= nnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 P= hone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-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=
    --f403045f8d3a22cd2b0557ffb759-- From nobody Wed Aug 30 16:16:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C80126DD9; Wed, 30 Aug 2017 16:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajTRGAx6f1mF; Wed, 30 Aug 2017 16:16:19 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB0B1241FC; Wed, 30 Aug 2017 16:16:19 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 63so6048923pgc.1; Wed, 30 Aug 2017 16:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LAKqjyP4ybBJ+q48kFVRWdwGqpW5TCd4fV8YboBxjcU=; b=YmJKNhXORt3/pOkE4Mrj/wKbCDNusBpstFD8RMtatP7gpoWyfAfYCQWCdpmvcePAeB uFgH4tbRxRpadyxynulWYXIb3OaaHjc0U6ru4LnzK6ra2oROGGS6dhc+WKv3uaeQ7W19 pbP0r1nFQkfZogFVQMkIJ/QFpJHjtF19gn6GNHwfudqrRNQ5mymZbtOZlrQB4ea5+kXN cvpdpds299cILBtSrunv0yYx+jc9SIaUtYhi75PR+nucRJ/4jJrESvV8RL+tNbncfEte o8M3ih1Q/E2vpKzGVlTq4SYXCHg/sfDcv3TNLo3iT+0oFEdWrj5HGadBn+SsEPu6nyQi 2jyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LAKqjyP4ybBJ+q48kFVRWdwGqpW5TCd4fV8YboBxjcU=; b=SpFMKNakyE4ig8DEoUHYO98WlVCVmq3tcHAA7h6vKVYrPFiZ1bXakCQJl7gRBEtubo 6UaMGy9N4cwA7NrRwe+M63Ua7mdke/Wh2t3PLuK9cBQbre5n3qdAsy5d3nLenwepDou5 NhPHlapdkdRWvaFXdaWebhUqNKWArbadj6Jzn1vVnYTwVhsDqOkmsWpcvf38fhvvQkM1 qKdaiKEJxu3gXg5aGeEGDLqQBXOeN35ldWiWYpKIrEDDXOsQdo4yTatybUI0q5WbFn4T pwXF3PO09ddEDk5JLv/Tb6d9cDZeLkiyX7zqGuNIWJjLMIdYvR9Rp9Vc6TaR15v3cs6z R5ug== X-Gm-Message-State: AHYfb5j+WjxCOd3gw86NhBf7UBYT90indMJY2CoRxJjUB7n1HLPwg0Es t7Y95AQ4G1uj2UPX X-Received: by 10.98.8.87 with SMTP id c84mr218635pfd.75.1504134978456; Wed, 30 Aug 2017 16:16:18 -0700 (PDT) Received: from ?IPv6:2406:e007:5c9e:1:28cc:dc4c:9703:6781? ([2406:e007:5c9e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w64sm10813048pfi.75.2017.08.30.16.16.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 16:16:17 -0700 (PDT) To: David Farmer , "Templin, Fred L" Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 31 Aug 2017 11:16:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:16:21 -0000 On 31/08/2017 10:04, David Farmer wrote: ... > However, if you have 1000 hosts all on the same link, and there is subnet > prefix per host, what prevents all 1000 hosts from forming SLAAC addresses > on each of the prefixes? If there are any multicast RA/PIOs for these prefixes, they should have A=0; L=0 (cf RFC8028). But I'm not sure why there would be any multicast RAs. They don't seem to be needed. The draft talks about unicast RAs. Brian From nobody Wed Aug 30 16:20:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FAB13243A for ; Wed, 30 Aug 2017 16:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzBvAGE4BECQ for ; Wed, 30 Aug 2017 16:20:54 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10EB51241FC for ; Wed, 30 Aug 2017 16:20:54 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id z187so21461491vkd.2 for ; Wed, 30 Aug 2017 16:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QNoknckByGZ7mGPJldyvBuxlQVHgRy8Di4iFWrJO7u8=; b=jLCLctN+dcoVS+R1YNThjdzw5TkooLqCSvrm6oKUuBrKL5V2BnQ8Dm8lRMopWdvyry RGfJN0uO2qNNaIhCkQDxM3nHGoROV2VdS5oGDkanmdbCcJuX+xIuz3MMlZiZzIZ83Bzg /+nwd1V6zd8vBF//uBCqETHkeW0YW2zh6ZjJvD3PChGRmZuRdym7EkiTfLWnv6D0IyaL 43DJwpzfk5XBK6/GybfrcIuTuN0G95+3hb7KKurolgtmPf5P9HRdVuEgxRM647/zkOoH pV2COGFzE7eGCamCXQbd4HojMlpQR0+5XwOrvNgMvTnqkFgPX7JiWYF7iqH62oG5QFid 7vtg== 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=QNoknckByGZ7mGPJldyvBuxlQVHgRy8Di4iFWrJO7u8=; b=rPyktcPq2SV08oRgrUMYoNPSAUgU659aweb+HPcHiKE4y68pw5ws71ZV9Y2segYHvc j3V1bFNOp70jHXBFVt4ojTuYZ5bXZ6n2EEGrEH23NY8SnPJeSNhC/2wVTAvCoktTP466 k5qbfE5Jqelas81BCKYFyFe/CaRAIO/pyzmZBaFrEAHMx7MR2ouqsFj73SMS4C+lzabt Liw6Pdzk3GMABBarNPJAm2kToxszTmCaBxVgovHi1x9U5F7GXZ8lt/H+exa1XJJYRNhc uFRpJG9H9m5oLHGw3NO2+RsYw9sH59hY5uiD5Pb8QnRMmX7Uf88Oh0bAxWY2pnN5TcxN 8FEA== X-Gm-Message-State: AHYfb5hbqdOYoamE091onCzNytxEk34p9mZo0qIMM0+rzMmPxkPKejn2 XJrHuLyJJd7UKuKxfJRJQ8FqD5l+yQ== X-Received: by 10.31.226.69 with SMTP id z66mr1871004vkg.79.1504135253103; Wed, 30 Aug 2017 16:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Wed, 30 Aug 2017 16:20:52 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Wed, 30 Aug 2017 16:20:52 -0700 (PDT) In-Reply-To: <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Thu, 31 Aug 2017 09:20:52 +1000 Message-ID: To: "Templin, Fred L" Cc: v6ops list , Mikael Abrahamsson Content-Type: multipart/alternative; boundary="001a114def94749c1e055800c7bb" Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 23:20:56 -0000 --001a114def94749c1e055800c7bb Content-Type: text/plain; charset="UTF-8" On 31 Aug. 2017 07:28, "Templin, Fred L" wrote: Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, August 29, 2017 10:08 PM > To: Templin, Fred L > Cc: Brian E Carpenter ; v6ops@ietf.org > Subject: RE: [v6ops] Prefix Delegation RS/RA vs DHCPv6 > > On Tue, 29 Aug 2017, Templin, Fred L wrote: > > > Probably, but I think there are two primary categories: 1) > > network-directed and 2) client-directed. Which is more appropriate > > probably needs to be examined on a case-by-case basis. > > I think whatever we come up with needs to support all of them. Client > needs to be able to release resources, it needs to indicate that "I don't > want this anymore, permanently" but also "I am disconnecting for a while, > I am still interested in this resource" and also perhaps "hello, I am now > here, can I please have my resource that I had over there" (in case of for > instance wifi handover). The network in turn needs to be able to tell the > device "sorry, this resource is or will soon no longer available, stop > using it within X seconds" Right, and that is what DHCPv6 PD already does. IPv6 ND could probably be made to do it too, but there would need to be a new protocol and possibly also new message types (in addition to what is already in PIO-X). I might not be understanding, however that sounds to me like a preferred or valid lifetime update. Thanks - Fred > -- > Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --001a114def94749c1e055800c7bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 31 Aug. 2017 07:28, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:=
    Hi Mikael,

    > -----Original Message-----
    > From: Mikael Abrahamsson [mailto:s= wmike@swm.pp.se]
    > Sent: Tuesday, August 29, 2017 10:08 = PM
    > To: Templin, Fred L <F= red.L.Templin@boeing.com>
    > Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; v6ops@ietf.org
    > Subject: RE: [v6ops] Prefix Delegation RS/RA vs DHCPv6
    >
    > On Tue, 29 Aug 2017, Templin, Fred L wrote:
    >
    > > Probably, but I think there are two primary categories: 1)
    > > network-directed and 2) client-directed. Which is more appropriat= e
    > > probably needs to be examined on a case-by-case basis.
    >
    > I think whatever we come up with needs to support all of them. Client<= br> > needs to be able to release resources, it needs to indicate that "= ;I don't
    > want this anymore, permanently" but also "I am disconnecting= for a while,
    > I am still interested in this resource" and also perhaps "he= llo, I am now
    > here, can I please have my resource that I had over there" (in ca= se of for
    > instance wifi handover). The network in turn needs to be able to tell = the
    > device "sorry, this resource is or will soon no longer available,= stop
    > using it within X seconds"

    Right, and that is what DHCPv6 PD already does. IPv6 ND could probabl= y
    be made to do it too, but there would need to be a new protocol and
    possibly also new message types (in addition to what is already in PIO-X).<= br>

    I might not be understanding, however that sounds to me like a preferr= ed or valid lifetime update.=C2=A0


    Thanks - Fred

    > --
    > Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

    --001a114def94749c1e055800c7bb-- From nobody Wed Aug 30 17:11:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F5132969 for ; Wed, 30 Aug 2017 17:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS2R9M110X8m for ; Wed, 30 Aug 2017 17:11:34 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 2629613263F for ; Wed, 30 Aug 2017 17:11:34 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id n71so13398526iod.1 for ; Wed, 30 Aug 2017 17:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eBHW9PegWswmm2TeCaDDX5IJh9RMiyqvInbNInM2ay4=; b=DZkAcYY0cVpA3vvgQLoagZRBcVYy7/9K+ixfAQxFKZNBiQR6xJQzBq2RE+IxyVqVyr X2w9pioQuDlSD5SVYFdRUQE3f6x5vJf5Mib91a4rZMLFa1eOwBy7LXFzTu29BgZ5Pl2U HbhGYszuZ/DQk8hvtbxgpQXJ2yCc260gyDOKd5NNcO+LwXq55LH/SPwGIrBILXxVn/+z ThZybWu2RQ40uBdo23nTWHBshhB94RATXdasZ1Qp9snXLQfR7enmp3RhemAFguCC3J0o ODktvrqu0kPJenOL/PoeOC1HS/P5mld4995SbeP4D2p48rxo+KgdTFMSY+audrti/m0T Crvw== 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=eBHW9PegWswmm2TeCaDDX5IJh9RMiyqvInbNInM2ay4=; b=paL8VFkXR6oh1pP2lNBEt7G31K9Q8VB5mLMUj6R11897naljTrZmEwu46jVLZ/W1mj FAcVXoXyWxc1xoDFAQXrgb92byYt8FsXJLswaC80+XoOp51kLDk0oIMT80xyD9hDqtaK UPg1JT1yKqmaCighRC4sc+13S7yW/12hJ6AbAfF0EfosuHzraVHnXocR5kg3hg/MjEZi 6rZbx4iwsO+rqUrWg4ilCI/jHKTQ4TkDZPQOOZfIaZg00ystJb2IR0xSlF2CKer3W96m MTGsdLeeplCgx8Xce8NIm5h75XaUOpiVKHHvHIpPeMxTuQe8tfqF0++mtBHx/6oyxR3v p4Kg== X-Gm-Message-State: AHYfb5gkT+mlxVry63HQ/9ijrgzShDfVbvlVE98LEmy3FJhtOe1LmuLP XNFl/3GI/kRZZFR0rceXFSnP6foZ9Rhg X-Google-Smtp-Source: ADKCNb7CH381+FgOcRXn/8ztVxPicLc50NO05g/hpdO7u4C5W7M/fMS8kMkikbxr3XszDf5ubWw3/CcYOlkOtFLVY/g= X-Received: by 10.36.84.193 with SMTP id t184mr2883200ita.115.1504138292953; Wed, 30 Aug 2017 17:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 30 Aug 2017 17:11:12 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 31 Aug 2017 09:11:12 +0900 Message-ID: To: Brian E Carpenter Cc: David Farmer , "Templin, Fred L" , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a11c15672a57ae20558017c6c" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 00:11:36 -0000 --001a11c15672a57ae20558017c6c Content-Type: text/plain; charset="UTF-8" On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If there are any multicast RA/PIOs for these prefixes, they should have > A=0; L=0 (cf RFC8028). > > But I'm not sure why there would be any multicast RAs. They don't > seem to be needed. The draft talks about unicast RAs. > Unicast RAs would require the router to keep state on all its clients regardless of its IP addresses and across IP address changes. That doesn't scale. It's much better for the router to send a multicast RA on each separate L2 link, knowing that it will go only to the host on that link that has that prefix. --001a11c15672a57ae20558017c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= hu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
    If ther= e are any multicast RA/PIOs for these prefixes, they should have
    A=3D0; L=3D0 (cf RFC8028).

    But I'm not sure why there would be any multicast RAs. They don't seem to be needed. The draft talks about unicast RAs.
    =
    Unicast RAs would require the router to keep state on all it= s clients regardless of its IP addresses and across IP address changes. Tha= t doesn't scale. It's much better for the router to send a multicas= t RA on each separate L2 link, knowing that it will go only to the host on = that link that has that prefix.
    --001a11c15672a57ae20558017c6c-- From nobody Wed Aug 30 18:15:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB9126BFD; Wed, 30 Aug 2017 18:15:18 -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 PKzWuc2o88Y7; Wed, 30 Aug 2017 18:15:17 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 5FE1C1204DA; Wed, 30 Aug 2017 18:15:17 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id m15so6221090pgc.0; Wed, 30 Aug 2017 18:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yJ4XpTI7lfv7x+rgRsa1wgABrrSLevYRWZuzjVGSk9M=; b=LXEMo//VCsnbUum6RoJW5RvX0sx6+48ytK6dHR6ZtiyVlDGoVg7N0HdXjx0m/ZEyU4 cptI5JC36dC55qhCjmAiUwphXDDEAgZU8+fM6jq6xnT+lqvZhQibBkJG3eJrkUS7gfY3 VFmZtNA+utyKGTl7YMP1Fs5Xr4qQngIfTOXSCCU2h1lv2cosWoyrqabBTC4NoyEpE7zH MnTFd0yGapPFYFo7LEtX9DSPyk1LsKZ08bXqmP2CrCtzHl31VnRGRYC5f4PJmb2e6SJ0 61hYAdToPGxq95YG7kxxT4/gHKetvDrb7qrJkY1c/cmca6FmSMJDf/Qrb5HoOcW1Bh9I iztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yJ4XpTI7lfv7x+rgRsa1wgABrrSLevYRWZuzjVGSk9M=; b=T+3ghs9V23PGoF7437NJAt7h7LUVTEB/mskNf7ua0eGL/NKBka5TUCaXAsJHl7Q3se zsrJX2D9/MD2H5GiMLf4d9scMLaEfm6TsKqoJV4NEY+omqAHLgmZDhjDw8jRTxi+PNJi edHBO5zss2mKyKZKOWtVEjejGSLprAH+ZgClxiShxOzYbvAkSLJrwOdwoG7EsigA9Q2I uEkoLDct4eBFhZmd5hqpRaM7SzAlO9cDFXkmQowAyCz4/7g/8Ng9b6D8mR2VdR9J3eXd 0JCgw5hAmo4b2kjgYi2myymQO7MjdDJ6rlxwGglYmuPVmFQSAC5uHvqANlG5j9v1Uuox yDXA== X-Gm-Message-State: AHYfb5gy6yAura95++ZlM2CpqUfuKzdSwCewvR3K1nE/vURaP7/1AXor ufj+QI7O2QziEMMl X-Received: by 10.84.130.1 with SMTP id 1mr618690plc.304.1504142116662; Wed, 30 Aug 2017 18:15:16 -0700 (PDT) Received: from ?IPv6:2406:e007:5c9e:1:28cc:dc4c:9703:6781? ([2406:e007:5c9e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n29sm611983pgf.78.2017.08.30.18.15.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 18:15:15 -0700 (PDT) To: Lorenzo Colitti Cc: David Farmer , "Templin, Fred L" , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0e0dce2e-890d-f4bd-9e9e-9378efc56578@gmail.com> Date: Thu, 31 Aug 2017 13:15:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:15:19 -0000 On 31/08/2017 12:11, Lorenzo Colitti wrote: > On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> If there are any multicast RA/PIOs for these prefixes, they should have >> A=0; L=0 (cf RFC8028). >> >> But I'm not sure why there would be any multicast RAs. They don't >> seem to be needed. The draft talks about unicast RAs. >> > > Unicast RAs would require the router to keep state on all its clients > regardless of its IP addresses and across IP address changes. That doesn't > scale. It's much better for the router to send a multicast RA on each > separate L2 link, knowing that it will go only to the host on that link > that has that prefix. Yes, certainly, if there are genuinely separate L2 links. But what if there is in reality a shared L2 link? In any case the draft doen't even contain the word "multicast". Brian From nobody Wed Aug 30 21:45:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD8126BFD for ; Wed, 30 Aug 2017 21:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSYMVKhBmogn for ; Wed, 30 Aug 2017 21:44:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAF0132256 for ; Wed, 30 Aug 2017 21:44:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1B5AFAF; Thu, 31 Aug 2017 06:44:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504154694; bh=Yla+x7o62yGIgjQIRVd4S3/+t5lYya13voBR9w4TAWg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dHWUyDjrBgZGmsbeRwduNOgJ/55Pk2EpbxfQ7xxw87zOXkNR2LohKP/S6QFRQW5xH lpN9LkR7vZItJo+PmLySdQrPZt0FG4JMxqTxdnXlmA0luUE93BIwHf+PKn9qvtzve6 dbgw9HKkDsTgrk67hac6BAx93H8CAILQk1d/4PhU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 02A7684; Thu, 31 Aug 2017 06:44:54 +0200 (CEST) Date: Thu, 31 Aug 2017 06:44:53 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: Brian E Carpenter , "v6ops@ietf.org" In-Reply-To: <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 04:44:59 -0000 On Wed, 30 Aug 2017, Templin, Fred L wrote: >> I think whatever we come up with needs to support all of them. Client >> needs to be able to release resources, it needs to indicate that "I don't >> want this anymore, permanently" but also "I am disconnecting for a while, >> I am still interested in this resource" and also perhaps "hello, I am now >> here, can I please have my resource that I had over there" (in case of for >> instance wifi handover). The network in turn needs to be able to tell the >> device "sorry, this resource is or will soon no longer available, stop >> using it within X seconds" > > Right, and that is what DHCPv6 PD already does. IPv6 ND could probably I don't believe it does. It can do release, but that is no guarantee that it'll get the resource back in the future. There is no intention included in the "release". If it doesn't release and then tries to renew it somewhere else, afaik there is no standard way for this to work either because that PD lease is typically tied to an interface and a DHCPv6 proxy is typically sitting there with a binding. Also, I have never seen DHCPv6 do "this resource is no longer available, stop using it in the next 60 seconds". You can shorten lifetimes when the client asks, but I have never seen the network reach out to the client to shorten the lifetime. >From what I can tell we have no solution for what we're talking here, we need to extend what we have to do what we're talking about. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 31 01:13:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AA313235A for ; Thu, 31 Aug 2017 01:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 CCsPxrmCBvUn for ; Thu, 31 Aug 2017 01:13:15 -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 E77A41320B5 for ; Thu, 31 Aug 2017 01:13:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 7E490A57 for ; Thu, 31 Aug 2017 08:13:14 +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 bVAN-JLXF7o7 for ; Thu, 31 Aug 2017 03:13:14 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 3097E945 for ; Thu, 31 Aug 2017 03:13:13 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id j16so5588497uai.8 for ; Thu, 31 Aug 2017 01:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mF3pTldh9YSaiMeHp+CzyyfBBXjpNZx6f6YUVtbANFY=; b=hvOFF4oVyEshVE+nd4WyzLf87DsRhG9Cr6+/pI4LD0T0773S1VTAZLw5WZ4iJm+Z4c pinmHUSq/Rk3jfc2VPBBXTA1SEy/3ZqglkkkFdlGZhkqRcfNWeeRFwzVYq4BCSanPISY S2yqMUmrv2kQSH0RIJQlcXM7KsUbG3PjVq3MR1xkSTVO9oBjUqQAAta3CZqJjDFkyc4H Q+iTukSRuXtHBK5m7ySsnhp0nS+vpdnwINx393ugpVdvPqISON/Jo6b+ixdpgwEegihl TnhZvrhcOGfliCuA+cp2v3GL2bHJ0shgeY9AugnNz2E9CwtFS5ibcJdirb++nOflf0x1 h+oQ== 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=mF3pTldh9YSaiMeHp+CzyyfBBXjpNZx6f6YUVtbANFY=; b=pGJXlT5aO9C3rsenk6fu2Br2dtLwZSizfKJlPVDf3A/WkG1rWo5LfvFqgWQ5p8BZcG HpCIUONTU66lE1I8wtCeU7FlLSYkT+Fas5APPqR7nAEepXJE65TepvmIj4NzG0yHv829 vOGNKKBQxJ1Q2SuHwkCpCfwwPNmZYwIYEEroTbZOrbpMg8QOS12i1556JPf4yMI+GTMd kjHCG6KLM+a2jdnAxLCFQ+imX3edIpyFScGKZMNE2o4PFJDouacljqSWwlKqLRVbVdXs KMdvlKZzdy9L8myCMGR+h1EFvc3seY2Zw4k00aSf+zG3LNY2WFrw3hifE2fy/Ips7tXH JZjQ== X-Gm-Message-State: AHYfb5iTp5vxc0/edH4w1mlAp5L2qABEVkI4LOFveF8rzW3S/eDIaTjR es/vmyuF7z8NM4lshZWANQd3RusKTqkfze7NbVJXpjuWW4vdsNSf5DScTz5z98WCtV946DTSqwv x17hc2Em6RZV0yKId X-Received: by 10.31.67.146 with SMTP id q140mr2743259vka.122.1504167193359; Thu, 31 Aug 2017 01:13:13 -0700 (PDT) X-Received: by 10.31.67.146 with SMTP id q140mr2743247vka.122.1504167192973; Thu, 31 Aug 2017 01:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.49.213 with HTTP; Thu, 31 Aug 2017 01:13:11 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Thu, 31 Aug 2017 03:13:11 -0500 Message-ID: To: Lorenzo Colitti Cc: Brian E Carpenter , "Templin, Fred L" , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a114d95b6386f1f05580837dc" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:13:19 -0000 --001a114d95b6386f1f05580837dc Content-Type: text/plain; charset="UTF-8" On Aug 30, 2017, at 19:11, Lorenzo Colitti wrote: On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If there are any multicast RA/PIOs for these prefixes, they should have > A=0; L=0 (cf RFC8028). > > But I'm not sure why there would be any multicast RAs. They don't > seem to be needed. The draft talks about unicast RAs. > Unicast RAs would require the router to keep state on all its clients regardless of its IP addresses and across IP address changes. That doesn't scale. It's much better for the router to send a multicast RA on each separate L2 link, knowing that it will go only to the host on that link that has that prefix. As I've said I'm not aware of any WiFi systems providing a full bi-directional VLAN per host isolation, or in other words, each host get its own VLAN interface on the router side. This seems to be what Lorenzo is talking about. However, I wouldn't be quite pleasantly surprised to be proven wrong about that though. The solutions I'm aware of provide isolation only on the host side, not the router side, similar to private VLANs on Ethernet switches, or in other words, all the hosts share a common VLAN interface on the router side, but are isolated from each other. https://en.m.wikipedia.org/wiki/Private_VLAN In any case the router has to maintain an association of host MAC addresses and unique prefixes for next-hop delivery of packets destine to each unique prefix. When the router assigns a unique prefix to a host in response to the host's initial RS, it will have to populate this. RAs can also be formed from the information in this table. As Lorenzo said the router should send RAs, with a PIO for the unique prefix of each host with A=1, L=0, in response to an RS or for periodic RAs, destine to the all-hosts multicast address in the IPv6 header, so it doesn't have to track all the IIDs associated with each host. However, it should not use the associated multicast MAC address as the L2 destination but the unicast MAC address of the host assigned the unique prefix. As I said the router has to maintain RA isolation per host, this is fundamental to this technique. If this is done then it doesn't matter if each host has it own VLAN interface on the router side or if the hosts share a common VLAN interface on the router side. Whether the return traffic is isolated, or not, is not up to the router, it's up to the WiFi system or Ethernet switch. But if it's not isolated the router has gone to the effort of isolating the RA for little reason, other than to waste a bunch of prefixes for no benefit that makes any sense to me. If you want the hosts to talk to each other directly this is far more efficiently done with the classic multi host per subnet model. It might also be useful to advertise a PIO for the aggregate prefix the router uses to assign the unique prefixes from, or even the providers aggregate prefix, with A=0, L=0, to the all-hosts multicast address in the IPv6 header and the MAC header, to ensure hosts compliment with RFC8028, that may have other interfaces, would prefer routing of these prefixes to the provider first hop router instead of out their other interface. If the technique above is used and isolation is provided on the host side, a host could form a duplicate Link-local address with another isolated host, and it wouldn't cause an issue, as the router is not using or tracking the link-local neighbors. This also requires a modification of the routers response to NS queries from hosts it must use the source IPv6 address and source MAC address from the NS as the destination IPv6 address and destination MAC address of the NA without tracking them, as different host could have the same source IPv6 address. The router needs to and should be able to defend its link-local address against each of isolated hosts so that the one of the hosts doesn't form a duplicate of the router's link-local address, as this would cause issues. In this case I would consider each host to be on a separate link, the router on each of these links has the same link-local address. If isolation at least on the host side is not provided by L2 then the router and all the hosts are on a common link, link-local addresses will work normally and malicious hosts could man-in-the-middle any traffic from any of the hosts on the network. If the Wifi system provides an ND proxy, fairly common at least in enterprise class WiFi systems, or if a separate ND proxy is provided on a separate promiscuous mode port like the router has, it sees and can send traffic to all hosts, the ND proxy could defend each of host's link-local address from the other isolated hosts preventing any possibility of a duplicate link-local address among the hosts, and allowing the router to track link-local addresses and utilize its standard NS and NA processes, only requiring modification of the RA process. There is a trade-off here though, if the router could track the hosts' link-local addresses it could use it's normal and presumably well debugged code paths for NS and NA and many of the normal tools on the router at least those that utilize link-local addressing. Or, it can use custom code for NS and NA probably breaking all tools on the router, even those that could use link-local addressing, for the advantage of not having to track each of the hosts link-local addresses. There are benefits and costs with both options, in my opinion it's mostly a tie. It probably boils down to how many hosts does the environment really need to scale too, verses how adaptable the staff that has to operate and troubleshoot the environment is. Here at UMN, if we can eliminate the tracking of each hosts multiple GUA addresses by the routers, that's probably a big enough win by itself that I'd probably opt to keep the tracking of link-local addresses normal, keeping as many tools on the router as normal as I could. Thanks --001a114d95b6386f1f05580837dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Aug 30, 2= 017, at 19:11, Lorenzo Colitti <lorenzo@google.com> wrote:

    On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    If there are any multicast RA/PIOs for the= se prefixes, they should have
    A=3D0; L=3D0 (cf RFC8028).

    But I'm not sure why there would be any multicast RAs. They don't seem to be needed. The draft talks about unicast RAs.
    =
    Unicast RAs would require the router to keep state on all it= s clients regardless of its IP addresses and across IP address changes. Tha= t doesn't scale. It's much better for the router to send a multicas= t RA on each separate L2 link, knowing that it will go only to the host on = that link that has that prefix.
    <= div>As I've said I'm not aware of any WiFi systems providing a full= bi-directional=C2=A0VLAN per host isolation, or in other words, each host = get its own VLAN interface on the router side. This seems to be what=C2=A0Lorenzo is=C2=A0talking about. However,=C2=A0I= wouldn't be quite pleasantly surprised to be proven wrong about that t= hough.

    The solutions I'm aware of provide isol= ation only on the host side, not the router side, similar to private VLANs = on Ethernet switches, or in other words, all the hosts share a common VLAN = interface on the router side, but are isolated from each other.
    <= br>

    In any case the router has to maintain an association of = host MAC addresses and unique prefixes for next-hop delivery of packets des= tine to each unique prefix. When the router assigns a unique prefix to a ho= st in response to the host's initial RS, it will have to populate this.= =C2=A0

    RAs can also be formed from the information= in this table. As Lor= enzo said the router should send RAs, with a PIO for the unique prefix of e= ach host with A=3D1, L=3D0, in response to an RS or for periodic RAs, desti= ne to the all-hosts multicast address in the IPv6 header, so it doesn't= have to track all the IIDs associated with each host. However, it should n= ot use the=C2= =A0associated multicast MAC address as the L2 destination but the unicast M= AC address of the host assigned the unique prefix. As I said the router has= to maintain RA isolation per host, this is fundamental to this technique. = If this is done then it doesn't matter if each host has it own VLAN int= erface=C2=A0on the router side or if the hosts share a common VLAN interfac= e on the router side.

    Whether the return traffic is isolated, or not, is not up = to the router, it's up to the WiFi system or Ethernet switch. But if it= 's not isolated the router has gone to the effort of isolating the RA f= or little reason, other than to waste a bunch of prefixes for no benefit th= at makes any sense to me. If you want the hosts to talk to each other direc= tly this is far more efficiently done with the classic multi host per subne= t model.=C2=A0

    It might also be useful to advertise a PIO for the aggregate pref= ix the router uses to assign the unique prefixes from, or even the provider= s aggregate prefix, with A=3D0, L=3D0,=C2=A0to the all-hosts multica= st address in the IPv6 header and the MAC header,=C2=A0to ensure hosts compliment with RFC= 8028,=C2=A0that may have other inter= faces, would prefer routing of these prefixes to the provider first hop rou= ter instead of out their other interface.

    I= f the technique above is used and isolation is provided on the host side, a= host could form a duplicate Link-local address with another isolated host,= and it wouldn't cause an issue, as the router is not using or tracking= the link-local neighbors.=C2=A0 This also requires a modification of the r= outers response to NS queries from hosts it must use the source IPv6 addres= s and source MAC address from the NS as the destination IPv6 address and de= stination MAC address of the NA without tracking them, as different host co= uld have the same source IPv6 address. The router needs to and should be ab= le to defend its link-local address against each of isolated hosts so that = the one of the hosts doesn't form a duplicate of the router's link-= local address, as this would cause issues. In this case I would consider ea= ch host to be on a separate link, the router on each of these links has the= same link-local address.=C2=A0

    If isolation= at least on the host side is not provided by L2 then the router and all th= e hosts are on a common link, link-local addresses will work normally and m= alicious hosts could man-in-the-middle any traffic from any of the hosts on= the network.=C2=A0

    If the Wifi system provides an= ND proxy, fairly common at least in enterprise class WiFi systems, or if a= separate ND proxy is provided on a separate promiscuous mode port like the= router has, it sees and can send traffic to all hosts, the ND proxy could = defend each of host's link-local address from the other isolated hosts = preventing any possibility of a duplicate link-local address among the host= s, and allowing the router to track link-local addresses and utilize its st= andard NS and NA processes, only requiring modification of the RA process. = =C2=A0=C2=A0

    There is a trade-off here though, if = the router could track the hosts' link-local addresses it could use it&= #39;s normal and presumably well debugged code paths for NS and NA and many= of the normal tools on the router at least those that utilize link-local a= ddressing.=C2=A0 Or, it can use custom code for NS and NA probably breaking= all tools on the router, even those that could use link-local addressing, = for the advantage of not having to track each of the hosts link-local addre= sses.=C2=A0 There are benefits and costs with both options, in my opinion i= t's mostly a tie.=C2=A0 It probably boils down to how many hosts does t= he environment really need to scale too, verses how adaptable the staff tha= t has to operate and troubleshoot=C2=A0the environment is.

    Here at UMN, if we can eliminate the tracking of each hosts multip= le GUA addresses by the routers, that's probably a big enough win by it= self that I'd probably opt to keep the tracking of link-local addresses= normal, keeping as many tools on the router as normal as I could.=C2=A0

    Thanks

    =C2=A0=C2=A0 =C2=A0<= /div>
    --001a114d95b6386f1f05580837dc-- From nobody Thu Aug 31 02:46:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13541329AB; Thu, 31 Aug 2017 02:46: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 kgR1JT3N0Bsa; Thu, 31 Aug 2017 02:46:53 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77890132715; Thu, 31 Aug 2017 02:46:53 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id C3AB52D5022; Thu, 31 Aug 2017 09:46:51 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C12A51007686D; Thu, 31 Aug 2017 11:46:50 +0200 (CEST) From: Ole Troan Message-Id: <6FD16281-8C04-44CC-AFA4-449D39CB5554@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FA773D28-904B-4484-B793-D3C714C2C662"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 11:46:49 +0200 In-Reply-To: Cc: Lorenzo Colitti , "v6ops-ads@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" To: David Farmer References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 09:46:56 -0000 --Apple-Mail=_FA773D28-904B-4484-B793-D3C714C2C662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31 Aug 2017, at 10:13, David Farmer wrote: >=20 >=20 > On Aug 30, 2017, at 19:11, Lorenzo Colitti wrote: >=20 >> On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter = wrote: >> If there are any multicast RA/PIOs for these prefixes, they should = have >> A=3D0; L=3D0 (cf RFC8028). >>=20 >> But I'm not sure why there would be any multicast RAs. They don't >> seem to be needed. The draft talks about unicast RAs. >>=20 >> Unicast RAs would require the router to keep state on all its clients = regardless of its IP addresses and across IP address changes. That = doesn't scale. It's much better for the router to send a multicast RA on = each separate L2 link, knowing that it will go only to the host on that = link that has that prefix. > As I've said I'm not aware of any WiFi systems providing a full = bi-directional VLAN per host isolation, or in other words, each host get = its own VLAN interface on the router side. This seems to be what Lorenzo = is talking about. However, I wouldn't be quite pleasantly surprised to = be proven wrong about that though. >=20 > The solutions I'm aware of provide isolation only on the host side, = not the router side, similar to private VLANs on Ethernet switches, or = in other words, all the hosts share a common VLAN interface on the = router side, but are isolated from each other. >=20 > https://en.m.wikipedia.org/wiki/Private_VLAN >=20 > In any case the router has to maintain an association of host MAC = addresses and unique prefixes for next-hop delivery of packets destine = to each unique prefix. When the router assigns a unique prefix to a host = in response to the host's initial RS, it will have to populate this. >=20 > RAs can also be formed from the information in this table. As Lorenzo = said the router should send RAs, with a PIO for the unique prefix of = each host with A=3D1, L=3D0, in response to an RS or for periodic RAs, = destine to the all-hosts multicast address in the IPv6 header, so it = doesn't have to track all the IIDs associated with each host. However, = it should not use the associated multicast MAC address as the L2 = destination but the unicast MAC address of the host assigned the unique = prefix. As I said the router has to maintain RA isolation per host, this = is fundamental to this technique. If this is done then it doesn't matter = if each host has it own VLAN interface on the router side or if the = hosts share a common VLAN interface on the router side. >=20 > Whether the return traffic is isolated, or not, is not up to the = router, it's up to the WiFi system or Ethernet switch. But if it's not = isolated the router has gone to the effort of isolating the RA for = little reason, other than to waste a bunch of prefixes for no benefit = that makes any sense to me. If you want the hosts to talk to each other = directly this is far more efficiently done with the classic multi host = per subnet model. >=20 > It might also be useful to advertise a PIO for the aggregate prefix = the router uses to assign the unique prefixes from, or even the = providers aggregate prefix, with A=3D0, L=3D0, to the all-hosts = multicast address in the IPv6 header and the MAC header, to ensure hosts = compliment with RFC8028, that may have other interfaces, would prefer = routing of these prefixes to the provider first hop router instead of = out their other interface. >=20 > If the technique above is used and isolation is provided on the host = side, a host could form a duplicate Link-local address with another = isolated host, and it wouldn't cause an issue, as the router is not = using or tracking the link-local neighbors. This also requires a = modification of the routers response to NS queries from hosts it must = use the source IPv6 address and source MAC address from the NS as the = destination IPv6 address and destination MAC address of the NA without = tracking them, as different host could have the same source IPv6 = address. The router needs to and should be able to defend its link-local = address against each of isolated hosts so that the one of the hosts = doesn't form a duplicate of the router's link-local address, as this = would cause issues. In this case I would consider each host to be on a = separate link, the router on each of these links has the same link-local = address. >=20 > If isolation at least on the host side is not provided by L2 then the = router and all the hosts are on a common link, link-local addresses will = work normally and malicious hosts could man-in-the-middle any traffic = from any of the hosts on the network. >=20 > If the Wifi system provides an ND proxy, fairly common at least in = enterprise class WiFi systems, or if a separate ND proxy is provided on = a separate promiscuous mode port like the router has, it sees and can = send traffic to all hosts, the ND proxy could defend each of host's = link-local address from the other isolated hosts preventing any = possibility of a duplicate link-local address among the hosts, and = allowing the router to track link-local addresses and utilize its = standard NS and NA processes, only requiring modification of the RA = process. >=20 > There is a trade-off here though, if the router could track the hosts' = link-local addresses it could use it's normal and presumably well = debugged code paths for NS and NA and many of the normal tools on the = router at least those that utilize link-local addressing. Or, it can = use custom code for NS and NA probably breaking all tools on the router, = even those that could use link-local addressing, for the advantage of = not having to track each of the hosts link-local addresses. There are = benefits and costs with both options, in my opinion it's mostly a tie. = It probably boils down to how many hosts does the environment really = need to scale too, verses how adaptable the staff that has to operate = and troubleshoot the environment is. This can be implemented without any changes to ND code. We have done that as part of the VPP project: = https://gerrit.fd.io/r/#/c/7224/ Since you no longer need to do address resolution and maintain the ND = cache, this scales well and is much more resilient against attack than = the ND cache. You only need to keep long lived "per subscriber" state in = the router. Ole --Apple-Mail=_FA773D28-904B-4484-B793-D3C714C2C662 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZp9sKAAoJEL7aWKiYQt92WJ8QAISZGCqnyI+Mv3m9TVYTEKHX vUleQI3qQhxVi0MLa4skLidriR0mdKbwER505Hfd2x6Q80oO06Vid9WGulHboLUP X0CDoLJZ/V7t6tQh9JUp9Dzfvix5Lh3pb8teIVOtZh4VF3hBUDHI35hHfWpPevGR 7WcIRuOrk68gHKvfVoma7H4OxpM3ejejgdyC165esARHPlb24PN/SE/DPp40uGsT K5T7jXnRn9YBvCa/6ekJFvkwrgUPVMvyFs4vY+Y6LnE9UIFiBGOa627RqCpYQfzA +x5RNaVrRva/SnX2d2OwQij6s0CGLvXGSrvg9TLLzEPkdkGLEr338SCpT+Fq/Yxo lk91tC1+QeHtNIvOPWJac1f8OQCnIbWnxHtXfQCZsFVzctoYnSzzXUY+M6eGJxfd nPmLIG/Ih/fW2FeS4dN972C9ZJm0pa9RpRFKexnGEORSkoI+h6ri9czF6qeAwzto S/vQF/VKAZgUGWklCwxlzugV709E3xl4ihFpBqPW7C5AMEFpO3M/uscJcYn6nU8y cYP0d2g/eNJN5BHnzs7qM9ziZWOEPXs9G29mLI3pGi7F5G3JyIoKXcUxYitKdKQO CJR2CGx58aky9uQxRmlaJGDQ0ujCZ9FMT3h+tE2BSD0VrFCH5GC3FWvd0t++Pgf8 jQvyIQaIrWoLyeK/KItI =L185 -----END PGP SIGNATURE----- --Apple-Mail=_FA773D28-904B-4484-B793-D3C714C2C662-- From nobody Thu Aug 31 02:54:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D64132D44 for ; Thu, 31 Aug 2017 02:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 LkrTjF4Dzyoy for ; Thu, 31 Aug 2017 02:54:11 -0700 (PDT) Received: from omr2.cc.vt.edu (omr2.cc.ipv6.vt.edu [IPv6:2607:b400:92:8400:0:33:fb76:806e]) (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 50EFC132D3F for ; Thu, 31 Aug 2017 02:54:11 -0700 (PDT) Received: from mr3.cc.vt.edu (mr3.cc.ipv6.vt.edu [IPv6:2607:b400:92:8500:0:7f:b804:6b0a]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id v7V9sAHR015563 for ; Thu, 31 Aug 2017 05:54:10 -0400 Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id v7V9s5cZ023057 for ; Thu, 31 Aug 2017 05:54:10 -0400 Received: by mail-oi0-f69.google.com with SMTP id l185so353696oib.4 for ; Thu, 31 Aug 2017 02:54:10 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B1qxf8emYXa9mUHK8SjogeU+i1U6904B9e47tOLh9PU=; b=Yl9t/a56zns6V8AAt26NumKsIn2GtoarmXv091RR9O9Et8j0QhRQ6pWc2d4gPghSp9 M3G74TCTscY3kTDaZFwgGjsm6yGMw5g6dKkUqym0CvmGWmuirhzJb1FGTI9Ln1my1hbl n5BQS1seRBHu7LtuQLl6pGXX959IFSh77YGYzElShN3kOr7dceeMMEJUTZC7lYil15V0 3ILoPes6HOPLGIin+rVPALAEiux8QByysVB/ZfLldVn5oX+TtD/nOWf/Moq8sa3SBR+q gsCixvVTfERwHgPd/ezKZ3yW2r1w32aalSMceUrl52zk6HGhDJkeQ+MKPRoHmg0eenhu fAJQ== X-Gm-Message-State: AHYfb5hKEYw/oOCJ+4HdI92//wCMCnbwP7vfGl5U1k35a9GOTD7FvDRV WpjPt75d4nJBEgrJ7jlSrNTxmKY8YHoYV2A+gK4JbZfJzljJ94dBQ3LRSjakEtUHf+97+/iKyos LQkWEZWprjhiLIY5maQnsR20= X-Received: by 10.202.102.80 with SMTP id a77mr4940365oic.282.1504173244904; Thu, 31 Aug 2017 02:54:04 -0700 (PDT) X-Received: by 10.202.102.80 with SMTP id a77mr4940345oic.282.1504173244518; Thu, 31 Aug 2017 02:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.13 with HTTP; Thu, 31 Aug 2017 02:54:03 -0700 (PDT) Received: by 10.168.73.13 with HTTP; Thu, 31 Aug 2017 02:54:03 -0700 (PDT) In-Reply-To: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> From: Clark Gaylord Date: Thu, 31 Aug 2017 05:54:03 -0400 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org" , "Templin, Fred L" Content-Type: multipart/alternative; boundary="001a1140fdf6ebabc20558099f51" Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 09:54:14 -0000 --001a1140fdf6ebabc20558099f51 Content-Type: text/plain; charset="UTF-8" On Aug 29, 2017 3:39 PM, "Mikael Abrahamsson" wrote: DHCP is fundamentally a polling protocol and if a lease has been handed out, it's not yours and you can keep it until it times out. Granted DHCP is polled, but more to the point it is an explicit assignment responding to the poll: "I'd like an address" "Ok here's your address" "Thanks, bud" With RS/RA it's more: "So how does one do addressing around here?" "If you do it like this, then I might talk to you. By the way, you don't need to ask, I'm going to occasionally remind you anyway. And I might change my mind." So for PD, the DHCP implementation is straightforward: "While your at it, I'd like a prefix I can use to give addresses to my friends. Someday I hope to be a real boy." "Here's a prefix you can use for your friends. But you'll always be a little wooden puppet." So what's the analog for a RS/RA PD implementation: "How does one do addressing around here? Btw, I might have friends that ask me the same question, if you'd care to give me that spec too." "Here's how we do things around here. If you have friends I don't otherwise know about, assign them addresses like this. Make sure you let me know when you do, if you expect me to send packets to you on behalf of your friends. These rules might change, so make sure your friends are aware of that too." It's certainly doable, and the protocol gap exists. The question is if you like RS/RA, are you likely to want to support PD? Right now we don't have a full solution for this. DHCPv6 and RS/RA are basically ships in the night and it's not clear how messages sent using one protocol, would affect the They can be ships in the night, but I think most environments choose which approach makes sense for them. They can coexist, but I don't think you want to couple them. other. A minimum would be some kind of coupling between a DHCPv6 relay router and what it puts in the RA and how this affects the DHCPv6 information. That's an interesting idea, regardless of PD implications, but PD makes it more clear. If the relay agent (typically the router) expects certain config policies, he can confirm the offered DHCP config is consistent with the policy. "DHCP is offering addresses like X and I'm using Y." Then the policy can choose: "But I'm not going to say anything" or "I'm telling mom!" or "I'm not forwarding this bogus offer" Perferrably I'd like to be able to do everything without DHCPv6 at all. The network is the one true source of its own configuration.... :-) -- Clark Gaylord cgaylord@vt.edu ... Autocorrect may have improved this message Brevity should not be interpreted as curtness ... --001a1140fdf6ebabc20558099f51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Aug 29, 2017 3:39 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
    DHCP is fundamental= ly a polling protocol and if a lease has been handed out, it's not your= s and you can keep it until it times out.

    Granted DHCP is polled= , but more to the point it is an explicit assignment responding to the poll= :
    "I'd like an address"
    "Ok here's your address"
    &qu= ot;Thanks, bud"

    Wit= h RS/RA it's more:
    "So how does one do addr= essing around here?"
    "If you do it like th= is, then I might talk to you. By the way, you don't need to ask, I'= m going to occasionally remind you anyway. And I might change my mind."= ;

    So for PD, the DHCP im= plementation is straightforward:
    "While your at= it, I'd like a prefix I can use to give addresses to my friends. Somed= ay I hope to be a real boy."
    "Here's a= prefix you can use for your friends. But you'll always be a little woo= den puppet."

    So wha= t's the analog for a RS/RA PD implementation:
    &q= uot;How does one do addressing around here? Btw, I might have friends that = ask me the same question, if you'd care to give me that spec too."=
    "Here's how we do things around here. If y= ou have friends I don't otherwise know about, assign them addresses lik= e this. Make sure you let me know when you do, if you expect me to send pac= kets to you on behalf of your friends. These rules might change, so make su= re your friends are aware of that too."

    It's certainly doable, and the protocol gap exists= . The question is if you like RS/RA, are you likely to want to support PD?<= /div>


    Right now we don't have a full solution for this. DHCPv6 and RS/RA are = basically ships in the night and it's not clear how messages sent using= one protocol, would affect the

    They can be ships in the night, but I thi= nk most environments choose which approach makes sense for them. They can c= oexist, but I don't think you want to couple them.

    other. A minimum would be some kind of c= oupling between a DHCPv6 relay router and what it puts in the RA and how th= is affects the DHCPv6 information.

    That's an interesting idea, reg= ardless of PD implications, but PD makes it more clear. If the relay agent = (typically the router) expects certain config policies, he can confirm the = offered DHCP config is consistent with the policy.
    &= quot;DHCP is offering addresses like X and I'm using Y."
    Then the policy can choose:
    "But = I'm not going to say anything" or
    "I&#= 39;m telling mom!" or
    "I'm not forward= ing this bogus offer"

    Perferrably I'd like to be able to do everything without DHCPv6= at all.

    The network is the one true source of its own configuration.... := -)

    --
    Cl= ark Gaylord
    cgaylord@vt.edu
    ..= . Autocorrect may have improved this message
    =C2=A0=C2=A0=C2=A0 Brevity = should not be interpreted as curtness ...
    --001a1140fdf6ebabc20558099f51-- From nobody Thu Aug 31 04:33:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF73A132D51 for ; Thu, 31 Aug 2017 04:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqhkHeqzAHbO for ; Thu, 31 Aug 2017 04:33:25 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4C5132D60 for ; Thu, 31 Aug 2017 04:33:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 763DCAF; Thu, 31 Aug 2017 13:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504179189; bh=kh/KYkg/JsFD25S9cPGPuv3pw9vbQ0hEpP/oPBGrpdg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vYVb5emRUOsKXLU4jQUD3mVOWbgsUA6k8c//OkSrnXsQLE+RgHDbh1Wc7E9QklUL+ EHkRQVp78WyohkqhOnz+59gkqNg1/qYsGhq2DOUIr7aXJJ5C5iji0taGbeMNw5ixX5 w71GzIunkFdDaLmLimiecycb5fofRfLIzmclh/yY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5ECD884; Thu, 31 Aug 2017 13:33:09 +0200 (CEST) Date: Thu, 31 Aug 2017 13:33:09 +0200 (CEST) From: Mikael Abrahamsson To: Clark Gaylord cc: "v6ops@ietf.org" , "Templin, Fred L" In-Reply-To: Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:33:28 -0000 On Thu, 31 Aug 2017, Clark Gaylord wrote: > They can be ships in the night, but I think most environments choose > which approach makes sense for them. They can coexist, but I don't think > you want to couple them. I have this problem right now. I have a largish router that does DHCPv6 PD proxy (amongst other things). For some reason the proxy loses state, so the PD binding isn't there, so no more PD route towards the HGW (home gateway). After refresh timer HGW asks "hey, can I please renew these?" the response is "nobinding" (ie "I have no idea what you're talking about"). The HGW then happily just says "ok then" and keeps the lease (because the lease is still valid), and thinks everything is fine and dandy (it's not). I can't make this router say anything in RA or ND that makes the HGW restart its DHCPv6 PD process (do discovery again). The only way I know is to physically flap the port towards the HGW. We have no signal to say "look, everything has changed around here, please re-confirm your resources, if you can't confirm them within X seconds, drop them and try to get new ones". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 31 04:55:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AC4132D51 for ; Thu, 31 Aug 2017 04:55: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 mEeolepMExS9 for ; Thu, 31 Aug 2017 04:55:01 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CE8132D60 for ; Thu, 31 Aug 2017 04:55:01 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6A0572D4FD1; Thu, 31 Aug 2017 11:54:58 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 556C8100B89DE; Thu, 31 Aug 2017 13:54:56 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_45FF5BD0-4A85-482E-B854-A88E4D71ADE5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 13:54:55 +0200 In-Reply-To: Cc: Clark Gaylord , "v6ops@ietf.org" To: Mikael Abrahamsson References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:55:08 -0000 --Apple-Mail=_45FF5BD0-4A85-482E-B854-A88E4D71ADE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, >> They can be ships in the night, but I think most environments choose = which approach makes sense for them. They can coexist, but I don't think = you want to couple them. >=20 > I have this problem right now. I have a largish router that does = DHCPv6 PD proxy (amongst other things). For some reason the proxy loses = state, so the PD binding isn't there, so no more PD route towards the = HGW (home gateway). After refresh timer HGW asks "hey, can I please = renew these?" the response is "nobinding" (ie "I have no idea what = you're talking about"). Let me quote this relevant paragraph from 1958: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. In this case when you have a snooping DHCPv6 PD relay, there are no = protocol mechanics there to save you. The obvious answer is that you shouldn't do this. Snooping and gathering = state by "listening" in to other protocol entities communicating is a = bad idea. Now what should you do instead? Well Markus and I wrote about this in: https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 We also wrote on this topic back in 2006: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 Which Ralph resubmitted a few months ago. With a somewhat unfortunate = date. ;-) If I were to recommend something, I would require the requesting router = (HGW in your parlance) to be responsible for maintaining the state in = intermediate devices. The mechanism I'd like to use for that is = something akin to BFD echo mode. The RR sends a packet (e.g. ICMP echo) = destined to _itself_ using a destination address from the delegated = prefix via its first-hop router. If packet is received the RR is = guaranteed that the fist hop router has forwarding state. If packet is = not received, that should trigger the RR to revalidate the prefix with a = DHCP VERIFY or RENEW message. >=20 > The HGW then happily just says "ok then" and keeps the lease (because = the lease is still valid), and thinks everything is fine and dandy (it's = not). >=20 > I can't make this router say anything in RA or ND that makes the HGW = restart its DHCPv6 PD process (do discovery again). The only way I know = is to physically flap the port towards the HGW. We have no signal to say = "look, everything has changed around here, please re-confirm your = resources, if you can't confirm them within X seconds, drop them and try = to get new ones". Best regards, Ole --Apple-Mail=_45FF5BD0-4A85-482E-B854-A88E4D71ADE5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZp/kQAAoJEL7aWKiYQt92oyUP/02bHRltdFdEBkvnVCU/NQRE GrSfcLPeWMPh9rloAGvjIMGA/jJedLhqBlizElpyNhsTjFNDgbuxTB62KuLWw6fi m/mMQelnHFYdJabJ2tGZui+kwz6NXdRClD3vtH5SeieHN44e6sBpLBEbUdNcAkrz tU3hxLavcZ6DM/K0zcGIap5Lrgwxy87msG3wHBbvg0i8XWdnysSzDDY52ElsmWXT In7SiNs3F8iR1BL7wvY3ycDew5J//ij3ExgkHTsa7FH0EO5VKgWdYeIua/cYn2+S LZts09BvIFzb0GYxEd5kkTNkOcugNcZ4xHevY6scHxbWIE7HGCs405eXIxV3BPl/ X9KxVL5K8YPwdcTqnqMHszZxWqNlTis8svIoad0TbmoWUX6Q+DKZ6KUcsQJy7uJv 2JP9XdVQ09JICT7hjo4AbgbpIV4a8orxdJOGgycrO7BY1exxB5ZgqTuHzG2/bPw8 ZQPSTqly1TOHV3JaGhOM47bGhTEjYXakeNJN9o8lBdEEmpGxIqeQHIRx/JgdMXft xwgq7M4yAXhr/jqE2D9ueBll1BWCrTIIpfHnNkxamKEcsOGAKkbHwItOtO2yNd7r oNNllYySibde/IGh89dTfr4+nFtbwnwZyhYLbIwsKFxQNT1ewQlTYsRpQRWxywgt LRh0jPHhh3R+uKeYwr8U =QSG2 -----END PGP SIGNATURE----- --Apple-Mail=_45FF5BD0-4A85-482E-B854-A88E4D71ADE5-- From nobody Thu Aug 31 04:57:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056B3132D5D for ; Thu, 31 Aug 2017 04:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RvoaERFOIUnV for ; Thu, 31 Aug 2017 04:57:27 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F4D132D51 for ; Thu, 31 Aug 2017 04:57:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id AECBF1BC37 for ; Thu, 31 Aug 2017 11:57:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Thu, 31 Aug 2017 12:57:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C3359F8-BEA8-401D-8AA7-29C9312381E4@thehobsons.co.uk> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:57:30 -0000 Mikael Abrahamsson wrote: > I have this problem right now. I have a largish router that does = DHCPv6 PD proxy (amongst other things). For some reason the proxy loses = state, so the PD binding isn't there, so no more PD route towards the = HGW (home gateway). After refresh timer HGW asks "hey, can I please = renew these?" the response is "nobinding" (ie "I have no idea what = you're talking about"). >=20 > The HGW then happily just says "ok then" and keeps the lease (because = the lease is still valid), and thinks everything is fine and dandy (it's = not). >=20 > I can't make this router say anything in RA or ND that makes the HGW = restart its DHCPv6 PD process (do discovery again). The only way I know = is to physically flap the port towards the HGW. We have no signal to say = "look, everything has changed around here, please re-confirm your = resources, if you can't confirm them within X seconds, drop them and try = to get new ones". But I don't think that's relevant here. Your issue is "I have this piece = of kit that doesn't work properly, it's a problem that I can't tell this = other bit of kit to do something 'out of spec' to work around the fault = in the faulty kit". From nobody Thu Aug 31 05:18:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9AA132D5A for ; Thu, 31 Aug 2017 05:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve7W13Yv7K_y for ; Thu, 31 Aug 2017 05:18:13 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAC9132D5B for ; Thu, 31 Aug 2017 05:18:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C80DAF; Thu, 31 Aug 2017 14:18:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504181891; bh=l/BV9k4rGHEh0qQ/EFkovym8iAViY2ZCpGkAq7VNsz8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=llWm+gyAWyZGG7ecz9K3FFb+fbB6gq1BvMwWBo1A5fBJDDo/Tc6cOuYZ4k66IuQC7 nEC3hUh59lDbXBnl1J5aKD8Yp14Rlzmakva0YLUws35ZYbAwy3zqtO7otCJqF44lZD jpFq8HbvYNq98ZrdxCyJ3ZWJLZgZ4BpaMoUUE8HA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3536E84; Thu, 31 Aug 2017 14:18:11 +0200 (CEST) Date: Thu, 31 Aug 2017 14:18:11 +0200 (CEST) From: Mikael Abrahamsson To: Simon Hobson cc: "v6ops@ietf.org list" In-Reply-To: <9C3359F8-BEA8-401D-8AA7-29C9312381E4@thehobsons.co.uk> Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <9C3359F8-BEA8-401D-8AA7-29C9312381E4@thehobsons.co.uk> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:18:15 -0000 On Thu, 31 Aug 2017, Simon Hobson wrote: > But I don't think that's relevant here. Your issue is "I have this piece > of kit that doesn't work properly, it's a problem that I can't tell this > other bit of kit to do something 'out of spec' to work around the fault > in the faulty kit". What part is faulty? The PD proxy in the router? Yes, you might say so. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 31 05:28:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE79132D84 for ; Thu, 31 Aug 2017 05:28: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llKHUIEfu8up for ; Thu, 31 Aug 2017 05:28:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC51D132D87 for ; Thu, 31 Aug 2017 05:28:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7A3BBAF; Thu, 31 Aug 2017 14:28:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504182505; bh=lxVz0TG+cGqIDxUTC7AZ8NQFJy/AeTnNoLiuZWY4OBQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sspmxFR2dhFxtNgRf5jLLkNEslwiIMaERN0aHPYHTIlU5f/gK9SIJpV5GiG9jUoIL A1rqoCPGbUlPhNIVQrG1mQNk8mM8wmEQiKn2YxpnwiEtLv3X+ScK5icaF9XgBsmZM+ F2i01pUcMPDNhTmoBbUPP1B/CYg7ducJrlT5rzIM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 62CD984; Thu, 31 Aug 2017 14:28:25 +0200 (CEST) Date: Thu, 31 Aug 2017 14:28:25 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Clark Gaylord , "v6ops@ietf.org" In-Reply-To: Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:28:30 -0000 On Thu, 31 Aug 2017, Ole Troan wrote: > In this case when you have a snooping DHCPv6 PD relay, there are no protocol mechanics there to save you. Well, the well-known vendor calls it a "proxy". It's kind of a relay. But not. And the code-base seems intertwined with the vendor DHCPv6 server implementation that is also available on the router, because sometimes the proxy does funky things that a relay/proxy should never do. > The obvious answer is that you shouldn't do this. Snooping and gathering state by "listening" in to other protocol entities communicating is a bad idea. I agree. But, this seems to be the way things are typically done in DHCPv6 land. > Now what should you do instead? > Well Markus and I wrote about this in: > https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 Seems to capture a lot of the problems, yes. > We also wrote on this topic back in 2006: > https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 > > Which Ralph resubmitted a few months ago. With a somewhat unfortunate date. ;-) Right. > If I were to recommend something, I would require the requesting router > (HGW in your parlance) to be responsible for maintaining the state in > intermediate devices. The mechanism I'd like to use for that is > something akin to BFD echo mode. The RR sends a packet (e.g. ICMP echo) > destined to _itself_ using a destination address from the delegated > prefix via its first-hop router. If packet is received the RR is > guaranteed that the fist hop router has forwarding state. If packet is > not received, that should trigger the RR to revalidate the prefix with a > DHCP VERIFY or RENEW message. Makes sense. Not that I am a network application programmer, but it looks like this will require raw sockets to accomplish. I'll look into it. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 31 05:28:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DFB132D87 for ; Thu, 31 Aug 2017 05:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=helix-net-nz.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 E9rUxX6xS8e2 for ; Thu, 31 Aug 2017 05:28:50 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A7C132D84 for ; Thu, 31 Aug 2017 05:28:50 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p67so2041784qkd.2 for ; Thu, 31 Aug 2017 05:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jUcrun4jsX8nRU1UOzxh3GnNNt6xHfBroIwZVyQLd5U=; b=rtmJmaNjdGy2sUXAKHqsHfL/NmP25jkMetgYJ1zltQfKM8F92f7/zPlS7WWn3uxTgN YjMk74Pvv+G9NdFbd/NACIS0l4JGHEn08/CQs0E1HSFVzC5WsCoQ9Bpm11I4tMXch9AR e7vWWEI4z3nqz28l4vsXfNKOyh5Jq2BropLgYLmMUAzrXt45EYMNJNz6BhUF9gqBQ7ts YhHPFPc3VuooCLYQYbl1JyKmh6yOr24dbYAf1cb/1jNao8O/WikeU+gxP5TcutlZS3Ki Zfpk/Srw6+zmSXYBSHx+9Urlvjam1qCqhpDbqYtBMFtCusKymaRSW0mvkZKINs2tKtkd OwuA== 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=jUcrun4jsX8nRU1UOzxh3GnNNt6xHfBroIwZVyQLd5U=; b=TOmyJ13blZC1DVqeIiTFd47dMUL2rCEzuIsehgXxID4O5/7BG0rgbzMRUQa7efgDbw J9I7BierJaaEFqbP/rnl4mZJmlEu9g+/S/VKPphnDpOrvH0vdG7WF1so90tc8l2+eWRK FfbiW36cKvFMD0G0rRTWKdMsi0wPbLSg8BxF24ZxsZYfVF2W4rbPHS+GCEHvIVUMl+nM JjBE/Qd8DfL8C8s9e+V0Ea095mQ3kKjygvyxw2G+fzaEmODKRwNrot9u43O4jk0hO/N9 1ZPxd//Qz2Cr3aSFeWL73DTPtA9r1zWnw/ke/b0PQ59uLJOmhUZdrmmh6wIKKin6z3c2 hfGQ== X-Gm-Message-State: AHYfb5ig2eyBYeY88BHSOO9gDyrhmpHDzYUdE0Gu21bybAOroQaUkejp nqYDj4p/ny4n8a/jq0k= X-Received: by 10.233.239.137 with SMTP id d131mr3657038qkg.67.1504182529241; Thu, 31 Aug 2017 05:28:49 -0700 (PDT) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com. [209.85.220.174]) by smtp.gmail.com with ESMTPSA id z35sm5556487qtb.34.2017.08.31.05.28.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 05:28:48 -0700 (PDT) Received: by mail-qk0-f174.google.com with SMTP id k126so2011896qkb.4 for ; Thu, 31 Aug 2017 05:28:48 -0700 (PDT) X-Received: by 10.55.204.214 with SMTP id n83mr3334086qkl.47.1504182528271; Thu, 31 Aug 2017 05:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.83.211 with HTTP; Thu, 31 Aug 2017 05:28:27 -0700 (PDT) In-Reply-To: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <9C3359F8-BEA8-401D-8AA7-29C9312381E4@thehobsons.co.uk> From: Richard Patterson Date: Thu, 31 Aug 2017 13:28:27 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , Mikael Abrahamsson Content-Type: multipart/alternative; boundary="001a11479968466da105580bc9c0" Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:28:53 -0000 --001a11479968466da105580bc9c0 Content-Type: text/plain; charset="UTF-8" On 31 August 2017 at 13:18, Mikael Abrahamsson wrote: > >> What part is faulty? The PD proxy in the router? Yes, you might say so. Your HGW/client. When the HGW receives the Reply with a "nobinding" in the IA, it should trigger a Request instead of failing silently. If the server can't honour that Request it should send back a Reply with NoAddrAvail. Your HGW/client can then send a new Solicit or Request for a different IA. When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently. For each IA in the original Renew or Rebind message, the client: - sends a Request message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages) --001a11479968466da105580bc9c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    = On 31 August 2017 at 13:18, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

    What part is faulty? The PD proxy in the router? Yes, you might say so.

    Your HGW/client.

    When= the HGW receives the Reply with a "nobinding" in the IA, it shou= ld trigger a Request instead of failing silently.
    If the server c= an't honour that Request it should send back a Reply with NoAddrAvail. = Your HGW/client can then send a new Solicit or Request for a different IA.<= /div>



     When the client receives a Reply message in response to a Re=
new or
   Rebind message, the client examines each IA independently.  For each
   IA in the original Renew or Rebind message, the client:

   -  sends a Request message if the IA contained a Status Code option
      with the NoBinding status (and does not send any additional
      Renew/Rebind messages)
    --001a11479968466da105580bc9c0-- From nobody Thu Aug 31 05:34:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE57132D92; Thu, 31 Aug 2017 05:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8uTYAfqmeZYV; Thu, 31 Aug 2017 05:34:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.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 76E5F132D8C; Thu, 31 Aug 2017 05:34:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GSAQCYAahZ/yYyC4dbAw4LAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCbyJJZIEVB54ugXGWJw6BJQNcLoUZAhqDcEAXAQIBAQEBAQE?= =?us-ascii?q?BA2gogmVGWAEBAQEBASMCPiwBAQEBAgESEQpMBQkCAgEIDQQBAwEBAQoWAQYDA?= =?us-ascii?q?gICGQsMFAMGCAIEAQ0EAQgaiStcCAEPo1iKaYInIgKLIQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBARgFBYMlggKBT4UKhDkJAQsBBgEhBAgJCgsKAg+CTDCCMQWYMYg+A?= =?us-ascii?q?odZmGCHBJZFIQE2TjQLdxWFYRyBKD92AYgKAQ4XgQwBgQ4BAQE?= X-IPAS-Result: =?us-ascii?q?A2GSAQCYAahZ/yYyC4dbAw4LAQEBAQEBAQEBAQEHAQEBAQG?= =?us-ascii?q?CbyJJZIEVB54ugXGWJw6BJQNcLoUZAhqDcEAXAQIBAQEBAQEBA2gogmVGWAEBA?= =?us-ascii?q?QEBASMCPiwBAQEBAgESEQpMBQkCAgEIDQQBAwEBAQoWAQYDAgICGQsMFAMGCAI?= =?us-ascii?q?EAQ0EAQgaiStcCAEPo1iKaYInIgKLIQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFB?= =?us-ascii?q?YMlggKBT4UKhDkJAQsBBgEhBAgJCgsKAg+CTDCCMQWYMYg+AodZmGCHBJZFIQE?= =?us-ascii?q?2TjQLdxWFYRyBKD92AYgKAQ4XgQwBgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.41,453,1498536000"; d="scan'208,217";a="211499525" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Aug 2017 08:34:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 09:09:13 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 08:34:12 -0400 From: "Mudric, Dusan (Dusan)" To: David Farmer , Tim Chown CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AQHTIaHXJRZ/2Amb6kuf8y3mZbnClqKdRWcAgAArdwCAAPQcQA== Date: Thu, 31 Aug 2017 12:34:12 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E4585AB93DE@AZ-US1EXMB03.global.avaya.com> References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E4585AB93DEAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:34:25 -0000 --_000_9142206A0C5BF24CB22755C8EC422E4585AB93DEAZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LTA3DQoNCuKAnFRoaXMNCg0KICAgUkEgY29udGFpbnMgdHdvIGltcG9y dGFudCBwYXJhbWV0ZXJzIGZvciB0aGUgRVUvc3Vic2NyaWJlciB0bw0KDQogICBjb25zdW1lOiBh IFVuaXF1ZSBJUHY2IHByZWZpeCAoY3VycmVudGx5IGEgLzY0IHByZWZpeCkgYW5kIHNvbWUNCg0K ICAgZmxhZ3MuICBUaGUgVW5pcXVlIElQdjYgcHJlZml4IGNhbiBiZSBkZXJpdmVkIGZyb20gYSBs b2NhbGx5IG1hbmFnZWQNCg0KICAgcG9vbCBvciBhZ2dyZWdhdGUgSVB2NiBibG9jayBhc3NpZ25l ZCB0byB0aGUgRmlyc3QgSG9wIFByb3ZpZGVyDQoNCiAgIFJvdXRlciBvciBmcm9tIGEgY2VudHJh bGx5IGFsbG9jYXRlZCBwb29sLg0KDQog4oCcDQpJZiB0aGUgcm91dGVyIGlzIGFibGUgdG8gYXNz aWduIGEgdW5pcXVlIHByZWZpeCBmcm9tIGEgcHJlZml4IHBvb2wsIGl0IHNob3VsZCBiZSBhYmxl IHRvIGFzc2lnbiBhIHVuaXF1ZSBhZGRyZXNzIGZyb20gYW4gYWRkcmVzcyBwb29sLiBUaGVyZSBp cyBubyBuZWVkIGZvciBEQUQgd2l0aCB1bmlxdWUgYWRkcmVzc2VzLiBJZiB0aGVyZSBpcyBubyBw cmVmaXggYXNzaWduZWQ6DQoNCuKAnCAgIG8gIFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3Rz KSwgYm90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KDQogICAgICBtYW5hZ2VkIHNo YXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdGhyb3VnaA0K DQogICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVy4oCcDQoNClRoZSBz ZWN1cml0eSBjb250cm9sIGlzIGFjaGlldmVkIHdpdGhvdXQgYXNzaWduaW5nIC82NCBzdWJuZXQg dG8gYSBob3N0Lg0KDQpEdXNhbg0KDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIEZhcm1lcg0KU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMzAsIDIwMTcgMTo1MSBQTQ0KVG86IFRpbSBDaG93bg0KQ2M6IHY2b3BzQGlldGYub3Jn OyB2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc7IHY2b3BzLWFkc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt cGVyLWhvc3QtMDcnDQoNCg0KDQpPbiBXZWQsIEF1ZyAzMCwgMjAxNyBhdCAxMDoxNSBBTSwgVGlt IENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51azxtYWlsdG86VGltLkNob3duQGppc2MuYWMudWs+ PiB3cm90ZToNCj4gT24gMzAgQXVnIDIwMTcsIGF0IDE2OjA3LCBMb3JlbnpvIENvbGl0dGkgPGxv cmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4gd3JvdGU6DQo+DQo+ IE9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0IDM6MzEgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdy b3RlOg0KPiBTbywgSSBzZWUgdGhpcyBiZWluZyBhIHZlcnkgc2ltcGxlIGRvY3VtZW50IHRoYXQg d3JhcHMgaXRzZWxmIGFyb3VuZCBSRkM0ODYxLg0KPg0KPiBSRkM0ODYxIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGFsc28gYXBwbHkgKGluY2x1ZGluZyBSRkMzNzU2KSBhbmQgdGhpcyBkb2MNCj4N Cj4gc2hvdWxkIG5vdCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgdW5uZWNlc3NhcmlseSByZXN0cmlj dGluZyB0aGUgZG9tYWluIG9mDQo+DQo+IGFwcGxpY2FiaWxpdHkuDQo+DQo+IEkgdGhpbmsgeW91 J3JlIGVudGlyZWx5IG1pc3NpbmcgdGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVudC4gSXQncyB3cml0 dGVuIGNsZWFybHkgaW4gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNlY3Rpb24gdGhhdCB0 aGUgdGV4dCBhcHBsaWVzIHRvIHNpdHVhdGlvbnMgd2hlcmU6DQo+DQo+ICAgIG8gIFR3byBkZXZp Y2VzIChzdWJzY3JpYmVyL2hvc3RzKSwgYm90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRl cg0KPiAgICAgICBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8g Y29tbXVuaWNhdGUgdGhyb3VnaA0KPiAgICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBI b3AgUm91dGVyDQo+DQo+IFRoaXMgaXMgYW4gZXh0cmVtZWx5IGRlc2lyYWJsZSBzZWN1cml0eSBw cm9wZXJ0eSBpbiBhbnkgZW52aXJvbm1lbnQgd2hlcmUgdHJ1c3QgYmV0d2VlbiBkZXZpY2VzIGlz IGxpbWl0ZWQuIEluIHN1Y2ggZW52aXJvbm1lbnRzLCBzdGFuZGFyZCBTTEFBQyBvbiBzaGFyZWQg bGlua3MgY2Fubm90IGJlIG1hZGUgcmVsaWFibGUgaW4gdGhlIHByZXNlbmNlIG9mIGJ1Z2d5IG9y IG1hbGljaW91cyBob3N0cyB3aXRob3V0IGJyaXR0bGUgaGFja3MgdGhhdCBkb24ndCBzY2FsZSwg YW5kIGlzIHRodXMgYSBub24tc3RhcnRlciBmcm9tIGEgYW4gb3BlcmF0aW9uYWwgcG9pbnQgb2Yg dmlldyB1bmxlc3MgdGhlIGRldmljZXMgYXJlIHRpZ2h0bHkgY29udHJvbGxlZC4gVGh1cywgdGhl cmUgYXJlIHZlcnkgc29saWQgb3BlcmF0aW9uYWwgcmVhc29ucyB0byBsaW1pdCB0aGUgc2NvcGUg b2YgYXBwbGljYWJpbGl0eSB0byBzdWNoIG5ldHdvcmtzLg0KPg0KPiBJZiB5b3UgY2FuIGNvbnZp bmNpbmdseSBhcmd1ZSB0aGF0IHNlY3VyaXR5IG9yIHJlbGlhYmlsaXR5IHdvdWxkIG5vdCBiZSBs ZXNzZW5lZCBieSBhbGxvd2luZyBkaXJlY3QgcGVlci10by1wZWVyIGNvbW11bmljYXRpb24sIHRo ZW4gc3VyZSwgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgb2YgdGhpcyBkcmFmdCBjYW4gYmUg ZXhwYW5kZWQuIEkgZG9uJ3QgdGhpbmsgeW91J2xsIGJlIGFibGUgdG8gY29udmluY2luZ2x5IGFy Z3VlIHRoYXQuIFNheWluZyAiaXQncyBubyB3b3JzZSB0aGFuIHN0YW5kYXJkIFNMQUFDIiBpcyBu b3QgYSBjb252aW5jaW5nIGFyZ3VtZW50LCBiZWNhdXNlIHN0YW5kYXJkIFNMQUFDIGhhcyBrbm93 biBzZWN1cml0eSBhbmQgcmVsaWFiaWxpdHkgaXNzdWVzIGluIHRoaXMgc29ydCBvZiBlbnZpcm9u bWVudC4NCg0KSW5kZWVkOyB0aGUgaXNvbGF0aW9uIHByb3BlcnR5IGlzIG9uZSBvZiB0aGUga2V5 IGF0dHJhY3Rpb25zIG9mIHRoZSBkcmFmdC4NCg0KRnVydGhlcm1vcmUsIGl0IGlzIHRoaXMgZGVz aXJhYmxlIGFuZCBrZXkgc2VjdXJpdHkgcHJvcGVydHkgdGhhdCBqdXN0aWZpZXMgd2hhdCB3b3Vs ZCBvdGhlcndpc2Ugc2VlbSB0byBiZSBhIHdhc3RlZnVsIHVzZSBvZiBudW1iZXIgcmVzb3VyY2Vz LiBXaXRoIHRoZSBhcHBsaWNhYmlsaXR5IGxpbWl0ZWQgdG8gc2l0dWF0aW9uIHdoZXJlIGlmIGl0 IHdhcyBwcmFjdGljYWwgZm9yIHNlY3VyaXR5IHJlYXNvbnMsIHlvdSB3b3VsZCBoYXZlIHB1dCBl YWNoIGhvc3Qgb24gaXQgb3duIHBoeXNpY2FsIGludGVyZmFjZSBhbmQgdGhlcmVmb3JlIGl0J3Mg c3VibmV0IGFueXdheSwgdGhlbiB0aGUgdGhlcmUgaXMgYW4gYXJndW1lbnQgdG8gYmUgbWFkZSB0 aGF0IHRoaXMgcHJhY3RpY2UgaXNuJ3Qgd2FzdGVmdWwuICBIb3dldmVyLCBpZiB0aGVyZSBpcyBu byBhZGRpdGlvbmFsIHNlY3VyaXR5IHByb3ZpZGVkIG92ZXIgdGhhdCBvZiB0aGUgbm9ybWFsIG11 bHRpcGxlIGhvc3QgcGVyIHN1Ym5ldCBtb2RlbCwgdGhlbiB3aGF0IGp1c3RpZmllcyB0aGUgdXNl IG9mIGEgMTAwMCAvNjRzIGZvciBhIDEwMDAgaG9zdHMgd2hlbiBvbmUgcHJlZml4IHdvdWxkIGhh dmUgZWFzaWx5IGJlZW4gc3VmZmljaWVudD8NCg0KRnJlZCwgeW91IHNlZW0gdG8gd2FudCB0byBt YWtlIHRoaXMgZ2VuZXJhbGx5IGFwcGxpY2FibGUgdG8gYWxtb3N0IGFueSBzaXR1YXRpb24uIElm IHRoYXQgdGhlIGNhc2UsIHRoZW4geW91IGhhdmUgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbiBvZiB3 aGF0IGp1c3RpZmllcyB0aGF0IGxldmVsIG9mIG51bWJlciByZXNvdXJjZSB1dGlsaXphdGlvbiwg aWYgaXRzIG5vdCB0aGUgc2VjdXJpdHkgYWR2YW50YWdlIG9mIHNlcGFyYXRpbmcgaG9zdHMuDQoN Ck9uZSBvZiB0aGUgcmVhc29ucyB3ZSBqdXN0aWZ5IC82NCBzdWJuZXRzIGluIHRoZSBmaXJzdCBw bGFjZSwgaXMgdG8gZW5zdXJlIHRoZXJlIGlzIG5vIHByYWN0aWNhbCBsaW1pdCwgYmFzZWQgb24g YWRkcmVzc2luZywgdG8gaG93IG1hbnkgaG9zdHMgeW91IHB1dCBpbiBhIHN1Ym5ldC4gIFRoZXJl IGlzIGEgbGltaXQsIGJ1dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBJUHY2IGFkZHJl c3NpbmcgYXJjaGl0ZWN0dXJlLiBTZWN1cml0eSBhcmNoaXRlY3R1cmUgaXMgb25lIG9mIHRoZSBs aW1pdHMgb24gaG93IG1hbnkgYW5kIHdoYXQgaG9zdHMgeW91IHB1dCBpbiBhbnkgcGFydGljdWxh ciBzdWJuZXQuDQoNClNvLCBJIHdpbGwgcmVwZWF0IG15c2VsZjsgIFRoZSBzdWJuZXQgcGVyIGhv c3QgbW9kZWwgaXMgbm90IGEgZ2VuZXJhbGl6ZWQgb3IgdW5pdmVyc2FsIHJlcGxhY2VtZW50IGZv ciB0aGUgbXVsdGlwbGUgaG9zdCBwZXIgc3VibmV0IG1vZGVsLg0KDQpBbmQgSSB3aWxsIGFkZCB0 byB0aGF0OyBUaGUgc3VibmV0IHBlciBob3N0IG1vZGVsIGlzIG9ubHkganVzdGlmaWVkIGJ5IHRo ZSBkZXNpcmFibGUgYW5kIGtleSBzZWN1cml0eSBwcm9wZXJ0eSBvZiBob3N0IHNlcGFyYXRpb24g cHJvdmlkZWQgaW4gdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkuDQoNClRoYXQgc2FpZCwgdGhl IGRldGFpbHMgb2YgaG93IHRoaXMgc2VjdXJpdHkgcHJvcGVydHkgb2YgaG9zdCBzZXBhcmF0aW9u IGlzIGludGVuZGVkIHRvIGJlIGltcGxlbWVudGVkIG5lZWRzIGEgYmV0dGVyIGRlc2NyaXB0aW9u IGluIHRoZSBkcmFmdCwgYW5kIHRoZSBjb25zZXF1ZW5jZXMgb2Ygbm90IG9yIG9ubHkgcGFydGx5 IGltcGxlbWVudGluZyBpdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zLg0KDQpUaGFua3MuDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KRGF2aWQgRmFybWVyICAgICAgICAgICAgICAgRW1haWw6 ZmFybWVyQHVtbi5lZHU8bWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHU+DQpOZXR3b3JraW5n ICYgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXMNCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNo bm9sb2d5DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAg ICAgICAgUGhvbmU6IDYxMi02MjYtMDgxNQ0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkgICBD ZWxsOiA2MTItODEyLTk5NTINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo= --_000_9142206A0C5BF24CB22755C8EC422E4585AB93DEAZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDMyMjMzLkVBNDdCMjAwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMzA8L3c6Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xl YW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5n Lz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2 ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRD b250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhv bGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJv bW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3Okxp ZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhT Y3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+ DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8 dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0K PC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBs b3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNh bWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBt OnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+ DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZK YyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxt OmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwv bTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVm VW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZh bHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFk aW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg OSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlv biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i VGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFt ZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVy IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFy ayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRp bmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJl bmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6 TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1hbHQ6IlRpbWVzIE5ldyBSb21hbiI7 DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0K CW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU5OTA1 IC0xMDczNzMyNDg1IDkgMCA1MTEgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1hbHQ6VmVyZGFu YTsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7 DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwODE2 NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhp ZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglt c28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1hc2NpaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1oYW5zaS1mb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6 eWVzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41 aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3Jt YWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJv d2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7 DQoJbXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2lu OjBpbjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246 d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFu c2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t YmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc8L2E+IDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPuKAnDwvc3Bhbj5UaGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+UkEgY29udGFpbnMgdHdvIGlt cG9ydGFudCBwYXJhbWV0ZXJzIGZvciB0aGUgRVUvc3Vic2NyaWJlciB0bzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsgPC9z cGFuPmNvbnN1bWU6IGEgVW5pcXVlIElQdjYgcHJlZml4IChjdXJyZW50bHkgYSAvNjQgcHJlZml4 KSBhbmQgc29tZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46eWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFuPmZsYWdzLjxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46eWVzIj4mbmJzcDsgPC9zcGFuPlRoZSBVbmlxdWUgSVB2NiBwcmVmaXggY2FuIGJlIGRlcml2 ZWQgZnJvbSBhIGxvY2FsbHkgbWFuYWdlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFuPnBvb2wgb3IgYWdncmVn YXRlIElQdjYgYmxvY2sgYXNzaWduZWQgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlcjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJz cDsgPC9zcGFuPlJvdXRlciBvciBmcm9tIGEgY2VudHJhbGx5IGFsbG9jYXRlZCBwb29sLiA8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDs8L3NwYW4+4oCcPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21z by1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHJvdXRlciBpcyBhYmxlIHRvIGFz c2lnbiBhIHVuaXF1ZSBwcmVmaXggZnJvbSBhIHByZWZpeCBwb29sLCBpdCBzaG91bGQgYmUgYWJs ZSB0byBhc3NpZ24gYSB1bmlxdWUgYWRkcmVzcyBmcm9tDQogYW4gYWRkcmVzcyBwb29sLiBUaGVy ZSBpcyBubyBuZWVkIGZvciBEQUQgd2l0aCB1bmlxdWUgYWRkcmVzc2VzLiBJZiB0aGVyZSBpcyBu byBwcmVmaXggYXNzaWduZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOnllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5vPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5 ZXMiPiZuYnNwOyA8L3NwYW4+VHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0 dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+bWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11 bmljYXRlIHRocm91Z2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj50aGUgcHJv dmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MUY0OTdEIj7igJw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgc2VjdXJpdHkgY29udHJvbCBpcyBhY2hpZXZlZCB3aXRob3V0IGFzc2lnbmlu ZyAvNjQgc3VibmV0IHRvIGEgaG9zdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+RHVzYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiB2Nm9wcw0KIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5EYXZpZCBGYXJtZXI8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBBdWd1c3QgMzAsIDIwMTcgMTo1MSBQTTxicj4NCjxiPlRvOjwvYj4gVGltIENo b3duPGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzsgdjZvcHMtY2hhaXJzQGlldGYub3Jn OyB2Nm9wcy1hZHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ29t bWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcn PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMw LCAyMDE3IGF0IDEwOjE1IEFNLCBUaW0gQ2hvd24gJmx0OzxhIGhyZWY9Im1haWx0bzpUaW0uQ2hv d25AamlzYy5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPlRpbS5DaG93bkBqaXNjLmFjLnVrPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9uIDMw IEF1ZyAyMDE3LCBhdCAxNjowNywgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPbiBUdWUsIEF1ZyAyOSwgMjAxNyBhdCAzOjMxIEFNLCBUZW1wbGlu LCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5G cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBTbywgSSBz ZWUgdGhpcyBiZWluZyBhIHZlcnkgc2ltcGxlIGRvY3VtZW50IHRoYXQgd3JhcHMgaXRzZWxmIGFy b3VuZCBSRkM0ODYxLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJGQzQ4NjEgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYWxzbyBhcHBseSAoaW5jbHVkaW5nIFJGQzM3NTYpIGFuZCB0aGlzIGRvYzxicj4N CiZndDs8YnI+DQomZ3Q7IHNob3VsZCBub3QgYmUgaW4gdGhlIGJ1c2luZXNzIG9mIHVubmVjZXNz YXJpbHkgcmVzdHJpY3RpbmcgdGhlIGRvbWFpbiBvZjxicj4NCiZndDs8YnI+DQomZ3Q7IGFwcGxp Y2FiaWxpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayB5b3UncmUgZW50aXJlbHkgbWlz c2luZyB0aGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50LiBJdCdzIHdyaXR0ZW4gY2xlYXJseSBpbiB0 aGUgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgc2VjdGlvbiB0aGF0IHRoZSB0ZXh0IGFwcGxpZXMg dG8gc2l0dWF0aW9ucyB3aGVyZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbyZu YnNwOyBUd28gZGV2aWNlcyAoc3Vic2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhl IHNhbWUgcHJvdmlkZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuYWdl ZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91 Z2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHByb3ZpZGVyIG1hbmFn ZWQgRmlyc3QgSG9wIFJvdXRlcjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgYW4gZXh0cmVt ZWx5IGRlc2lyYWJsZSBzZWN1cml0eSBwcm9wZXJ0eSBpbiBhbnkgZW52aXJvbm1lbnQgd2hlcmUg dHJ1c3QgYmV0d2VlbiBkZXZpY2VzIGlzIGxpbWl0ZWQuIEluIHN1Y2ggZW52aXJvbm1lbnRzLCBz dGFuZGFyZCBTTEFBQyBvbiBzaGFyZWQgbGlua3MgY2Fubm90IGJlIG1hZGUgcmVsaWFibGUgaW4g dGhlIHByZXNlbmNlIG9mIGJ1Z2d5IG9yIG1hbGljaW91cyBob3N0cyB3aXRob3V0IGJyaXR0bGUg aGFja3MgdGhhdA0KIGRvbid0IHNjYWxlLCBhbmQgaXMgdGh1cyBhIG5vbi1zdGFydGVyIGZyb20g YSBhbiBvcGVyYXRpb25hbCBwb2ludCBvZiB2aWV3IHVubGVzcyB0aGUgZGV2aWNlcyBhcmUgdGln aHRseSBjb250cm9sbGVkLiBUaHVzLCB0aGVyZSBhcmUgdmVyeSBzb2xpZCBvcGVyYXRpb25hbCBy ZWFzb25zIHRvIGxpbWl0IHRoZSBzY29wZSBvZiBhcHBsaWNhYmlsaXR5IHRvIHN1Y2ggbmV0d29y a3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGNhbiBjb252aW5jaW5nbHkgYXJndWUgdGhh dCBzZWN1cml0eSBvciByZWxpYWJpbGl0eSB3b3VsZCBub3QgYmUgbGVzc2VuZWQgYnkgYWxsb3dp bmcgZGlyZWN0IHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uLCB0aGVuIHN1cmUsIHRoZSBzY29w ZSBvZiBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgZHJhZnQgY2FuIGJlIGV4cGFuZGVkLiBJIGRvbid0 IHRoaW5rIHlvdSdsbCBiZSBhYmxlIHRvIGNvbnZpbmNpbmdseSBhcmd1ZSB0aGF0LiBTYXlpbmcN CiAmcXVvdDtpdCdzIG5vIHdvcnNlIHRoYW4gc3RhbmRhcmQgU0xBQUMmcXVvdDsgaXMgbm90IGEg Y29udmluY2luZyBhcmd1bWVudCwgYmVjYXVzZSBzdGFuZGFyZCBTTEFBQyBoYXMga25vd24gc2Vj dXJpdHkgYW5kIHJlbGlhYmlsaXR5IGlzc3VlcyBpbiB0aGlzIHNvcnQgb2YgZW52aXJvbm1lbnQu PGJyPg0KPGJyPg0KSW5kZWVkOyB0aGUgaXNvbGF0aW9uIHByb3BlcnR5IGlzIG9uZSBvZiB0aGUg a2V5IGF0dHJhY3Rpb25zIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlcm1vcmUsIGl0IGlzIHRoaXMgZGVzaXJh YmxlIGFuZCBrZXkgc2VjdXJpdHkgcHJvcGVydHkgdGhhdCBqdXN0aWZpZXMgd2hhdCB3b3VsZCBv dGhlcndpc2Ugc2VlbSB0byBiZSBhIHdhc3RlZnVsIHVzZSBvZiBudW1iZXIgcmVzb3VyY2VzLiBX aXRoIHRoZSBhcHBsaWNhYmlsaXR5IGxpbWl0ZWQgdG8gc2l0dWF0aW9uIHdoZXJlIGlmIGl0IHdh cyBwcmFjdGljYWwgZm9yIHNlY3VyaXR5IHJlYXNvbnMsIHlvdQ0KIHdvdWxkIGhhdmUgcHV0IGVh Y2ggaG9zdCBvbiBpdCBvd24gcGh5c2ljYWwgaW50ZXJmYWNlIGFuZCB0aGVyZWZvcmUgaXQncyBz dWJuZXQgYW55d2F5LCB0aGVuIHRoZSB0aGVyZSBpcyBhbiBhcmd1bWVudCB0byBiZSBtYWRlIHRo YXQgdGhpcyBwcmFjdGljZSBpc24ndCB3YXN0ZWZ1bC4mbmJzcDsgSG93ZXZlciwgaWYgdGhlcmUg aXMgbm8gYWRkaXRpb25hbCBzZWN1cml0eSBwcm92aWRlZCBvdmVyIHRoYXQgb2YgdGhlIG5vcm1h bCBtdWx0aXBsZSBob3N0DQogcGVyIHN1Ym5ldCBtb2RlbCwgdGhlbiB3aGF0IGp1c3RpZmllcyB0 aGUgdXNlIG9mIGEgMTAwMCAvNjRzIGZvciBhIDEwMDAgaG9zdHMgd2hlbiBvbmUgcHJlZml4IHdv dWxkIGhhdmUgZWFzaWx5IGJlZW4gc3VmZmljaWVudD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJlZCwgeW91IHNlZW0gdG8gd2Fu dCB0byBtYWtlIHRoaXMgZ2VuZXJhbGx5IGFwcGxpY2FibGUgdG8gYWxtb3N0IGFueSBzaXR1YXRp b24uIElmIHRoYXQgdGhlIGNhc2UsIHRoZW4geW91IGhhdmUgdG8gYW5zd2VyIHRoZSBxdWVzdGlv biBvZiB3aGF0IGp1c3RpZmllcyB0aGF0IGxldmVsIG9mIG51bWJlciByZXNvdXJjZSB1dGlsaXph dGlvbiwgaWYgaXRzIG5vdCB0aGUgc2VjdXJpdHkgYWR2YW50YWdlIG9mIHNlcGFyYXRpbmcNCiBo b3N0cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T25lIG9mIHRoZSByZWFzb25zIHdlIGp1c3RpZnkgLzY0IHN1Ym5ldHMgaW4gdGhl IGZpcnN0IHBsYWNlLCBpcyB0byBlbnN1cmUgdGhlcmUgaXMgbm8gcHJhY3RpY2FsIGxpbWl0LCBi YXNlZCBvbiBhZGRyZXNzaW5nLCB0byBob3cgbWFueSBob3N0cyB5b3UgcHV0IGluIGEgc3VibmV0 LiZuYnNwOyBUaGVyZSBpcyBhIGxpbWl0LCBidXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0 aGUgSVB2NiBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZS4NCiBTZWN1cml0eSBhcmNoaXRlY3R1cmUg aXMgb25lIG9mIHRoZSBsaW1pdHMgb24gaG93IG1hbnkgYW5kIHdoYXQgaG9zdHMgeW91IHB1dCBp biBhbnkgcGFydGljdWxhciBzdWJuZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgSSB3aWxsIHJlcGVhdCBteXNlbGY7ICZu YnNwO1RoZSBzdWJuZXQgcGVyIGhvc3QgbW9kZWwmbmJzcDtpcyBub3QgYSBnZW5lcmFsaXplZCBv ciB1bml2ZXJzYWwgcmVwbGFjZW1lbnQgZm9yIHRoZSBtdWx0aXBsZSBob3N0IHBlciBzdWJuZXQg bW9kZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZCBJIHdpbGwgYWRkIHRvIHRoYXQ7IFRoZSBzdWJuZXQgcGVyIGhvc3QgbW9kZWwgaXMg b25seSBqdXN0aWZpZWQgYnkgdGhlIGRlc2lyYWJsZSBhbmQga2V5IHNlY3VyaXR5IHByb3BlcnR5 IG9mIGhvc3Qgc2VwYXJhdGlvbiBwcm92aWRlZCZuYnNwO2luIHRoZSBzY29wZSBvZiBhcHBsaWNh YmlsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF0IHNhaWQsIHRoZSBkZXRhaWxzIG9mIGhvdyB0aGlzIHNlY3VyaXR5IHBy b3BlcnR5IG9mIGhvc3Qgc2VwYXJhdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBpbXBsZW1lbnRlZCBu ZWVkcyBhIGJldHRlciBkZXNjcmlwdGlvbiBpbiB0aGUgZHJhZnQsIGFuZCB0aGUgY29uc2VxdWVu Y2VzIG9mIG5vdCBvciBvbmx5IHBhcnRseSBpbXBsZW1lbnRpbmcgaXQgbmVlZHMgdG8gYmUgZGlz Y3Vzc2VkIGluIHRoZSBzZWN1cml0eQ0KIGNvbnNpZGVyYXRpb25zLiAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXIm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVt YWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmlj YXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4N ClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0 eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDYxMi02MjYtMDgxNTxi cj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDYxMi04MTIt OTk1Mjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9142206A0C5BF24CB22755C8EC422E4585AB93DEAZUS1EXMB03glob_-- From nobody Thu Aug 31 05:38:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74629132D87 for ; Thu, 31 Aug 2017 05:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RheqcDH6Taj0 for ; Thu, 31 Aug 2017 05:38:25 -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 D94A1132D5B for ; Thu, 31 Aug 2017 05:38:24 -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 v7VCcM06004326 for ; Thu, 31 Aug 2017 14:38:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 676972060AD for ; Thu, 31 Aug 2017 14:38:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5D188206067 for ; Thu, 31 Aug 2017 14:38:22 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v7VCcLr6002376 for ; Thu, 31 Aug 2017 14:38:22 +0200 To: v6ops@ietf.org References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <04a073e1-ba8b-94e6-ba95-a315d97fb59b@gmail.com> Date: Thu, 31 Aug 2017 14:38:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 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: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:38:27 -0000 Le 31/08/2017 à 14:28, Mikael Abrahamsson a écrit : > On Thu, 31 Aug 2017, Ole Troan wrote: > >> In this case when you have a snooping DHCPv6 PD relay, there are no >> protocol mechanics there to save you. > > Well, the well-known vendor calls it a "proxy". It's kind of a relay. > But not. And the code-base seems intertwined with the vendor DHCPv6 > server implementation that is also available on the router, because > sometimes the proxy does funky things that a relay/proxy should never do. > >> The obvious answer is that you shouldn't do this. Snooping and >> gathering state by "listening" in to other protocol entities >> communicating is a bad idea. > > I agree. But, this seems to be the way things are typically done in > DHCPv6 land. Also in RA land there are modems that implement strange RA matters: receive an RA on one side, create another one, and send it on another side. Alex > >> Now what should you do instead? >> Well Markus and I wrote about this in: >> https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 > > Seems to capture a lot of the problems, yes. > >> We also wrote on this topic back in 2006: >> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 >> >> Which Ralph resubmitted a few months ago. With a somewhat unfortunate >> date. ;-) > > Right. > >> If I were to recommend something, I would require the requesting >> router (HGW in your parlance) to be responsible for maintaining the >> state in intermediate devices. The mechanism I'd like to use for that >> is something akin to BFD echo mode. The RR sends a packet (e.g. ICMP >> echo) destined to _itself_ using a destination address from the >> delegated prefix via its first-hop router. If packet is received the >> RR is guaranteed that the fist hop router has forwarding state. If >> packet is not received, that should trigger the RR to revalidate the >> prefix with a DHCP VERIFY or RENEW message. > > Makes sense. Not that I am a network application programmer, but it > looks like this will require raw sockets to accomplish. I'll look into it. > From nobody Thu Aug 31 06:09:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2383132D91 for ; Thu, 31 Aug 2017 06:09:35 -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 aAu91tko8wZU for ; Thu, 31 Aug 2017 06:09:32 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCE8132D92 for ; Thu, 31 Aug 2017 06:09:24 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id B536C2D4F9E; Thu, 31 Aug 2017 13:09:23 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id EFDE6100C5D35; Thu, 31 Aug 2017 15:09:20 +0200 (CEST) From: Ole Troan Message-Id: <982E6DB0-2E8F-484A-934A-8C71F539B36A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2846A118-3FB9-4D1B-A744-CE3390C3C6BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 15:09:20 +0200 In-Reply-To: Cc: Clark Gaylord , "v6ops@ietf.org" To: Mikael Abrahamsson References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:09:36 -0000 --Apple-Mail=_2846A118-3FB9-4D1B-A744-CE3390C3C6BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> If I were to recommend something, I would require the requesting = router (HGW in your parlance) to be responsible for maintaining the = state in intermediate devices. The mechanism I'd like to use for that is = something akin to BFD echo mode. The RR sends a packet (e.g. ICMP echo) = destined to _itself_ using a destination address from the delegated = prefix via its first-hop router. If packet is received the RR is = guaranteed that the fist hop router has forwarding state. If packet is = not received, that should trigger the RR to revalidate the prefix with a = DHCP VERIFY or RENEW message. >=20 > Makes sense. Not that I am a network application programmer, but it = looks like this will require raw sockets to accomplish. I'll look into = it. Right, the BSD socket API is probably not very accommodating for this. On an Ethernet link you need to send a packet with IP source and = destination address equal to your own address from the delegated prefix. = The L2 MAC destination address must be set to the first-hop router's. This mechanism has been described here and there... at least alluded to. = I don't know if it is worthwhile documenting in a draft in excruciating = detail? Ole --Apple-Mail=_2846A118-3FB9-4D1B-A744-CE3390C3C6BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZqAqAAAoJEL7aWKiYQt92MEsQAMcj4GcHU9Akl4Ki+X+Sc5PA FOMqSfGkOWZt9bwtsp21GF5C4o7w9GIqJ/h0txN2hjw3OgzgxjLGxFm4Kh9+X+5M HWAbXO4ic1cdk2pepMjJSzKQmR6fTqRFXrw3uxdJPm9Y0EuirxN0KtrOLlCsfc2q dXsP5zaIaHKbi530uMMF16upmf3P2Cx9gJnDMeq/oJ8XoD6EXOCjL819NH7Mza5S 1aXiroS/nKNybP7nATbTWWMSNQoYP5KzqwOxXW39qrjrk00RnxxbgzxYR54UToIP 1oLnUZdj13dIUJkKnB4lxCCo5gFQdagy6SpMseyxAkKyy2/oFjP4awL3COrpEuBA 3kw0/SvjVFHEWC9lfDSiBwP5BJDpL21aRIPlU1Etr/E7bf+t44DMi3Uhm5YLkX+L aumtoKpV6qjo/a6x3Y3YC4MVh3TcJYm7QoMJ0zBzvkn8mOR5Om3EHjb4QvEY1+w3 4cH+KWwf73iA96n7/pzpxBOR9e4meyDfniTx+JmiaVcKuPx3J5OvoxyTkTOlNqsk /H+ENwJLwKe7OB+2Lp6R95OyJLejY7+yp5xfk5aPjUD0aaIbtCRUh6mfd0B5LLKg 9emkb9S5hnUsCbA+eNH09cIcjnWSyOSKutvZjipSWt08ywYzkAv1CO/F+ZiPkEqX sXX6AnPlGw4tq6HMqOfw =gxod -----END PGP SIGNATURE----- --Apple-Mail=_2846A118-3FB9-4D1B-A744-CE3390C3C6BA-- From nobody Thu Aug 31 06:19:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A747E132DA2 for ; Thu, 31 Aug 2017 06:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QLn0nNPXZ8TC for ; Thu, 31 Aug 2017 06:19:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.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 55937132D8F for ; Thu, 31 Aug 2017 06:19:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FZAAAoDKhZ/wUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxFJZIEVB44QkB6BcYg5ixYHglEOgUFDLIUbAhqDbz8YAQIBAQE?= =?us-ascii?q?BAQEBA2gogmUvCAMMIQgDAQEBAQEBAQEBAgEBAQFGAg9BAQEYAQEBAQIBEhERO?= =?us-ascii?q?gsMBAIBCA0EBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIGol3Aw0IAQ+jHYppgic?= =?us-ascii?q?iAocWDYN/AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDYIdggKBT4FhgymCV0+BH?= =?us-ascii?q?AESAQkYBRAPFIJZMIIxBaAzPAKHWYd/AYcJhWeDcIcEjE6Ed4UAHzmBAgt3FUm?= =?us-ascii?q?FGByBZ3YBiBmBIwGBDgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2FZAAAoDKhZ/wUHmMZeGQEBAQEBAQEBAQEBBwEBAQEBgxF?= =?us-ascii?q?JZIEVB44QkB6BcYg5ixYHglEOgUFDLIUbAhqDbz8YAQIBAQEBAQEBA2gogmUvC?= =?us-ascii?q?AMMIQgDAQEBAQEBAQEBAgEBAQFGAg9BAQEYAQEBAQIBEhEROgsMBAIBCA0EBAE?= =?us-ascii?q?BAQICBh0DAgICHxEUAQgIAgQBDQUIGol3Aw0IAQ+jHYppgiciAocWDYN/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBDYIdggKBT4FhgymCV0+BHAESAQkYBRAPFIJ?= =?us-ascii?q?ZMIIxBaAzPAKHWYd/AYcJhWeDcIcEjE6Ed4UAHzmBAgt3FUmFGByBZ3YBiBmBI?= =?us-ascii?q?wGBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,453,1498536000"; d="scan'208";a="211504904" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Aug 2017 09:18:59 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 09:19:00 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 09:18:58 -0400 From: "Mudric, Dusan (Dusan)" To: "Templin, Fred L" , Mikael Abrahamsson CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgARjqyAAA5VXnD//5byAIAAWYhwgAA7jAD//2QhwP/9vzhA Date: Thu, 31 Aug 2017 13:18:57 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E4585AB9479@AZ-US1EXMB03.global.avaya.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:19:07 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlbXBsaW4sIEZyZWQgTA0KPiBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyA1OjI4IFBNDQo+IFRvOiBNaWthZWwgQWJyYWhh bXNzb24NCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFByZWZp eCBEZWxlZ2F0aW9uIFJTL1JBIHZzIERIQ1B2Ng0KPiANCj4gSGkgTWlrYWVsLA0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1pa2FlbCBBYnJhaGFtc3NvbiBb bWFpbHRvOnN3bWlrZUBzd20ucHAuc2VdDQo+ID4gU2VudDogVHVlc2RheSwgQXVndXN0IDI5LCAy MDE3IDEwOjA4IFBNDQo+ID4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCj4gPiBDYzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbT47IHY2b3BzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFt2Nm9wc10gUHJlZml4 IERlbGVnYXRpb24gUlMvUkEgdnMgREhDUHY2DQo+ID4NCj4gPiBPbiBUdWUsIDI5IEF1ZyAyMDE3 LCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4NCj4gPiA+IFByb2JhYmx5LCBidXQgSSB0aGlu ayB0aGVyZSBhcmUgdHdvIHByaW1hcnkgY2F0ZWdvcmllczogMSkNCj4gPiA+IG5ldHdvcmstZGly ZWN0ZWQgYW5kIDIpIGNsaWVudC1kaXJlY3RlZC4gV2hpY2ggaXMgbW9yZSBhcHByb3ByaWF0ZQ0K PiA+ID4gcHJvYmFibHkgbmVlZHMgdG8gYmUgZXhhbWluZWQgb24gYSBjYXNlLWJ5LWNhc2UgYmFz aXMuDQo+ID4NCj4gPiBJIHRoaW5rIHdoYXRldmVyIHdlIGNvbWUgdXAgd2l0aCBuZWVkcyB0byBz dXBwb3J0IGFsbCBvZiB0aGVtLiBDbGllbnQNCj4gPiBuZWVkcyB0byBiZSBhYmxlIHRvIHJlbGVh c2UgcmVzb3VyY2VzLCBpdCBuZWVkcyB0byBpbmRpY2F0ZSB0aGF0ICJJIGRvbid0DQo+ID4gd2Fu dCB0aGlzIGFueW1vcmUsIHBlcm1hbmVudGx5IiBidXQgYWxzbyAiSSBhbSBkaXNjb25uZWN0aW5n IGZvciBhIHdoaWxlLA0KPiA+IEkgYW0gc3RpbGwgaW50ZXJlc3RlZCBpbiB0aGlzIHJlc291cmNl IiBhbmQgYWxzbyBwZXJoYXBzICJoZWxsbywgSSBhbSBub3cNCj4gPiBoZXJlLCBjYW4gSSBwbGVh c2UgaGF2ZSBteSByZXNvdXJjZSB0aGF0IEkgaGFkIG92ZXIgdGhlcmUiIChpbiBjYXNlIG9mIGZv cg0KPiA+IGluc3RhbmNlIHdpZmkgaGFuZG92ZXIpLiBUaGUgbmV0d29yayBpbiB0dXJuIG5lZWRz IHRvIGJlIGFibGUgdG8gdGVsbCB0aGUNCj4gPiBkZXZpY2UgInNvcnJ5LCB0aGlzIHJlc291cmNl IGlzIG9yIHdpbGwgc29vbiBubyBsb25nZXIgYXZhaWxhYmxlLCBzdG9wDQo+ID4gdXNpbmcgaXQg d2l0aGluIFggc2Vjb25kcyINCj4gDQo+IFJpZ2h0LCBhbmQgdGhhdCBpcyB3aGF0IERIQ1B2NiBQ RCBhbHJlYWR5IGRvZXMuIElQdjYgTkQgY291bGQgcHJvYmFibHkNCj4gYmUgbWFkZSB0byBkbyBp dCB0b28sIGJ1dCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGEgbmV3IHByb3RvY29sIGFuZA0KPiBw b3NzaWJseSBhbHNvIG5ldyBtZXNzYWdlIHR5cGVzIChpbiBhZGRpdGlvbiB0byB3aGF0IGlzIGFs cmVhZHkgaW4gUElPLVgpLg0KPiANCj4gVGhhbmtzIC0gRnJlZA0KPiANCltbRHVzYW5dXSANCk5v dCBxdWl0ZS4gSSBzdGFydGVkIGEgZGlzY3Vzc2lvbiB0byBhZGQgYW4gZXJyb3IgY29kZSB0aGF0 IGEgY2xpZW50IGNhbiBzZXQgd2hlbjoNCg0KPj4gQ2xpZW50DQo+ID4gbmVlZHMgdG8gYmUgYWJs ZSB0byByZWxlYXNlIHJlc291cmNlcywgaXQgbmVlZHMgdG8gaW5kaWNhdGUgdGhhdCAiSSBkb24n dA0KPiA+IHdhbnQgdGhpcyBhbnltb3JlLCBwZXJtYW5lbnRseSIgYnV0IGFsc28gIkkgYW0gZGlz Y29ubmVjdGluZyBmb3IgYSB3aGlsZSwNCkkgZGlkIG5vdCBnZXQgYW55IHVuZGVyc3RhbmRpbmcg YXQgREhDUCBXRy4gSW4gdGhlIFdHIGl0IGlzIGFjY2VwdGFibGUgZm9yIERIQ1Agc2VydmVyIHRv IA0KcmV0dXJuIGVycm9ycyBvciBhc3NpZ24gYW55dGhpbmcgYnV0IG5vdCBmb3IgYSBjbGllbnQg dG8gcmVsZWFzZSBhbiBhZGRyZXNzIGFuZCBwcm92aWRlIGEgcmVhc29uIGZvciBpdC4NCg0KW1tE dXNhbl1dIA0KW1tEdXNhbl1dIA0KDQo+ID4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBz d21pa2VAc3dtLnBwLnNlDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3Jn DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4g M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJQ0FnJmM9QkZwV1F3 OGJzdUtwbDENCj4gU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAy OXNNUUdRMmtZJm09NGNPTnoNCj4gY21BeEdBbVRSRTdaaG43aEdOVUZVdkJZVmpoc1Bzcjg5N3gw dGMmcz0xSzlMWlFUVFRGMGpMNEJWUHZLdDdJMQ0KPiBfWmRFUTkxMUp4ejdRVk5ORUkzSSZlPQ0K From nobody Thu Aug 31 06:57:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311FB132DF9 for ; Thu, 31 Aug 2017 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 7vx3tRXmCgUh for ; Thu, 31 Aug 2017 06:57:42 -0700 (PDT) Received: from atl4mhob14.registeredsite.com (atl4mhob14.registeredsite.com [209.17.115.52]) (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 2289E132DF0 for ; Thu, 31 Aug 2017 06:57:41 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob14.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7VDvTKf025208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Aug 2017 09:57:29 -0400 Received: (qmail 23913 invoked by uid 0); 31 Aug 2017 13:57:29 -0000 X-TCPREMOTEIP: 72.221.14.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.181) by 0 with ESMTPA; 31 Aug 2017 13:57:28 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 31 Aug 2017 09:57:23 -0400 From: Lee Howard To: Mikael Abrahamsson , "Templin, Fred L" CC: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:57:44 -0000 No hat. . . On 8/30/17, 1:07 AM, "v6ops on behalf of Mikael Abrahamsson" wrote: >On Tue, 29 Aug 2017, Templin, Fred L wrote: > >> Probably, but I think there are two primary categories: 1) >> network-directed and 2) client-directed. Which is more appropriate >> probably needs to be examined on a case-by-case basis. > >I think whatever we come up with needs to support all of them. Client >needs to be able to release resources, it needs to indicate that "I don't >want this anymore, permanently" but also "I am disconnecting for a while, >I am still interested in this resource" and also perhaps "hello, I am now >here, can I please have my resource that I had over there" (in case of >for=20 >instance wifi handover). The network in turn needs to be able to tell the >device "sorry, this resource is or will soon no longer available, stop >using it within X seconds" Why should we be encouraging staticness on the netwrk? Shouldn=E2=80=99t we be making it easier to renumber, rather than making the network less dynamic? Lee From nobody Thu Aug 31 07:00:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7584E132DFD for ; Thu, 31 Aug 2017 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzeVj5aVDLu4 for ; Thu, 31 Aug 2017 07:00:06 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34410132DF9 for ; Thu, 31 Aug 2017 07:00:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 264A7AF; Thu, 31 Aug 2017 16:00:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504188003; bh=c/Gc/HBA2Ol3aRT7arOXnuohzwtCNKI/6OfgHkCY3T0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wnJ9m3+O7Idvhy8c5JvZ34AFYwC5LflTrzSj85aX1227rXXbF6ua96brS8hpDYNjT F4p45zx5JNqYEjxlmA3z8SG84MCNfDMqoE9y/kzm8IEpPyHDp/XA8FCuhPC1G3kqMj om1CdXJaFs69fKaWPuaeslkxD9iNtGvw2dgRbm0g= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2385584; Thu, 31 Aug 2017 16:00:03 +0200 (CEST) Date: Thu, 31 Aug 2017 16:00:03 +0200 (CEST) From: Mikael Abrahamsson To: Lee Howard cc: "Templin, Fred L" , "v6ops@ietf.org" In-Reply-To: Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1273554891-1504188003=:3655" Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 14:00:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1273554891-1504188003=:3655 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 31 Aug 2017, Lee Howard wrote: > Why should we be encouraging staticness on the netwrk? Shouldn’t we be > making it easier to renumber, rather than making the network less > dynamic? Sounds like a great idea. How? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1273554891-1504188003=:3655-- From nobody Thu Aug 31 08:18:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D36F1329C5; Thu, 31 Aug 2017 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUWgJtxkXeqe; Thu, 31 Aug 2017 08:18:17 -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 E1169132742; Thu, 31 Aug 2017 08:18: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 v7VFIFH1041328; Thu, 31 Aug 2017 08:18:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7VFI5un041222 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 08:18:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 08:18:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 08:18:04 -0700 From: "Templin, Fred L" To: David Farmer CC: Tim Chown , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKAABmowzAAMCdaBQAHEcpAABByPIAAFPhlwA== Date: Thu, 31 Aug 2017 15:18:04 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b03c8a9baaa04700b0bf2ddc7d832ce1XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:18:19 -0000 --_000_b03c8a9baaa04700b0bf2ddc7d832ce1XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBzaW1wbGUgcG9pbnQgaW4gYWxsIG9mIHRoaXMgaXMgdGhhdCBSZWRpcmVjdHMg YXJlIChhbmQgd2lsbCByZW1haW4pIGENCnVzZWZ1bCBjb21wb25lbnQgb2YgSVB2NiBORCwgeWV0 IHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gZGVwcmVjYXRlDQp0aGVpciB1c2UgaW4gYWxsIGNhc2Vz IGV2ZW4gZm9yIGxpbmtzIHdoZXJlIHVzZSBvZiBSZWRpcmVjdHMgaXMgZXNzZW50aWFsLg0KDQpU aGUgc2VuZGluZyBvciBub3Qgc2VuZGluZyBvZiBSZWRpcmVjdHMgaXMgdXAgdG8gdGhlIHJvdXRl ciBhbmQsIG9uDQpsaW5rcyB3aGVyZSBSZWRpcmVjdHMgYXJlIG5vdCBkZXNpcmVkLCB0aGUgcm91 dGVyIHNpbXBseSByZWZyYWlucyBmcm9tDQpzZW5kaW5nIHRoZW0uIFRoaXMgaXMgbm8gZGlmZmVy ZW50IHRoYW4gd2hhdCBoYXMgYmVlbiBkb2N1bWVudGVkDQppbiBSRkM0ODYxIGFuZCBpdHMgcHJl ZGVjZXNzb3JzIChSRkMxOTcwLCBSRkMyNDYxKSBzaW5jZSB0aGUgZWFybGllc3QNCmRheXMgb2Yg SVB2Ni4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJt ZXJAdW1uLmVkdV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3IDM6MDUgUE0NClRv OiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogVGltIENo b3duIDxUaW0uQ2hvd25AamlzYy5hYy51az47IHY2b3BzQGlldGYub3JnOyB2Nm9wcy1jaGFpcnNA aWV0Zi5vcmc7IHY2b3BzLWFkc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gQ29tbWVu dCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcnDQoN Cg0KDQpPbiBXZWQsIEF1ZyAzMCwgMjAxNyBhdCA0OjIyIFBNLCBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ PiB3cm90ZToNCkhpLCBhZ2FpbiB0aGlzIGRvY3VtZW50IGlzIG5vdGhpbmcgbW9yZSB0aGFuIGFu IGV4cHJlc3Npb24gb2Ygd2hhdCBpcyBhbHJlYWR5DQppbiBSRkM0ODYxLCBidXQgdGhlbiBpdCBh ZGRzIGNvbnN0cmFpbnRzIHRoYXQgZG9u4oCZdCBuZWVkIHRvIGJlIHRoZXJlLiBJZiB0aGUNClBJ TyBoYXMgQT0xLCBMPTAgdGhlbiBieSBSRkM0ODYxIHRoZSBob3N0IHdpbGwgYXV0b2NvbmZpZ3Vy ZSBvbmUgb3IgbW9yZQ0KYWRkcmVzc2VzIGFuZCBzZW5kIHBhY2tldHMgdmlhIHRoZSBkZWZhdWx0 IHJvdXRlciAoc2luY2Ug4oCYTOKAmSBpcyAwKSB1bmxlc3MNCnRoZXJlIGlzIGEgbW9yZS1zcGVj aWZpYyByb3V0ZS4NCg0KQnV0LCB0aGUgcm91dGVyIG1heSBzZW5kIGEgUmVkaXJlY3QgYW5kIHRo ZXJlZm9yZSBzdWJzZXF1ZW50IHBhY2tldHMgY291bGQNCmdvIGZyb20gcGVlci10by1wZWVyIHdp dGhvdXQgaGF2aW5nIHRvIGdvIHRocm91Z2ggdGhlIHJvdXRlci4gVGhpcyBkb2N1bWVudA0Kc2hv dWxkIG5vdCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgZGlzYWJsaW5nIG9yIGRpc2FsbG93aW5nIHRo ZSBSZWRpcmVjdCBmdW5jdGlvbiwNCndoaWNoIGlzIGEgY29yZSBlbGVtZW50IG9mIElQdjYgTkQg YW5kIG5lY2Vzc2FyeSBmb3Igc29tZSBsaW5rIHR5cGVzLg0KDQpUaGFua3MgLSBGcmVkDQoNCkFu ZCB5b3UgY2FuIGRvIGp1c3QgdGhhdCB3aXRoIG9uZSAvNjQgc3VibmV0IGZvciBob3cgbWFueSBl dmVyeSBob3N0cyB5b3Ugd2FudCB0b28gb24gdGhlIHNhbWUgc3VibmV0Lg0KDQpIb3dldmVyLCBp ZiB5b3UgaGF2ZSAxMDAwIGhvc3RzIGFsbCBvbiB0aGUgc2FtZSBsaW5rLCBhbmQgdGhlcmUgaXMg c3VibmV0IHByZWZpeCBwZXIgaG9zdCwgd2hhdCBwcmV2ZW50cyBhbGwgMTAwMCBob3N0cyBmcm9t IGZvcm1pbmcgU0xBQUMgYWRkcmVzc2VzIG9uIGVhY2ggb2YgdGhlIHByZWZpeGVzPyBTb21ldGhp bmcgaGFzIHRvIHByZXZlbnQgSG9zdDEgZnJvbSBrbm93aW5nIGFib3V0IHRoZSBwcmVmaXhlcyBm b3IgdGhlIG90aGVyIDk5OSBob3N0cy4gT3RoZXJ3aXNlIHBlciBSRkM0ODYxLCBIb3N0MSB3b3Vs ZCBmb3JtIGFuIGFkZHJlc3Mgb24gdGhvc2Ugb3RoZXIgOTk5IHByZWZpeGVzIGFzIHdlbGwuICBU aGlzIGltcGxpZXMgc29tZSBraW5kIG9mIHNlcGFyYXRpb24gb2YgdGhlIGhvc3RzIGlzIGFscmVh ZHkgcmVxdWlyZWQgaWYgYSBob3N0IGlzIGdvaW5nIHRvIHVzZSBvbmx5IGl0J3MgcHJlZml4Lg0K DQpBbmQgaWYgdGhhdCBzZXBhcmF0aW9uIGlzIG9ubHkgYXBwbGllZCB0byB0aGUgUkFzLCBhbmQg dGhlIGhvc3RzIGNhbiBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIGVhY2ggb3RoZXIgb3ZlciB0 aGUgc2hhcmVkIG5ldHdvcmsgdGhlbiB3aGF0IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgZG9pbmcgdGhh dCBvdmVyIDEgc3VibmV0IGZvciB0aGUgMTAwMCBob3N0cz8gWW91IGFyZSBtYWtpbmcgdGhpbmtz IG1vcmUgY29tcGxpY2F0ZSB3aXRob3V0IGFueSBzZWVtaW5nIGFkdmFudGFnZS4gTm93IGlmIHRo ZSBob3N0cyBjYW4ndCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIgdGhlbiB0aGVyZSBpcyBh biBhZHZhbnRhZ2UgcHJvdmlkZWQgYnkgc2VncmVnYXRpbmcgdGhlIFJBcyBmb3IgdGhlIG90aGVy IDk5OSBwcmVmaXhlcyBmcm9tIEhvc3QxLg0KDQpUaGVyZWZvcmUgc29tZSBsZXZlbCBvZiBob3N0 IHNlZ3JlZ2F0aW9uIGlzIGEgZnVuZGFtZW50YWwgcHJvcGVydHkgb2YgdGhpcyB3aG9sZSB0ZWNo bmlxdWUsIGFuZCBpdCBtYWtlcyBubyBzZW5zZSB0byBsaW1pdCBpdCBwZXIgaG9zdCBhZHZlcnRp c2VtZW50IG9mIFJBcy4NCg0KVGhhbmtzDQoNCg0KDQoNCg0KLS0NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAg ICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5l dHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0 aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkg QXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQt MzAyOSAgIENlbGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg== --_000_b03c8a9baaa04700b0bf2ddc7d832ce1XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNpbXBsZSBwb2ludCBpbiBhbGwgb2YgdGhpcyBpcyB0 aGF0IFJlZGlyZWN0cyBhcmUgKGFuZCB3aWxsIHJlbWFpbikgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj51 c2VmdWwgY29tcG9uZW50IG9mIElQdjYgTkQsIHlldCB0aGlzIGRvY3VtZW50IHNlZW1zIHRvIGRl cHJlY2F0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGVpciB1c2UgaW4gYWxsIGNhc2VzIGV2ZW4gZm9y IGxpbmtzIHdoZXJlIHVzZSBvZiBSZWRpcmVjdHMgaXMgZXNzZW50aWFsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNlbmRpbmcgb3Igbm90IHNlbmRpbmcg b2YgUmVkaXJlY3RzIGlzIHVwIHRvIHRoZSByb3V0ZXIgYW5kLCBvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5saW5rcyB3aGVyZSBSZWRpcmVjdHMgYXJlIG5vdCBkZXNpcmVkLCB0aGUgcm91dGVyIHNpbXBs eSByZWZyYWlucyBmcm9tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNlbmRpbmcgdGhlbS4gVGhpcyBpcyBu byBkaWZmZXJlbnQgdGhhbiB3aGF0IGhhcyBiZWVuIGRvY3VtZW50ZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+aW4gUkZDNDg2MSBhbmQgaXRzIHByZWRlY2Vzc29ycyAoUkZDMTk3MCwgUkZDMjQ2MSkgc2lu Y2UgdGhlIGVhcmxpZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmRheXMgb2YgSVB2Ni48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyAzOjA1IFBNPGJyPg0KPGI+VG86PC9iPiBUZW1w bGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBUaW0gQ2hvd24gJmx0O1RpbS5DaG93bkBqaXNjLmFjLnVrJmd0OzsgdjZvcHNAaWV0Zi5v cmc7IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA3JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAzMCwgMjAxNyBhdCA0OjIyIFBNLCBUZW1wbGluLCBGcmVk IEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9 Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksIGFnYWluIHRoaXMgZG9jdW1lbnQg aXMgbm90aGluZyBtb3JlIHRoYW4gYW4gZXhwcmVzc2lvbiBvZiB3aGF0IGlzIGFscmVhZHk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5pbiBSRkM0ODYxLCBidXQgdGhlbiBpdCBhZGRzIGNvbnN0cmFpbnRz IHRoYXQgZG9u4oCZdCBuZWVkIHRvIGJlIHRoZXJlLiBJZiB0aGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5QSU8gaGFzIEE9MSwgTD0wIHRoZW4gYnkgUkZDNDg2MSB0aGUgaG9zdCB3aWxsIGF1dG9jb25m aWd1cmUgb25lIG9yIG1vcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hZGRyZXNzZXMgYW5kIHNlbmQg cGFja2V0cyB2aWEgdGhlIGRlZmF1bHQgcm91dGVyIChzaW5jZSDigJhM4oCZIGlzIDApIHVubGVz czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZXJlIGlzIGEgbW9yZS1zcGVjaWZpYyByb3V0ZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQsIHRoZSByb3V0 ZXIgbWF5IHNlbmQgYSBSZWRpcmVjdCBhbmQgdGhlcmVmb3JlIHN1YnNlcXVlbnQgcGFja2V0cyBj b3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmdvIGZyb20gcGVlci10by1wZWVyIHdpdGhvdXQgaGF2 aW5nIHRvIGdvIHRocm91Z2ggdGhlIHJvdXRlci4gVGhpcyBkb2N1bWVudDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPnNob3VsZCBub3QgYmUgaW4gdGhlIGJ1c2luZXNzIG9mIGRpc2FibGluZyBvciBkaXNh bGxvd2luZyB0aGUgUmVkaXJlY3QgZnVuY3Rpb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2hpY2gg aXMgYSBjb3JlIGVsZW1lbnQgb2YgSVB2NiBORCBhbmQgbmVjZXNzYXJ5IGZvciBzb21lIGxpbmsg dHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIC0gRnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgeW91IGNhbiBkbyBqdXN0 IHRoYXQgd2l0aCBvbmUgLzY0IHN1Ym5ldCBmb3IgaG93IG1hbnkgZXZlcnkgaG9zdHMgeW91IHdh bnQgdG9vIG9uIHRoZSBzYW1lIHN1Ym5ldC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGlmIHlvdSBoYXZlIDEwMDAg aG9zdHMgYWxsIG9uIHRoZSBzYW1lIGxpbmssIGFuZCB0aGVyZSBpcyBzdWJuZXQgcHJlZml4IHBl ciBob3N0LCB3aGF0IHByZXZlbnRzIGFsbCAxMDAwIGhvc3RzIGZyb20gZm9ybWluZyBTTEFBQyBh ZGRyZXNzZXMgb24gZWFjaCBvZiB0aGUgcHJlZml4ZXM/IFNvbWV0aGluZyBoYXMgdG8gcHJldmVu dCBIb3N0MSBmcm9tIGtub3dpbmcgYWJvdXQgdGhlIHByZWZpeGVzDQogZm9yIHRoZSBvdGhlciA5 OTkgaG9zdHMuIE90aGVyd2lzZSBwZXIgUkZDNDg2MSwgSG9zdDEgd291bGQgZm9ybSBhbiBhZGRy ZXNzIG9uIHRob3NlIG90aGVyIDk5OSBwcmVmaXhlcyBhcyB3ZWxsLiZuYnNwOyBUaGlzIGltcGxp ZXMgc29tZSBraW5kIG9mIHNlcGFyYXRpb24gb2YgdGhlIGhvc3RzIGlzIGFscmVhZHkgcmVxdWly ZWQgaWYgYSBob3N0IGlzIGdvaW5nIHRvIHVzZSBvbmx5IGl0J3MgcHJlZml4LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgaWYgdGhhdCBz ZXBhcmF0aW9uIGlzIG9ubHkgYXBwbGllZCB0byB0aGUgUkFzLCBhbmQgdGhlIGhvc3RzIGNhbiBj b21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIGVhY2ggb3RoZXIgb3ZlciB0aGUgc2hhcmVkIG5ldHdv cmsgdGhlbiB3aGF0IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgZG9pbmcgdGhhdCBvdmVyIDEgc3VibmV0 IGZvciB0aGUgMTAwMCBob3N0cz8gWW91IGFyZSBtYWtpbmcgdGhpbmtzIG1vcmUgY29tcGxpY2F0 ZQ0KIHdpdGhvdXQgYW55IHNlZW1pbmcgYWR2YW50YWdlLiBOb3cgaWYgdGhlIGhvc3RzIGNhbid0 IGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlciB0aGVuIHRoZXJlIGlzIGFuIGFkdmFudGFnZSBw cm92aWRlZCBieSBzZWdyZWdhdGluZyB0aGUgUkFzIGZvciB0aGUgb3RoZXIgOTk5IHByZWZpeGVz IGZyb20gSG9zdDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlZm9yZSBzb21lIGxldmVsIG9mIGhvc3Qgc2VncmVnYXRpb24gaXMgYSBm dW5kYW1lbnRhbCBwcm9wZXJ0eSBvZiB0aGlzIHdob2xlIHRlY2huaXF1ZSwgYW5kIGl0IG1ha2Vz IG5vIHNlbnNlIHRvIGxpbWl0IGl0IHBlciBob3N0IGFkdmVydGlzZW1lbnQgb2YgUkFzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpE YXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHUiIHRhcmdldD0i X2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFtcDsg VGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVj aG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4NCjIy MTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDYx Mi02MjYtMDgxNTxicj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5Jm5ic3A7Jm5ic3A7IENl bGw6IDYxMi04MTItOTk1Mjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b03c8a9baaa04700b0bf2ddc7d832ce1XCH150608nwnosboeingcom_-- From nobody Thu Aug 31 08:31:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE87132C23 for ; Thu, 31 Aug 2017 08:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx96IyVLK2XT for ; Thu, 31 Aug 2017 08:31:25 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E09413219E for ; Thu, 31 Aug 2017 08:31:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7VFVOQW041416; Thu, 31 Aug 2017 08:31:25 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7VFVHts040875 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 08:31:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 08:31:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 08:31:16 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgARjqyAAA5VXnD//5byAIAAWYhwgAA7jAD//2QhwIACJ9SA///CQsA= Date: Thu, 31 Aug 2017 15:31:16 +0000 Message-ID: <8735eb0ddf5c4d05b19d4dd5c7ddd400@XCH15-06-08.nw.nos.boeing.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:31:27 -0000 Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Wednesday, August 30, 2017 9:45 PM > To: Templin, Fred L > Cc: Brian E Carpenter ; v6ops@ietf.org > Subject: RE: [v6ops] Prefix Delegation RS/RA vs DHCPv6 >=20 > On Wed, 30 Aug 2017, Templin, Fred L wrote: >=20 > >> I think whatever we come up with needs to support all of them. Client > >> needs to be able to release resources, it needs to indicate that "I do= n't > >> want this anymore, permanently" but also "I am disconnecting for a whi= le, > >> I am still interested in this resource" and also perhaps "hello, I am = now > >> here, can I please have my resource that I had over there" (in case of= for > >> instance wifi handover). The network in turn needs to be able to tell = the > >> device "sorry, this resource is or will soon no longer available, stop > >> using it within X seconds" > > > > Right, and that is what DHCPv6 PD already does. IPv6 ND could probably >=20 > I don't believe it does. It can do release, but that is no guarantee that > it'll get the resource back in the future. There is no intention included > in the "release". If it doesn't release and then tries to renew it > somewhere else, afaik there is no standard way for this to work either > because that PD lease is typically tied to an interface and a DHCPv6 prox= y > is typically sitting there with a binding. DHCPv6 servers can maintain a list of (client, prefix) associations so that the client can get the same prefix every time it asks. I do this in my DHCP= v6 server configurations today. The client can even provide the server with a "hint" as to the prefix it wants to receive so that it can get the same one every time. > Also, I have never seen DHCPv6 do "this resource is no longer available, > stop using it in the next 60 seconds". You can shorten lifetimes when the > client asks, but I have never seen the network reach out to the client to > shorten the lifetime. That can be done with DHCPv6 Reconfigure. Server sends Reconfigure, client responds by sending Renew, and server responds by sending a Reply (the sixth "R") with a shortened prefix lifetime. > From what I can tell we have no solution for what we're talking here, we > need to extend what we have to do what we're talking about. I think it can be done with RFC3315/RFC3633 compliant DHCPv6. Thanks - Fred >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 31 09:29:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540DE132025 for ; Thu, 31 Aug 2017 09:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfcgfnSHHDzY for ; Thu, 31 Aug 2017 09:29:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99691321A0 for ; Thu, 31 Aug 2017 09:29:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3E52EAF; Thu, 31 Aug 2017 18:29:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504196981; bh=3Bn+eGOOeKWQRIvOchZnx2AleVP3wM2+D/LXYOm6vio=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XipHH8ywxYaRvRtP5h4UWKxFGg5llhUQFdpRwrF3afKBQJrOU9JHvgKQnxFpCaj0F fRjQwxLUzwoFFxWZF26afzKnBOYiH4ywSvL7hbtVB3sNj+EJjF7W7lm13yQsRJL0kw DHAkifOSMFQ/hgbW3IXwFt7o/3wKiD52tNsPbBVY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 39B3584; Thu, 31 Aug 2017 18:29:41 +0200 (CEST) Date: Thu, 31 Aug 2017 18:29:41 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: Brian E Carpenter , "v6ops@ietf.org" In-Reply-To: <8735eb0ddf5c4d05b19d4dd5c7ddd400@XCH15-06-08.nw.nos.boeing.com> Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> <8735eb0ddf5c4d05b19d4dd5c7ddd400@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 16:29:47 -0000 On Thu, 31 Aug 2017, Templin, Fred L wrote: > That can be done with DHCPv6 Reconfigure. Server sends Reconfigure, > client responds by sending Renew, and server responds by sending a Reply > (the sixth "R") with a shortened prefix lifetime. What DHCPv6 servers support reconfigure today? How is this reconfigure supposed to be triggered by the DR (because it's probably the one that knows that something happened)? From nobody Thu Aug 31 09:49:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36A132E11 for ; Thu, 31 Aug 2017 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 BzPdugtPvAkX for ; Thu, 31 Aug 2017 09:49:51 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF09132A8E for ; Thu, 31 Aug 2017 09:49:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id A7099B60 for ; Thu, 31 Aug 2017 16:49:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V3chcgbVfyA for ; Thu, 31 Aug 2017 11:49:50 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 45357B0B for ; Thu, 31 Aug 2017 11:49:50 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id y50so280340uay.0 for ; Thu, 31 Aug 2017 09:49:50 -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=FnCn3Wfb5of4le8paBYSb662+g/hb3Kr2q228UuPg6I=; b=R12iylFQU3mZOZWHZiK+2SmVcDO2c8DIaPjSgJuSa6Rk70Q6Q4Xvqh3DQ1b9/ZFfPq aS8t87HLqCL/Qsp6LcVWCk/iNVCWNgX7HJ3V8RJIr51rX+sVXDa5FgKbPIQKPuCGdpgX zD/VrLHX8PojaqvEi2WuQu+FTpy0k6iqT4QUPKnWz07fxQbEH6bvQmwDXfl6LxXSKqqm mH75AyHuHPoXUzMuJ0FfPkXzbZjzwnMvRm+TIWC8hMbck0O2zipj/AU94B7oyZwoq92o 5hgIwcZf0Na8awGpPAihao38t9gcYusuEr1tbtqAr79yDLSvjAldJM/xad9gva6il4lD AF2g== 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=FnCn3Wfb5of4le8paBYSb662+g/hb3Kr2q228UuPg6I=; b=g4NJZcFu8Wsae1goEZiqQOA4uYVZtLD1jo+xitBTGLjzq8DlpgakWB/nnn4Nmttl8I HDrc29hfr0+lMJR5aTZThtooWtiqrMn8yeo1NSMmFeDAc6ayBVK1ek83kXCydDBpPr42 Tfgmvg+pZlAkuW6/ujg7DDjsKbyL/GAmCdAN3uWeQZFP8rmhHY+wII2IP3YlxX331BdO la070nWVAgSlp7O9/JEsez1LPcgV8uYsCq4946qpQzFfyPFiPzeAXTaeSJPGqsN4ACJu RjTzkoqRWH1+UT6GHFccemTL8R+asLjL4/Fz4HQssvpq870T5kOeByM9TD36eTMicCzE nM5Q== X-Gm-Message-State: AHPjjUg69T6pa+8e8mCfY3rBIv/bs8GGPZy4KPYDiXdV73jfeIQoVvil UxIywYZEPF0+ZcCW8arXSReYVTicK4geeolZyyzJ915V/YsRDyQjeGNVkEXFpJD+H46ZHvK8+59 SRMCZHmRLzsUSSlG6 X-Received: by 10.159.38.34 with SMTP id 31mr1686233uag.160.1504198189138; Thu, 31 Aug 2017 09:49:49 -0700 (PDT) X-Google-Smtp-Source: ADKCNb5FnNhadRAQbzifteKnFIlj3h/bG5pbu1mtsRBsaLpdP4RRvfta8Y5S2vQE5ozjzYS/rdNqBDBA6jrRnKgf/Hc= X-Received: by 10.159.38.34 with SMTP id 31mr1686216uag.160.1504198188879; Thu, 31 Aug 2017 09:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.49.213 with HTTP; Thu, 31 Aug 2017 09:49:47 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Thu, 31 Aug 2017 11:49:47 -0500 Message-ID: To: "Templin, Fred L" Cc: Tim Chown , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a113eff4cb8c57605580f6e43" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 16:49:53 -0000 --001a113eff4cb8c57605580f6e43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are talking about redirects as if they are a universal good, and yes they are necessary in some situations, but they also have security considerations. You claim the draft is ignoring the potential usefulness of redirects in some environments and yes it is. However, you are ignoring the potential additional security that not having redirects has in other environments. Further, you have not discussed any advantages that the use of prefix per host subnets model has over the classic multiple hosts per subnet model in an insecure environment to justify the increased use of number resources by prefix per host subnets model. Please explain some of the use cases you think their are and why the prefix per host subnets model with redirects has any kind of advantage over the classic multiple hosts per subnet model. Thanks. On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L wrote: > Hi, > > > > The simple point in all of this is that Redirects are (and will remain) a > > useful component of IPv6 ND, yet this document seems to deprecate > > their use in all cases even for links where use of Redirects is essential= . > > > > The sending or not sending of Redirects is up to the router and, on > > links where Redirects are not desired, the router simply refrains from > > sending them. This is no different than what has been documented > > in RFC4861 and its predecessors (RFC1970, RFC2461) since the earliest > > days of IPv6. > > > > Thanks - Fred > > > > *From:* David Farmer [mailto:farmer@umn.edu] > *Sent:* Wednesday, August 30, 2017 3:05 PM > *To:* Templin, Fred L > *Cc:* Tim Chown ; v6ops@ietf.org; > v6ops-chairs@ietf.org; v6ops-ads@ietf.org > *Subject:* Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6- > prefix-per-host-07' > > > > > > > > On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > Hi, again this document is nothing more than an expression of what is > already > > in RFC4861, but then it adds constraints that don=E2=80=99t need to be th= ere. If > the > > PIO has A=3D1, L=3D0 then by RFC4861 the host will autoconfigure one or m= ore > > addresses and send packets via the default router (since =E2=80=98L=E2=80= =99 is 0) unless > > there is a more-specific route. > > > > But, the router may send a Redirect and therefore subsequent packets coul= d > > go from peer-to-peer without having to go through the router. This docume= nt > > should not be in the business of disabling or disallowing the Redirect > function, > > which is a core element of IPv6 ND and necessary for some link types. > > > > Thanks - Fred > > > > And you can do just that with one /64 subnet for how many every hosts you > want too on the same subnet. > > > > However, if you have 1000 hosts all on the same link, and there is subnet > prefix per host, what prevents all 1000 hosts from forming SLAAC addresse= s > on each of the prefixes? Something has to prevent Host1 from knowing abou= t > the prefixes for the other 999 hosts. Otherwise per RFC4861, Host1 would > form an address on those other 999 prefixes as well. This implies some > kind of separation of the hosts is already required if a host is going to > use only it's prefix. > > > > And if that separation is only applied to the RAs, and the hosts can > communicate directly with each other over the shared network then what is > the advantage of doing that over 1 subnet for the 1000 hosts? You are > making thinks more complicate without any seeming advantage. Now if the > hosts can't communicate with each other then there is an advantage provid= ed > by segregating the RAs for the other 999 prefixes from Host1. > > > > Therefore some level of host segregation is a fundamental property of thi= s > whole technique, and it makes no sense to limit it per host advertisement > of RAs. > > > > Thanks > > > > > > > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a113eff4cb8c57605580f6e43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    You are talking about redirects as if they are a universal= good, and yes they are necessary in some situations, but they also have se= curity considerations. You claim the draft is ignoring the potential useful= ness of redirects in some environments and yes it is.=C2=A0 However, you ar= e ignoring the potential additional security that not having redirects has = in other environments.=C2=A0

    Further, you have not discu= ssed any advantages that the use of prefix per host subnets model has over = the classic multiple hosts per subnet model in an insecure environment to j= ustify the increased use of number resources by prefix per host subnets mod= el. Please explain some of the use cases you think their are and why the pr= efix per host subnets model with redirects has any kind of advantage over t= he classic multiple hosts per subnet model.

    Thanks= .

    On Thu,= Aug 31, 2017 at 10:18 AM, Templin, Fred L <Fred.L.Templin@boeing.= com> wrote:

    Hi,

    =C2=A0

    The simple point in all of this is that Redi= rects are (and will remain) a

    useful component of IPv6 ND, yet this docume= nt seems to deprecate

    their use in all cases even for links where = use of Redirects is essential.

    =C2=A0

    The sending or not sending of Redirects is u= p to the router and, on

    links where Redirects are not desired, the r= outer simply refrains from

    sending them. This is no different than what= has been documented

    in RFC4861 and its predecessors (RFC1970, RF= C2461) since the earliest

    days of IPv6.

    =C2=A0

    Thanks - Fred

    =C2=A0

    From: David Farmer [mailto:farmer@umn.edu]
    Sent: Wednesday, August 30, 2017 3:05 PM
    To: Templin, Fred L <Fred.L.Templin@boeing.com>
    Cc: Tim Chown <Tim.Chown@jisc.ac.uk>; v6ops@ietf.org; v6ops-chairs@ietf.org; v6ops-ads@ietf.org
    Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

    =C2=A0

    =C2=A0

    =C2=A0

    On Wed, Aug 30, 2017 at 4:22 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

    Hi, again this document is nothing more than= an expression of what is already

    in RFC4861, but then it adds constraints tha= t don=E2=80=99t need to be there. If the

    PIO has A=3D1, L=3D0 then by RFC4861 the hos= t will autoconfigure one or more

    addresses and send packets via the default r= outer (since =E2=80=98L=E2=80=99 is 0) unless

    there is a more-specific route.

    =C2=A0

    But, the router may send a Redirect and ther= efore subsequent packets could

    go from peer-to-peer without having to go th= rough the router. This document

    should not be in the business of disabling o= r disallowing the Redirect function,

    which is a core element of IPv6 ND and neces= sary for some link types.

    =C2=A0

    Thanks - Fred

    =C2=A0

    And you can do just that with one /64 subnet for how= many every hosts you want too on the same subnet. =C2=A0

    =C2=A0

    However, if you have 1000 hosts all on the same link= , and there is subnet prefix per host, what prevents all 1000 hosts from fo= rming SLAAC addresses on each of the prefixes? Something has to prevent Hos= t1 from knowing about the prefixes for the other 999 hosts. Otherwise per RFC4861, Host1 would form an addres= s on those other 999 prefixes as well.=C2=A0 This implies some kind of sepa= ration of the hosts is already required if a host is going to use only it&#= 39;s prefix.

    =C2=A0

    And if that separation is only applied to the RAs, a= nd the hosts can communicate directly with each other over the shared netwo= rk then what is the advantage of doing that over 1 subnet for the 1000 host= s? You are making thinks more complicate without any seeming advantage. Now if the hosts can't communicate with= each other then there is an advantage provided by segregating the RAs for = the other 999 prefixes from Host1.

    =C2=A0

    Therefore some level of host segregation is a fundam= ental property of this whole technique, and it makes no sense to limit it p= er host advertisement of RAs.

    =C2=A0

    Thanks

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0=C2=A0

    =C2=A0

    --

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




    --
    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Cel= l: 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
    --001a113eff4cb8c57605580f6e43-- From nobody Thu Aug 31 10:03:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A842132025 for ; Thu, 31 Aug 2017 10:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mG5tqy-YRHT for ; Thu, 31 Aug 2017 10:03:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51504132360 for ; Thu, 31 Aug 2017 10:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1346; q=dns/txt; s=iport; t=1504199026; x=1505408626; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VWrylAqxozDDfRJ+Q1Q0OiLxxGxOh1i7htZ3dOsPPhE=; b=hXXP5JXwWlJt3rrm5YBX6/ygBZvYjBubjUwASULpSD7GxdZ396Szt4Nw 5DWbz+5y97bvfbBSKnjX9pgftJ3wmsOs4MBGPEGBc7pIEQ78Z23b0iv7G rz1Bii5rjK+nK5W6OvcoOkz0Br1RCiGvQXnwhws6uqlz3DP+AzqZR8dsZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACDQKhZ/5hdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjhCQHoFxlieCEiELhRsChA4/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBATg0CwUHBAIBCA4DBAEBHwkHJwsUCQgCBA4FCIohCBCxKotgAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDKoIChlmEXx2FbQWgbwKURpJ3lkQBHziBDXc?= =?us-ascii?q?VSYcbdgGJPIEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,454,1498521600"; d="scan'208";a="287991145" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 17:03:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VH3jcF003440 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 17:03:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 12:03:44 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 12:03:44 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson , "Templin, Fred L" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgANXcmAAAC4x4AAAHrvAAADlXeAAA8M/gAAIj+ygAAPPumAABaTHgAAAgpJgAAJZpVw Date: Thu, 31 Aug 2017 17:03:44 +0000 Message-ID: References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> <8735eb0ddf5c4d05b19d4dd5c7ddd400@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:03:48 -0000 > What DHCPv6 servers support reconfigure today? Cisco Prime Network Registrar does. You can reconfigure individual clients; we don't have a function to reconfi= gure all the clients on a particular network segment, but it isn't difficul= t to do this -- you can request the leases active on a network segment, and= issue reconfiguration operations to each of those clients. Of course, this requires the clients to support Reconfigure -- and most of = the DOCSIS devices do. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, August 31, 2017 12:30 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 On Thu, 31 Aug 2017, Templin, Fred L wrote: > That can be done with DHCPv6 Reconfigure. Server sends Reconfigure,=20 > client responds by sending Renew, and server responds by sending a=20 > Reply (the sixth "R") with a shortened prefix lifetime. What DHCPv6 servers support reconfigure today? How is this reconfigure supp= osed to be triggered by the DR (because it's probably the one that knows th= at something happened)? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 31 10:12:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D24132DF8 for ; Thu, 31 Aug 2017 10:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q66ALs7qn43C for ; Thu, 31 Aug 2017 10:12:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32CA132E11 for ; Thu, 31 Aug 2017 10:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1504199555; x=1505409155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LxufYal61tozaz+btVp2hWzYOz6KfTrQ9Gii/oD+tEA=; b=aV46YOiPOUMQWytHJA5i/8v+oE4a1guZ0f4Iiz/D+RJQRracNr/wzL0K 1BuHULzeFeeQ0boc61kfFg5IbH8NqLmmoNbV4fCfbZhj0nXIOIxkF6yVO sQqb7Q6HUWXmboZQm9oOPtHUx18Nb5So6SmVVijc2Gncrs7v0IsovFtj0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACwQqhZ/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjhCQHoFxlieCEiELhRsChA4/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBATg0CwUHBAIBCA4DBAEBHwkHJwsUCQgCBA4FCIohCBCxNItgAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDKoIChlmEXx2FbQWgbwKURpJ3lkQBHziBDXc?= =?us-ascii?q?VSYcbdgGJPIEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,454,1498521600"; d="scan'208";a="71866281" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 17:12:35 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7VHCYrI017946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 17:12:34 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 12:12:34 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 12:12:33 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson , "Templin, Fred L" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 Thread-Index: AdMg8wF4Bj2oG9WzR0yYMCXMp4zOMgANXcmAAAC4x4AAAHrvAAADlXeAAA8M/gAAIj+ygAAPPumAABaTHgAAAgpJgAAJZpVwABJ5R/A= Date: Thu, 31 Aug 2017 17:12:33 +0000 Message-ID: <982be7e13a3a418d860b6a37479556e9@XCH-ALN-003.cisco.com> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> <5c8330c943464353afe0dd0fb302c171@XCH15-06-08.nw.nos.boeing.com> <8735eb0ddf5c4d05b19d4dd5c7ddd400@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:12:37 -0000 BTW: I should add that we can send Reconfigure to devices that may only hav= e done PD (and thus do not have a leased address). We can send the Reconfig= ure via the relay chain (Relay-Reply) that the client last used to communic= ate with the server. This is also useful in cases where the DHCPv6 server i= s unable to communicate directly with the client (though that is less typic= al in v6 network than in V4, hopefully). -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Thursday, August 31, 2017 1:04 PM To: Mikael Abrahamsson ; Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 > What DHCPv6 servers support reconfigure today? Cisco Prime Network Registrar does. You can reconfigure individual clients; we don't have a function to reconfi= gure all the clients on a particular network segment, but it isn't difficul= t to do this -- you can request the leases active on a network segment, and= issue reconfiguration operations to each of those clients. Of course, this requires the clients to support Reconfigure -- and most of = the DOCSIS devices do. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, August 31, 2017 12:30 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 On Thu, 31 Aug 2017, Templin, Fred L wrote: > That can be done with DHCPv6 Reconfigure. Server sends Reconfigure,=20 > client responds by sending Renew, and server responds by sending a=20 > Reply (the sixth "R") with a shortened prefix lifetime. What DHCPv6 servers support reconfigure today? How is this reconfigure supp= osed to be triggered by the DR (because it's probably the one that knows th= at something happened)? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 31 10:18:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59E132E22; Thu, 31 Aug 2017 10:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k0cZ97UELNE; Thu, 31 Aug 2017 10:18:28 -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 49166132E11; Thu, 31 Aug 2017 10:18:28 -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 v7VHIR4A059945; Thu, 31 Aug 2017 10:18:27 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v7VHIKZD059914 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 10:18:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 10:18:19 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 10:18:19 -0700 From: "Templin, Fred L" To: David Farmer CC: Tim Chown , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKAABmowzAAMCdaBQAHEcpAABByPIAAFPhlwAASUnyAAA5AGBA= Date: Thu, 31 Aug 2017 17:18:19 +0000 Message-ID: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_d20b63e3001f4b33bb645b7f9bb3ab15XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:18:31 -0000 --_000_d20b63e3001f4b33bb645b7f9bb3ab15XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQg4oCTIHNlZSBiZWxvdyBmb3IgZm9sbG93LXVwcy4NCg0KVGhhbmtzIC0gRnJlZA0K DQpGcm9tOiBEYXZpZCBGYXJtZXIgW21haWx0bzpmYXJtZXJAdW1uLmVkdV0NClNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMzEsIDIwMTcgOTo1MCBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVr PjsgdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBDb21tZW50IG9uICdkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNycNCg0KWW91IGFyZSB0YWxraW5nIGFib3V0IHJl ZGlyZWN0cyBhcyBpZiB0aGV5IGFyZSBhIHVuaXZlcnNhbCBnb29kLCBhbmQgeWVzIHRoZXkgYXJl IG5lY2Vzc2FyeSBpbiBzb21lIHNpdHVhdGlvbnMsIGJ1dCB0aGV5IGFsc28gaGF2ZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4gWW91IGNsYWltIHRoZSBkcmFmdCBpcyBpZ25vcmluZyB0aGUgcG90 ZW50aWFsIHVzZWZ1bG5lc3Mgb2YgcmVkaXJlY3RzIGluIHNvbWUgZW52aXJvbm1lbnRzIGFuZCB5 ZXMgaXQgaXMuICBIb3dldmVyLCB5b3UgYXJlIGlnbm9yaW5nIHRoZSBwb3RlbnRpYWwgYWRkaXRp b25hbCBzZWN1cml0eSB0aGF0IG5vdCBoYXZpbmcgcmVkaXJlY3RzIGhhcyBpbiBvdGhlciBlbnZp cm9ubWVudHMuDQoNCg0Kw5ggICAgSSBuZXZlciBzYWlkIFJlZGlyZWN0cyBhcmUgYSB1bml2ZXJz YWwgZ29vZCwgYXMgdGhhdCB3b3VsZCBiZSBmYXIgZnJvbSB0aGUgdHJ1dGguIEkgc2FpZA0KDQrD mCAgICB0aGF0IG9uIHNvbWUgbGlua3MgdXNlIG9mIFJlZGlyZWN0cyBpcyDigJxlc3NlbnRpYWzi gJ0sIGJ1dCB3aGF0IEkgbWVhbnQgdG8gc2F5IGlzIHRoYXQNCg0Kw5ggICAgUmVkaXJlY3RzIGNh biBwcm92aWRlIGEgdXNlZnVsIG9wdGltaXphdGlvbi4gUm91dGVycyBkb27igJl0IG5lZWQgdG8g c2VuZCBSZWRpcmVjdHMNCg0Kw5ggICAgYW5kIGhvc3RzIGRvbuKAmXQgbmVlZCB0byBsaXN0ZW4g dG8gdGhlbSwgYnV0IG9uIHNvbWUgbGluayB0eXBlcyAoZS5nLiwgTkJNQSkgdGhlaXINCg0Kw5gg ICAgdXNlIGNhbiBpbXByb3ZlIHBlcmZvcm1hbmNlIGZvciBib3RoIHRoZSBpbmRpdmlkdWFsIHBl ZXJzIGFuZCB0aGUgbGluayBhcyBhIHdob2xlLg0KDQrDmA0KDQrDmCAgICBBYm91dCBzZWN1cml0 eSwgYWxsIG9mIElQdjYgTkQgaGFzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIChSRkMzNzU2LCBS RkM0ODYxKS4gU28gbXVjaA0KDQrDmCAgICBzbyB0aGF0IFNlY3VyZSBOZWlnaGJvciBEaXNjb3Zl cnkgd2FzIHN0YW5kYXJkaXplZCAoUkZDMzk3MSkuIFRydWUgdGhhdCBSRkMzOTcxIGlzDQoNCsOY ICAgIG5vdCB3aWRlbHkgdXNlZC9kZXBsb3llZCwgYnV0IHRoZSBmYWN0IGlzIHRoYXQgTmVpZ2hi b3IgRGlzY292ZXJ5IFRydXN0IE1vZGVscyBhbmQNCg0Kw5ggICAgVGhyZWF0cyBuZWVkIHRvIGJl IGNvbnNpZGVyZWQgZm9yIGVhY2ggbGluayB0eXBlIGZvciBhbGwgTkQgbWVzc2FnZSB0eXBlcyDi gJMgbm90DQoNCsOYICAgIGp1c3QgUmVkaXJlY3RzLg0KDQpGdXJ0aGVyLCB5b3UgaGF2ZSBub3Qg ZGlzY3Vzc2VkIGFueSBhZHZhbnRhZ2VzIHRoYXQgdGhlIHVzZSBvZiBwcmVmaXggcGVyIGhvc3Qg c3VibmV0cyBtb2RlbCBoYXMgb3ZlciB0aGUgY2xhc3NpYyBtdWx0aXBsZSBob3N0cyBwZXIgc3Vi bmV0IG1vZGVsIGluIGFuIGluc2VjdXJlIGVudmlyb25tZW50IHRvIGp1c3RpZnkgdGhlIGluY3Jl YXNlZCB1c2Ugb2YgbnVtYmVyIHJlc291cmNlcyBieSBwcmVmaXggcGVyIGhvc3Qgc3VibmV0cyBt b2RlbC4gUGxlYXNlIGV4cGxhaW4gc29tZSBvZiB0aGUgdXNlIGNhc2VzIHlvdSB0aGluayB0aGVp ciBhcmUgYW5kIHdoeSB0aGUgcHJlZml4IHBlciBob3N0IHN1Ym5ldHMgbW9kZWwgd2l0aCByZWRp cmVjdHMgaGFzIGFueSBraW5kIG9mIGFkdmFudGFnZSBvdmVyIHRoZSBjbGFzc2ljIG11bHRpcGxl IGhvc3RzIHBlciBzdWJuZXQgbW9kZWwuDQoNCg0Kw5ggICAgSSBoYXZlIGFscmVhZHkgc2FpZCBt YW55IHRpbWVzIHRoYXQgUmVkaXJlY3RzIGFyZSB1c2VmdWwgdG8gYWxsb3cgcGVlci10by1wZWVy DQoNCsOYICAgIGNvbW11bmljYXRpb25zIGluc3RlYWQgb2YgcGVlci10by1yb3V0ZXItdG8tcGVl ci4gQ2FsbCBpdCBhIHJvdXRlIG9wdGltaXphdGlvbg0KDQrDmCAgICBvciBhIG5laWdoYm9yIGRp c2NvdmVyeSBmdW5jdGlvbiDigJMgeW91ciBjaG9pY2UuIFRoZXJlIG1heSBiZSBiZW5lZml0cyBv cg0KDQrDmCAgICBkcmF3YmFja3MgdG8gcGVlci10by1wZWVyIGRlcGVuZGluZyBvbiB0aGUgdXNl IGNhc2Ug4oCTIGJ1dCB0aGVyZSB3aWxsIGJlDQoNCsOYICAgdXNlIGNhc2VzIHdoZXJlIHRoZXJl IGFyZSBiZW5lZml0cy4NCg0KVGhhbmtzLg0KDQpPbiBUaHUsIEF1ZyAzMSwgMjAxNyBhdCAxMDox OCBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpIaSwNCg0KVGhlIHNpbXBsZSBwb2lu dCBpbiBhbGwgb2YgdGhpcyBpcyB0aGF0IFJlZGlyZWN0cyBhcmUgKGFuZCB3aWxsIHJlbWFpbikg YQ0KdXNlZnVsIGNvbXBvbmVudCBvZiBJUHY2IE5ELCB5ZXQgdGhpcyBkb2N1bWVudCBzZWVtcyB0 byBkZXByZWNhdGUNCnRoZWlyIHVzZSBpbiBhbGwgY2FzZXMgZXZlbiBmb3IgbGlua3Mgd2hlcmUg dXNlIG9mIFJlZGlyZWN0cyBpcyBlc3NlbnRpYWwuDQoNClRoZSBzZW5kaW5nIG9yIG5vdCBzZW5k aW5nIG9mIFJlZGlyZWN0cyBpcyB1cCB0byB0aGUgcm91dGVyIGFuZCwgb24NCmxpbmtzIHdoZXJl IFJlZGlyZWN0cyBhcmUgbm90IGRlc2lyZWQsIHRoZSByb3V0ZXIgc2ltcGx5IHJlZnJhaW5zIGZy b20NCnNlbmRpbmcgdGhlbS4gVGhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiB3aGF0IGhhcyBiZWVu IGRvY3VtZW50ZWQNCmluIFJGQzQ4NjEgYW5kIGl0cyBwcmVkZWNlc3NvcnMgKFJGQzE5NzAsIFJG QzI0NjEpIHNpbmNlIHRoZSBlYXJsaWVzdA0KZGF5cyBvZiBJUHY2Lg0KDQpUaGFua3MgLSBGcmVk DQoNCkZyb206IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1bW4uZWR1PG1haWx0bzpmYXJt ZXJAdW1uLmVkdT5dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyAzOjA1IFBNDQpU bzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPj4NCkNjOiBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFj LnVrPG1haWx0bzpUaW0uQ2hvd25AamlzYy5hYy51az4+OyB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+OyB2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWNoYWly c0BpZXRmLm9yZz47IHY2b3BzLWFkc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYWRzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gQ29tbWVudCBvbiAnZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcnDQoNCg0KDQpPbiBXZWQsIEF1ZyAzMCwgMjAxNyBh dCA0OjIyIFBNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFp bHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCkhpLCBhZ2FpbiB0aGlzIGRv Y3VtZW50IGlzIG5vdGhpbmcgbW9yZSB0aGFuIGFuIGV4cHJlc3Npb24gb2Ygd2hhdCBpcyBhbHJl YWR5DQppbiBSRkM0ODYxLCBidXQgdGhlbiBpdCBhZGRzIGNvbnN0cmFpbnRzIHRoYXQgZG9u4oCZ dCBuZWVkIHRvIGJlIHRoZXJlLiBJZiB0aGUNClBJTyBoYXMgQT0xLCBMPTAgdGhlbiBieSBSRkM0 ODYxIHRoZSBob3N0IHdpbGwgYXV0b2NvbmZpZ3VyZSBvbmUgb3IgbW9yZQ0KYWRkcmVzc2VzIGFu ZCBzZW5kIHBhY2tldHMgdmlhIHRoZSBkZWZhdWx0IHJvdXRlciAoc2luY2Ug4oCYTOKAmSBpcyAw KSB1bmxlc3MNCnRoZXJlIGlzIGEgbW9yZS1zcGVjaWZpYyByb3V0ZS4NCg0KQnV0LCB0aGUgcm91 dGVyIG1heSBzZW5kIGEgUmVkaXJlY3QgYW5kIHRoZXJlZm9yZSBzdWJzZXF1ZW50IHBhY2tldHMg Y291bGQNCmdvIGZyb20gcGVlci10by1wZWVyIHdpdGhvdXQgaGF2aW5nIHRvIGdvIHRocm91Z2gg dGhlIHJvdXRlci4gVGhpcyBkb2N1bWVudA0Kc2hvdWxkIG5vdCBiZSBpbiB0aGUgYnVzaW5lc3Mg b2YgZGlzYWJsaW5nIG9yIGRpc2FsbG93aW5nIHRoZSBSZWRpcmVjdCBmdW5jdGlvbiwNCndoaWNo IGlzIGEgY29yZSBlbGVtZW50IG9mIElQdjYgTkQgYW5kIG5lY2Vzc2FyeSBmb3Igc29tZSBsaW5r IHR5cGVzLg0KDQpUaGFua3MgLSBGcmVkDQoNCkFuZCB5b3UgY2FuIGRvIGp1c3QgdGhhdCB3aXRo IG9uZSAvNjQgc3VibmV0IGZvciBob3cgbWFueSBldmVyeSBob3N0cyB5b3Ugd2FudCB0b28gb24g dGhlIHNhbWUgc3VibmV0Lg0KDQpIb3dldmVyLCBpZiB5b3UgaGF2ZSAxMDAwIGhvc3RzIGFsbCBv biB0aGUgc2FtZSBsaW5rLCBhbmQgdGhlcmUgaXMgc3VibmV0IHByZWZpeCBwZXIgaG9zdCwgd2hh dCBwcmV2ZW50cyBhbGwgMTAwMCBob3N0cyBmcm9tIGZvcm1pbmcgU0xBQUMgYWRkcmVzc2VzIG9u IGVhY2ggb2YgdGhlIHByZWZpeGVzPyBTb21ldGhpbmcgaGFzIHRvIHByZXZlbnQgSG9zdDEgZnJv bSBrbm93aW5nIGFib3V0IHRoZSBwcmVmaXhlcyBmb3IgdGhlIG90aGVyIDk5OSBob3N0cy4gT3Ro ZXJ3aXNlIHBlciBSRkM0ODYxLCBIb3N0MSB3b3VsZCBmb3JtIGFuIGFkZHJlc3Mgb24gdGhvc2Ug b3RoZXIgOTk5IHByZWZpeGVzIGFzIHdlbGwuICBUaGlzIGltcGxpZXMgc29tZSBraW5kIG9mIHNl cGFyYXRpb24gb2YgdGhlIGhvc3RzIGlzIGFscmVhZHkgcmVxdWlyZWQgaWYgYSBob3N0IGlzIGdv aW5nIHRvIHVzZSBvbmx5IGl0J3MgcHJlZml4Lg0KDQpBbmQgaWYgdGhhdCBzZXBhcmF0aW9uIGlz IG9ubHkgYXBwbGllZCB0byB0aGUgUkFzLCBhbmQgdGhlIGhvc3RzIGNhbiBjb21tdW5pY2F0ZSBk aXJlY3RseSB3aXRoIGVhY2ggb3RoZXIgb3ZlciB0aGUgc2hhcmVkIG5ldHdvcmsgdGhlbiB3aGF0 IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgZG9pbmcgdGhhdCBvdmVyIDEgc3VibmV0IGZvciB0aGUgMTAw MCBob3N0cz8gWW91IGFyZSBtYWtpbmcgdGhpbmtzIG1vcmUgY29tcGxpY2F0ZSB3aXRob3V0IGFu eSBzZWVtaW5nIGFkdmFudGFnZS4gTm93IGlmIHRoZSBob3N0cyBjYW4ndCBjb21tdW5pY2F0ZSB3 aXRoIGVhY2ggb3RoZXIgdGhlbiB0aGVyZSBpcyBhbiBhZHZhbnRhZ2UgcHJvdmlkZWQgYnkgc2Vn cmVnYXRpbmcgdGhlIFJBcyBmb3IgdGhlIG90aGVyIDk5OSBwcmVmaXhlcyBmcm9tIEhvc3QxLg0K DQpUaGVyZWZvcmUgc29tZSBsZXZlbCBvZiBob3N0IHNlZ3JlZ2F0aW9uIGlzIGEgZnVuZGFtZW50 YWwgcHJvcGVydHkgb2YgdGhpcyB3aG9sZSB0ZWNobmlxdWUsIGFuZCBpdCBtYWtlcyBubyBzZW5z ZSB0byBsaW1pdCBpdCBwZXIgaG9zdCBhZHZlcnRpc2VtZW50IG9mIFJBcy4NCg0KVGhhbmtzDQoN Cg0KDQoNCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWls dG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlv biBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkg b2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYy Ni0wODE1PHRlbDooNjEyKSUyMDYyNi0wODE1Pg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkg ICBDZWxsOiA2MTItODEyLTk5NTI8dGVsOig2MTIpJTIwODEyLTk5NTI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KLS0NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAg ICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVk dT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIElu Zm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZl cnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYyNi0wODE1PHRlbDooNjEyKSUyMDYyNi0w ODE1Pg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkgICBDZWxsOiA2MTItODEyLTk5NTI8dGVs Oig2MTIpJTIwODEyLTk5NTI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0K --_000_d20b63e3001f4b33bb645b7f9bb3ab15XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTQwNzUzNzc7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTM2NDE4NjMwIDEzMzE4ODA4 NjggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkIOKAkyBzZWUgYmVsb3cgZm9yIGZvbGxv dy11cHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg LSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAzMSwgMjAxNyA5OjUwIEFNPGJyPg0K PGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBUaW0gQ2hvd24gJmx0O1RpbS5DaG93bkBqaXNjLmFjLnVrJmd0 OzsgdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsgdjZvcHMtYWRzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbW1lbnQgb24gJ2RyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3JzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIHRhbGtpbmcgYWJv dXQgcmVkaXJlY3RzIGFzIGlmIHRoZXkgYXJlIGEgdW5pdmVyc2FsIGdvb2QsIGFuZCB5ZXMgdGhl eSBhcmUgbmVjZXNzYXJ5IGluIHNvbWUgc2l0dWF0aW9ucywgYnV0IHRoZXkgYWxzbyBoYXZlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zLiBZb3UgY2xhaW0gdGhlIGRyYWZ0IGlzIGlnbm9yaW5nIHRo ZSBwb3RlbnRpYWwgdXNlZnVsbmVzcyBvZiByZWRpcmVjdHMgaW4gc29tZSBlbnZpcm9ubWVudHMN CiBhbmQgeWVzIGl0IGlzLiZuYnNwOyBIb3dldmVyLCB5b3UgYXJlIGlnbm9yaW5nIHRoZSBwb3Rl bnRpYWwgYWRkaXRpb25hbCBzZWN1cml0eSB0aGF0IG5vdCBoYXZpbmcgcmVkaXJlY3RzIGhhcyBp biBvdGhlciBlbnZpcm9ubWVudHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkkgbmV2ZXIgc2FpZCBSZWRpcmVjdHMgYXJlIGEgdW5pdmVyc2Fs IGdvb2QsIGFzIHRoYXQgd291bGQgYmUgZmFyIGZyb20gdGhlIHRydXRoLiBJIHNhaWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhdCBvbiBzb21lIGxpbmtzIHVzZSBvZiBSZWRpcmVj dHMgaXMg4oCcZXNzZW50aWFs4oCdLCBidXQgd2hhdCBJIG1lYW50IHRvIHNheSBpcyB0aGF0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZGlyZWN0cyBjYW4gcHJvdmlkZSBhIHVzZWZ1 bCBvcHRpbWl6YXRpb24uIFJvdXRlcnMgZG9u4oCZdCBuZWVkIHRvIHNlbmQgUmVkaXJlY3RzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCBob3N0cyBkb27igJl0IG5lZWQgdG8gbGlz dGVuIHRvIHRoZW0sIGJ1dCBvbiBzb21lIGxpbmsgdHlwZXMgKGUuZy4sIE5CTUEpIHRoZWlyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnVzZSBjYW4gaW1wcm92ZSBwZXJmb3JtYW5jZSBm b3IgYm90aCB0aGUgaW5kaXZpZHVhbCBwZWVycyBhbmQgdGhlIGxpbmsgYXMgYSB3aG9sZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1p bmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkFib3V0IHNlY3VyaXR5LCBhbGwgb2YgSVB2NiBORCBoYXMgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgKFJGQzM3NTYsIFJGQzQ4NjEpLiBTbyBtdWNoPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4 dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPnNvIHRoYXQgU2VjdXJlIE5laWdoYm9yIERpc2NvdmVyeSB3YXMgc3RhbmRhcmRp emVkIChSRkMzOTcxKS4gVHJ1ZSB0aGF0IFJGQzM5NzEgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0 LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+bm90IHdpZGVseSB1c2VkL2RlcGxveWVkLCBidXQgdGhlIGZhY3QgaXMgdGhhdCBO ZWlnaGJvciBEaXNjb3ZlcnkgVHJ1c3QgTW9kZWxzIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQt aW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaHJlYXRzIG5lZWQgdG8gYmUgY29uc2lkZXJlZCBmb3IgZWFjaCBsaW5rIHR5cGUg Zm9yIGFsbCBORCBtZXNzYWdlIHR5cGVzIOKAkyBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWlu ZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+anVzdCBSZWRpcmVjdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlciwgeW91IGhhdmUgbm90IGRpc2N1c3NlZCBhbnkgYWR2 YW50YWdlcyB0aGF0IHRoZSB1c2Ugb2YgcHJlZml4IHBlciBob3N0IHN1Ym5ldHMgbW9kZWwgaGFz IG92ZXIgdGhlIGNsYXNzaWMgbXVsdGlwbGUgaG9zdHMgcGVyIHN1Ym5ldCBtb2RlbCBpbiBhbiBp bnNlY3VyZSBlbnZpcm9ubWVudCB0byBqdXN0aWZ5IHRoZSBpbmNyZWFzZWQgdXNlIG9mIG51bWJl ciByZXNvdXJjZXMgYnkgcHJlZml4IHBlcg0KIGhvc3Qgc3VibmV0cyBtb2RlbC4gUGxlYXNlIGV4 cGxhaW4gc29tZSBvZiB0aGUgdXNlIGNhc2VzIHlvdSB0aGluayB0aGVpciBhcmUgYW5kIHdoeSB0 aGUgcHJlZml4IHBlciBob3N0IHN1Ym5ldHMgbW9kZWwgd2l0aCByZWRpcmVjdHMgaGFzIGFueSBr aW5kIG9mIGFkdmFudGFnZSBvdmVyIHRoZSBjbGFzc2ljIG11bHRpcGxlIGhvc3RzIHBlciBzdWJu ZXQgbW9kZWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkkgaGF2ZSBhbHJlYWR5IHNhaWQgbWFueSB0aW1lcyB0aGF0IFJlZGlyZWN0cyBhcmUgdXNlZnVs IHRvIGFsbG93IHBlZXItdG8tcGVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jb21t dW5pY2F0aW9ucyBpbnN0ZWFkIG9mIHBlZXItdG8tcm91dGVyLXRvLXBlZXIuIENhbGwgaXQgYSBy b3V0ZSBvcHRpbWl6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b3IgYSBuZWln aGJvciBkaXNjb3ZlcnkgZnVuY3Rpb24g4oCTIHlvdXIgY2hvaWNlLiBUaGVyZSBtYXkgYmUgYmVu ZWZpdHMgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZHJhd2JhY2tzIHRvIHBlZXIt dG8tcGVlciBkZXBlbmRpbmcgb24gdGhlIHVzZSBjYXNlIOKAkyBidXQgdGhlcmUgd2lsbCBiZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NS4yNXB0O3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj51c2UgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGJlbmVm aXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIEF1ZyAzMSwgMjAxNyBhdCAxMDoxOCBBTSwgVGVtcGxpbiwgRnJlZCBMICZs dDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzaW1wbGUgcG9pbnQgaW4gYWxsIG9mIHRoaXMgaXMg dGhhdCBSZWRpcmVjdHMgYXJlIChhbmQgd2lsbCByZW1haW4pIGE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij51c2VmdWwgY29tcG9uZW50IG9mIElQdjYgTkQsIHlldCB0aGlzIGRvY3VtZW50IHNlZW1zIHRv IGRlcHJlY2F0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZWlyIHVzZSBpbiBhbGwgY2FzZXMgZXZl biBmb3IgbGlua3Mgd2hlcmUgdXNlIG9mIFJlZGlyZWN0cyBpcyBlc3NlbnRpYWwuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNlbmRpbmcgb3Igbm90 IHNlbmRpbmcgb2YgUmVkaXJlY3RzIGlzIHVwIHRvIHRoZSByb3V0ZXIgYW5kLCBvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmxpbmtzIHdoZXJlIFJlZGlyZWN0cyBhcmUgbm90IGRlc2lyZWQsIHRoZSBy b3V0ZXIgc2ltcGx5IHJlZnJhaW5zIGZyb208L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zZW5kaW5nIHRo ZW0uIFRoaXMgaXMgbm8gZGlmZmVyZW50IHRoYW4gd2hhdCBoYXMgYmVlbiBkb2N1bWVudGVkPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+aW4gUkZDNDg2MSBhbmQgaXRzIHByZWRlY2Vzc29ycyAoUkZDMTk3 MCwgUkZDMjQ2MSkgc2luY2UgdGhlIGVhcmxpZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGF5cyBv ZiBJUHY2Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmZhcm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+ZmFybWVyQHVtbi5lZHU8L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3IDM6MDUgUE08 YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRpbSBDaG93biAmbHQ7PGEgaHJlZj0ibWFp bHRvOlRpbS5DaG93bkBqaXNjLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+VGltLkNob3duQGppc2Mu YWMudWs8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzLWNoYWlyc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdjZvcHMtY2hhaXJzQGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOnY2b3BzLWFkc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzLWFk c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gQ29tbWVudCBv biAnZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcnPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcg MzAsIDIwMTcgYXQgNDoyMiBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSwgYWdhaW4g dGhpcyBkb2N1bWVudCBpcyBub3RoaW5nIG1vcmUgdGhhbiBhbiBleHByZXNzaW9uIG9mIHdoYXQg aXMgYWxyZWFkeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmluIFJGQzQ4NjEsIGJ1dCB0aGVuIGl0IGFk ZHMgY29uc3RyYWludHMgdGhhdCBkb27igJl0IG5lZWQgdG8gYmUgdGhlcmUuIElmIHRoZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlBJTyBoYXMgQT0xLCBMPTAgdGhlbiBieSBSRkM0ODYxIHRoZSBob3N0 IHdpbGwgYXV0b2NvbmZpZ3VyZSBvbmUgb3IgbW9yZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFkZHJl c3NlcyBhbmQgc2VuZCBwYWNrZXRzIHZpYSB0aGUgZGVmYXVsdCByb3V0ZXIgKHNpbmNlIOKAmEzi gJkgaXMgMCkgdW5sZXNzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlcmUgaXMgYSBtb3JlLXNwZWNp ZmljIHJvdXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkJ1dCwgdGhlIHJvdXRlciBtYXkgc2VuZCBhIFJlZGlyZWN0IGFuZCB0aGVyZWZvcmUgc3Vic2Vx dWVudCBwYWNrZXRzIGNvdWxkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Z28gZnJvbSBwZWVyLXRvLXBl ZXIgd2l0aG91dCBoYXZpbmcgdG8gZ28gdGhyb3VnaCB0aGUgcm91dGVyLiBUaGlzIGRvY3VtZW50 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+c2hvdWxkIG5vdCBiZSBpbiB0aGUgYnVzaW5lc3Mgb2YgZGlz YWJsaW5nIG9yIGRpc2FsbG93aW5nIHRoZSBSZWRpcmVjdCBmdW5jdGlvbiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj53aGljaCBpcyBhIGNvcmUgZWxlbWVudCBvZiBJUHY2IE5EIGFuZCBuZWNlc3Nhcnkg Zm9yIHNvbWUgbGluayB0eXBlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bmQgeW91IGNhbiBkbyBqdXN0IHRoYXQgd2l0aCBvbmUgLzY0IHN1Ym5ldCBmb3IgaG93IG1hbnkg ZXZlcnkgaG9zdHMgeW91IHdhbnQgdG9vIG9uIHRoZSBzYW1lIHN1Ym5ldC4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dl dmVyLCBpZiB5b3UgaGF2ZSAxMDAwIGhvc3RzIGFsbCBvbiB0aGUgc2FtZSBsaW5rLCBhbmQgdGhl cmUgaXMgc3VibmV0IHByZWZpeCBwZXIgaG9zdCwgd2hhdCBwcmV2ZW50cyBhbGwgMTAwMCBob3N0 cyBmcm9tIGZvcm1pbmcgU0xBQUMgYWRkcmVzc2VzIG9uIGVhY2ggb2YgdGhlIHByZWZpeGVzPyBT b21ldGhpbmcNCiBoYXMgdG8gcHJldmVudCBIb3N0MSBmcm9tIGtub3dpbmcgYWJvdXQgdGhlIHBy ZWZpeGVzIGZvciB0aGUgb3RoZXIgOTk5IGhvc3RzLiBPdGhlcndpc2UgcGVyIFJGQzQ4NjEsIEhv c3QxIHdvdWxkIGZvcm0gYW4gYWRkcmVzcyBvbiB0aG9zZSBvdGhlciA5OTkgcHJlZml4ZXMgYXMg d2VsbC4mbmJzcDsgVGhpcyBpbXBsaWVzIHNvbWUga2luZCBvZiBzZXBhcmF0aW9uIG9mIHRoZSBo b3N0cyBpcyBhbHJlYWR5IHJlcXVpcmVkIGlmIGEgaG9zdCBpcyBnb2luZw0KIHRvIHVzZSBvbmx5 IGl0J3MgcHJlZml4LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QW5kIGlmIHRoYXQgc2VwYXJhdGlvbiBpcyBvbmx5IGFwcGxpZWQgdG8g dGhlIFJBcywgYW5kIHRoZSBob3N0cyBjYW4gY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBlYWNo IG90aGVyIG92ZXIgdGhlIHNoYXJlZCBuZXR3b3JrIHRoZW4gd2hhdCBpcyB0aGUgYWR2YW50YWdl IG9mIGRvaW5nIHRoYXQgb3ZlciAxDQogc3VibmV0IGZvciB0aGUgMTAwMCBob3N0cz8gWW91IGFy ZSBtYWtpbmcgdGhpbmtzIG1vcmUgY29tcGxpY2F0ZSB3aXRob3V0IGFueSBzZWVtaW5nIGFkdmFu dGFnZS4gTm93IGlmIHRoZSBob3N0cyBjYW4ndCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIg dGhlbiB0aGVyZSBpcyBhbiBhZHZhbnRhZ2UgcHJvdmlkZWQgYnkgc2VncmVnYXRpbmcgdGhlIFJB cyBmb3IgdGhlIG90aGVyIDk5OSBwcmVmaXhlcyBmcm9tIEhvc3QxLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmVmb3JlIHNvbWUg bGV2ZWwgb2YgaG9zdCBzZWdyZWdhdGlvbiBpcyBhIGZ1bmRhbWVudGFsIHByb3BlcnR5IG9mIHRo aXMgd2hvbGUgdGVjaG5pcXVlLCBhbmQgaXQgbWFrZXMgbm8gc2Vuc2UgdG8gbGltaXQgaXQgcGVy IGhvc3QgYWR2ZXJ0aXNlbWVudCBvZiBSQXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpEYXZpZCBG YXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJz cDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVyQHVtbi5lZHUiIHRhcmdldD0iX2JsYW5r Ij4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4NCk5ldHdvcmtpbmcgJmFtcDsgVGVsZWNv bW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9n eTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5ic3A7Jm5ic3A7IDxicj4NCjIyMTggVW5p dmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDxhIGhyZWY9 InRlbDooNjEyKSUyMDYyNi0wODE1IiB0YXJnZXQ9Il9ibGFuayI+DQo2MTItNjI2LTA4MTU8L2E+ PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkmbmJzcDsmbmJzcDsgQ2VsbDogPGEgaHJl Zj0idGVsOig2MTIpJTIwODEyLTk5NTIiIHRhcmdldD0iX2JsYW5rIj4NCjYxMi04MTItOTk1Mjwv YT48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVy Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxh IGhyZWY9Im1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpF bWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48YnI+DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5p Y2F0aW9uIFNlcnZpY2VzPGJyPg0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+ DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290YSZuYnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNp dHkgQXZlIFNFJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBob25lOiA8YSBocmVmPSJ0ZWw6 KDYxMiklMjA2MjYtMDgxNSIgdGFyZ2V0PSJfYmxhbmsiPg0KNjEyLTYyNi0wODE1PC9hPjxicj4N Ck1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDxhIGhyZWY9InRl bDooNjEyKSUyMDgxMi05OTUyIiB0YXJnZXQ9Il9ibGFuayI+DQo2MTItODEyLTk5NTI8L2E+PGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_d20b63e3001f4b33bb645b7f9bb3ab15XCH150608nwnosboeingcom_-- From nobody Thu Aug 31 11:20:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E713293F for ; Thu, 31 Aug 2017 11:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 3OteOW5-tPhL for ; Thu, 31 Aug 2017 11:20:47 -0700 (PDT) Received: from atl4mhob12.registeredsite.com (atl4mhob12.registeredsite.com [209.17.115.50]) (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 6640013234E for ; Thu, 31 Aug 2017 11:20:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7VIKim8031825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Aug 2017 14:20:44 -0400 Received: (qmail 25936 invoked by uid 0); 31 Aug 2017 18:20:44 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 31 Aug 2017 18:20:42 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 31 Aug 2017 14:20:39 -0400 From: Lee Howard To: Mikael Abrahamsson CC: "Templin, Fred L" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Prefix Delegation RS/RA vs DHCPv6 References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <38bc18556bcc4c1ba74606ecc087f02a@XCH15-06-08.nw.nos.boeing.com> <03cb306e3e35406f8509bd86be44401e@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 18:20:49 -0000 On 8/31/17, 10:00 AM, "Mikael Abrahamsson" wrote: >On Thu, 31 Aug 2017, Lee Howard wrote: > >> Why should we be encouraging staticness on the netwrk? Shouldn=E2=80=99t we be >> making it easier to renumber, rather than making the network less >> dynamic? > >Sounds like a great idea. How? Well, I note that the anima WG has this in their charter: A simple example is assigning address prefixes to network segments in a large and constantly changing network. https://datatracker.ietf.org/wg/anima/about/ Lee > From nobody Thu Aug 31 16:23:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B169133110 for ; Thu, 31 Aug 2017 16:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkSiXzlrlLYd for ; Thu, 31 Aug 2017 16:23:10 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F3713310C for ; Thu, 31 Aug 2017 16:23:10 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 63so3121513pgc.2 for ; Thu, 31 Aug 2017 16:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nQTzBwFh/3ZBy9OAQr1vLdjJ7Wd0K2fQgPNhR6Kzxsg=; b=JJ0r6CXL5Aibk6FWIrV6Nar6qO2EYYLZvL4brdiUaHYFfxrWDwU44SDogEbA1/gIFd /X+26kG3gmZSd+c2kIVEhA41aypb13UeC/y5NeD2CBaixiG24Nmbv6II2kTtxXuZ1TxX 6l2j5+HXNStFCtSWZyCm9zRvlSt+uUAUoBIFSQE6U9PcsPETBnEsLlrEwQ2teEpElpEx XvSPjnRfmV1/rbJpYqjIUPIgMPbnKVLNI8CgFlCM8JayyWVB2YfsBNwP9R/a0k11TYv5 9ePKX10Q3SYZj3UE0PJOd5auU//Q+iMdvy3eaRZZu8HpvjJXfYk07P1OqubYnCFhcyfF baZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nQTzBwFh/3ZBy9OAQr1vLdjJ7Wd0K2fQgPNhR6Kzxsg=; b=YUwvwNBxnzqMdiYRt/cMKBNWroPKBPOnxycSG48PDii1XJm6YTTBuCggGxuaKjDrlw GnLjc831p7diTjZCUa9auUPlYAk5XFiK8oBTsHlSdHpKULlTa8o5K8Sv+gcVNBxWCQpO RxLSc3onAHFXGC5wVty4v+dqoI/4P/+UZc1ZBMyZ0x+o0mgl/hsgyzS6fgwY3b2wdu5C rbI4QSxsZ9NgyYRLPDyFo0x2+ZNmDBpYcn+0J/Z88VjQMA5L+xSlv7BmWNMczjyhxTGv JNFg3jgo6FC6ILzwV2uGXD1SkYoKA05FCTu029t7gZXbmP66UX1DDmGHxLt3EkU4l5kW +ebw== X-Gm-Message-State: AHPjjUgA21MlpY22+e8FBX5URPcTXPmHPvvehz7fay58fuCvcnwLV8ic E7LfTX10zUbIQbTc X-Google-Smtp-Source: ADKCNb4MvbTTeNPHUzxuuBjExtqjpRlXhb45x/xzT+BRKp3ViHHlmv3ZFnmFv7/2popM4LghmhsD0A== X-Received: by 10.84.217.10 with SMTP id o10mr99406pli.75.1504221789622; Thu, 31 Aug 2017 16:23:09 -0700 (PDT) Received: from ?IPv6:2406:e007:5c9e:1:28cc:dc4c:9703:6781? ([2406:e007:5c9e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p13sm946817pgs.9.2017.08.31.16.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 16:23:08 -0700 (PDT) To: David Farmer Cc: "v6ops@ietf.org" References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 1 Sep 2017 11:23:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 23:23:12 -0000 On 31/08/2017 20:13, David Farmer wrote: > On Aug 30, 2017, at 19:11, Lorenzo Colitti wrote: > > On Thu, Aug 31, 2017 at 8:16 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> If there are any multicast RA/PIOs for these prefixes, they should have >> A=0; L=0 (cf RFC8028). >> >> But I'm not sure why there would be any multicast RAs. They don't >> seem to be needed. The draft talks about unicast RAs. >> > > Unicast RAs would require the router to keep state on all its clients > regardless of its IP addresses and across IP address changes. That doesn't > scale. It's much better for the router to send a multicast RA on each > separate L2 link, knowing that it will go only to the host on that link > that has that prefix. Nevertheless, (a) the draft says unicast. (b) hypothetically there *is* no separate L2 link for multicast; there is just a logical separation for unicast purposes. That seems to be what Ole described. Brian