From nobody Sat Jun 1 03:06:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E7D120254 for ; Sat, 1 Jun 2019 03:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 OvtBhnZqnG-P for ; Sat, 1 Jun 2019 03:06:05 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id E7FC6120247 for ; Sat, 1 Jun 2019 03:06:04 -0700 (PDT) Received: from [192.168.1.7] (ppp-2-86-144-160.home.otenet.gr [2.86.144.160]) by calypso.otenet.gr (ESMTP) with ESMTPA id 857FA13803D; Sat, 1 Jun 2019 13:06:00 +0300 (EEST) To: =?UTF-8?Q?G=c3=a1bor_Lencse?= , v6ops@ietf.org References: <77004251-b478-696d-8e7b-a1f460a88c9e@hit.bme.hu> From: Yannis Nikolopoulos Message-ID: <40b2e0c7-84b6-bd9b-45ba-08dafd14d7b7@otenet.gr> Date: Sat, 1 Jun 2019 13:06:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <77004251-b478-696d-8e7b-a1f460a88c9e@hit.bme.hu> Content-Type: multipart/alternative; boundary="------------CCBC47C84DC85F7698D92ABE" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 10:06:07 -0000 This is a multi-part message in MIME format. --------------CCBC47C84DC85F7698D92ABE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello, I'll just re-iterate what I thought about this in the past. I do find it useful in principle, but it does not yet feel like a comparison document that operators can use as reference. Having said that, I do support its adoption and would like to see a new version regards, Yannis On 5/3/19 12:26 PM, Gábor Lencse wrote: > > Dear v6ops Members, > > Yes, as Fread wrote, we would like our draft be adopted by the WG. > > IMHO, RFC 6180 covers a much wider topic than our I-D, thus I > recommend that our I-D should only update it (and not obsolete it). > > It seemed to me from the minutes ( > https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html > ) that several people considered our draft useful. > > Please, react now: Do you consider it useful and support its adoption > as a WG item? > > What do you think is missing from it? Which direction should we go? > > Are there any questionable statements? Anything, which is biased? > > Best regards, > > Gábor > > > On 4/30/2019 11:03, Fred Baker wrote: >> At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180. >> >>> On Apr 29, 2019, at 10:32 AM, Ron Bonica wrote: >>> >>> Folks, >>> >>> Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it. >>> >>> This week, please review and comment on draft-lmhp-v6ops-transition-comparison. >>> >>> Fred and Ron >>> >>> Non-Juniper >>> >>> _______________________________________________ >>> 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 --------------CCBC47C84DC85F7698D92ABE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello,

I'll just re-iterate what I thought about this in the past. I do find it useful in principle, but it does not yet feel like a comparison document that operators can use as reference. Having said that, I do support its adoption and would like to see a new version

regards,
Yannis

On 5/3/19 12:26 PM, Gábor Lencse wrote:

Dear v6ops Members,

Yes, as Fread wrote, we would like our draft be adopted by the WG.

IMHO, RFC 6180 covers a much wider topic than our I-D, thus I recommend that our I-D should only update it (and not obsolete it).

It seemed to me from the minutes ( https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html ) that several people considered our draft useful.

Please, react now: Do you consider it useful and support its adoption as a WG item?

What do you think is missing from it? Which direction should we go?

Are there any questionable statements? Anything, which is biased?

Best regards,

Gábor


On 4/30/2019 11:03, Fred Baker wrote:
At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180.


On Apr 29, 2019, at 10:32 AM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:

Folks,

Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-lmhp-v6ops-transition-comparison.

                                                            Fred and Ron

Non-Juniper

_______________________________________________
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

--------------CCBC47C84DC85F7698D92ABE-- From nobody Sat Jun 1 04:24:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8A12026B for ; Sat, 1 Jun 2019 04:24: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, HTML_MESSAGE=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 JUGVA4bM75sd for ; Sat, 1 Jun 2019 04:24:43 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7417E1200F7 for ; Sat, 1 Jun 2019 04:24:43 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x51BOTgj020966 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 1 Jun 2019 13:24:37 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: Yannis Nikolopoulos , v6ops@ietf.org References: <77004251-b478-696d-8e7b-a1f460a88c9e@hit.bme.hu> <40b2e0c7-84b6-bd9b-45ba-08dafd14d7b7@otenet.gr> From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: <9727945d-808c-f1ac-2594-a52142eb3c9e@hit.bme.hu> Date: Sat, 1 Jun 2019 20:24:28 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <40b2e0c7-84b6-bd9b-45ba-08dafd14d7b7@otenet.gr> Content-Type: multipart/alternative; boundary="------------38B1C2101C1B808DA5F5D4E0" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 11:24:46 -0000 This is a multi-part message in MIME format. --------------38B1C2101C1B808DA5F5D4E0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Yannis, Thank you very much for your support and comments. Could you please elaborate, what you miss from the document? Best regards, Gábor On 6/1/2019 19:06, Yannis Nikolopoulos wrote: > Hello, > > I'll just re-iterate what I thought about this in the past. I do find > it useful in principle, but it does not yet feel like a comparison > document that operators can use as reference. Having said that, I do > support its adoption and would like to see a new version > > regards, > Yannis > > On 5/3/19 12:26 PM, Gábor Lencse wrote: >> >> Dear v6ops Members, >> >> Yes, as Fread wrote, we would like our draft be adopted by the WG. >> >> IMHO, RFC 6180 covers a much wider topic than our I-D, thus I >> recommend that our I-D should only update it (and not obsolete it). >> >> It seemed to me from the minutes ( >> https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html >> ) that several people considered our draft useful. >> >> Please, react now: Do you consider it useful and support its adoption >> as a WG item? >> >> What do you think is missing from it? Which direction should we go? >> >> Are there any questionable statements? Anything, which is biased? >> >> Best regards, >> >> Gábor >> >> >> On 4/30/2019 11:03, Fred Baker wrote: >>> At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180. >>> >>>> On Apr 29, 2019, at 10:32 AM, Ron Bonica wrote: >>>> >>>> Folks, >>>> >>>> Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it. >>>> >>>> This week, please review and comment on draft-lmhp-v6ops-transition-comparison. >>>> >>>> Fred and Ron >>>> >>>> Non-Juniper >>>> >>>> _______________________________________________ >>>> 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 > --------------38B1C2101C1B808DA5F5D4E0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dear Yannis,

Thank you very much for your support and comments.

Could you please elaborate, what you miss from the document?

Best regards,

Gábor

On 6/1/2019 19:06, Yannis Nikolopoulos wrote:
Hello,

I'll just re-iterate what I thought about this in the past. I do find it useful in principle, but it does not yet feel like a comparison document that operators can use as reference. Having said that, I do support its adoption and would like to see a new version

regards,
Yannis

On 5/3/19 12:26 PM, Gábor Lencse wrote:

Dear v6ops Members,

Yes, as Fread wrote, we would like our draft be adopted by the WG.

IMHO, RFC 6180 covers a much wider topic than our I-D, thus I recommend that our I-D should only update it (and not obsolete it).

It seemed to me from the minutes ( https://tools.ietf.org/wg/v6ops/minutes?item=minutes-104-v6ops-00.html ) that several people considered our draft useful.

Please, react now: Do you consider it useful and support its adoption as a WG item?

What do you think is missing from it? Which direction should we go?

Are there any questionable statements? Anything, which is biased?

Best regards,

Gábor


On 4/30/2019 11:03, Fred Baker wrote:
At least part of the question is that the authors would like this to be a working group draft. I'm interested to know what the working group thinks of it. It started out as an essentially academic paper, and would update or obsolete RFC 6180.


On Apr 29, 2019, at 10:32 AM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:

Folks,

Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-lmhp-v6ops-transition-comparison.

                                                            Fred and Ron

Non-Juniper

_______________________________________________
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

--------------38B1C2101C1B808DA5F5D4E0-- From nobody Fri Jun 7 07:00:27 2019 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 6ECC61200E3; Fri, 7 Jun 2019 07:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ron Bonica via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson , swmike@swm.pp.se Message-ID: <155991602544.19838.4204803875721901229.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2019 07:00:25 -0700 Archived-At: Subject: [v6ops] Publication has been requested for draft-ietf-v6ops-nat64-deployment-06 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 14:00:26 -0000 Ron Bonica has requested publication of draft-ietf-v6ops-nat64-deployment-06 as Informational on behalf of the V6OPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ From nobody Wed Jun 12 11:23:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F321200B9; Wed, 12 Jun 2019 11:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7gsux1I7Mpq; Wed, 12 Jun 2019 11:22:33 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670128.outbound.protection.outlook.com [40.107.67.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D72112008D; Wed, 12 Jun 2019 11:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQoDSFWY8Ii6TC7ui8xsBVIdjALbRinPMd+PKOiMJy8=; b=yZs7Efu9/nzBKbwz2/LMSGowLJopgSWoglQQPnYGNWAYx08VmzXKHN6pHDnm8h7Cd/xlh/5UpIVGaa61zphUXu1RrNr35mEPEvrSeiKYaFt0lzhCxEYRowH1apkcn9H/uDJTHDtAasiZuZyYd3keiNJov7F8byXHPc9jioOcAOU= Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.45.144) by YTOPR0101MB1419.CANPRD01.PROD.OUTLOOK.COM (52.132.49.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Wed, 12 Jun 2019 18:22:31 +0000 Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::e11f:e72a:8da2:ea29]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::e11f:e72a:8da2:ea29%7]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 18:22:31 +0000 From: Suresh Krishnan To: int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AQHVIUvM9WEXtmDvEkCRovcCdcQgcA== Date: Wed, 12 Jun 2019 18:22:30 +0000 Message-ID: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> 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=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34230df7-8b4e-4d2c-ca09-08d6ef62eec1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTOPR0101MB1419; x-ms-traffictypediagnostic: YTOPR0101MB1419: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39850400004)(396003)(376002)(346002)(189003)(199004)(53754006)(80792005)(2501003)(72206003)(316002)(508600001)(8936002)(450100002)(68736007)(102836004)(81166006)(6506007)(966005)(8676002)(81156014)(14454004)(606006)(476003)(2201001)(3846002)(86362001)(6116002)(66066001)(2906002)(256004)(5660300002)(4744005)(486006)(71190400001)(71200400001)(36756003)(33656002)(7736002)(66946007)(76116006)(91956017)(66556008)(66476007)(73956011)(6306002)(54896002)(6512007)(2616005)(25786009)(66446008)(64756008)(99286004)(53936002)(236005)(110136005)(186003)(6486002)(6436002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1419; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uTKHcp+QsS73Cd55U1EwW1MBxrUfCrImqjHs1KoBv56tUUNtfq4nynjDTWPa5Am5ulF+zDc/0oVazaZAUnGTYoMe9hbW5D9aH+K2bxxYGPm86NBzDaRfKd8Fb402A0s84LOrLCTmfcUY6GUtu1abXgcQbl71eRQYdr+7PvJeE9IvwZOjX2hIY1JclF5fXocFu/PC4iHdiB8sdITDHkmyU4EqUjEeMln/bWlPpfthaw/448x1vzKvS7SAW2gYvj8EfUDdVGJEKXitQP0oROEf/dWaFXaFOUtDOnrIRG/bgznO1rlx4X68I6IWGX8qZVl3057nsKeEUwI0AG4QeG0bE+qRU3ERNeVwrJy218KYFM2y29C0SzBPfFKD2IYtvM+1YSCiIntwUm7KbQ9NKWdSCEBJnlCtL3K2RyE8gvZgwXM= Content-Type: multipart/alternative; boundary="_000_75825363B4BA4F94A935B87F474F06C9kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34230df7-8b4e-4d2c-ca09-08d6ef62eec1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 18:22:30.9865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Suresh@kaloom.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1419 Archived-At: Subject: [v6ops] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 18:22:37 -0000 --_000_75825363B4BA4F94A935B87F474F06C9kaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to AD sponsor the following draft that provides guidelines f= or definition of new interface types in the IANA IfType registries https://tools.ietf.org/html/draft-thaler-iftype-reg-02 If you have any concerns either with the contents of the draft, or about me= AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potential= ly interested in this work. If you think I have missed out some WG(s) please l= et me know. --_000_75825363B4BA4F94A935B87F474F06C9kaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <494ADFAEEE1CBD4C8CB36ACC8DD09892@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable
Hi all,
  I would like to AD sponsor the following draft that provides gu= idelines for definition of new interface types in the IANA IfType= registries

https://tools.ietf.org/html/draft-thaler-iftype-reg-02

If you have any concerns either with the contents of the dr= aft, or about me AD sponsoring it please let me know before 2019/06/26.
Thanks
Suresh

NOTE: I have CCed: all the working groups that I thought could be potential= ly
interested in this work. If you think I have missed out some WG(s) please l= et
me know.
--_000_75825363B4BA4F94A935B87F474F06C9kaloomcom_-- From nobody Wed Jun 12 11:49:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0FB120144 for ; Wed, 12 Jun 2019 11:49:45 -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_HELO_NONE=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 FHNc75IabAX9 for ; Wed, 12 Jun 2019 11:49:43 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7876612016D for ; Wed, 12 Jun 2019 11:49:30 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id j19so16481938otq.2 for ; Wed, 12 Jun 2019 11:49: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:message-id :references:to; bh=4SfsNyNer6bX4ddnnIE3PXMYO02LiWEZj65M452CJW4=; b=TVClyw4LY4WRMr1+j/RWY0MV566NYqhFqF1KYO0h+hVQJHTZdOIUGY0ND+5FDk3mTF nY3tamoyQDx7odZl4Yi0vfrTNdx57ARC0mwxF8BjMVTWnwnetqd4aRFlUN2NwSLXy8Ps eD+dUlPMd/0IpVIvHEl8w4alUPX7WvoBvWwxqs6QyBUHagvY9BuGollP6yXGN9htRFof LVpULvFRL2Bf3ZW7m1orzlJTeoe73vsW9GjeRv7R4xIu5mnYdZOujKs6Oamt+zQwvEBd +cH8OoOFJRHQfa9k/EO1DBHlP/x/YMcJ4/MHchgpmSDhNFIHOHqxXcYTg/w9mJ9tuBYU eObQ== 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:message-id:references:to; bh=4SfsNyNer6bX4ddnnIE3PXMYO02LiWEZj65M452CJW4=; b=tC5i3kWMUWm2M2z9KlM5yEvktGG0YHHKFUcFfCJJ/bHlgU0UPOF1l1VEWQivWzi1xg et9E0MMmk73/RJaMp1WKzd2C3NMyLuLryHNOcE2gvVDRm/FcV8jSuzhioK3rTexRcudl 7YT/V5/4//+sjutXyOG+pyFBBTe7dBDG8Lk1Vdz9vQpiI24v4qLPXftD1Bj4fDpPM/or cpvH90uqlP6O7m6zlGenv3NzJqi6+9wmZtHaVeZIphWb08tf72KYyhZHhGohgIjRLozN +lI66KWiIAtc9ckZ9n57WiEBeZqCYZWDYqK8Q5zB+evg9QTJsE1Hp9ntyyjbFJOQPhD9 iOKg== X-Gm-Message-State: APjAAAXqJyYEcVLLww42iYmnlKXkIadhq6IDhhBqz3uC0WygiSDomqXd +DSFTjGBa55XNu83Se1VJdDLIu1/ X-Google-Smtp-Source: APXvYqySruGOEFnCFOK+K74ZFUT1Rh4FLLBXAnI1ve2mWTgYo3q9GFP47UovC3g5anLzSDYfHRVHlA== X-Received: by 2002:a9d:2941:: with SMTP id d59mr14519991otb.8.1560365369623; Wed, 12 Jun 2019 11:49:29 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1004? ([2600:8802:5903:df16::1004]) by smtp.gmail.com with ESMTPSA id y4sm146194oiy.56.2019.06.12.11.49.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jun 2019 11:49:28 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-31902B6B-1499-42AE-A274-BC86A890126C Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 12 Jun 2019 11:49:27 -0700 Message-Id: <74544186-D139-4D4A-BFBD-1A7D19530FB0@gmail.com> References: <57c5e476-b013-0199-5036-e7c8bcaddf5e@nostrum.com> To: v6ops@ietf.org X-Mailer: iPhone Mail (16G5038d) Archived-At: Subject: [v6ops] Fwd: Datatracker outage : Sunday Jun 16 at 1600 UTC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 18:49:46 -0000 --Apple-Mail-31902B6B-1499-42AE-A274-BC86A890126C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable FYI... Sent using a machine that autocorrects in interesting ways... Begin forwarded message: > From: Robert Sparks > Date: June 12, 2019 at 11:33:28 AM PDT > To: "wgchairs@ietf.org" > Subject: Fwd: Datatracker outage : Sunday Jun 16 at 1600 UTC >=20 > Chairs please take note. (And feel free to forward). >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: Datatracker outage : Sunday Jun 16 at 1600 UTC > Date: Wed, 12 Jun 2019 13:27:13 -0500 > From: Robert Sparks > Reply-To: ietf@ietf.org > To: ietf-announce@ietf.org >=20 >=20 > The datatracker will be offline for approximately three hours starting at 1= 600 UTC on Sunday Jun 16. >=20 > We will be installing a release that significantly changes the database st= ructure for Document and DocAlias objects. This will allow us to correctly r= epresent BCPs and will generally improve datatracker response time. The chan= ge requires a set of database migrations that we expect to take 2 to 3 hours= . >=20 > This is an unusual event, and we don't expect more like it in the foreseea= ble future. >=20 > Thank you for your patience, and apologies for any inconvenience this caus= es. >=20 > RjS >=20 --Apple-Mail-31902B6B-1499-42AE-A274-BC86A890126C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit FYI...

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

Begin forwarded message:

From: Robert Sparks <rjsparks@nostrum.com>
Date: June 12, 2019 at 11:33:28 AM PDT
To: "wgchairs@ietf.org" <wgchairs@ietf.org>
Subject: Fwd: Datatracker outage : Sunday Jun 16 at 1600 UTC

Chairs please take note. (And feel free to forward).



-------- Forwarded Message --------
Subject: Datatracker outage : Sunday Jun 16 at 1600 UTC
Date: Wed, 12 Jun 2019 13:27:13 -0500
From: Robert Sparks <rjsparks@nostrum.com>
Reply-To: ietf@ietf.org
To: ietf-announce@ietf.org


The datatracker will be offline for approximately three hours starting at 1600 UTC on Sunday Jun 16.

We will be installing a release that significantly changes the database structure for Document and DocAlias objects. This will allow us to correctly represent BCPs and will generally improve datatracker response time. The change requires a set of database migrations that we expect to take 2 to 3 hours.

This is an unusual event, and we don't expect more like it in the foreseeable future.

Thank you for your patience, and apologies for any inconvenience this causes.

RjS

--Apple-Mail-31902B6B-1499-42AE-A274-BC86A890126C-- From nobody Thu Jun 13 06:46:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D981202B6; Thu, 13 Jun 2019 06:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jDQ2rsKjRyPC; Thu, 13 Jun 2019 06:45:56 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A401201DB; Thu, 13 Jun 2019 06:45:55 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 45PlPY6c6cz8wTY; Thu, 13 Jun 2019 15:45:53 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45PlPY4mBWz3wcF; Thu, 13 Jun 2019 15:45:53 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([fe80::bcfe:4850:e646:f223%21]) with mapi id 14.03.0439.000; Thu, 13 Jun 2019 15:45:53 +0200 From: To: Suresh Krishnan , int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AQHVIUvM9WEXtmDvEkCRovcCdcQgcKaZmBOg Date: Thu, 13 Jun 2019 13:45:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA62A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> In-Reply-To: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EAA62A9OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 13:45:58 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EAA62A9OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suresh, all, I fully support this effort. I hope the authors can address two comments we received as part of draft-ie= tf-softwire-iftunnel that I do think belong to this I-D: * Add a clear mention under https://www.iana.org/assignments/smi-numbers/sm= i-numbers.xhtml#smi-numbers-6 to indicate this is about "tunnelType Registr= y". * Add some text to encourage UDP-based tunnel protocol designers to registe= r their own code instead of reusing the one currently assigned to generic U= DP encap (8). Thank you. Cheers, Med De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krish= nan Envoy=E9 : mercredi 12 juin 2019 20:23 =C0 : int-area; 6man; dhcwg; V6 Ops List; opsawg@ietf.org; softwires@ietf.o= rg Objet : [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Hi all, I would like to AD sponsor the following draft that provides guidelines f= or definition of new interface types in the IANA IfType registries https://tools.ietf.org/html/draft-thaler-iftype-reg-02 If you have any concerns either with the contents of the draft, or about me= AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potential= ly interested in this work. If you think I have missed out some WG(s) please l= et me know. --_000_787AE7BB302AE849A7480A190F8B93302EAA62A9OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Suresh, all,

 

I fully support this effort.&nb= sp;

 

I hope the authors can address = two comments we received as part of draft-ietf-softwire-iftunnel that I do = think belong to this I-D:

* Add a clear mention under = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 6 to indicate this is about "tunnelType Registry".

* Add some text to encourage= UDP-based tunnel protocol designers to register their own code instead of = reusing the one currently assigned to generic UDP encap (8).

 

Thank you.

 

Cheers,

Med

 

De : Int-= area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan
Envoy=E9 : mercredi 12 juin 2019 20:23
=C0 : int-area; 6man; dhcwg; V6 Ops List; opsawg@ietf.org; soft= wires@ietf.org
Objet : [Int-area] AD sponsoring draft-thaler-iftype-reg-02

 

Hi all,
  I would like to AD sponsor the following draft that provides gu= idelines for definition of new interface types in the IANA IfType= registries

https://= tools.ietf.org/html/draft-thaler-iftype-reg-02

 

If you have any concerns either with the contents of= the draft, or about me AD sponsoring it please let me know before 2019/06/= 26.


Thanks
Suresh

NOTE: I have CCed: all the working groups that I thought could be potential= ly
interested in this work. If you think I have missed out some WG(s) please l= et
me know.

--_000_787AE7BB302AE849A7480A190F8B93302EAA62A9OPEXCAUBMA2corp_-- From nobody Fri Jun 14 09:28:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B671205D4; Fri, 14 Jun 2019 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, 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 (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iipsQEcM10dc; Fri, 14 Jun 2019 09:28:19 -0700 (PDT) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90139.outbound.protection.outlook.com [40.107.9.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CB31205D2; Fri, 14 Jun 2019 09:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gZNuJkIRG/kCDStcfGsStHNwg0ftbG7ZbaYFePPkpaI=; b=VPbOfYueA3jmjPaTsZa32i9INArgVwm5y5mRor7nVd4hAes2HdYyRXCd2VvO6oDdp7CdGPxW6ttqVCXpx5/3S4u7w//7RDb1h8yJTMQp6WZG7K47LalV6h/p205LZBTAScn8ap+0zQ5OpJP410m7pYlUQQ7JDADWOZ5XqvL+hcA= Received: from PR1PR07MB5868.eurprd07.prod.outlook.com (20.177.211.152) by PR1PR07MB4874.eurprd07.prod.outlook.com (20.177.211.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.5; Fri, 14 Jun 2019 16:28:15 +0000 Received: from PR1PR07MB5868.eurprd07.prod.outlook.com ([fe80::e06b:a40d:a4a3:fd78]) by PR1PR07MB5868.eurprd07.prod.outlook.com ([fe80::e06b:a40d:a4a3:fd78%7]) with mapi id 15.20.1987.010; Fri, 14 Jun 2019 16:28:14 +0000 From: tom petch To: Suresh Krishnan , int-area , 6man , dhcwg , V6 Ops List , "opsawg@ietf.org" , "softwires@ietf.org" Thread-Topic: [Int-area] AD sponsoring draft-thaler-iftype-reg-02 Thread-Index: AQHVIs4qTBv2QWTgtEuQvGI24hA49A== Date: Fri, 14 Jun 2019 16:28:14 +0000 Message-ID: <019801d522ce$34bff3a0$4001a8c0@gateway.2wire.net> References: <75825363-B4BA-4F94-A935-B87F474F06C9@kaloom.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0030.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::18) To PR1PR07MB5868.eurprd07.prod.outlook.com (2603:10a6:102:e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00a4a854-6312-483a-a710-08d6f0e54c4c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:PR1PR07MB4874; x-ms-traffictypediagnostic: PR1PR07MB4874: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0068C7E410 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(189003)(45074003)(54094003)(43544003)(51444003)(13464003)(199004)(53754006)(44716002)(66066001)(81816011)(71200400001)(316002)(62236002)(6246003)(71190400001)(386003)(81686011)(84392002)(81156014)(81166006)(76176011)(53936002)(14454004)(6506007)(7736002)(64756008)(50226002)(8676002)(5660300002)(305945005)(66946007)(102836004)(26005)(186003)(966005)(2906002)(8936002)(66556008)(99286004)(2501003)(4720700003)(66476007)(86362001)(66446008)(256004)(2201001)(52116002)(68736007)(25786009)(6486002)(6512007)(9686003)(6306002)(478600001)(6436002)(44736005)(110136005)(3846002)(486006)(446003)(73956011)(14496001)(476003)(229853002)(6116002)(61296003)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB4874; H:PR1PR07MB5868.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Wm8OkUn3/Ns/FAJYFl2JCdfzPMS+GYhh5KgmpwmN+Rrsioz1NHrw45TgYq/s8vmNvg7LRfqaNcPpW+Hsq1JXWz2WMMjEp1G9vayYIVtuyocH2SNeaKSgOOPiNgU9fBhjdkwANb3kVyRWq6B229xet900OV4bxtcLKTzNtAaC7hUcOv7DNOONB4WPafnQAiXxPkWII2zTWDr09I4fUqRdvWaKluqUPIfURcNlWDNdTjd1PI0gwDwqy6q1UxnkIxF15yzurjkKIpgEHsNP+KqUuICKRcLstjn7CzdzpoRAZKdNNnhrWzlSFq5sO+lwOzI4C7IIhrQ2qzMpa5O1GhtT2Y1t4Y9gsBRZH0ZfYZPhQvEgIgnPYk44QtizwF7PFaPZzdJrJAJAyI7A6yVX1oO2XjLQMMpvbUq6onj2aspeTn8= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8D88A68E9157D94C9E64E30A0CBA11CE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00a4a854-6312-483a-a710-08d6f0e54c4c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 16:28:14.8696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ietfc@btconnect.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4874 Archived-At: Subject: Re: [v6ops] [Int-area] AD sponsoring draft-thaler-iftype-reg-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 16:28:22 -0000 Suresh The concern I have is that it muddies the waters further on the standing of tunnels so while I think that its proposals for ifType per se are fine, I would like it to make explicit that tunnels are out-of-scope at this time. I have been trying to reconcile the workings of softwire, in creating a tunnel YANG module, with the existing IANA structure and failing. I believe that is because the current status of tunnels is unclear. Thus the softwire I-D refers to a registry that does not exist (as such) although the URL that the softwire I-D does. I think the timing unfortunate in that IMHO the softwires I-D will get pressed ahead before this work can complete, so quite what this I-D then says about tunnels will be coloured by what then exists for tunnels. So this I-D should make clear what a tunnel is, when it is not an interface, but otherwise declaring tunnels out-of-scope, for a future I-D to do a comparable job for tunnels, setting up a tunnel registry from which MIB modules, YANG modules and anything else can be derived (as long as the relevant data is supplied - SMI needs integers, YANG does not, which I-Ds do not always recognise although the Designated Experts can take care of that). Finally, when I first encountered this I-D I asked on NETCONF and NETMOD WG lists if anyone knew of it, where it was being worked on and got no reply - which surprised me. I note that you have not copied them although they were involved in making the interface type registry what it currently is when creating the YANG module for interface types. I wonder if other WG have an interest, CCAMP or TEAS perhaps. I agree that int-area is the WG best equipped to work on it and that it needs working on. Tom Petch ----- Original Message ----- From: "Suresh Krishnan" To: "int-area" ; "6man" ; "dhcwg" ; "V6 Ops List" ; ; Sent: Wednesday, June 12, 2019 7:22 PM Hi all, I would like to AD sponsor the following draft that provides guidelines for definition of new interface types in the IANA IfType registries https://tools.ietf.org/html/draft-thaler-iftype-reg-02 If you have any concerns either with the contents of the draft, or about me AD sponsoring it please let me know before 2019/06/26. Thanks Suresh NOTE: I have CCed: all the working groups that I thought could be potentially interested in this work. If you think I have missed out some WG(s) please let me know. ------------------------------------------------------------------------ -------- > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Fri Jun 14 13:24:22 2019 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 DBDBC1201C3; Fri, 14 Jun 2019 13:24:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.97.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: v6ops@ietf.org, v6ops-chairs@ietf.org, Mikael Abrahamsson , draft-ietf-v6ops-nat64-deployment@ietf.org, warren@kumari.net, swmike@swm.pp.se Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156054385480.28313.10761099558155500775.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2019 13:24:14 -0700 Archived-At: Subject: [v6ops] Last Call: (Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 20:24:15 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-06-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 20 16:41:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338441200C5 for ; Thu, 20 Jun 2019 16:41:14 -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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtWcRTYAVUgk for ; Thu, 20 Jun 2019 16:41:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0B712004D for ; Thu, 20 Jun 2019 16:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1561074068; x=1561678868; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=uuNADjET FJtklGe+XBw7oEq7Yfm1qB7/cQBjSNLDSHQ=; b=QU19mYvluh4KSBOiNGv6lIda QyBlkP0vBVypCrv/rSCEhzXJFQR/C3V+7EywkS5FJh2Bdz18tI0V0rkHdb8Zkzz4 s7u7DXZ/KS1k+85kFfdiNqtcZD3fjToU0S603P1yE4hfjo6H0PCaRgHK15cA7+1Y EWM+vbwFKvsGdphDlr4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 21 Jun 2019 01:41:08 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 21 Jun 2019 01:41:08 +0200 Received: from [172.20.1.33] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006300502.msg for ; Fri, 21 Jun 2019 01:41:08 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [172.20.1.33] X-MDArrival-Date: Fri, 21 Jun 2019 01:41:08 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1074da1757=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Fri, 21 Jun 2019 02:40:59 +0300 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <0DA04196-DD42-4574-981B-5A69B4214858@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> In-Reply-To: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 23:41:14 -0000 Hi all, We just published a new version of this document, which we believe has reso= lved all the issues and inputs received in the last meeting in Prague, and = some new additional considerations. https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/ Please provide your inputs! Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 21/6/19 2:38, "internet-drafts@ietf.org" escribi=C3=B3: =20 A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-464xlat-opt-cdn-caches Revision: 02 Title: 464XLAT Optimization Document date: 2019-06-20 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= 464xlat-opt-cdn-caches-02.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-464x= lat-opt-cdn-caches/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xlat-o= pt-cdn-caches-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -464xlat-opt-cdn-caches Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-4= 64xlat-opt-cdn-caches-02 =20 Abstract: This document proposes possible solutions to avoid certain drawbacks of IP/ICMP Translation Algorithm (SIIT) when the destinations are available with IPv6. When SIIT is used as a NAT46 and IPv4-only devices or applications initiate traffic flows to dual-stack CDNs (Content Delivery Networks), Caches or other network resources (in the operator network or Internet), those flows will be translated back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T. =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.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Jun 22 21:10:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBDA1200C5 for ; Sat, 22 Jun 2019 21:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=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 X0l6ga7zHzHq for ; Sat, 22 Jun 2019 21:10:49 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE3A12004D for ; Sat, 22 Jun 2019 21:10:49 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id f9so10228952wre.12 for ; Sat, 22 Jun 2019 21:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=3WAAUxAE2JvnMrn6wgLeYxRtswO8a2M8qmOM6nOVm30=; b=rhdh/kL/6bUxGIXyGxmLH3sxyEOeW80dXjcTwHgLJCs/n82lTvT9GGxcPZDZbkq5Tn Ag9xtjPKLO8PA5kP20oSpoNqohnJc8xmeEIGbnXDADJX170JlAfGxVCrYwJUQ8JdNzje fRTObcGbQI12LLGBVSygklmW9rjfChPzr3xmt1yEcY/e3H9lC50dNmxytsG7nCQyGuBI oQRL7EQSdG2eeB54VkB6DWaON9Au4WQAwNLstyxqz8Ka+7uWQaqVMSn8wx3Y+XWEUpld ZP2lphdm6Tce1s9ZmfXyBiYUUgnior/IyFVnw33pv2z+KGkpTdfjYTqJ5GG3gKzbNzEu imDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=3WAAUxAE2JvnMrn6wgLeYxRtswO8a2M8qmOM6nOVm30=; b=qlCYIZKwPzLVI10U1LDMaEGckyT8384OYaUZ+/nrWtdwodmJuE0Njryhzd/AzVhoDn WDA9Yav3gGPUvETwFw200FHyLM71KTCyWqfRbha9oIkNne8oP5jsIuWBA92y4ZszAig1 o9Q8aEwnV+R8aIHDkUbhpcHCisMNk5tPcp134foQdPVRRsGv8XDjquC1bVwFHWJa+8TH 2MNbEk1b/kAtxZ5+9vA8w9mv0GVdudQDUEaY8xixreqhD4GXzPv05GkrxBCt5lpnX82G PT8+YsLI6QTYzYxE/9zjd0KI0TPnVqpE3aoA7fnyI0MiWB63R9mCIYtwrOP3JImfUp+y IUuQ== X-Gm-Message-State: APjAAAU8YrcwNeTpTRTrFRG/UqQcAt+KWFOQzUH/zYkMxyJFFyIwPSO2 Rp+hdviHkHF9wYJoCib9h4035QxySIc= X-Google-Smtp-Source: APXvYqwo8w4jgJ77WYdt+5F5WOAHy9XcuJ7HFWC6F9JRO8at6941sLBV3994hC+SCOTmO1FQR14qBg== X-Received: by 2002:adf:f542:: with SMTP id j2mr40784245wrp.16.1561263047368; Sat, 22 Jun 2019 21:10:47 -0700 (PDT) Received: from [172.20.3.252] ([88.255.11.35]) by smtp.gmail.com with ESMTPSA id i188sm8705470wma.27.2019.06.22.21.10.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 21:10:46 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_B73FDF89-8DCB-4654-B995-EFE1C2DC1EC3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <41FF6749-A4DE-405C-B6B2-8C69123373B0@gmail.com> Date: Sun, 23 Jun 2019 07:10:33 +0300 To: IPv6 Operations X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 04:10:50 -0000 --Apple-Mail=_B73FDF89-8DCB-4654-B995-EFE1C2DC1EC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IPv6 Operations is planned to meet on Monday afternoon at IETF 105. We = schedule drafts on our agenda that have been posted since the past IETF = (in this case, IETF 104) and have supportive commentary on the mailing = list. If you want agenda time, now would be the time to post drafts; = slipping them in under the wire doesn't give people a chance to read and = comment on them. So, file your draft, and drop a note the list requesting requesting = discussion. --Apple-Mail=_B73FDF89-8DCB-4654-B995-EFE1C2DC1EC3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0O+7kACgkQEhdRnd2G P+DwFxAAkUN9r9eHeZlYH+OnRGhT1/sYOyvsdRez9c5/oloVrqqbWauulyJc4khr KMC6JV1Ej/obPPoR9QAmTboQtcleZYQug2bp2Avmmq660gXxAPreUJbJI3jN6i9s br4dlarHFnQY/Av5BJyS8b8DJo5WQY2IrJkofBh8BCngcN28phgWsmWZhskzQivE c3iVqFAaVgXzyCzRPVxSXJRQutgZItVDwTb5OgLZB2vkoOXxO0OwDKWBGOmxAzFu Xq5FdWsuR5DBBQzpdJ0fbEiyAMpWK3Tzubz1EJyOBHkRvO0IucQTi3ztALrrXXMS x5HSkGV3pK5veI07Rp2ukw5rXl1VaeKa3RdgK6ufziTtG8VUqnyY3KYrqP748TBU J53z2pQh8Q5N7WikPfjSXf2KP19u2w0gOYKer8dPWx2o07adV0Mh1mchWd2rQjRc eyTrff/bMLRrUhXpyVdAHz0iIP7Nk70phc2DowZ/GnyTrHJbChbj0aknM/aY9t71 3D95+u9u0nxivxQsB+tfHQzZdonpywWMEiiDmW6aBem3O/2G5Pd26w6oTeFs7wZO nOwmuogwJEgTpD0zM/L8LyLBbJMbnfZQ+YmdnB6ZTqPaPxUVwFscP+IyIFjeqsRm Y6RQLL9xfLgQUOGSDMI2zXjYmAyo4kIn5w4+sjMBJotzIZT9dxU= =VTKk -----END PGP SIGNATURE----- --Apple-Mail=_B73FDF89-8DCB-4654-B995-EFE1C2DC1EC3-- From nobody Sun Jun 23 01:44:38 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32A1200C5 for ; Sun, 23 Jun 2019 01:44:37 -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, SPF_HELO_NONE=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=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 X4ohEweQP2za for ; Sun, 23 Jun 2019 01:44:35 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7928120025 for ; Sun, 23 Jun 2019 01:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1561279471; x=1561884271; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=QEUYgwEK KvNmZ3VZjcaxQX96ItcBoq4r/PWviP4dn24=; b=nNyVXJNeVsdVGM8dsSGdm0SS epjColK4ShOhUd2G4EOeGXBqYQ+DKvgE4TgnKfJaIX+MwlAWfavVhgCCX0fB4svQ 0QfeRWR2nNJAFNrYqIn9TFiA4GtZDv+Iz9RmYwnuz9RTJpqUD6STHUFSRisnW43S GhJnUGgpDQGXqFm6Bmw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 23 Jun 2019 10:44:31 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 23 Jun 2019 10:44:31 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006302496.msg for ; Sun, 23 Jun 2019 10:44:31 +0200 X-MDRemoteIP: 2001:470:1f09:495:905a:bac3:f25e:1b6d X-MDHelo: [10.10.10.139] X-MDArrival-Date: Sun, 23 Jun 2019 10:44:31 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10776bdf84=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Sun, 23 Jun 2019 10:44:26 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <37AD6B26-D19B-4DF2-9127-D569A18DD115@consulintel.es> Thread-Topic: [v6ops] Call for agenda items References: <41FF6749-A4DE-405C-B6B2-8C69123373B0@gmail.com> In-Reply-To: <41FF6749-A4DE-405C-B6B2-8C69123373B0@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Call for agenda items X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 08:44:37 -0000 Hi Fred, all, I will like to present https://datatracker.ietf.org/doc/draft-palet-v6ops-4= 64xlat-opt-cdn-caches/ I will love to have inputs during the next week in case, it is neccesary to= update it before the cut-off. In fact, the authors are seeking for WG adop= tion of this ID. I'm also working to update some of my outdated drafts and will like to pres= ent them, but of course, I first need to send a new version for each one, h= opefully I've sufficient time to do so during next week. =20 Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 23/6/19 6:11, "v6ops en nombre de Fred Baker" escribi=C3=B3: IPv6 Operations is planned to meet on Monday afternoon at IETF 105. We = schedule drafts on our agenda that have been posted since the past IETF (in= this case, IETF 104) and have supportive commentary on the mailing list. I= f you want agenda time, now would be the time to post drafts; slipping them= in under the wire doesn't give people a chance to read and comment on them= . =20 So, file your draft, and drop a note the list requesting requesting dis= cussion. _______________________________________________ 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.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jun 23 15:27:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BF71201A8 for ; Sun, 23 Jun 2019 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 40QnEd16BI7n for ; Sun, 23 Jun 2019 15:27:30 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.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 658B612001E for ; Sun, 23 Jun 2019 15:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 6B74818050A08 for ; Mon, 24 Jun 2019 00:27:26 +0200 (CEST) From: Martin Hunek To: v6ops@ietf.org Date: Mon, 24 Jun 2019 00:27:20 +0200 Message-ID: <1586996.8CYXve7ngK@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: <0DA04196-DD42-4574-981B-5A69B4214858@consulintel.es> References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <0DA04196-DD42-4574-981B-5A69B4214858@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3582731.LLmBlmS8lr"; micalg="sha256"; protocol="application/pkcs7-signature" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 22:27:33 -0000 --nextPart3582731.LLmBlmS8lr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jordi, hi all, Same question I asked you at IETF 104: How did you solve situation in which multiple IPv6 services would share sin= gle IPv4 to IPv6 proxy? Example: a.example.com IN A 192.0.2.1 <- This is a proxy IN AAAA 2001:db8::a <- This is a real server b.example.com IN A 192.0.2.1 IN AAAA 2001:db8::b Now if you would have for example 2 IPv4-only hosts. One device would commu= nicate with a.example.com, subsequently the second one with b.example.com. To which service would second device connect to? What about first device, w= ouldn't its connection be severed by second device asking for b.example.com? If this is not solved by draft (and I cannot see it), I think that this cou= ld lead to inaccessible services and non-predictable behavior in general. Possible solution: Maybe this could be solved by some kind of "blacklist for shared IPv4 addre= sses with different IPv6 target" thing. This situation should be detectable= if there would be EAMT record already present with different IPv6 address.= Then if CPE would ask for DNS record which created EAMT record and DNS rec= ord has not changed it should delete EAMT and blacklist that IPv4 address s= o it would not make more EAMT records for it. Apart of this, it seems like good idea, but I think that it should really b= e solved as we may see such things with shortage of IPv4 addresses. Regards, Martin Dne p=C3=A1tek 21. =C4=8Dervna 2019 1:40:59 CEST, JORDI PALET MARTINEZ naps= al(a): > Hi all, >=20 > We just published a new version of this document, which we believe has re= solved all the issues and inputs received in the last meeting in Prague, an= d some new additional considerations. >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/ >=20 > Please provide your inputs! >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 21/6/19 2:38, "internet-drafts@ietf.org" escribi=C3=B3: >=20 > =20 > A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt > has been successfully submitted by Jordi Palet Martinez and posted to= the > IETF repository. > =20 > Name: draft-palet-v6ops-464xlat-opt-cdn-caches > Revision: 02 > Title: 464XLAT Optimization > Document date: 2019-06-20 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-palet-v6op= s-464xlat-opt-cdn-caches-02.txt > Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-46= 4xlat-opt-cdn-caches/ > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464xlat= =2Dopt-cdn-caches-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6o= ps-464xlat-opt-cdn-caches > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops= =2D464xlat-opt-cdn-caches-02 > =20 > Abstract: > This document proposes possible solutions to avoid certain drawbac= ks > of IP/ICMP Translation Algorithm (SIIT) when the destinations are > available with IPv6. When SIIT is used as a NAT46 and IPv4-only > devices or applications initiate traffic flows to dual-stack CDNs > (Content Delivery Networks), Caches or other network resources (in > the operator network or Internet), those flows will be translated > back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T. > =20 > = =20 > =20 > =20 > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > =20 > The IETF Secretariat > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nextPart3582731.LLmBlmS8lr Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCpYw ggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwp9Jj5Aej1xPkS1GV 3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYtyqDGF2nnItxV1SkwVoDxFeRzOIHYNYvBR HaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VW Ff/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyimatBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0ba minfLcsh6ubCdINZc+Nof2lU387NCDggoh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAM C57iZXssncp24eaN08VlAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQu Y29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkFOxA/TUiu K2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBSWxITl1KHBS9Y BskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsBiWU2muAoGItwbaP5 5EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101S1OI6J1tUil1r7ES/svN qVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9EowggWFMIIEbaADAgECAhAMQfNc 2yZ76uFuFsYvU6DuMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29y ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwHhcNMTgxMjMwMDAwMDAwWhcNMjAwMTI5MTIw MDAwWjCBqjETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEG CgmSJomT8ixkARkWA3RjczELMAkGA1UEBhMCQ1oxKDAmBgNVBAoTH1RlY2huaWNhbCBVbml2ZXJz aXR5IG9mIExpYmVyZWMxLzAtBgNVBAMMJk1hcnRpbiAgSHVuZWsgbWFydGluLmh1bmVrQHR1bC5j ei0xMTMwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtyGGFckzuJwXJj4YNL1+QmNZ 7XSQMTY0RWWGL2gNQsCIqiBN+eoZkPYUEIhtfJfNmh/kFpLQAGKHRnlx/+aGcOMXMGrg71noNKr4 5p2iBtmeIwoQPvBKgNXREstHVm2qcQjzNUbfC5CLTesbZILWMZI9bAHrFeubdq7urlgk5MlF+uCr h+D4F7GRfYDEkY9PXr6Dcb15RFlFBN3zJCqyfFfyxlhUjGj6biMP8fhSMWWnpHoD7OdKPiWQ0NNZ IAe0zeVxmOFo5t2+iXfhM+WfbFT0PeQAAvA5yoBAzge/hWp3CM2HnJB8vB+d93tftpj2DhCDfKlD SQFMu/v5qfVAHQIDAQABo4IB3DCCAdgwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWLRggEpu2XcKYw HQYDVR0OBBYEFBsqD39E4UgZxyftxDYlCqGCyOALMAwGA1UdEwEB/wQCMAAwHgYDVR0RBBcwFYET bWFydGluLmh1bmVrQHR1bC5jejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMDQGA1UdIAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3 TAUCAwMDMIGFBgNVHR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5B ZVNjaWVuY2VQZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9U RVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IB AQBZZ5rT9Ac11lX7SSXXmKrrDr2KMzPCw6S7MW1z36sNaqvi++KBwio9HdxEgN02SJsf5R2Up3xf cyhkNFr6QR5Klca/dY1xO+c9qQHsYDX5Hi3N59xMyVw0bz9u0tOYj/D/qEncm7qrdmdolSV55Nm4 Vr3ZzGl+qBFnskbwpmDgiiyAOfSL8gK++HPxWVKY/Mvv0MSaoVbyiBh0oiFRxX5fwuBJxaSh7bhC dlQ8SXoAhDNwQnSMKYroOn7ZWKlhT41L6IaMfJ2xSBGHtB+1OmehwLWU9FBzw0GAG34ZsshdJiTS fTuUk/hQAM9vNXzkd3ubPFh+H/DgH0GdPsXg/09oMYICSDCCAkQCAQEwgYYwcjELMAkGA1UEBhMC TkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMG VEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0EgMwIQDEHzXNsme+rh bhbGL1Og7jANBglghkgBZQMEAgEFAKCBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xOTA2MjMyMjI3MjBaMCgGCSqGSIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCAon5cezIUZVlZC+bwwzlJNnT4wsg2O0daDZF9NeuCr ZDANBgkqhkiG9w0BAQEFAASCAQBcfTLUnPy+RXrHQ2IiUrE2EX934wmgz1thdcdAeynzHiJNrwzB T9QBVpIy7L4WRmynpRSyNVnYjDOpeCdTy/bnEFoHX1sySjhc1ynvn656KZfqaxtCNA8cxYGQhHMd tk2vDst0+uFzjxm0WamW24prQPHtPZgEoQoCoUlWxNytSJsdaokIFQ3zq/DQHu+5xoAdMFMRc6ns 3KJ/OLZ3GWHlJ0tH3GtUwTBmqVaTWgg7Aq7pof9h+b0XzfFWzRzWq7gofsmKzXL9pdrWsUyLqyhV FWe+dmqI8vOjEaebjboIi6nlgQJq8/2cm9kG7bpMHhjCpcZ2Y9Y1NulXY1GxPyI3AAAAAAAA --nextPart3582731.LLmBlmS8lr-- From nobody Sun Jun 23 16:09:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394F21201AE for ; Sun, 23 Jun 2019 16:09:26 -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, SPF_HELO_NONE=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=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 o89tFTiITfh3 for ; Sun, 23 Jun 2019 16:09:23 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017511200B8 for ; Sun, 23 Jun 2019 16:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1561331360; x=1561936160; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=oRiOG19s MQJugNBB3QoZHCW8dsKuegdPVFyVgarLVJo=; b=evBYkugTBCUlY9ccCP0seEZ6 Ep57wgukao6CkNU+90qHXrAVDNWSj25fB1DiFIVqWcdrCMrOSDRsdsN+nx4Mz8II xNjNd+6MWBSJ3IQBnGqTBU9DIRFlte+7+92tjJITjT+AORb3VlZKjCSxQAuIvYK6 Wr6bA5vjjuFdboHiCMw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 24 Jun 2019 01:09:20 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 24 Jun 2019 01:09:19 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006302955.msg for ; Mon, 24 Jun 2019 01:09:19 +0200 X-MDRemoteIP: 2001:470:1f09:495:149e:793d:60d4:eef6 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 24 Jun 2019 01:09:19 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10776bdf84=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 24 Jun 2019 01:09:14 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <5F260045-C6B0-4225-B885-67F234273BD9@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <0DA04196-DD42-4574-981B-5A69B4214858@consulintel.es> <1586996.8CYXve7ngK@rumburak.ite.tul.cz> In-Reply-To: <1586996.8CYXve7ngK@rumburak.ite.tul.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 23:09:26 -0000 Hi Martin, Thanks for reading the document! See below in-line. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: Hi Jordi, hi all, =20 Same question I asked you at IETF 104: =20 How did you solve situation in which multiple IPv6 services would share= single IPv4 to IPv6 proxy? When you mean a proxy, what do you exactly mean? I'm confused here with you= r example. Do you refer to SNI ? If that's the case, I believe it is resolv= ed already, because what it matters here is the IPv6 address (the AAAA). If I'm using and IPv4 browser and query to a.example.com, I will go to the = same IPv4 address that if I query for b.example.com. Remember that what it matters here is the contents in IPv6, because the EAM= T entry will bring the SmartTV (for example) either to the AAAA for a.examp= le.com or b.example.com. So, if those AAAA provide the right address for IP= v6, for the right service, it should work correctly. Otherwise (according to your example), you get different results for an IPv= 4 only host and IPv6-only hosts. Normally this is not done in production se= rvices, and again, if this is done, the result of the optimization is like = the IPv4-only SmartTV is actually an IPv6-enabled one, so it works again, a= s intended. =20 Example: a.example.com IN A 192.0.2.1 <- This is a proxy IN AAAA 2001:db8::a <- This is a real server b.example.com IN A 192.0.2.1 IN AAAA 2001:db8::b =20 Now if you would have for example 2 IPv4-only hosts. One device would c= ommunicate with a.example.com, subsequently the second one with b.example.c= om. =20 To which service would second device connect to? What about first devic= e, wouldn't its connection be severed by second device asking for b.example= .com? =20 If this is not solved by draft (and I cannot see it), I think that this= could lead to inaccessible services and non-predictable behavior in genera= l. =20 We should understand if caches/CDNs are using the scheme that you mention o= r it is more like (as I guess): a.example.com IN A 192.0.2.1 <- This is a proxy IN AAAA 2001:db8::a <- This is a real server b.example.com IN A 192.0.2.1 IN AAAA 2001:db8::a This means (and I think is the *normal* way) to do that, that the "server" = is dual-stack and is the "apache" (or whatever), using the SNI the way that= resolves the problem. Is that what you mean? Possible solution: Maybe this could be solved by some kind of "blacklist for shared IPv4 a= ddresses with different IPv6 target" thing. This situation should be detect= able if there would be EAMT record already present with different IPv6 addr= ess. Then if CPE would ask for DNS record which created EAMT record and DNS= record has not changed it should delete EAMT and blacklist that IPv4 addre= ss so it would not make more EAMT records for it. Right now, we have this in the ID: TBD. Should a way to manually exclude EAMT entries be considered? May be a manual config in the CPE and by means of operator config. This is way-out to ensure nothing is broken by surprise and is not solvable. May be what you mention help to be able to also do it automated. =20 Apart of this, it seems like good idea, but I think that it should real= ly be solved as we may see such things with shortage of IPv4 addresses. =20 Regards, Martin =20 Dne p=C3=A1tek 21. =C4=8Dervna 2019 1:40:59 CEST, JORDI PALET MARTINEZ = napsal(a): > Hi all, >=20 > We just published a new version of this document, which we believe ha= s resolved all the issues and inputs received in the last meeting in Prague= , and some new additional considerations. >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-ca= ches/ >=20 > Please provide your inputs! >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 21/6/19 2:38, "internet-drafts@ietf.org" escribi=C3=B3: >=20 > =20 > A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-02= .txt > has been successfully submitted by Jordi Palet Martinez and poste= d to the > IETF repository. > =20 > Name: draft-palet-v6ops-464xlat-opt-cdn-caches > Revision: 02 > Title: 464XLAT Optimization > Document date: 2019-06-20 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-palet-= v6ops-464xlat-opt-cdn-caches-02.txt > Status: https://datatracker.ietf.org/doc/draft-palet-v6op= s-464xlat-opt-cdn-caches/ > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-464= xlat-opt-cdn-caches-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet= -v6ops-464xlat-opt-cdn-caches > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v= 6ops-464xlat-opt-cdn-caches-02 > =20 > Abstract: > This document proposes possible solutions to avoid certain dra= wbacks > of IP/ICMP Translation Algorithm (SIIT) when the destinations = are > available with IPv6. When SIIT is used as a NAT46 and IPv4-on= ly > devices or applications initiate traffic flows to dual-stack C= DNs > (Content Delivery Networks), Caches or other network resources= (in > the operator network or Internet), those flows will be transla= ted > back to IPv4 by a NAT64. This is the case for 464XLAT and MAP= -T. > =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.o= rg. > =20 > The IETF Secretariat > =20 > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=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.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 24 14:14:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDCC120199 for ; Mon, 24 Jun 2019 14:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqYbAYAK95mO for ; Mon, 24 Jun 2019 14:14:05 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11A712016B for ; Mon, 24 Jun 2019 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 6281618050A08 for ; Mon, 24 Jun 2019 23:13:59 +0200 (CEST) From: Martin Hunek To: v6ops@ietf.org Date: Mon, 24 Jun 2019 23:13:54 +0200 Message-ID: <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: <5F260045-C6B0-4225-B885-67F234273BD9@consulintel.es> References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <1586996.8CYXve7ngK@rumburak.ite.tul.cz> <5F260045-C6B0-4225-B885-67F234273BD9@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1925738.AV6kXyhhau"; micalg="sha256"; protocol="application/pkcs7-signature" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:14:08 -0000 --nextPart1925738.AV6kXyhhau Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jordi, See below in-line. Regards, Martin Post Scriptum: My e-mail client doesn't seems to like indentation as quotat= ion mark. Could you change your client settings to use '> '? It is hard to = distinguish who wrote what. With your client is should be in: Options -> Mail -> "When replying to a message" -> "Prefix each line of the= original message" Dne pond=C4=9Bl=C3=AD 24. =C4=8Dervna 2019 1:09:14 CEST, JORDI PALET MARTIN= EZ napsal(a): > Hi Martin, >=20 > Thanks for reading the document! >=20 > See below in-line. >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: >=20 > Hi Jordi, hi all, > =20 > Same question I asked you at IETF 104: > =20 > How did you solve situation in which multiple IPv6 services would sha= re single IPv4 to IPv6 proxy? >=20 > When you mean a proxy, what do you exactly mean? I'm confused here with y= our example. Do you refer to SNI ? If that's the case, I believe it is reso= lved already, because what it matters here is the IPv6 address (the AAAA). Sort of. I mean essentially IPv4 web proxy shared by multiple IPv6 only ser= vers. Proxy would use SNI to distinguish between target server to which it = would send payload to. Thing is that you won't be able to do concurrent bin= dings in EAMT table for this case. >=20 > If I'm using and IPv4 browser and query to a.example.com, I will go to th= e same IPv4 address that if I query for b.example.com. So far so good. >=20 > Remember that what it matters here is the contents in IPv6, because the E= AMT entry will bring the SmartTV (for example) either to the AAAA for a.exa= mple.com or b.example.com. So, if those AAAA provide the right address for = IPv6, for the right service, it should work correctly. No problem on IPv6 side, problem would be to which IPv6 destination should = IPv4 destination get mapped to. As in that case you get two bindings in EAM= T: 192.0.2.1 <-> 2001:db8::a 192.0.2.1 <-> 2001:db8::b Both would be valid but which should be chosen by NAT46? >=20 > Otherwise (according to your example), you get different results for an I= Pv4 only host and IPv6-only hosts. Normally this is not done in production = services, and again, if this is done, the result of the optimization is lik= e the IPv4-only SmartTV is actually an IPv6-enabled one, so it works again,= as intended. Maybe it is bit "ad absurdum" case, certainly for CDNs. But I think that it= is not discouraged/prohibited and I can see its use for VPS provider which= would like to save some IPv4 addresses. By the way, it would be somehow si= milar to what you are proposing: get IPv6-only services accessible by IPv4-= only hosts. Only tools would be different. > =20 > Example: > a.example.com IN A 192.0.2.1 <- This is a proxy > IN AAAA 2001:db8::a <- This is a real server > b.example.com IN A 192.0.2.1 > IN AAAA 2001:db8::b > =20 > Now if you would have for example 2 IPv4-only hosts. One device would= communicate with a.example.com, subsequently the second one with b.example= =2Ecom. > =20 > To which service would second device connect to? What about first dev= ice, wouldn't its connection be severed by second device asking for b.examp= le.com? > =20 > If this is not solved by draft (and I cannot see it), I think that th= is could lead to inaccessible services and non-predictable behavior in gene= ral. > =20 > We should understand if caches/CDNs are using the scheme that you mention= or it is more like (as I guess): >=20 > a.example.com IN A 192.0.2.1 <- This is a proxy > IN AAAA 2001:db8::a <- This is a real server > b.example.com IN A 192.0.2.1 > IN AAAA 2001:db8::a No dispute here. CDNs would probably use it this way. But as not all servic= es are provided by CDNs, so their optimization techniques must not brake ot= her services (even less common). >=20 > This means (and I think is the *normal* way) to do that, that the "server= " is dual-stack and is the "apache" (or whatever), using the SNI the way th= at resolves the problem. Is that what you mean? No. I case I'm trying to present multiple servers would be IPv6-only. And A= record would point to web proxy (dual-staked) which would proxy web reques= ts according to SNI (or request in HTTP) to appropriate IPv6-only server. H= osting provider would save IPv4 addresses and IPv6-only web server would st= ill be accessible by IPv4. Clearly win-win, except that it would be broken = by this optimization. Just so we would be on same page, connections to such deployment would look= like this: a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> Prox= y <--- IPv6 ---> IPv6 Server b) IPv6 Client <--- IPv6 ---> IPv6 Server You are proposing: c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server We can probably all agree that "b" is best and "c" is better than "a". Prob= lem is that you have no way of knowing if you are talking to actual server = or just proxy. Another example when this optimization would not work exactly as planted wo= uld be case in which service provider deployed IPv6 by NAT64 placed before = its IPv4-only infrastructure. But in this case I would say that such operat= or would deserve higher load on its NAT64. :-) This would be case: d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server Optimization would result in: e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4= Server But in this case NAT64 would be in the servers' network rather than clients= '. This is actually good as it is transferring load from network doing IPv6= right to network doing it wrong. :-) >=20 > Possible solution: > Maybe this could be solved by some kind of "blacklist for shared IPv4= addresses with different IPv6 target" thing. This situation should be dete= ctable if there would be EAMT record already present with different IPv6 ad= dress. Then if CPE would ask for DNS record which created EAMT record and D= NS record has not changed it should delete EAMT and blacklist that IPv4 add= ress so it would not make more EAMT records for it. >=20 > Right now, we have this in the ID: > TBD. Should a way to manually exclude EAMT entries be considered? > May be a manual config in the CPE and by means of operator config. > This is way-out to ensure nothing is broken by surprise and is not > solvable. >=20 > May be what you mention help to be able to also do it automated. Doing it manually would not quite cut it as you are proposing to done optim= ization on CPE and as it may be under customer control, you may not be able= to provision it with updated EAMT excludes. It had to be somehow automated= as it would be hard to instruct customer to modify EAMT by hand. However there is also trade-off with automated approach as it would have to= either severe session for user which is already using present binding (whe= n conflicting binding appears). As user starts to communicate over IPv4 (fr= om servers' perspective) as it would get excluded from EAMT. Or you would h= ave to forge fake IPv4 for conflicting binding and corresponding A record, = which would break DNSSEC. The first case wouldn't be big deal but might be worth mentioning, the seco= nd one would be in my opinion worse. > =20 > Apart of this, it seems like good idea, but I think that it should re= ally be solved as we may see such things with shortage of IPv4 addresses. > =20 > Regards, > Martin > =20 > Dne p=C3=A1tek 21. =C4=8Dervna 2019 1:40:59 CEST, JORDI PALET MARTINE= Z napsal(a): > > Hi all, > >=20 > > We just published a new version of this document, which we believe = has resolved all the issues and inputs received in the last meeting in Prag= ue, and some new additional considerations. > >=20 > > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-= caches/ > >=20 > > Please provide your inputs! > >=20 > > Regards, > > Jordi > > @jordipalet > > =20 > > =20 > >=20 > > =EF=BB=BFEl 21/6/19 2:38, "internet-drafts@ietf.org" escribi=C3=B3: > >=20 > > =20 > > A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-= 02.txt > > has been successfully submitted by Jordi Palet Martinez and pos= ted to the > > IETF repository. > > =20 > > Name: draft-palet-v6ops-464xlat-opt-cdn-caches > > Revision: 02 > > Title: 464XLAT Optimization > > Document date: 2019-06-20 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-pale= t-v6ops-464xlat-opt-cdn-caches-02.txt > > Status: https://datatracker.ietf.org/doc/draft-palet-v6= ops-464xlat-opt-cdn-caches/ > > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-4= 64xlat-opt-cdn-caches-02 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-pal= et-v6ops-464xlat-opt-cdn-caches > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet= =2Dv6ops-464xlat-opt-cdn-caches-02 > > =20 > > Abstract: > > This document proposes possible solutions to avoid certain d= rawbacks > > of IP/ICMP Translation Algorithm (SIIT) when the destination= s are > > available with IPv6. When SIIT is used as a NAT46 and IPv4-= only > > devices or applications initiate traffic flows to dual-stack= CDNs > > (Content Delivery Networks), Caches or other network resourc= es (in > > the operator network or Internet), those flows will be trans= lated > > back to IPv4 by a NAT64. This is the case for 464XLAT and M= AP-T. > > =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= =2Eorg. > > =20 > > The IETF Secretariat > > =20 > > =20 > >=20 > >=20 > >=20 > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > >=20 > > This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nextPart1925738.AV6kXyhhau Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCpYw ggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwp9Jj5Aej1xPkS1GV 3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYtyqDGF2nnItxV1SkwVoDxFeRzOIHYNYvBR HaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VW Ff/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyimatBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0ba minfLcsh6ubCdINZc+Nof2lU387NCDggoh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAM C57iZXssncp24eaN08VlAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQu Y29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkFOxA/TUiu K2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBSWxITl1KHBS9Y BskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsBiWU2muAoGItwbaP5 5EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101S1OI6J1tUil1r7ES/svN qVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9EowggWFMIIEbaADAgECAhAMQfNc 2yZ76uFuFsYvU6DuMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29y ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwHhcNMTgxMjMwMDAwMDAwWhcNMjAwMTI5MTIw MDAwWjCBqjETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEG CgmSJomT8ixkARkWA3RjczELMAkGA1UEBhMCQ1oxKDAmBgNVBAoTH1RlY2huaWNhbCBVbml2ZXJz aXR5IG9mIExpYmVyZWMxLzAtBgNVBAMMJk1hcnRpbiAgSHVuZWsgbWFydGluLmh1bmVrQHR1bC5j ei0xMTMwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtyGGFckzuJwXJj4YNL1+QmNZ 7XSQMTY0RWWGL2gNQsCIqiBN+eoZkPYUEIhtfJfNmh/kFpLQAGKHRnlx/+aGcOMXMGrg71noNKr4 5p2iBtmeIwoQPvBKgNXREstHVm2qcQjzNUbfC5CLTesbZILWMZI9bAHrFeubdq7urlgk5MlF+uCr h+D4F7GRfYDEkY9PXr6Dcb15RFlFBN3zJCqyfFfyxlhUjGj6biMP8fhSMWWnpHoD7OdKPiWQ0NNZ IAe0zeVxmOFo5t2+iXfhM+WfbFT0PeQAAvA5yoBAzge/hWp3CM2HnJB8vB+d93tftpj2DhCDfKlD SQFMu/v5qfVAHQIDAQABo4IB3DCCAdgwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWLRggEpu2XcKYw HQYDVR0OBBYEFBsqD39E4UgZxyftxDYlCqGCyOALMAwGA1UdEwEB/wQCMAAwHgYDVR0RBBcwFYET bWFydGluLmh1bmVrQHR1bC5jejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMDQGA1UdIAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3 TAUCAwMDMIGFBgNVHR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5B ZVNjaWVuY2VQZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9U RVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IB AQBZZ5rT9Ac11lX7SSXXmKrrDr2KMzPCw6S7MW1z36sNaqvi++KBwio9HdxEgN02SJsf5R2Up3xf cyhkNFr6QR5Klca/dY1xO+c9qQHsYDX5Hi3N59xMyVw0bz9u0tOYj/D/qEncm7qrdmdolSV55Nm4 Vr3ZzGl+qBFnskbwpmDgiiyAOfSL8gK++HPxWVKY/Mvv0MSaoVbyiBh0oiFRxX5fwuBJxaSh7bhC dlQ8SXoAhDNwQnSMKYroOn7ZWKlhT41L6IaMfJ2xSBGHtB+1OmehwLWU9FBzw0GAG34ZsshdJiTS fTuUk/hQAM9vNXzkd3ubPFh+H/DgH0GdPsXg/09oMYICSDCCAkQCAQEwgYYwcjELMAkGA1UEBhMC TkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMG VEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0EgMwIQDEHzXNsme+rh bhbGL1Og7jANBglghkgBZQMEAgEFAKCBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xOTA2MjQyMTEzNTRaMCgGCSqGSIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCA7LN/MgSSLZTSiq7QSm0ssOwVV6OOcpU+GAYibQqun 2DANBgkqhkiG9w0BAQEFAASCAQB6uEUcY1Jnv5c8lD9C7bYoZdlACY/nfX3hgYols0QNz6yZJuyU tjRas8FuMOAr83HyqDIEne6rBk3eDaa5ZEXmBRBjJaAomzFBiSTywDrfmFS7YkAzn6Pd3QL1w3mu Jhu5SgjJORTZ53W1+zrFCJFOniNa85FNVC8LYjGToA38T+qpTf+CNWcWS+zjjP7spkVspOID0cG9 LVaIfhSOkoWj6iIb/3lGCPwUqcNFPFDXf2/azIL6wiJQjMD/c/EzqK8/RVszinKjv34MfQOsvOnA t9vSPpz6+OhNbRoSBQHK3Amhr3pF8ncD+8RKM7l1kD0kYnIgm8cOO7Gy92JnCYFGAAAAAAAA --nextPart1925738.AV6kXyhhau-- From nobody Mon Jun 24 14:40:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE8C120118 for ; Mon, 24 Jun 2019 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHYH2cii1mXa for ; Mon, 24 Jun 2019 14:40:02 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F2412009C for ; Mon, 24 Jun 2019 14:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1561412398; x=1562017198; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=ZRqxB+u/ /xzPGFXx4PCj89b7ywptJfp+Ufgdf5SVC9g=; b=rC5Jwv+kV7Lg2SL5IAPqVQC2 YBNMs2Ro2ldKqlJFMe9r0Mw0RA2qQkjNsMVJlaTodfF82Bnv/BAVnRHq5qkRfFDp E5VPB2WN7gt29zoGYFOn572QNAo+d8F363z/Ka635liMSEDYX6WNFqLgw1ystHko +J4toeba+zHwS74XUxE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 24 Jun 2019 23:39:58 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 24 Jun 2019 23:39:57 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006304021.msg for ; Mon, 24 Jun 2019 23:39:55 +0200 X-MDRemoteIP: 2001:470:1f09:495:4be:927b:6a21:9707 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 24 Jun 2019 23:39:55 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1078a526c3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Mon, 24 Jun 2019 23:39:52 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <1586996.8CYXve7ngK@rumburak.ite.tul.cz> <5F260045-C6B0-4225-B885-67F234273BD9@consulintel.es> <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> In-Reply-To: <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 21:40:06 -0000 Hi Martin, I use Outlook and it doesn't allow (as I know) anything else than indentati= on. I will try to find a solution, I just need some time ... but is not top= priority. When I see my emails back in the list, it works for me, so it is dificult .= .. See below, in-line. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 24/6/19 23:14, "v6ops en nombre de Martin Hunek" escribi=C3=B3: Hi Jordi, =20 See below in-line. =20 Regards, Martin =20 Post Scriptum: My e-mail client doesn't seems to like indentation as qu= otation mark. Could you change your client settings to use '> '? It is hard= to distinguish who wrote what. With your client is should be in: Options -> Mail -> "When replying to a message" -> "Prefix each line of= the original message" =20 Dne pond=C4=9Bl=C3=AD 24. =C4=8Dervna 2019 1:09:14 CEST, JORDI PALET MA= RTINEZ napsal(a): > Hi Martin, >=20 > Thanks for reading the document! >=20 > See below in-line. >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: >=20 > Hi Jordi, hi all, > =20 > Same question I asked you at IETF 104: > =20 > How did you solve situation in which multiple IPv6 services would= share single IPv4 to IPv6 proxy? >=20 > When you mean a proxy, what do you exactly mean? I'm confused here wi= th your example. Do you refer to SNI ? If that's the case, I believe it is = resolved already, because what it matters here is the IPv6 address (the AAA= A). =20 Sort of. I mean essentially IPv4 web proxy shared by multiple IPv6 only= servers. Proxy would use SNI to distinguish between target server to which= it would send payload to. Thing is that you won't be able to do concurrent= bindings in EAMT table for this case. -> We need to see if this is really common. My guess is that even if you us= e SNI, the IPv4 and the IPv6 page is still hosted by the same dual-stack se= rver. In that case, I don't think we have the problem you mention. You are = describing a case where the IPv4 and IPv6 content is hosted by a different = server, not a dual-stack one, right? We really need to check if CDNs/caches= do that. >=20 > If I'm using and IPv4 browser and query to a.example.com, I will go t= o the same IPv4 address that if I query for b.example.com. =20 So far so good. >=20 > Remember that what it matters here is the contents in IPv6, because t= he EAMT entry will bring the SmartTV (for example) either to the AAAA for a= .example.com or b.example.com. So, if those AAAA provide the right address = for IPv6, for the right service, it should work correctly. =20 No problem on IPv6 side, problem would be to which IPv6 destination sho= uld IPv4 destination get mapped to. As in that case you get two bindings in= EAMT: 192.0.2.1 <-> 2001:db8::a 192.0.2.1 <-> 2001:db8::b Both would be valid but which should be chosen by NAT46? >=20 > Otherwise (according to your example), you get different results for = an IPv4 only host and IPv6-only hosts. Normally this is not done in product= ion services, and again, if this is done, the result of the optimization is= like the IPv4-only SmartTV is actually an IPv6-enabled one, so it works ag= ain, as intended. =20 Maybe it is bit "ad absurdum" case, certainly for CDNs. But I think tha= t it is not discouraged/prohibited and I can see its use for VPS provider w= hich would like to save some IPv4 addresses. By the way, it would be someho= w similar to what you are proposing: get IPv6-only services accessible by I= Pv4-only hosts. Only tools would be different. -> We need to see if this is a real and usual production case. IPv6-only se= rvices today can be deployed with SIIT-DC to allow dual-stack access, but t= his will not suffer the problem you mention. > =20 > Example: > a.example.com IN A 192.0.2.1 <- This is a proxy > IN AAAA 2001:db8::a <- This is a real server > b.example.com IN A 192.0.2.1 > IN AAAA 2001:db8::b > =20 > Now if you would have for example 2 IPv4-only hosts. One device w= ould communicate with a.example.com, subsequently the second one with b.exa= mple.com. > =20 > To which service would second device connect to? What about first= device, wouldn't its connection be severed by second device asking for b.e= xample.com? > =20 > If this is not solved by draft (and I cannot see it), I think tha= t this could lead to inaccessible services and non-predictable behavior in = general. > =20 > We should understand if caches/CDNs are using the scheme that you men= tion or it is more like (as I guess): >=20 > a.example.com IN A 192.0.2.1 <- This is a proxy > IN AAAA 2001:db8::a <- This is a real server > b.example.com IN A 192.0.2.1 > IN AAAA 2001:db8::a =20 No dispute here. CDNs would probably use it this way. But as not all se= rvices are provided by CDNs, so their optimization techniques must not brak= e other services (even less common). >=20 > This means (and I think is the *normal* way) to do that, that the "se= rver" is dual-stack and is the "apache" (or whatever), using the SNI the wa= y that resolves the problem. Is that what you mean? =20 No. I case I'm trying to present multiple servers would be IPv6-only. A= nd A record would point to web proxy (dual-staked) which would proxy web re= quests according to SNI (or request in HTTP) to appropriate IPv6-only serve= r. Hosting provider would save IPv4 addresses and IPv6-only web server woul= d still be accessible by IPv4. Clearly win-win, except that it would be bro= ken by this optimization. -> Avoiding the EAMT entry will resolve the problem, but will not be optimi= zed. =20 Just so we would be on same page, connections to such deployment would = look like this: a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> = Proxy <--- IPv6 ---> IPv6 Server b) IPv6 Client <--- IPv6 ---> IPv6 Server =20 You are proposing: c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server We can probably all agree that "b" is best and "c" is better than "a". = Problem is that you have no way of knowing if you are talking to actual ser= ver or just proxy. =20 Another example when this optimization would not work exactly as plante= d would be case in which service provider deployed IPv6 by NAT64 placed bef= ore its IPv4-only infrastructure. But in this case I would say that such op= erator would deserve higher load on its NAT64. :-) This would be case: d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server Optimization would result in: e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---> = IPv4 Server But in this case NAT64 would be in the servers' network rather than cli= ents'. This is actually good as it is transferring load from network doing = IPv6 right to network doing it wrong. :-) -> I think d) is using "only" NAT64, but it is a broken model, because it d= oesn't work for IPv4-only hosts behind the CPE. So not in scope for our doc= ument. e) is the "normal" case for 464XLAT when we don't have the optimizat= ion described in this document. >=20 > Possible solution: > Maybe this could be solved by some kind of "blacklist for shared = IPv4 addresses with different IPv6 target" thing. This situation should be = detectable if there would be EAMT record already present with different IPv= 6 address. Then if CPE would ask for DNS record which created EAMT record a= nd DNS record has not changed it should delete EAMT and blacklist that IPv4= address so it would not make more EAMT records for it. >=20 > Right now, we have this in the ID: > TBD. Should a way to manually exclude EAMT entries be considered? > May be a manual config in the CPE and by means of operator config. > This is way-out to ensure nothing is broken by surprise and is not > solvable. >=20 > May be what you mention help to be able to also do it automated. =20 Doing it manually would not quite cut it as you are proposing to done o= ptimization on CPE and as it may be under customer control, you may not be = able to provision it with updated EAMT excludes. It had to be somehow autom= ated as it would be hard to instruct customer to modify EAMT by hand. -> Agree that manually only makes sense if there is a strange case or the u= ser for some reason doesn't want optimization. It is a special case 99% of = users will not use it, but must be supported. =20 However there is also trade-off with automated approach as it would hav= e to either severe session for user which is already using present binding = (when conflicting binding appears). As user starts to communicate over IPv4= (from servers' perspective) as it would get excluded from EAMT. Or you wou= ld have to forge fake IPv4 for conflicting binding and corresponding A reco= rd, which would break DNSSEC. -> I can't parse the complete paragraph ... =20 The first case wouldn't be big deal but might be worth mentioning, the = second one would be in my opinion worse. > =20 > Apart of this, it seems like good idea, but I think that it shoul= d really be solved as we may see such things with shortage of IPv4 addresse= s. > =20 > Regards, > Martin > =20 > Dne p=C3=A1tek 21. =C4=8Dervna 2019 1:40:59 CEST, JORDI PALET MAR= TINEZ napsal(a): > > Hi all, > >=20 > > We just published a new version of this document, which we beli= eve has resolved all the issues and inputs received in the last meeting in = Prague, and some new additional considerations. > >=20 > > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-= cdn-caches/ > >=20 > > Please provide your inputs! > >=20 > > Regards, > > Jordi > > @jordipalet > > =20 > > =20 > >=20 > > =EF=BB=BFEl 21/6/19 2:38, "internet-drafts@ietf.org" escribi=C3=B3: > >=20 > > =20 > > A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-cac= hes-02.txt > > has been successfully submitted by Jordi Palet Martinez and= posted to the > > IETF repository. > > =20 > > Name: draft-palet-v6ops-464xlat-opt-cdn-caches > > Revision: 02 > > Title: 464XLAT Optimization > > Document date: 2019-06-20 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-= palet-v6ops-464xlat-opt-cdn-caches-02.txt > > Status: https://datatracker.ietf.org/doc/draft-pale= t-v6ops-464xlat-opt-cdn-caches/ > > Htmlized: https://tools.ietf.org/html/draft-palet-v6o= ps-464xlat-opt-cdn-caches-02 > > Htmlized: https://datatracker.ietf.org/doc/html/draft= -palet-v6ops-464xlat-opt-cdn-caches > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-p= alet-v6ops-464xlat-opt-cdn-caches-02 > > =20 > > Abstract: > > This document proposes possible solutions to avoid certa= in drawbacks > > of IP/ICMP Translation Algorithm (SIIT) when the destina= tions are > > available with IPv6. When SIIT is used as a NAT46 and I= Pv4-only > > devices or applications initiate traffic flows to dual-s= tack CDNs > > (Content Delivery Networks), Caches or other network res= ources (in > > the operator network or Internet), those flows will be t= ranslated > > back to IPv4 by a NAT64. This is the case for 464XLAT a= nd MAP-T. > > =20 > > = =20 > > =20 > > =20 > > Please note that it may take a couple of minutes from the t= ime of submission > > until the htmlized version and diff are available at tools.= ietf.org. > > =20 > > The IETF Secretariat > > =20 > > =20 > >=20 > >=20 > >=20 > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > >=20 > > This electronic message contains information which may be privi= leged or confidential. The information is intended to be for the exclusive = use of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this informatio= n, even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense. If you are not the intended recipien= t be aware that any disclosure, copying, distribution or use of the content= s of this information, even if partially, including attached files, is stri= ctly prohibited, will be considered a criminal offense, so you must reply t= o the original sender to inform about this communication and delete it. > >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=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.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 24 16:46:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8994C12013E for ; Mon, 24 Jun 2019 16:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsBBTJ4J8dOC for ; Mon, 24 Jun 2019 16:46:13 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B5212007C for ; Mon, 24 Jun 2019 16:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 5F10E180509A3 for ; Tue, 25 Jun 2019 01:46:09 +0200 (CEST) From: Martin Hunek To: v6ops@ietf.org Date: Tue, 25 Jun 2019 01:46:04 +0200 Message-ID: <13355366.0fiuOKKrGf@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: References: <156107391252.12250.3911860558299506579.idtracker@ietfa.amsl.com> <1571307.uvGIkSPLC4@rumburak.ite.tul.cz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2896070.ThPJhqzv4E"; micalg="sha256"; protocol="application/pkcs7-signature" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 23:46:16 -0000 --nextPart2896070.ThPJhqzv4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jordi, don worry I'll manage, I wrote that just that you know some clients (kmail = in my case) have issue with this quotation style. :-) Anyway, see reply in-line (shortened to relevant parts). Regards, Martin Dne pond=C4=9Bl=C3=AD 24. =C4=8Dervna 2019 23:39:52 CEST, JORDI PALET MARTI= NEZ napsal(a): > Hi Martin, >=20 > I use Outlook and it doesn't allow (as I know) anything else than indenta= tion. I will try to find a solution, I just need some time ... but is not t= op priority. >=20 > When I see my emails back in the list, it works for me, so it is dificult= ... >=20 > See below, in-line. >=20 > Regards, > Jordi > @jordipalet > =20 > =20 >=20 > =EF=BB=BFEl 24/6/19 23:14, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > =EF=BB=BFEl 24/6/19 0:28, "v6ops en nombre de Martin Hunek" escribi=C3=B3: > > How did you solve situation in which multiple IPv6 services wou= ld share single IPv4 to IPv6 proxy? > >=20 > > When you mean a proxy, what do you exactly mean? I'm confused here = with your example. Do you refer to SNI ? If that's the case, I believe it i= s resolved already, because what it matters here is the IPv6 address (the A= AAA). > =20 > Sort of. I mean essentially IPv4 web proxy shared by multiple IPv6 on= ly servers. Proxy would use SNI to distinguish between target server to whi= ch it would send payload to. Thing is that you won't be able to do concurre= nt bindings in EAMT table for this case. >=20 > -> We need to see if this is really common. My guess is that even if you = use SNI, the IPv4 and the IPv6 page is still hosted by the same dual-stack = server. In that case, I don't think we have the problem you mention. You ar= e describing a case where the IPv4 and IPv6 content is hosted by a differen= t server, not a dual-stack one, right? We really need to check if CDNs/cach= es do that. Actually hosted on single (IPv6-only) server, on IPv4 there would be only p= roxy. By Apache terminology "reverse proxy". For a moment forget CDNs/cache= s, those wouldn't probably need that as they do have different tools how to= deal with IPv4 runout. Think more like VPS providers. This is likely to ha= ppen when operator is running IPv6-only infrastructure. > > Remember that what it matters here is the contents in IPv6, because= the EAMT entry will bring the SmartTV (for example) either to the AAAA for= a.example.com or b.example.com. So, if those AAAA provide the right addres= s for IPv6, for the right service, it should work correctly. > =20 > No problem on IPv6 side, problem would be to which IPv6 destination s= hould IPv4 destination get mapped to. As in that case you get two bindings = in EAMT: > 192.0.2.1 <-> 2001:db8::a > 192.0.2.1 <-> 2001:db8::b > Both would be valid but which should be chosen by NAT46? > >=20 > > Otherwise (according to your example), you get different results fo= r an IPv4 only host and IPv6-only hosts. Normally this is not done in produ= ction services, and again, if this is done, the result of the optimization = is like the IPv4-only SmartTV is actually an IPv6-enabled one, so it works = again, as intended. > =20 > Maybe it is bit "ad absurdum" case, certainly for CDNs. But I think t= hat it is not discouraged/prohibited and I can see its use for VPS provider= which would like to save some IPv4 addresses. By the way, it would be some= how similar to what you are proposing: get IPv6-only services accessible by= IPv4-only hosts. Only tools would be different. >=20 > -> We need to see if this is a real and usual production case. IPv6-only = services today can be deployed with SIIT-DC to allow dual-stack access, but= this will not suffer the problem you mention. You are right, but SIIT-DC requires as many IPv4 addresses as IPv4-enabled = services (n:n). It provides stateless translation. I'm talking one IPv4 add= ress for multiple IPv4-services (1:n). > >=20 > > This means (and I think is the *normal* way) to do that, that the "= server" is dual-stack and is the "apache" (or whatever), using the SNI the = way that resolves the problem. Is that what you mean? > =20 > No. I case I'm trying to present multiple servers would be IPv6-only.= And A record would point to web proxy (dual-staked) which would proxy web = requests according to SNI (or request in HTTP) to appropriate IPv6-only ser= ver. Hosting provider would save IPv4 addresses and IPv6-only web server wo= uld still be accessible by IPv4. Clearly win-win, except that it would be b= roken by this optimization. >=20 > -> Avoiding the EAMT entry will resolve the problem, but will not be opti= mized. Yes it would solve that problem, but as it is written right now, you have n= o way of knowing that for this specific address EAMT entry should be avoide= d. This is how it could get broken and how NAT46 device would be able to detec= t that: 1) Client asks for A record of a.example.com. 2) CPE would also ask for AAAA. 3) CPE receives: a.example.com IN A 192.0.2.1 a.example.com IN AAAA 2001:db8::a 4) CPE makes EAMT entry: 192.0.2.1 <-> 2001:db8::a 5) CPE sends A record to client. 6) Client starts to communicate with 2001:db8::a without knowing it. 7) Client (same or another) asks for A record of b.example.com. 8) CPE would also ask for AAAA. 9) CPE receives: b.example.com IN A 192.0.2.1 b.example.com IN AAAA 2001:db8::b 10) CPE does what with EAMT entry? There is already EAMT entry present for = 192.0.2.1! Option A: CPE would simply update EAMT entry: 10a) EAMT entry gets updated to: 192.0.2.1 <-> 2001:db8::b 11a) CPE sends A record to client. 12a) Client starts communication with 2001:db8::b but connection with 2001:= db8::a is severed Result: a.example.com is not accessible until its TTL expire. Option B: CPE ignores new EAMT entry: 10b) CPE checks if A record for a.example.com have been changed if yes than= option A, if not than: 11b) EAMT entry stays: 192.0.2.1 <-> 2001:db8::a 12b) CPE sends A record to client. 13b) Client is unable to connect to b.example.com but connection to a.examp= le.com is not interrupted. Result: b.example.com is not accessible until TTL of a.example.com expire. Option C: CPE excludes 192.0.2.1 from EAMT: 10c) CPE checks if A record for a.example.com have been changed if yes than= option A, if not than: 11c) EAMT entry of 192.0.2.1 <-> 2001:db8::a gets deleted: 12c) CPE sends A record to client. 13c) Client is able to connect to b.example.com but connection to a.example= =2Ecom is momentary interrupted. Result: Session made to a.example.com via IPv6 is severed and had to be rei= nitiated, but both are accessible. Option D: CPE handles additional entries for 192.0.2.1 as it would not have= A record: 10d) CPE checks if A record for a.example.com have been changed if yes than= option A, if not than: 11d) CPE generates pseudo IPv4 address 198.51.100.1 for 2001:db8::b 12d) CPE makes EAMT entry: 198.51.100.1 <-> 2001:db8::b 13d) CPE send 198.51.100.1 to client. 14d) Client communicate with 2001:db8::b, communication with 2001:db8::a is= not interrupted. Result: If client is validating DNSSEC, then validation would fail. Same wa= y as if service would be IPv6-only as A query would end up with NSEC(3) wit= h NODATA response. If client attempts validation b.example.com would not be= accessible. > =20 > Just so we would be on same page, connections to such deployment woul= d look like this: > a) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---= > Proxy <--- IPv6 ---> IPv6 Server > b) IPv6 Client <--- IPv6 ---> IPv6 Server > =20 > You are proposing: > c) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> IPv6 Server > We can probably all agree that "b" is best and "c" is better than "a"= =2E Problem is that you have no way of knowing if you are talking to actual= server or just proxy. > =20 > Another example when this optimization would not work exactly as plan= ted would be case in which service provider deployed IPv6 by NAT64 placed b= efore its IPv4-only infrastructure. But in this case I would say that such = operator would deserve higher load on its NAT64. :-) > This would be case: > d) IPv6 Client <--- IPv6 ---> NAT64 <--- IPv4 ---> IPv4 Server > Optimization would result in: > e) IPv4 Client <--- IPv4 ---> CLAT <--- IPv6 ---> NAT64 <--- IPv4 ---= > IPv4 Server > But in this case NAT64 would be in the servers' network rather than c= lients'. This is actually good as it is transferring load from network doin= g IPv6 right to network doing it wrong. :-) >=20 > -> I think d) is using "only" NAT64, but it is a broken model, because it= doesn't work for IPv4-only hosts behind the CPE. So not in scope for our d= ocument. e) is the "normal" case for 464XLAT when we don't have the optimiz= ation described in this document. Never mind d) and e), this is not important as this would not be actually b= roken. Difference is between transporting IPv4 or IPv6 packets over interne= t. IPv4 without optimization, IPv6 with. >=20 > >=20 > > Possible solution: > > Maybe this could be solved by some kind of "blacklist for share= d IPv4 addresses with different IPv6 target" thing. This situation should b= e detectable if there would be EAMT record already present with different I= Pv6 address. Then if CPE would ask for DNS record which created EAMT record= and DNS record has not changed it should delete EAMT and blacklist that IP= v4 address so it would not make more EAMT records for it. > >=20 > > Right now, we have this in the ID: > > TBD. Should a way to manually exclude EAMT entries be considered? > > May be a manual config in the CPE and by means of operator confi= g. > > This is way-out to ensure nothing is broken by surprise and is n= ot > > solvable. > >=20 > > May be what you mention help to be able to also do it automated. > =20 > Doing it manually would not quite cut it as you are proposing to done= optimization on CPE and as it may be under customer control, you may not b= e able to provision it with updated EAMT excludes. It had to be somehow aut= omated as it would be hard to instruct customer to modify EAMT by hand. >=20 > -> Agree that manually only makes sense if there is a strange case or the= user for some reason doesn't want optimization. It is a special case 99% o= f users will not use it, but must be supported. > =20 > However there is also trade-off with automated approach as it would h= ave to either severe session for user which is already using present bindin= g (when conflicting binding appears). As user starts to communicate over IP= v4 (from servers' perspective) as it would get excluded from EAMT. Or you w= ould have to forge fake IPv4 for conflicting binding and corresponding A re= cord, which would break DNSSEC. >=20 > -> I can't parse the complete paragraph ... See Option C and Option D above. Thing is that you had to choose between te= rminating current connection by deleting EAMT entry or making fake address = for new connections. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nextPart2896070.ThPJhqzv4E Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCpYw ggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwp9Jj5Aej1xPkS1GV 3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYtyqDGF2nnItxV1SkwVoDxFeRzOIHYNYvBR HaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VW Ff/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyimatBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0ba minfLcsh6ubCdINZc+Nof2lU387NCDggoh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAM C57iZXssncp24eaN08VlAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQu Y29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkFOxA/TUiu K2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBSWxITl1KHBS9Y BskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsBiWU2muAoGItwbaP5 5EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101S1OI6J1tUil1r7ES/svN qVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9EowggWFMIIEbaADAgECAhAMQfNc 2yZ76uFuFsYvU6DuMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29y ZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwHhcNMTgxMjMwMDAwMDAwWhcNMjAwMTI5MTIw MDAwWjCBqjETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEG CgmSJomT8ixkARkWA3RjczELMAkGA1UEBhMCQ1oxKDAmBgNVBAoTH1RlY2huaWNhbCBVbml2ZXJz aXR5IG9mIExpYmVyZWMxLzAtBgNVBAMMJk1hcnRpbiAgSHVuZWsgbWFydGluLmh1bmVrQHR1bC5j ei0xMTMwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtyGGFckzuJwXJj4YNL1+QmNZ 7XSQMTY0RWWGL2gNQsCIqiBN+eoZkPYUEIhtfJfNmh/kFpLQAGKHRnlx/+aGcOMXMGrg71noNKr4 5p2iBtmeIwoQPvBKgNXREstHVm2qcQjzNUbfC5CLTesbZILWMZI9bAHrFeubdq7urlgk5MlF+uCr h+D4F7GRfYDEkY9PXr6Dcb15RFlFBN3zJCqyfFfyxlhUjGj6biMP8fhSMWWnpHoD7OdKPiWQ0NNZ IAe0zeVxmOFo5t2+iXfhM+WfbFT0PeQAAvA5yoBAzge/hWp3CM2HnJB8vB+d93tftpj2DhCDfKlD SQFMu/v5qfVAHQIDAQABo4IB3DCCAdgwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWLRggEpu2XcKYw HQYDVR0OBBYEFBsqD39E4UgZxyftxDYlCqGCyOALMAwGA1UdEwEB/wQCMAAwHgYDVR0RBBcwFYET bWFydGluLmh1bmVrQHR1bC5jejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMDQGA1UdIAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3 TAUCAwMDMIGFBgNVHR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5B ZVNjaWVuY2VQZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9U RVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IB AQBZZ5rT9Ac11lX7SSXXmKrrDr2KMzPCw6S7MW1z36sNaqvi++KBwio9HdxEgN02SJsf5R2Up3xf cyhkNFr6QR5Klca/dY1xO+c9qQHsYDX5Hi3N59xMyVw0bz9u0tOYj/D/qEncm7qrdmdolSV55Nm4 Vr3ZzGl+qBFnskbwpmDgiiyAOfSL8gK++HPxWVKY/Mvv0MSaoVbyiBh0oiFRxX5fwuBJxaSh7bhC dlQ8SXoAhDNwQnSMKYroOn7ZWKlhT41L6IaMfJ2xSBGHtB+1OmehwLWU9FBzw0GAG34ZsshdJiTS fTuUk/hQAM9vNXzkd3ubPFh+H/DgH0GdPsXg/09oMYICSDCCAkQCAQEwgYYwcjELMAkGA1UEBhMC TkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMG VEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2UgUGVyc29uYWwgQ0EgMwIQDEHzXNsme+rh bhbGL1Og7jANBglghkgBZQMEAgEFAKCBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xOTA2MjQyMzQ2MDRaMCgGCSqGSIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCAWVT7DS8G/tIhrugHmPh8ftmvkTwZkTFezNLE0HmZ2 rTANBgkqhkiG9w0BAQEFAASCAQBb6OmuDcDrPdTSdp1IPPFyxBwktdUKxjJD6dQXL3jLzQY8wdtF tBoZC0Qwe2rx4ILbHX/DRHLbmjfHN9z+PkYkOyaoC30BQoiXeNeD0tPDp6Nt0cEyKpsCNvkb3LgS Fsa1fhFY8tzZaL/G5VZD/EAJdnTfPTUU58m0tvSV5jhwFejCImYwUtwvaGNI1qCCWU9aGUAQU6s+ P1DcadPGf5b5bPkQj8lroCkUxAw7+haBgl3bQkPkhrRa9F4sU6LnTJMMw6pJPTNZyNS3vj7lVZGE gM6MAfe0BoD6wARb1P5FGZK7rtXv6aEPJHA+anDuJVONAfrROeAKYfnvL5SBzi2yAAAAAAAA --nextPart2896070.ThPJhqzv4E-- From nobody Mon Jun 24 21:03:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29187120077 for ; Mon, 24 Jun 2019 21:03:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIBteSG9MJRy for ; Mon, 24 Jun 2019 21:03:05 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CDD12004D for ; Mon, 24 Jun 2019 21:03:05 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id p10so8245444pgn.1 for ; Mon, 24 Jun 2019 21:03:05 -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:message-id:cc:to; bh=RGRdb6uupqIEhrn1kt4neoYAd05qAx+401X59A5xmBE=; b=uV9H5n5MTvH2ygDqJHMXgYtyfV2fA4arPsq2uBuAZ4QHSkCoiG1rhLgXk33TSoNvEt 84guMoB7OVZj1rd7VOiDwV8F1nD7ZpAv6ftAN0mWe+Wc/NaZOdIFuRk/CxwHeyb6SwcW qlFvwanjEoU6KnTOKJjblMTsedDQ2YGOuPF55iOJNlZSjcW7S/HMdpOnW5MukdvG8JXI KF3OZhdyuGy6cXf2iE5Qlh01x5yHQOdwp1MSpx86mvDCbU+jZV+j3fkKuYIG5Bxeqcmc H59D0DX4APsrfLU4H798rUuTLVqV1KeKULFYpa/ffq6d+Ezgfgm9vzon/nXeVoIPkviW qsrw== 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 :message-id:cc:to; bh=RGRdb6uupqIEhrn1kt4neoYAd05qAx+401X59A5xmBE=; b=G9F9mSnwqjYm1HFqgrdIaBOseP6yLW9LAYIsRbWlqPq8ggHxLEMQobHjHISVg2LUhW RXEo99gzByerdXMtOE515/m1ESXylqV2gNR74kicwHKsf132aLDgqaK8WzMwKJCuAWWl qwt/52QgEOlQ88bvbkQqA/P+MA4209Ef4sx8XDkBahdbGFB5Qygx9/GWR5m7JVdMx8Pc gIzUrqu0HJiy2EuyLEBsAQWAnYF53oflwUW58rPHjZMaaFJgvlKubYUbij9W83Bq38PE xC0U2Qv0hJQlpngYBncuFkUc+yOI6pDuxPgkCglaFKCnCSLlURVVBab1au2HkXdM86Yd 6gtA== X-Gm-Message-State: APjAAAUIN5vXYkrd3KAnVLbjeIusMGkI1FP0jiEMt69izavf10uGXilY g7vpFRepAKhTqhrQEPx3emanm9lAJIQ= X-Google-Smtp-Source: APXvYqztKGdwRbgv7ifhXFVrnfphV/y64rY0bfjFB78IJBRTete7gmPLuLdRwwesjUHsk6bhN8+aIw== X-Received: by 2002:a63:5d61:: with SMTP id o33mr36779483pgm.114.1561435384492; Mon, 24 Jun 2019 21:03:04 -0700 (PDT) Received: from 234.66.20.149.in-addr.arpa (234.66.20.149.in-addr.arpa. [149.20.66.234]) by smtp.gmail.com with ESMTPSA id d4sm810514pju.19.2019.06.24.21.03.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 21:03:03 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_E937C335-68AB-4C32-87F3-616AD75B1A78"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: V6Ops Chairs Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Jun 2019 05:02:58 +0100 Message-Id: To: IPv6 Operations X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [v6ops] Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 04:03:11 -0000 --Apple-Mail=_E937C335-68AB-4C32-87F3-616AD75B1A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ron and I have posted a preliminary agenda at = https://datatracker.ietf.org/doc/agenda-105-v6ops/. There is space for additional drafts, if they are posted before the = repository closes on July 8 and we see email list commentary supportive = of their having agenda time. --Apple-Mail=_E937C335-68AB-4C32-87F3-616AD75B1A78 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0RnPIACgkQEhdRnd2G P+DE0RAAu2dOUUQRo13z6GUil6QqZBX1R/XEWx4blMLcEEZZ+TpR3V+5Q7pUsolp qBShNEq244Ig3MpU7Zsh99a6W6BxTNABcYdiUU9xJ68tqsbr7U78SO6u8mk+Bb1s VKdnfjRV8lXizUs4I5CQtyCuoK7ZImIfQCrMFtpevJFz0Asqro4MuBaHP2QwQK3d DHYzf0n7KN1omcIanHsb83HfKxTaCOguytFZr6+P28fHnKb2eU6LlMcHIcJh1fwV JhdFmPpWKaJlaelOfmBOyGjAJqph/VyGjtMI2cbemkX4isVAHSBJpht6FjOXtKJr Rt5HbrBNcjiet8FPgvuLUdJJBEOVxxcv8F2Kp4kn4NW/MR6DlElfbCNITDa7nlAT GMDiF+YQSd3VnkJUaMPKf1kM4IepwHZq3hjhHf+TOJ1L/CAW7qDivXyJIQS37MI9 juaS4uZB5gANQm+SaDsBSpZw8aCRwvBc/aiJaL1gXVVs2h39GW4uOcMik4K/4mO2 0HleJe2nXhucADNw1Bq9NAJdW0QHBOc9xW+RBVu1z6PCGh0bJYslrlENvtXOfefr 6zbWFX6j36CWdrYMheH5S2OhJ47lj7AaiZmn/SWg+wUFe9o7NPsFEktYlyTDngsJ FQXX2Ww2P0wFHGmm+K1/zC8JIK0fz8cTXgiZ99D+47dLHOrWLZY= =0AOK -----END PGP SIGNATURE----- --Apple-Mail=_E937C335-68AB-4C32-87F3-616AD75B1A78-- From nobody Tue Jun 25 09:14:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4AF12076E; Tue, 25 Jun 2019 09:14:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60BFbn5Vb9X1; Tue, 25 Jun 2019 09:14:15 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2759120787; Tue, 25 Jun 2019 09:14:14 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id u19so424263ior.9; Tue, 25 Jun 2019 09:14:14 -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=XXNIEwqNGEru6jQ1W8KoGVKcLUCJy4NMPPorDO72LIU=; b=Pg/5az/A83GCdq9N29f1hnCNleoIzSMC6A7QBZYskwKLvQfOZrpoYsmOahTYwvm3GA viOv1DjmAbNcjcJ/Aw3eHu7zsTuXRL/+g0hft4qOt/krd6W9hoeiTx6LWFGInTz8XzS7 mHYvwHiX8qfTnAnOPkCU6+BhCjqlGhztca4mtNhC1bt8Akb9sDm5TR6FtJEhbmc6YPkM 8+eCQUvIO8nP/p4zkW4MsnrmBr8HDVX41UIvDmWNORbrdbVqYKN+Js0Rvi/AHJIuwUGX VCpqWIDkFpoHrY0+rEf9Dy2U8lSjikJmfqnx1C62HHJqf7oEyPsRmsV00TFsHqe/zLQj DBYQ== 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=XXNIEwqNGEru6jQ1W8KoGVKcLUCJy4NMPPorDO72LIU=; b=e8+QhBI4T0aWWlft9EvoeVaRVZpLORTKwVzp9v6LOXeFV4xeAt6Yw4QUXrAN7cZWNw 3Rj39UVn0eICprtND4CC9f/U6Qq26iOWcTZVE6PPuxv0u1eVYql2W4UMNz7w1zPK+Jev 9ck4HHQtDlzxHZg6GvDnoxcHLd9Fv+XF/Sn594qoNSp12BMulqa5lmi+/Ufrr27LvS88 LjDvpU7vc1I/WtQgBd4wW5BDpHdpgwiv8fyrxmiw772JRAwElm6BA4ZIiFlpFn17S4Tb fUoDfy1MpBDr8hnxuGCKlVTgcseiRbR1WgeAoP12K+mE9n7u9OU9uHrI6cWPEIW5O/kU 2cQA== X-Gm-Message-State: APjAAAU3jBl5IoA0ATyq4Mb8ahdAqb7QVsXr4/23AOvlAexPcMhcmFpA PK8Lf0Cw3UxpmWCX2wh52vuFTH9MkeTIc4UBJpW2uA== X-Google-Smtp-Source: APXvYqwtOg5ILtGAEBlM1Hrh1ulOcRcwPohlvGIQTKczlEO7lLl3xpYzfce8y94HAHlfMMfd/68zvaCe774Ru9QBPK4= X-Received: by 2002:a6b:b7cf:: with SMTP id h198mr1225870iof.259.1561479253839; Tue, 25 Jun 2019 09:14:13 -0700 (PDT) MIME-Version: 1.0 References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> In-Reply-To: <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> From: Naveen Kottapalli Date: Tue, 25 Jun 2019 21:43:48 +0530 Message-ID: To: v6ops list , dhcwg@ietf.org Content-Type: multipart/alternative; boundary="0000000000003fd477058c283846" Archived-At: Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 16:14:18 -0000 --0000000000003fd477058c283846 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello All, A new draft on this subject is submitted today. Please go through the same in below link and let us know your feedback. ---- A new version of I-D, draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt has been successfully submitted by Naveen Kottapalli and posted to the IETF repository. Name: draft-fkhp-dhc-dhcpv6-pd-relay-requirements Revision: 00 Title: DHCPv6 Prefix Delegating relay Document date: 2019-06-25 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-require= ments-00.txt Status: https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirement= s/ Htmlized: https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requir= ements Abstract: Operational experience with DHCPv6 prefix delegation has shown that when the DHCPv6 relay function is not co-located with the DHCPv6 server function, issues such as timer synchronization between the DHCP functional elements, rejection of client's messages by the relay, and other problems have been observed. These problems can result in prefix delegation failing or traffic to/from clients addressed from the delegated prefix being unrouteable. Although [RFC8415] mentions this deployment scenario, it does not provide necessary detail on how the relay element should behave when used with PD. This document describes functional requirements for a DHCPv6 PD relay when used for relaying prefixes delegated by a separate DHCPv6 server. Yours, Naveen. On Mon, 1 Apr 2019 at 18:34, wrote: > Hi Martin, > > I would also be interested in working on this as it=E2=80=99s a problem f= or us. > I=E2=80=99ve got something I wrote a while back. I=E2=80=99ll share it as= a starting point. > > Cheers, > Ian > > > On 1. Apr 2019, at 11:31, Martin Hunek wrote: > > > > Hi Fred, > > > > I would be interested to address this issue, as it is the one I'm also > having. But I would need some assistance, as I don't really know my ways > around IETF processes yet. > > > > Martin > > > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a): > >> > https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terast= ream/, > slide 3-4 > >> > >> What do we want to say about DHCPv6 issues in vendor product and/or > services? This headache doesn't have an obvious draft. I think that > probably calls for a person or design team to create such a draft for > discussion on the list and in Montreal. > >> > >> Any takers? > >> > -------------------------------------------------------------------------= ------- > >> The fact that there is a highway to hell and a stairway to heaven is a= n > interesting comment on projected traffic volume... > >> > > > > _______________________________________________ > > 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 > --0000000000003fd477058c283846 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

A new draft on this subject = is submitted today.=C2=A0 Please go through the same in below link and let = us know your feedback.

----

A new version of I-D, draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt=
has been successfully submitted by Naveen Kottapalli and posted to the<= br>IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dr= aft-fkhp-dhc-dhcpv6-pd-relay-requirements
Revision:=C2=A0 =C2=A0 =C2=A0 = =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCPv6 Prefix Delegati= ng relay
Document date:=C2=A0 2019-06-25
Group:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/int= ernet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
Stat= us:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-rel= ay-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-fkhp-dh= c-dhcpv6-pd-relay-requirements-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2= =A0https://datatrac= ker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements

Abstract:
=C2=A0 =C2=A0Operational experience with DHCPv6 prefix d= elegation has shown that
=C2=A0 =C2=A0when the DHCPv6 relay function is = not co-located with the DHCPv6
=C2=A0 =C2=A0server function, issues such= as timer synchronization between the
=C2=A0 =C2=A0DHCP functional eleme= nts, rejection of client's messages by the
=C2=A0 =C2=A0relay, and o= ther problems have been observed.=C2=A0 These problems can
=C2=A0 =C2=A0= result in prefix delegation failing or traffic to/from clients
=C2=A0 = =C2=A0addressed from the delegated prefix being unrouteable.=C2=A0 Although=
=C2=A0 =C2=A0[RFC8415] mentions this deployment scenario, it does not p= rovide
=C2=A0 =C2=A0necessary detail on how the relay element should beh= ave when used
=C2=A0 =C2=A0with PD.

=C2=A0 =C2=A0This document de= scribes functional requirements for a DHCPv6 PD relay
=C2=A0 =C2=A0when = used for relaying prefixes delegated by a separate DHCPv6
=C2=A0 =C2=A0s= erver.

= Yours,
Naveen.


On Mon, 1 Apr 2019 at 18:34, <ianfarrer@gmx.com&g= t; wrote:
Hi Mar= tin,

I would also be interested in working on this as it=E2=80=99s a problem for= us. I=E2=80=99ve got something I wrote a while back. I=E2=80=99ll share it= as a starting point.

Cheers,
Ian

> On 1. Apr 2019, at 11:31, Martin Hunek <martin.hunek@tul.cz> wrote:
>
> Hi Fred,
>
> I would be interested to address this issue, as it is the one I'm = also having. But I would need some assistance, as I don't really know m= y ways around IETF processes yet.
>
> Martin
>
> Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a)= :
>> https://datat= racker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slid= e 3-4
>>
>> What do we want to say about DHCPv6 issues in vendor product and/o= r services? This headache doesn't have an obvious draft. I think that p= robably calls for a person or design team to create such a draft for discus= sion on the list and in Montreal.
>>
>> Any takers?
>> ------------------------------------------------------------------= --------------
>> The fact that there is a highway to hell and a stairway to heaven = is an interesting comment on projected traffic volume...
>>
>
> _______________________________________________
> 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
--0000000000003fd477058c283846-- From nobody Wed Jun 26 08:15:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868381202C5; Wed, 26 Jun 2019 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 y5L6skFpXVg5; Wed, 26 Jun 2019 08:15:19 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C6D1201D3; Wed, 26 Jun 2019 08:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x5QFEnAO022237; Wed, 26 Jun 2019 11:14:50 -0400 Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x5QFEm3F022227 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 11:14:48 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 26 Jun 2019 08:14:47 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Wed, 26 Jun 2019 08:14:47 -0700 From: "Templin (US), Fred L" To: Naveen Kottapalli , v6ops list , "dhcwg@ietf.org" Thread-Topic: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay Thread-Index: AQHVK3EUciY/hggKEUyles3tiq6GiaauCx7w Date: Wed, 26 Jun 2019 15:14:46 +0000 Message-ID: <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 02CB3CA020EFDF5E60DCA1D260E7641BB96C8B85F41B16CD69870F18471460082000:8 Content-Type: multipart/alternative; boundary="_000_3ad799f39ebb41e4a4435a7fdfcc41d0boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:15:25 -0000 --_000_3ad799f39ebb41e4a4435a7fdfcc41d0boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmF2ZWVuLA0KDQpUaGFua3MgZm9yIHRoZSBkcmFmdCDigJMgYSBxdWljayBxdWVzdGlvbiAt IHdoYXQgaXMgbWVhbnQgYnkg4oCcREhDUHY2IHJlbGF5IGZ1bmN0aW9uIGlzIG5vdCBjby1sb2Nh dGVkDQp3aXRoIHRoZSBESENQdjYgc2VydmVyIGZ1bmN0aW9u4oCdLiBEb2VzIGl0IG1lYW4g4oCc Y28tbG9jYXRlZOKAnSBhcyBpbiB3aXRoaW4gdGhlIHNhbWUgcHJvY2Vzcywgd2l0aGluDQp0aGUg c2FtZSB2aXJ0dWFsIG1hY2hpbmUsIHdpdGhpbiB0aGUgc2FtZSBwaHlzaWNhbCBib3gsIHdpdGhp biB0aGUgc2FtZSBMQU4sIGV0Yy4/DQoNClJGQzYyMjEgYWxsb3dzIGZvciB0aGUgcmVsYXkgZnVu Y3Rpb24gdG8gYmUgaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIGZyb20gdGhlIHNlcnZlciBmdW5jdGlv biBidXQNCndpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lzdGVtIGluc3RhbmNlLiBTbywgdGhl IHR3byBwcm9jZXNzZXMgc2hhcmUgdGhlIHNhbWUgY2xvY2ssIElQDQpmb3J3YXJkaW5nIHRhYmxl LCBzeXN0ZW0gbWVtb3J5LCBldGMuIEluIHN1Y2ggYW4gYXJyYW5nZW1lbnQsIGNhbiBpdCBiZSBz YWlkIHRoYXQgdGhlIERIQ1B2Ng0KcmVsYXkgYW5kIHNlcnZlciBmdW5jdGlvbnMgYXJlIGluIGZh Y3Qg4oCcY28tbG9jYXRlZOKAnSBldmVuIGlmIHRoZXkgZG8gbm90IHJlc2lkZSB3aXRoaW4gdGhl IHNhbWUNCnByb2Nlc3MgY29udGV4dD8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBkaGN3ZyBb bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXZlZW4gS290dGFw YWxsaQ0KU2VudDogVHVlc2RheSwgSnVuZSAyNSwgMjAxOSA5OjE0IEFNDQpUbzogdjZvcHMgbGlz dCA8djZvcHNAaWV0Zi5vcmc+OyBkaGN3Z0BpZXRmLm9yZw0KQ2M6IE1hcnRpbiBIdW5layA8bWFy dGluLmh1bmVrQHR1bC5jej4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9u YWwgSGVhZGFjaGU6IERIQ1AgVjYgUmVsYXkNCg0KSGVsbG8gQWxsLA0KDQpBIG5ldyBkcmFmdCBv biB0aGlzIHN1YmplY3QgaXMgc3VibWl0dGVkIHRvZGF5LiAgUGxlYXNlIGdvIHRocm91Z2ggdGhl IHNhbWUgaW4gYmVsb3cgbGluayBhbmQgbGV0IHVzIGtub3cgeW91ciBmZWVkYmFjay4NCg0KLS0t LQ0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5 LXJlcXVpcmVtZW50cy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg TmF2ZWVuIEtvdHRhcGFsbGkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgIGRyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVu dHMNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIERIQ1B2NiBQcmVmaXggRGVs ZWdhdGluZyByZWxheQ0KRG9jdW1lbnQgZGF0ZTogIDIwMTktMDYtMjUNCkdyb3VwOiAgICAgICAg ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMA0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ma2hwLWRoYy1k aGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxh eS1yZXF1aXJlbWVudHMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDANCkh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZr aHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCg0KDQpBYnN0cmFjdDoNCiAgIE9w ZXJhdGlvbmFsIGV4cGVyaWVuY2Ugd2l0aCBESENQdjYgcHJlZml4IGRlbGVnYXRpb24gaGFzIHNo b3duIHRoYXQNCiAgIHdoZW4gdGhlIERIQ1B2NiByZWxheSBmdW5jdGlvbiBpcyBub3QgY28tbG9j YXRlZCB3aXRoIHRoZSBESENQdjYNCiAgIHNlcnZlciBmdW5jdGlvbiwgaXNzdWVzIHN1Y2ggYXMg dGltZXIgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlDQogICBESENQIGZ1bmN0aW9uYWwgZWxl bWVudHMsIHJlamVjdGlvbiBvZiBjbGllbnQncyBtZXNzYWdlcyBieSB0aGUNCiAgIHJlbGF5LCBh bmQgb3RoZXIgcHJvYmxlbXMgaGF2ZSBiZWVuIG9ic2VydmVkLiAgVGhlc2UgcHJvYmxlbXMgY2Fu DQogICByZXN1bHQgaW4gcHJlZml4IGRlbGVnYXRpb24gZmFpbGluZyBvciB0cmFmZmljIHRvL2Zy b20gY2xpZW50cw0KICAgYWRkcmVzc2VkIGZyb20gdGhlIGRlbGVnYXRlZCBwcmVmaXggYmVpbmcg dW5yb3V0ZWFibGUuICBBbHRob3VnaA0KICAgW1JGQzg0MTVdIG1lbnRpb25zIHRoaXMgZGVwbG95 bWVudCBzY2VuYXJpbywgaXQgZG9lcyBub3QgcHJvdmlkZQ0KICAgbmVjZXNzYXJ5IGRldGFpbCBv biBob3cgdGhlIHJlbGF5IGVsZW1lbnQgc2hvdWxkIGJlaGF2ZSB3aGVuIHVzZWQNCiAgIHdpdGgg UEQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRz IGZvciBhIERIQ1B2NiBQRCByZWxheQ0KICAgd2hlbiB1c2VkIGZvciByZWxheWluZyBwcmVmaXhl cyBkZWxlZ2F0ZWQgYnkgYSBzZXBhcmF0ZSBESENQdjYNCiAgIHNlcnZlci4NCg0KWW91cnMsDQpO YXZlZW4uDQoNCg0KT24gTW9uLCAxIEFwciAyMDE5IGF0IDE4OjM0LCA8aWFuZmFycmVyQGdteC5j b208bWFpbHRvOmlhbmZhcnJlckBnbXguY29tPj4gd3JvdGU6DQpIaSBNYXJ0aW4sDQoNCkkgd291 bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gdGhpcyBhcyBpdOKAmXMgYSBwcm9i bGVtIGZvciB1cy4gSeKAmXZlIGdvdCBzb21ldGhpbmcgSSB3cm90ZSBhIHdoaWxlIGJhY2suIEni gJlsbCBzaGFyZSBpdCBhcyBhIHN0YXJ0aW5nIHBvaW50Lg0KDQpDaGVlcnMsDQpJYW4NCg0KPiBP biAxLiBBcHIgMjAxOSwgYXQgMTE6MzEsIE1hcnRpbiBIdW5layA8bWFydGluLmh1bmVrQHR1bC5j ejxtYWlsdG86bWFydGluLmh1bmVrQHR1bC5jej4+IHdyb3RlOg0KPg0KPiBIaSBGcmVkLA0KPg0K PiBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLCBhcyBpdCBpcyB0 aGUgb25lIEknbSBhbHNvIGhhdmluZy4gQnV0IEkgd291bGQgbmVlZCBzb21lIGFzc2lzdGFuY2Us IGFzIEkgZG9uJ3QgcmVhbGx5IGtub3cgbXkgd2F5cyBhcm91bmQgSUVURiBwcm9jZXNzZXMgeWV0 Lg0KPg0KPiBNYXJ0aW4NCj4NCj4gRG5lIHDDoXRlayAyOS4gYsWZZXpuYSAyMDE5IDY6Mzc6MjUg Q0VTVCwgRnJlZCBCYWtlciBuYXBzYWwoYSk6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9zbGlkZXMtMTA0LXY2b3BzLWRldXRzY2hlLXRlbGVrb20tdGVyYXN0cmVhbS8sIHNs aWRlIDMtNA0KPj4NCj4+IFdoYXQgZG8gd2Ugd2FudCB0byBzYXkgYWJvdXQgREhDUHY2IGlzc3Vl cyBpbiB2ZW5kb3IgcHJvZHVjdCBhbmQvb3Igc2VydmljZXM/IFRoaXMgaGVhZGFjaGUgZG9lc24n dCBoYXZlIGFuIG9idmlvdXMgZHJhZnQuIEkgdGhpbmsgdGhhdCBwcm9iYWJseSBjYWxscyBmb3Ig YSBwZXJzb24gb3IgZGVzaWduIHRlYW0gdG8gY3JlYXRlIHN1Y2ggYSBkcmFmdCBmb3IgZGlzY3Vz c2lvbiBvbiB0aGUgbGlzdCBhbmQgaW4gTW9udHJlYWwuDQo+Pg0KPj4gQW55IHRha2Vycz8NCj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGln aHdheSB0byBoZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBj b21tZW50IG9uIHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLg0KPj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0Bp ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_3ad799f39ebb41e4a4435a7fdfcc41d0boeingcom_ 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 ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE5h dmVlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBm b3IgdGhlIGRyYWZ0IOKAkyBhIHF1aWNrIHF1ZXN0aW9uIC0gd2hhdCBpcyBtZWFudCBieSDigJxE SENQdjYgcmVsYXkgZnVuY3Rpb24gaXMgbm90IGNvLWxvY2F0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ d2l0aCB0aGUgREhDUHY2IHNlcnZlciBmdW5jdGlvbuKAnS4gRG9lcyBpdCBtZWFuIOKAnGNvLWxv Y2F0ZWTigJ0gYXMgaW4gd2l0aGluIHRoZSBzYW1lIHByb2Nlc3MsIHdpdGhpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj50aGUgc2FtZSB2aXJ0dWFsIG1hY2hpbmUsIHdpdGhpbiB0aGUgc2FtZSBwaHlzaWNh bCBib3gsIHdpdGhpbiB0aGUgc2FtZSBMQU4sIGV0Yy4/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SRkM2MjIxIGFsbG93cyBmb3IgdGhlIHJlbGF5IGZ1bmN0aW9u IHRvIGJlIGluIGEgc2VwYXJhdGUgcHJvY2VzcyBmcm9tIHRoZSBzZXJ2ZXIgZnVuY3Rpb24gYnV0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPndpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lzdGVtIGluc3Rh bmNlLiBTbywgdGhlIHR3byBwcm9jZXNzZXMgc2hhcmUgdGhlIHNhbWUgY2xvY2ssIElQPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmZvcndhcmRpbmcgdGFibGUsIHN5c3RlbSBtZW1vcnksIGV0Yy4gSW4gc3Vj aCBhbiBhcnJhbmdlbWVudCwgY2FuIGl0IGJlIHNhaWQgdGhhdCB0aGUgREhDUHY2PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPnJlbGF5IGFuZCBzZXJ2ZXIgZnVuY3Rpb25zIGFyZSBpbiBmYWN0IOKAnGNvLWxv Y2F0ZWTigJ0gZXZlbiBpZiB0aGV5IGRvIG5vdCByZXNpZGUgd2l0aGluIHRoZSBzYW1lPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPnByb2Nlc3MgY29udGV4dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBkaGN3ZyBbbWFpbHRvOmRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5hdmVlbiBLb3R0YXBh bGxpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTkgOToxNCBBTTxicj4N CjxiPlRvOjwvYj4gdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyBkaGN3Z0BpZXRm Lm9yZzxicj4NCjxiPkNjOjwvYj4gTWFydGluIEh1bmVrICZsdDttYXJ0aW4uaHVuZWtAdHVsLmN6 Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBbdjZvcHNdIE9wZXJhdGlvbmFs IEhlYWRhY2hlOiBESENQIFY2IFJlbGF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmV3IGRyYWZ0IG9uIHRoaXMgc3ViamVjdCBpcyBzdWJt aXR0ZWQgdG9kYXkuJm5ic3A7IFBsZWFzZSBnbyB0aHJvdWdoIHRoZSBzYW1lIGluIGJlbG93IGxp bmsgYW5kIGxldCB1cyBrbm93IHlvdXIgZmVlZGJhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAudHh0PGJyPg0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYXZlZW4gS290dGFwYWxsaSBhbmQgcG9z dGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBk LXJlbGF5LXJlcXVpcmVtZW50czxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBESENQ djYgUHJlZml4IERlbGVnYXRpbmcgcmVsYXk8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE5 LTA2LTI1PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDEwPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAudHh0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZraHAt ZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAudHh0PC9hPjxicj4NClN0YXR1czom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVt ZW50cy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLzwvYT48YnI+DQpIdG1s aXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy0w MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ma2hw LWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwPC9hPjxicj4NCkh0bWxpemVkOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50 cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50czwvYT48YnI+DQo8YnI+ DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7T3BlcmF0aW9uYWwgZXhwZXJpZW5j ZSB3aXRoIERIQ1B2NiBwcmVmaXggZGVsZWdhdGlvbiBoYXMgc2hvd24gdGhhdDxicj4NCiZuYnNw OyAmbmJzcDt3aGVuIHRoZSBESENQdjYgcmVsYXkgZnVuY3Rpb24gaXMgbm90IGNvLWxvY2F0ZWQg d2l0aCB0aGUgREhDUHY2PGJyPg0KJm5ic3A7ICZuYnNwO3NlcnZlciBmdW5jdGlvbiwgaXNzdWVz IHN1Y2ggYXMgdGltZXIgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlPGJyPg0KJm5ic3A7ICZu YnNwO0RIQ1AgZnVuY3Rpb25hbCBlbGVtZW50cywgcmVqZWN0aW9uIG9mIGNsaWVudCdzIG1lc3Nh Z2VzIGJ5IHRoZTxicj4NCiZuYnNwOyAmbmJzcDtyZWxheSwgYW5kIG90aGVyIHByb2JsZW1zIGhh dmUgYmVlbiBvYnNlcnZlZC4mbmJzcDsgVGhlc2UgcHJvYmxlbXMgY2FuPGJyPg0KJm5ic3A7ICZu YnNwO3Jlc3VsdCBpbiBwcmVmaXggZGVsZWdhdGlvbiBmYWlsaW5nIG9yIHRyYWZmaWMgdG8vZnJv bSBjbGllbnRzPGJyPg0KJm5ic3A7ICZuYnNwO2FkZHJlc3NlZCBmcm9tIHRoZSBkZWxlZ2F0ZWQg cHJlZml4IGJlaW5nIHVucm91dGVhYmxlLiZuYnNwOyBBbHRob3VnaDxicj4NCiZuYnNwOyAmbmJz cDtbUkZDODQxNV0gbWVudGlvbnMgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvLCBpdCBkb2VzIG5v dCBwcm92aWRlPGJyPg0KJm5ic3A7ICZuYnNwO25lY2Vzc2FyeSBkZXRhaWwgb24gaG93IHRoZSBy ZWxheSBlbGVtZW50IHNob3VsZCBiZWhhdmUgd2hlbiB1c2VkPGJyPg0KJm5ic3A7ICZuYnNwO3dp dGggUEQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZ1 bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciBhIERIQ1B2NiBQRCByZWxheTxicj4NCiZuYnNwOyAm bmJzcDt3aGVuIHVzZWQgZm9yIHJlbGF5aW5nIHByZWZpeGVzIGRlbGVnYXRlZCBieSBhIHNlcGFy YXRlIERIQ1B2Njxicj4NCiZuYnNwOyAmbmJzcDtzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91cnMsPGJyPg0KTmF2ZWVuLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIDEgQXByIDIwMTkgYXQgMTg6MzQsICZsdDs8YSBocmVmPSJtYWlsdG86aWFuZmFycmVyQGdt eC5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5mYXJyZXJAZ214LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgTWFydGluLDxicj4NCjxicj4NCkkgd291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIHdvcmtp bmcgb24gdGhpcyBhcyBpdOKAmXMgYSBwcm9ibGVtIGZvciB1cy4gSeKAmXZlIGdvdCBzb21ldGhp bmcgSSB3cm90ZSBhIHdoaWxlIGJhY2suIEnigJlsbCBzaGFyZSBpdCBhcyBhIHN0YXJ0aW5nIHBv aW50Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpJYW48YnI+DQo8YnI+DQomZ3Q7IE9uIDEuIEFw ciAyMDE5LCBhdCAxMTozMSwgTWFydGluIEh1bmVrICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGlu Lmh1bmVrQHR1bC5jeiIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi5odW5la0B0dWwuY3o8L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgRnJlZCw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSwgYXMgaXQgaXMg dGhlIG9uZSBJJ20gYWxzbyBoYXZpbmcuIEJ1dCBJIHdvdWxkIG5lZWQgc29tZSBhc3Npc3RhbmNl LCBhcyBJIGRvbid0IHJlYWxseSBrbm93IG15IHdheXMgYXJvdW5kIElFVEYgcHJvY2Vzc2VzIHll dC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFydGluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERuZSBw w6F0ZWsgMjkuIGLFmWV6bmEgMjAxOSA2OjM3OjI1IENFU1QsIEZyZWQgQmFrZXIgbmFwc2FsKGEp Ojxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L3NsaWRlcy0xMDQtdjZvcHMtZGV1dHNjaGUtdGVsZWtvbS10ZXJhc3RyZWFtLyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2xpZGVzLTEwNC12Nm9w cy1kZXV0c2NoZS10ZWxla29tLXRlcmFzdHJlYW0vPC9hPiwgc2xpZGUgMy00PGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgV2hhdCBkbyB3ZSB3YW50IHRvIHNheSBhYm91dCBESENQdjYgaXNz dWVzIGluIHZlbmRvciBwcm9kdWN0IGFuZC9vciBzZXJ2aWNlcz8gVGhpcyBoZWFkYWNoZSBkb2Vz bid0IGhhdmUgYW4gb2J2aW91cyBkcmFmdC4gSSB0aGluayB0aGF0IHByb2JhYmx5IGNhbGxzIGZv ciBhIHBlcnNvbiBvciBkZXNpZ24gdGVhbSB0byBjcmVhdGUgc3VjaCBhIGRyYWZ0IGZvciBkaXNj dXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBpbiBNb250cmVhbC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBBbnkgdGFrZXJzPzxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyZndDsgVGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIGhpZ2h3YXkgdG8gaGVsbCBh bmQgYSBzdGFpcndheSB0byBoZWF2ZW4gaXMgYW4gaW50ZXJlc3RpbmcgY29tbWVudCBvbiBwcm9q ZWN0ZWQgdHJhZmZpYyB2b2x1bWUuLi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_3ad799f39ebb41e4a4435a7fdfcc41d0boeingcom_-- From nobody Wed Jun 26 08:22:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77AC120074; Wed, 26 Jun 2019 08:22:28 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLeYB6X9PSRF; Wed, 26 Jun 2019 08:22:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418AD12004D; Wed, 26 Jun 2019 08:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1561562532; bh=isDWTmYR+1HNWXJ3htTLcqX44oPAd0aSm++MZPzYPJM=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=bATTYmg68e/u1YfkmT4pMuveSrqhasM0j/VDilcbuBz0PorBDD+9L3iJH8LIMsNcI ynx5ypRTdmqrjVT/31QobrZD3rL1Gr+p7v8HwGl+AIiH0nIrwl1KiC479NYWcCpc0h mn8Fwe5KeBb6XC/JEYvzX8RHSmyUs8kHsH9dotIk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.78.36.51]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N0X8u-1iTb4i22Bo-00wWNo; Wed, 26 Jun 2019 17:22:12 +0200 From: ianfarrer@gmx.com Message-Id: <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3FB3A4AC-688B-4DA8-BFEC-1D028521B6EC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 17:22:10 +0200 In-Reply-To: <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> Cc: Naveen Kottapalli , v6ops list , "dhcwg@ietf.org" , Martin Hunek To: "Templin (US), Fred L" References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:iWss4SeSwEh+DfMYMpVsz7zlQdTnAcEH6sS8DypyRyWfr+rzQAo a0RYcUmh/VSuLOUV4vtn2ktcmMkwJm7txeKTOR4CE107U3Lsr1s/y5yzj36lidV5e4AeNTF DegNg6MP8FB0XeRma/dqeJb7Y9vnyXP2fuvoEetNikcK1qeSGOPTOsUM+ERY+nqNELbOa6G 1vhQfb0wipSk700UgEKwg== X-UI-Out-Filterresults: notjunk:1;V03:K0:IjHetrFKv0s=:SPUD87s5sHizSlx1ri9N+V GU6v4rEEUzuW7sXJf+AR5VgGh9aLe55GvUtmKJhHz8y7WHwAPSn7PfAToCRMy3P3A/1sgslYo 8pPjZrGamujPm1K/HDJdluUCdmsuxxqlLYlqIAvQ2sdITJV37MaqodubHDt7iry0nnWJnEPcG PyZcl/rbeXum1U743aqXm5S0EQFciI2GpnEHtR4B8ejm4t6qtR8zITNEs4WWdg7nJCyRXQ3pq pB5atbY6LFZm1JZpuTvhKULijqzPIZ0HY1NEDhqdoBQBVgowmp4qTS/sAfuq9T1fOMqazx+Xa wcHrZeAMqM/rqgo/T3iTuBXZUiFa9xG/KtWOP+KRsApcD+xQ1bX2HQifuI51n3OUfci044N89 rlH50nRwtqHqLCCvW1/XVeJusqCihRbwjtOw72OpjOJFjUsVRxQk2IE27Pxr+rSGxpma/qHHU QU/NPwTLldS5pfVxGHPdM6VETlcCujDWbutfqApcVxVFs3NwV7CMPhSS0ZPOC2oSP4dxTpA17 rnkPdNiY/VWzUPoEWvM1fdOR+JFhysklMOQFXuuFF411IApKsj8eTf3v1UwMlhp8PDGzaQwZp IkjDPLZ5PJTw5zslMgbQAEnwKDIeTDbIPITcx7MZ23nbjNh2vgOAu2rpnJp/YeIcBFmXG3iNs PTZMfAsi/W1zp6wOOxPaFeJfK5fSDQaT/2RjniVffZLx3hDhXrsEHyZ2+a9WVfWttck673VK3 uMTXYqUoi+ZW5t9MXy/EdEKKUMsTeWNGUQ3+VKBh7tKMWR8q1CM78RGX/uWuEuptTpULrv8ae ZAYiK1eaoAOFY7rJr8CEyDnitftki9/LHAWhjBt387bCbCm2QHMW3rRYdUgNhgfQM9QvayHjl 5C1XZgqi6A90e+sMMIw2tjJ5wqkjKi8+dM1U6TeOvwHjOjIC9b167z2Ay7hIDvXwjJtfk7EOg +HRWc8Cq/4FfaYvEMi0LMkYS2NLy+LAigJw/Fs0WCwi7cyofTvJj9 Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:22:29 -0000 --Apple-Mail=_3FB3A4AC-688B-4DA8-BFEC-1D028521B6EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fred, In this instance, we are talking about being in a separate physical box, = or VM. The problems I=E2=80=99ve observed are with L3 edge routers with the relay function in the access network with a centralised DHCPv6 = server. We can clarify this better in the next update. Thanks, Ian > On 26. Jun 2019, at 17:14, Templin (US), Fred L = wrote: >=20 > Hi Naveen, > =20 > Thanks for the draft =E2=80=93 a quick question - what is meant by = =E2=80=9CDHCPv6 relay function is not co-located > with the DHCPv6 server function=E2=80=9D. Does it mean = =E2=80=9Cco-located=E2=80=9D as in within the same process, within > the same virtual machine, within the same physical box, within the = same LAN, etc.? > =20 > RFC6221 allows for the relay function to be in a separate process from = the server function but > within the same operating system instance. So, the two processes share = the same clock, IP > forwarding table, system memory, etc. In such an arrangement, can it = be said that the DHCPv6 > relay and server functions are in fact =E2=80=9Cco-located=E2=80=9D = even if they do not reside within the same > process context? > =20 > Thanks - Fred > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Naveen Kottapalli > Sent: Tuesday, June 25, 2019 9:14 AM > To: v6ops list >; = dhcwg@ietf.org > Cc: Martin Hunek > > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay > =20 > Hello All, > =20 > A new draft on this subject is submitted today. Please go through the = same in below link and let us know your feedback. > =20 > ---- > =20 > A new version of I-D, = draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt > has been successfully submitted by Naveen Kottapalli and posted to the > IETF repository. >=20 > Name: draft-fkhp-dhc-dhcpv6-pd-relay-requirements > Revision: 00 > Title: DHCPv6 Prefix Delegating relay > Document date: 2019-06-25 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requir= ements-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requiremen= ts/ = > Htmlized: = https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00= = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requi= rements = >=20 >=20 > Abstract: > Operational experience with DHCPv6 prefix delegation has shown that > when the DHCPv6 relay function is not co-located with the DHCPv6 > server function, issues such as timer synchronization between the > DHCP functional elements, rejection of client's messages by the > relay, and other problems have been observed. These problems can > result in prefix delegation failing or traffic to/from clients > addressed from the delegated prefix being unrouteable. Although > [RFC8415] mentions this deployment scenario, it does not provide > necessary detail on how the relay element should behave when used > with PD. >=20 > This document describes functional requirements for a DHCPv6 PD = relay > when used for relaying prefixes delegated by a separate DHCPv6 > server. > =20 > Yours, > Naveen. > =20 > =20 > On Mon, 1 Apr 2019 at 18:34, > wrote: > Hi Martin, >=20 > I would also be interested in working on this as it=E2=80=99s a = problem for us. I=E2=80=99ve got something I wrote a while back. I=E2=80=99= ll share it as a starting point. >=20 > Cheers, > Ian >=20 > > On 1. Apr 2019, at 11:31, Martin Hunek > wrote: > >=20 > > Hi Fred, > >=20 > > I would be interested to address this issue, as it is the one I'm = also having. But I would need some assistance, as I don't really know my = ways around IETF processes yet. > >=20 > > Martin > >=20 > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker = napsal(a): > >> = https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr= eam/ = , slide 3-4 > >>=20 > >> What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal. > >>=20 > >> Any takers? > >> = --------------------------------------------------------------------------= ------ > >> The fact that there is a highway to hell and a stairway to heaven = is an interesting comment on projected traffic volume... > >>=20 > >=20 > > _______________________________________________ > > 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 = _____________________________= __________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg = --Apple-Mail=_3FB3A4AC-688B-4DA8-BFEC-1D028521B6EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Fred,

In this = instance, we are talking about being in a separate physical box, or VM. = The problems I=E2=80=99ve observed are with  L3 edge routers = with
the relay function in the access network with = a centralised DHCPv6 server. We can clarify this better in the next = update.

Thanks,
Ian

On 26. = Jun 2019, at 17:14, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:

Hi Naveen,
 
Thanks for the draft = =E2=80=93 a quick question - what is meant by =E2=80=9CDHCPv6 relay = function is not co-located
with the DHCPv6 server function=E2=80=9D. Does it mean = =E2=80=9Cco-located=E2=80=9D as in within the same process, within
the same virtual = machine, within the same physical box, within the same LAN, etc.?
 
RFC6221 allows for the = relay function to be in a separate process from the server function = but
within the same = operating system instance. So, the two processes share the same clock, = IP
forwarding table, = system memory, etc. In such an arrangement, can it be said that the = DHCPv6
relay and server = functions are in fact =E2=80=9Cco-located=E2=80=9D even if they do not = reside within the same
process context?
 
Thanks - Fred
 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Naveen = Kottapalli
Sent: Tuesday, June 25, 2019 9:14 = AM
To: v6ops list <v6ops@ietf.org>; dhcwg@ietf.org
Cc: Martin Hunek <martin.hunek@tul.cz>
Subject: Re: [dhcwg] [v6ops] = Operational Headache: DHCP V6 Relay
 
Hello All,
 
A new draft = on this subject is submitted today.  Please go through the same in = below link and let us know your feedback.
 
----
 
A new = version of I-D, draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
has been successfully submitted by Naveen Kottapalli and = posted to the
IETF repository.

Name:          =  draft-fkhp-dhc-dhcpv6-pd-relay-requirements
Revision:       00
Title:          DHCPv6 Prefix = Delegating relay
Document date:  2019-06-25
Group:          Individual = Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-r= elay-requirements-00.txt
Status:      =    https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay= -requirements/
Htmlized:       https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requ= irements-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-= relay-requirements


Abstract:
   Operational experience = with DHCPv6 prefix delegation has shown that
  =  when the DHCPv6 relay function is not co-located with the = DHCPv6
   server function, issues such as timer = synchronization between the
   DHCP functional = elements, rejection of client's messages by the
  =  relay, and other problems have been observed.  These problems = can
   result in prefix delegation failing or = traffic to/from clients
   addressed from the = delegated prefix being unrouteable.  Although
  =  [RFC8415] mentions this deployment scenario, it does not = provide
   necessary detail on how the relay = element should behave when used
   with PD.

   This document describes = functional requirements for a DHCPv6 PD relay
  =  when used for relaying prefixes delegated by a separate DHCPv6
   server.
 
Yours,
Naveen.
 
 
On Mon, 1 = Apr 2019 at 18:34, <ianfarrer@gmx.com> wrote:
Hi = Martin,

I would also be interested in = working on this as it=E2=80=99s a problem for us. I=E2=80=99ve got = something I wrote a while back. I=E2=80=99ll share it as a starting = point.

Cheers,
Ian

> On 1. Apr 2019, at 11:31, Martin Hunek = <martin.hunek@tul.cz> wrote:
> 
> Hi = Fred,
> 
> I would = be interested to address this issue, as it is the one I'm also having. = But I would need some assistance, as I don't really know my ways around = IETF processes yet.
> 
> = Martin
> 
> Dne = p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a):
>> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-tele= kom-terastream/, slide 3-4
>> 
>> = What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal.
>> 
>> Any = takers?
>> = --------------------------------------------------------------------------= ------
>> The fact that there is a highway to hell = and a stairway to heaven is an interesting comment on projected traffic = volume...
>> 
> 
> = _______________________________________________
> 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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --Apple-Mail=_3FB3A4AC-688B-4DA8-BFEC-1D028521B6EC-- From nobody Wed Jun 26 08:28:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0112004D; Wed, 26 Jun 2019 08:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 fYhkNX2UKA2I; Wed, 26 Jun 2019 08:28:02 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECB212015B; Wed, 26 Jun 2019 08:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x5QFRxmP007057; Wed, 26 Jun 2019 11:27:59 -0400 Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x5QFRvSX007041 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 11:27:57 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 26 Jun 2019 08:27:56 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Wed, 26 Jun 2019 08:27:56 -0700 From: "Templin (US), Fred L" To: "ianfarrer@gmx.com" CC: Naveen Kottapalli , v6ops list , "dhcwg@ietf.org" , Martin Hunek Thread-Topic: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay Thread-Index: AQHVK3EUciY/hggKEUyles3tiq6GiaauCx7wgAB5MAD//4rxUA== Date: Wed, 26 Jun 2019 15:27:55 +0000 Message-ID: References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> In-Reply-To: <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 1F8921144509B9369B1909875B92837A01CB1C807F1726482FF30641AA7E06672000:8 Content-Type: multipart/alternative; boundary="_000_e0e7576d188141c088e7baf89d5cdc2dboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:28:06 -0000 --_000_e0e7576d188141c088e7baf89d5cdc2dboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuIOKAkyB5ZXMsIGEgY2xhcmlmaWNhdGlvbiBvZiDigJxjby1sb2NhdGVk4oCdIHdvdWxk IGJlIGdyZWF0LiBTb3VuZHMgbGlrZSB0aGVyZSBpcw0Kbm90IGEgY29uY2VybiB3aGVuIHRoZSBy ZWxheSBhbmQgc2VydmVyIGFyZSBpbiB0aGUgc2FtZSBib3ggb3IgVk0sIHJpZ2h0Pw0KDQpUaGFu a3MgLSBGcmVkDQoNCkZyb206IGlhbmZhcnJlckBnbXguY29tIFttYWlsdG86aWFuZmFycmVyQGdt eC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjYsIDIwMTkgODoyMiBBTQ0KVG86IFRlbXBs aW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IE5hdmVlbiBL b3R0YXBhbGxpIDxuYXZlZW4uc2FybWFAZ21haWwuY29tPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0 Zi5vcmc+OyBkaGN3Z0BpZXRmLm9yZzsgTWFydGluIEh1bmVrIDxtYXJ0aW4uaHVuZWtAdHVsLmN6 Pg0KU3ViamVjdDogUmU6IFtkaGN3Z10gW3Y2b3BzXSBPcGVyYXRpb25hbCBIZWFkYWNoZTogREhD UCBWNiBSZWxheQ0KDQpIaSBGcmVkLA0KDQpJbiB0aGlzIGluc3RhbmNlLCB3ZSBhcmUgdGFsa2lu ZyBhYm91dCBiZWluZyBpbiBhIHNlcGFyYXRlIHBoeXNpY2FsIGJveCwgb3IgVk0uIFRoZSBwcm9i bGVtcyBJ4oCZdmUgb2JzZXJ2ZWQgYXJlIHdpdGggIEwzIGVkZ2Ugcm91dGVycyB3aXRoDQp0aGUg cmVsYXkgZnVuY3Rpb24gaW4gdGhlIGFjY2VzcyBuZXR3b3JrIHdpdGggYSBjZW50cmFsaXNlZCBE SENQdjYgc2VydmVyLiBXZSBjYW4gY2xhcmlmeSB0aGlzIGJldHRlciBpbiB0aGUgbmV4dCB1cGRh dGUuDQoNClRoYW5rcywNCklhbg0KDQoNCk9uIDI2LiBKdW4gMjAxOSwgYXQgMTc6MTQsIFRlbXBs aW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQoNCkhpIE5hdmVlbiwNCg0KVGhhbmtzIGZvciB0 aGUgZHJhZnQg4oCTIGEgcXVpY2sgcXVlc3Rpb24gLSB3aGF0IGlzIG1lYW50IGJ5IOKAnERIQ1B2 NiByZWxheSBmdW5jdGlvbiBpcyBub3QgY28tbG9jYXRlZA0Kd2l0aCB0aGUgREhDUHY2IHNlcnZl ciBmdW5jdGlvbuKAnS4gRG9lcyBpdCBtZWFuIOKAnGNvLWxvY2F0ZWTigJ0gYXMgaW4gd2l0aGlu IHRoZSBzYW1lIHByb2Nlc3MsIHdpdGhpbg0KdGhlIHNhbWUgdmlydHVhbCBtYWNoaW5lLCB3aXRo aW4gdGhlIHNhbWUgcGh5c2ljYWwgYm94LCB3aXRoaW4gdGhlIHNhbWUgTEFOLCBldGMuPw0KDQpS RkM2MjIxIGFsbG93cyBmb3IgdGhlIHJlbGF5IGZ1bmN0aW9uIHRvIGJlIGluIGEgc2VwYXJhdGUg cHJvY2VzcyBmcm9tIHRoZSBzZXJ2ZXIgZnVuY3Rpb24gYnV0DQp3aXRoaW4gdGhlIHNhbWUgb3Bl cmF0aW5nIHN5c3RlbSBpbnN0YW5jZS4gU28sIHRoZSB0d28gcHJvY2Vzc2VzIHNoYXJlIHRoZSBz YW1lIGNsb2NrLCBJUA0KZm9yd2FyZGluZyB0YWJsZSwgc3lzdGVtIG1lbW9yeSwgZXRjLiBJbiBz dWNoIGFuIGFycmFuZ2VtZW50LCBjYW4gaXQgYmUgc2FpZCB0aGF0IHRoZSBESENQdjYNCnJlbGF5 IGFuZCBzZXJ2ZXIgZnVuY3Rpb25zIGFyZSBpbiBmYWN0IOKAnGNvLWxvY2F0ZWTigJ0gZXZlbiBp ZiB0aGV5IGRvIG5vdCByZXNpZGUgd2l0aGluIHRoZSBzYW1lDQpwcm9jZXNzIGNvbnRleHQ/DQoN ClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTmF2ZWVuIEtvdHRhcGFsbGkNClNlbnQ6IFR1ZXNkYXksIEp1bmUg MjUsIDIwMTkgOToxNCBBTQ0KVG86IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2 Nm9wc0BpZXRmLm9yZz4+OyBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQpD YzogTWFydGluIEh1bmVrIDxtYXJ0aW4uaHVuZWtAdHVsLmN6PG1haWx0bzptYXJ0aW4uaHVuZWtA dHVsLmN6Pj4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVhZGFj aGU6IERIQ1AgVjYgUmVsYXkNCg0KSGVsbG8gQWxsLA0KDQpBIG5ldyBkcmFmdCBvbiB0aGlzIHN1 YmplY3QgaXMgc3VibWl0dGVkIHRvZGF5LiAgUGxlYXNlIGdvIHRocm91Z2ggdGhlIHNhbWUgaW4g YmVsb3cgbGluayBhbmQgbGV0IHVzIGtub3cgeW91ciBmZWVkYmFjay4NCg0KLS0tLQ0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVt ZW50cy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmF2ZWVuIEtv dHRhcGFsbGkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgICAgIGRyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNClJldmlz aW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIERIQ1B2NiBQcmVmaXggRGVsZWdhdGluZyBy ZWxheQ0KRG9jdW1lbnQgZGF0ZTogIDIwMTktMDYtMjUNCkdyb3VwOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMA0KVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQt cmVsYXktcmVxdWlyZW1lbnRzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJl bWVudHMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDANCkh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZraHAtZGhjLWRo Y3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCg0KDQpBYnN0cmFjdDoNCiAgIE9wZXJhdGlvbmFs IGV4cGVyaWVuY2Ugd2l0aCBESENQdjYgcHJlZml4IGRlbGVnYXRpb24gaGFzIHNob3duIHRoYXQN CiAgIHdoZW4gdGhlIERIQ1B2NiByZWxheSBmdW5jdGlvbiBpcyBub3QgY28tbG9jYXRlZCB3aXRo IHRoZSBESENQdjYNCiAgIHNlcnZlciBmdW5jdGlvbiwgaXNzdWVzIHN1Y2ggYXMgdGltZXIgc3lu Y2hyb25pemF0aW9uIGJldHdlZW4gdGhlDQogICBESENQIGZ1bmN0aW9uYWwgZWxlbWVudHMsIHJl amVjdGlvbiBvZiBjbGllbnQncyBtZXNzYWdlcyBieSB0aGUNCiAgIHJlbGF5LCBhbmQgb3RoZXIg cHJvYmxlbXMgaGF2ZSBiZWVuIG9ic2VydmVkLiAgVGhlc2UgcHJvYmxlbXMgY2FuDQogICByZXN1 bHQgaW4gcHJlZml4IGRlbGVnYXRpb24gZmFpbGluZyBvciB0cmFmZmljIHRvL2Zyb20gY2xpZW50 cw0KICAgYWRkcmVzc2VkIGZyb20gdGhlIGRlbGVnYXRlZCBwcmVmaXggYmVpbmcgdW5yb3V0ZWFi bGUuICBBbHRob3VnaA0KICAgW1JGQzg0MTVdIG1lbnRpb25zIHRoaXMgZGVwbG95bWVudCBzY2Vu YXJpbywgaXQgZG9lcyBub3QgcHJvdmlkZQ0KICAgbmVjZXNzYXJ5IGRldGFpbCBvbiBob3cgdGhl IHJlbGF5IGVsZW1lbnQgc2hvdWxkIGJlaGF2ZSB3aGVuIHVzZWQNCiAgIHdpdGggUEQuDQoNCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciBhIERI Q1B2NiBQRCByZWxheQ0KICAgd2hlbiB1c2VkIGZvciByZWxheWluZyBwcmVmaXhlcyBkZWxlZ2F0 ZWQgYnkgYSBzZXBhcmF0ZSBESENQdjYNCiAgIHNlcnZlci4NCg0KWW91cnMsDQpOYXZlZW4uDQoN Cg0KT24gTW9uLCAxIEFwciAyMDE5IGF0IDE4OjM0LCA8aWFuZmFycmVyQGdteC5jb208bWFpbHRv OmlhbmZhcnJlckBnbXguY29tPj4gd3JvdGU6DQpIaSBNYXJ0aW4sDQoNCkkgd291bGQgYWxzbyBi ZSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gdGhpcyBhcyBpdOKAmXMgYSBwcm9ibGVtIGZvciB1 cy4gSeKAmXZlIGdvdCBzb21ldGhpbmcgSSB3cm90ZSBhIHdoaWxlIGJhY2suIEnigJlsbCBzaGFy ZSBpdCBhcyBhIHN0YXJ0aW5nIHBvaW50Lg0KDQpDaGVlcnMsDQpJYW4NCg0KPiBPbiAxLiBBcHIg MjAxOSwgYXQgMTE6MzEsIE1hcnRpbiBIdW5layA8bWFydGluLmh1bmVrQHR1bC5jejxtYWlsdG86 bWFydGluLmh1bmVrQHR1bC5jej4+IHdyb3RlOg0KPg0KPiBIaSBGcmVkLA0KPg0KPiBJIHdvdWxk IGJlIGludGVyZXN0ZWQgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLCBhcyBpdCBpcyB0aGUgb25lIEkn bSBhbHNvIGhhdmluZy4gQnV0IEkgd291bGQgbmVlZCBzb21lIGFzc2lzdGFuY2UsIGFzIEkgZG9u J3QgcmVhbGx5IGtub3cgbXkgd2F5cyBhcm91bmQgSUVURiBwcm9jZXNzZXMgeWV0Lg0KPg0KPiBN YXJ0aW4NCj4NCj4gRG5lIHDDoXRlayAyOS4gYsWZZXpuYSAyMDE5IDY6Mzc6MjUgQ0VTVCwgRnJl ZCBCYWtlciBuYXBzYWwoYSk6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9z bGlkZXMtMTA0LXY2b3BzLWRldXRzY2hlLXRlbGVrb20tdGVyYXN0cmVhbS8sIHNsaWRlIDMtNA0K Pj4NCj4+IFdoYXQgZG8gd2Ugd2FudCB0byBzYXkgYWJvdXQgREhDUHY2IGlzc3VlcyBpbiB2ZW5k b3IgcHJvZHVjdCBhbmQvb3Igc2VydmljZXM/IFRoaXMgaGVhZGFjaGUgZG9lc24ndCBoYXZlIGFu IG9idmlvdXMgZHJhZnQuIEkgdGhpbmsgdGhhdCBwcm9iYWJseSBjYWxscyBmb3IgYSBwZXJzb24g b3IgZGVzaWduIHRlYW0gdG8gY3JlYXRlIHN1Y2ggYSBkcmFmdCBmb3IgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdCBhbmQgaW4gTW9udHJlYWwuDQo+Pg0KPj4gQW55IHRha2Vycz8NCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+PiBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGlnaHdheSB0byBo ZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBjb21tZW50IG9u IHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLg0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2 b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== --_000_e0e7576d188141c088e7baf89d5cdc2dboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIElhbiDigJMgeWVz LCBhIGNsYXJpZmljYXRpb24gb2Yg4oCcY28tbG9jYXRlZOKAnSB3b3VsZCBiZSBncmVhdC4gU291 bmRzIGxpa2UgdGhlcmUgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bm90IGEgY29uY2VybiB3aGVuIHRo ZSByZWxheSBhbmQgc2VydmVyIGFyZSBpbiB0aGUgc2FtZSBib3ggb3IgVk0sIHJpZ2h0PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IGlhbmZhcnJlckBnbXguY29tIFttYWlsdG86aWFuZmFycmVyQGdteC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDI2LCAyMDE5IDg6MjIgQU08YnI+DQo8Yj5U bzo8L2I+IFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmF2ZWVuIEtvdHRhcGFsbGkgJmx0O25hdmVlbi5zYXJtYUBn bWFpbC5jb20mZ3Q7OyB2Nm9wcyBsaXN0ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRoY3dnQGll dGYub3JnOyBNYXJ0aW4gSHVuZWsgJmx0O21hcnRpbi5odW5la0B0dWwuY3omZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVhZGFjaGU6IERI Q1AgVjYgUmVsYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBGcmVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gdGhpcyBpbnN0YW5jZSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYmVpbmcgaW4gYSBzZXBhcmF0 ZSBwaHlzaWNhbCBib3gsIG9yIFZNLiBUaGUgcHJvYmxlbXMgSeKAmXZlIG9ic2VydmVkIGFyZSB3 aXRoICZuYnNwO0wzIGVkZ2Ugcm91dGVycyB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgcmVsYXkgZnVuY3Rpb24gaW4gdGhlIGFjY2Vz cyBuZXR3b3JrIHdpdGggYSBjZW50cmFsaXNlZCBESENQdjYgc2VydmVyLiBXZSBjYW4gY2xhcmlm eSB0aGlzIGJldHRlciBpbiB0aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklhbjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjYuIEp1biAyMDE5LCBhdCAxNzoxNCwgVGVt cGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgTmF2ZWVuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZHJh ZnQg4oCTIGEgcXVpY2sgcXVlc3Rpb24gLSB3aGF0IGlzIG1lYW50IGJ5IOKAnERIQ1B2NiByZWxh eSBmdW5jdGlvbiBpcyBub3QgY28tbG9jYXRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj53aXRoIHRoZSBESENQdjYgc2VydmVyIGZ1bmN0aW9u4oCdLiBEb2VzIGl0IG1lYW4g4oCc Y28tbG9jYXRlZOKAnSBhcyBpbiB3aXRoaW4gdGhlIHNhbWUgcHJvY2Vzcywgd2l0aGluPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSBzYW1lIHZpcnR1YWwgbWFjaGluZSwgd2l0 aGluIHRoZSBzYW1lIHBoeXNpY2FsIGJveCwgd2l0aGluIHRoZSBzYW1lIExBTiwgZXRjLj88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlJGQzYyMjEgYWxsb3dzIGZvciB0aGUgcmVsYXkgZnVuY3Rpb24gdG8gYmUg aW4gYSBzZXBhcmF0ZSBwcm9jZXNzIGZyb20gdGhlIHNlcnZlciBmdW5jdGlvbiBidXQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aGluIHRoZSBzYW1lIG9wZXJhdGluZyBzeXN0 ZW0gaW5zdGFuY2UuIFNvLCB0aGUgdHdvIHByb2Nlc3NlcyBzaGFyZSB0aGUgc2FtZSBjbG9jaywg SVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Zm9yd2FyZGluZyB0YWJsZSwgc3lz dGVtIG1lbW9yeSwgZXRjLiBJbiBzdWNoIGFuIGFycmFuZ2VtZW50LCBjYW4gaXQgYmUgc2FpZCB0 aGF0IHRoZSBESENQdjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmVsYXkgYW5k IHNlcnZlciBmdW5jdGlvbnMgYXJlIGluIGZhY3Qg4oCcY28tbG9jYXRlZOKAnSBldmVuIGlmIHRo ZXkgZG8gbm90IHJlc2lkZSB3aXRoaW4gdGhlIHNhbWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+cHJvY2VzcyBjb250ZXh0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmRo Y3dnDQogWzxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5tYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBC ZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPk5hdmVlbiBLb3R0YXBhbGxpPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEp1bmUgMjUsIDIwMTkgOTox NCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+djZvcHMgbGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52Nm9wc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 Ozs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaGN3 Z0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NYXJ0aW4gSHVuZWsgJmx0OzxhIGhyZWY9Im1h aWx0bzptYXJ0aW4uaHVuZWtAdHVsLmN6Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYXJ0 aW4uaHVuZWtAdHVsLmN6PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbZGhjd2ddIFt2 Nm9wc10gT3BlcmF0aW9uYWwgSGVhZGFjaGU6IERIQ1AgVjYgUmVsYXk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGVsbG8gQWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBuZXcgZHJhZnQgb24g dGhpcyBzdWJqZWN0IGlzIHN1Ym1pdHRlZCB0b2RheS4mbmJzcDsgUGxlYXNlIGdvIHRocm91Z2gg dGhlIHNhbWUgaW4gYmVsb3cgbGluayBhbmQgbGV0IHVzIGtub3cgeW91ciBmZWVkYmFjay48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVp cmVtZW50cy0wMC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE5h dmVlbiBLb3R0YXBhbGxpIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxi cj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzPGJyPg0KUmV2aXNpb246 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERIQ1B2NiBQcmVmaXggRGVsZWdhdGluZyByZWxheTxicj4NCkRv Y3VtZW50IGRhdGU6Jm5ic3A7IDIwMTktMDYtMjU8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTA8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVp cmVtZW50cy0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmtocC1kaGMtZGhj cHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy0wMC50eHQ8L3NwYW4+PC9hPjxicj4NClN0YXR1czom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVt ZW50cy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXkt cmVxdWlyZW1lbnRzLzwvc3Bhbj48L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZraHAt ZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy0wMDwvc3Bhbj48L2E+PGJyPg0K SHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXkt cmVxdWlyZW1lbnRzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ma2hwLWRoYy1kaGNw djYtcGQtcmVsYXktcmVxdWlyZW1lbnRzPC9zcGFuPjwvYT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7T3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIERIQ1B2 NiBwcmVmaXggZGVsZWdhdGlvbiBoYXMgc2hvd24gdGhhdDxicj4NCiZuYnNwOyAmbmJzcDt3aGVu IHRoZSBESENQdjYgcmVsYXkgZnVuY3Rpb24gaXMgbm90IGNvLWxvY2F0ZWQgd2l0aCB0aGUgREhD UHY2PGJyPg0KJm5ic3A7ICZuYnNwO3NlcnZlciBmdW5jdGlvbiwgaXNzdWVzIHN1Y2ggYXMgdGlt ZXIgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwO0RIQ1AgZnVu Y3Rpb25hbCBlbGVtZW50cywgcmVqZWN0aW9uIG9mIGNsaWVudCdzIG1lc3NhZ2VzIGJ5IHRoZTxi cj4NCiZuYnNwOyAmbmJzcDtyZWxheSwgYW5kIG90aGVyIHByb2JsZW1zIGhhdmUgYmVlbiBvYnNl cnZlZC4mbmJzcDsgVGhlc2UgcHJvYmxlbXMgY2FuPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc3VsdCBp biBwcmVmaXggZGVsZWdhdGlvbiBmYWlsaW5nIG9yIHRyYWZmaWMgdG8vZnJvbSBjbGllbnRzPGJy Pg0KJm5ic3A7ICZuYnNwO2FkZHJlc3NlZCBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGJlaW5n IHVucm91dGVhYmxlLiZuYnNwOyBBbHRob3VnaDxicj4NCiZuYnNwOyAmbmJzcDtbUkZDODQxNV0g bWVudGlvbnMgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvLCBpdCBkb2VzIG5vdCBwcm92aWRlPGJy Pg0KJm5ic3A7ICZuYnNwO25lY2Vzc2FyeSBkZXRhaWwgb24gaG93IHRoZSByZWxheSBlbGVtZW50 IHNob3VsZCBiZWhhdmUgd2hlbiB1c2VkPGJyPg0KJm5ic3A7ICZuYnNwO3dpdGggUEQuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZ1bmN0aW9uYWwgcmVx dWlyZW1lbnRzIGZvciBhIERIQ1B2NiBQRCByZWxheTxicj4NCiZuYnNwOyAmbmJzcDt3aGVuIHVz ZWQgZm9yIHJlbGF5aW5nIHByZWZpeGVzIGRlbGVnYXRlZCBieSBhIHNlcGFyYXRlIERIQ1B2Njxi cj4NCiZuYnNwOyAmbmJzcDtzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91cnMs PGJyPg0KTmF2ZWVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIDEgQXByIDIwMTkgYXQgMTg6MzQsICZsdDs8YSBocmVmPSJtYWlsdG86aWFuZmFy cmVyQGdteC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5p YW5mYXJyZXJAZ214LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNYXJ0aW4sPGJyPg0KPGJyPg0K SSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiB0aGlzIGFzIGl04oCZcyBh IHByb2JsZW0gZm9yIHVzLiBJ4oCZdmUgZ290IHNvbWV0aGluZyBJIHdyb3RlIGEgd2hpbGUgYmFj ay4gSeKAmWxsIHNoYXJlIGl0IGFzIGEgc3RhcnRpbmcgcG9pbnQuPGJyPg0KPGJyPg0KQ2hlZXJz LDxicj4NCklhbjxicj4NCjxicj4NCiZndDsgT24gMS4gQXByIDIwMTksIGF0IDExOjMxLCBNYXJ0 aW4gSHVuZWsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaHVuZWtAdHVsLmN6IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFydGluLmh1bmVrQHR1bC5jejwv c3Bhbj48L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgSGkgRnJlZCw8YnI+DQomZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgSSB3 b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZSwgYXMgaXQgaXMgdGhlIG9u ZSBJJ20gYWxzbyBoYXZpbmcuIEJ1dCBJIHdvdWxkIG5lZWQgc29tZSBhc3Npc3RhbmNlLCBhcyBJ IGRvbid0IHJlYWxseSBrbm93IG15IHdheXMgYXJvdW5kIElFVEYgcHJvY2Vzc2VzIHlldC48YnI+ DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCiZndDsgTWFydGluPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IERuZSBww6F0ZWsgMjkuIGLFmWV6bmEgMjAxOSA2 OjM3OjI1IENFU1QsIEZyZWQgQmFrZXIgbmFwc2FsKGEpOjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDQtdjZvcHMtZGV1dHNjaGUtdGVsZWtv bS10ZXJhc3RyZWFtLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDQtdjZvcHMtZGV1dHNj aGUtdGVsZWtvbS10ZXJhc3RyZWFtLzwvc3Bhbj48L2E+LA0KIHNsaWRlIDMtNDxicj4NCiZndDsm Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CiZndDsmZ3Q7IFdoYXQgZG8gd2Ugd2FudCB0byBzYXkgYWJvdXQgREhDUHY2IGlzc3VlcyBpbiB2 ZW5kb3IgcHJvZHVjdCBhbmQvb3Igc2VydmljZXM/IFRoaXMgaGVhZGFjaGUgZG9lc24ndCBoYXZl IGFuIG9idmlvdXMgZHJhZnQuIEkgdGhpbmsgdGhhdCBwcm9iYWJseSBjYWxscyBmb3IgYSBwZXJz b24gb3IgZGVzaWduIHRlYW0gdG8gY3JlYXRlIHN1Y2ggYSBkcmFmdCBmb3IgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdCBhbmQgaW4gTW9udHJlYWwuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgQW55IHRha2Vy cz88YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7IFRo ZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhlbGwgYW5kIGEgc3RhaXJ3YXkgdG8g aGVhdmVuIGlzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgb24gcHJvamVjdGVkIHRyYWZmaWMgdm9s dW1lLi4uPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzPC9zcGFuPjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRoY3dn IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5kaGN3Z0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxl Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e0e7576d188141c088e7baf89d5cdc2dboeingcom_-- From nobody Wed Jun 26 08:39:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44CB1201DE; Wed, 26 Jun 2019 08:39:10 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7-_stR3hJgt; Wed, 26 Jun 2019 08:39:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36CC12003E; Wed, 26 Jun 2019 08:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1561563536; bh=cxIHq09kSlj3E0N4akUVywkpkRLryZsIQZQx1zHYPnk=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=PwGJ9l4cfpQUb/eEoAyXB/GW783oFKnvWCz0rbMPizutgYuH05qbkvw15pCe9otA+ EMBpm0uGK+Ad8YO2FMXlCc+6JfWH/Sh6h3CJqqb10hLYFIgut98PIvFCpkGETsC5d5 +JtdWa8YV9cb4/ea10KpLkAcZ3PP9iostUFWMU34= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.78.36.51]) by mail.gmx.com (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MStCY-1i9QY20xlW-00UM2f; Wed, 26 Jun 2019 17:38:56 +0200 From: ianfarrer@gmx.com Message-Id: <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0DE89014-5978-4B39-A631-D933BA0D324E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 17:38:52 +0200 In-Reply-To: Cc: Naveen Kottapalli , v6ops list , "dhcwg@ietf.org" , Martin Hunek To: "Templin (US), Fred L" References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:fItYCqhOFlKpbSd2u5xJMwFaaQOuj5gntxpEdz8B0jMZ3viYug2 8VG8pZCdlgXkTOXWzVIpdB/36HGFt4UNGYsxjK4UuzSis1ECP2AFqw6gP8RGmhzDNzIHC3L cWeM3lKr5djvNzz4lSMZoU/uDMe5M9ma80Km2Wvpu22CENINcO/Aci15AwLh5e74kkSckYA o7GZr2jrWImlVVGCIqUZQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:F1VHUdahQK4=:Z+4u9Gbh/d9C82s3LC20RU qcXYRGtRciJJiUKbUn7UlWQ3JVBLFoM9VnZlPkqL6C4DYvKZlzQNs6bc8nfVrTci1nPFrRNWt Qqsh0eb6s2JePoMviDBG/6jVAN41vsp2mvVoiBcZOxn2C+xAJGDXE0caZBk0e/unmZgpYC/+8 0b209xrn3LYLUvqSpKzwcWXlFuzfI8SYjCveQikyu6GT6AiU1crv4Uv0s4GdEHURLSOAIrm/x qk88rOrvWxn7Gkltb4s5b1n3btEBcRhwPrAbg1w+E557sOgFsJOWapvyunpikhTLFmHB1zagr qAb7HFggupHMA3bauywmsyLRLuXEi1xJIT2IxjuAFA99YwnMoC/E1eXfm5JQF0qDmZyIkHK5u Zb+dcrZbWy1D+jtg/dD1tuGdqH3b6G5BqI3zdurcP8k1i35sqEAHREBIhRPizKDAjyduFoMIW uYirbH6xT/wyyiUfKYXmmYkXduyr2EkI+fA02xDmcuilC1dPh2LYIdocHV4Xc/fnSliZbTyDK dra8dNFo7NxhuAKhh25iRp/zb0b/7s0JYx/qeirI61Ms3v8ohXTdc2FkejRQK08mrZIT8wCsd idYWLFqoRkVB2k5D3Z0Vwe2w+xx60+b17I8UBwfff/jz2pgiU7DXTnLCFpShNavUvw3fFob9E rMX6zRnBQVcAOlUDbP489JXoiE5BPzN6tFgVGvfHi5GvsdWpRGfbb2r3QH7YVosTFc1CHGjzm SR9pc2ViS8cwTgrzQXiKqYrzWf2h5mcUl1/hAPorlDjT04gmQqvmwKdAiNj/pw1rQV/X/7ILq Lmg+Z1W4ReiaugUklYORJ6d3OawG/V05tMjgqwUerguXyhMWFK0/BQm3P0feouAgXsmvGkiim h4WQNRnZSmEguAlZ/epirGHh3biV+Gb22tODzVycoS/0+s07L+SN7pFyC4dZjqJX0UOAwFBnJ vMgww1EToPSRnLa9y+usN64eC6zvMUaM+6hFAa/xGXZe3GNu5XVzurg60lai9TKcCZL+DBhOe ylXFjYpBKlUiDxyXLBe2UKHZ7dy21TpX9hboqh+VCVzUTpMeUzIO8sz3JZ9XBKAcxXk3Xv1dr UnQAlk73I7ScJJee561BE19XMtURQQNreaYD3lDF1MaF13BsjdpVeMuodqAMquLJZ2rXOeEKw 2/cdk= Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:39:11 -0000 --Apple-Mail=_0DE89014-5978-4B39-A631-D933BA0D324E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fred, Will do. I haven=E2=80=99t tried that particular deployment scenario. I suppose = that if the relay and server processes didn=E2=80=99t share any state = information then you could see these problems. Is there a case for = running both server and relay functions on the same box, rather than = just the server (as a delegating router)? Thanks, Ian > On 26. Jun 2019, at 17:27, Templin (US), Fred L = wrote: >=20 > Hi Ian =E2=80=93 yes, a clarification of =E2=80=9Cco-located=E2=80=9D = would be great. Sounds like there is > not a concern when the relay and server are in the same box or VM, = right? > =20 > Thanks - Fred > =20 > From: ianfarrer@gmx.com = [mailto:ianfarrer@gmx.com ]=20 > Sent: Wednesday, June 26, 2019 8:22 AM > To: Templin (US), Fred L > > Cc: Naveen Kottapalli >; v6ops list >; dhcwg@ietf.org ; Martin = Hunek > > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay > =20 > Hi Fred, > =20 > In this instance, we are talking about being in a separate physical = box, or VM. The problems I=E2=80=99ve observed are with L3 edge routers = with > the relay function in the access network with a centralised DHCPv6 = server. We can clarify this better in the next update. > =20 > Thanks, > Ian >=20 >=20 > On 26. Jun 2019, at 17:14, Templin (US), Fred L = > wrote: > =20 > Hi Naveen, > =20 > Thanks for the draft =E2=80=93 a quick question - what is meant by = =E2=80=9CDHCPv6 relay function is not co-located > with the DHCPv6 server function=E2=80=9D. Does it mean = =E2=80=9Cco-located=E2=80=9D as in within the same process, within > the same virtual machine, within the same physical box, within the = same LAN, etc.? > =20 > RFC6221 allows for the relay function to be in a separate process from = the server function but > within the same operating system instance. So, the two processes share = the same clock, IP > forwarding table, system memory, etc. In such an arrangement, can it = be said that the DHCPv6 > relay and server functions are in fact =E2=80=9Cco-located=E2=80=9D = even if they do not reside within the same > process context? > =20 > Thanks - Fred > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Naveen Kottapalli > Sent: Tuesday, June 25, 2019 9:14 AM > To: v6ops list >; = dhcwg@ietf.org > Cc: Martin Hunek > > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay > =20 > Hello All, > =20 > A new draft on this subject is submitted today. Please go through the = same in below link and let us know your feedback. > =20 > ---- > =20 > A new version of I-D, = draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt > has been successfully submitted by Naveen Kottapalli and posted to the > IETF repository. >=20 > Name: draft-fkhp-dhc-dhcpv6-pd-relay-requirements > Revision: 00 > Title: DHCPv6 Prefix Delegating relay > Document date: 2019-06-25 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requir= ements-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requiremen= ts/ = > Htmlized: = https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00= = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requi= rements = >=20 >=20 > Abstract: > Operational experience with DHCPv6 prefix delegation has shown that > when the DHCPv6 relay function is not co-located with the DHCPv6 > server function, issues such as timer synchronization between the > DHCP functional elements, rejection of client's messages by the > relay, and other problems have been observed. These problems can > result in prefix delegation failing or traffic to/from clients > addressed from the delegated prefix being unrouteable. Although > [RFC8415] mentions this deployment scenario, it does not provide > necessary detail on how the relay element should behave when used > with PD. >=20 > This document describes functional requirements for a DHCPv6 PD = relay > when used for relaying prefixes delegated by a separate DHCPv6 > server. > =20 > Yours, > Naveen. > =20 > =20 > On Mon, 1 Apr 2019 at 18:34, > wrote: > Hi Martin, >=20 > I would also be interested in working on this as it=E2=80=99s a = problem for us. I=E2=80=99ve got something I wrote a while back. I=E2=80=99= ll share it as a starting point. >=20 > Cheers, > Ian >=20 > > On 1. Apr 2019, at 11:31, Martin Hunek > wrote: > >=20 > > Hi Fred, > >=20 > > I would be interested to address this issue, as it is the one I'm = also having. But I would need some assistance, as I don't really know my = ways around IETF processes yet. > >=20 > > Martin > >=20 > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker = napsal(a): > >> = https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr= eam/ = , slide 3-4 > >>=20 > >> What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal. > >>=20 > >> Any takers? > >> = --------------------------------------------------------------------------= ------ > >> The fact that there is a highway to hell and a stairway to heaven = is an interesting comment on projected traffic volume... > >>=20 > >=20 > > _______________________________________________ > > 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 = > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg = --Apple-Mail=_0DE89014-5978-4B39-A631-D933BA0D324E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Fred,

Will = do.

I = haven=E2=80=99t tried that particular deployment scenario. I suppose = that if the relay and server processes didn=E2=80=99t share any state = information then you could see these problems. Is there a case for = running both server and relay functions on the same box, rather than = just the server (as a delegating router)?

Thanks,
Ian

On 26. Jun 2019, at 17:27, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:

Hi Ian =E2=80=93 yes, a = clarification of =E2=80=9Cco-located=E2=80=9D would be great. Sounds = like there is
not= a concern when the relay and server are in the same box or VM, = right?
 
Thanks - Fred
 
From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com] 
Sent: Wednesday, June 26, 2019 = 8:22 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; = v6ops list <v6ops@ietf.org>; dhcwg@ietf.org; Martin Hunek <martin.hunek@tul.cz>
Subject: Re: [dhcwg] [v6ops] = Operational Headache: DHCP V6 Relay
 
Hi Fred,
 
In this instance, we are talking about = being in a separate physical box, or VM. The problems I=E2=80=99ve = observed are with  L3 edge routers with
the relay function in the access network with a = centralised DHCPv6 server. We can clarify this better in the next = update.
 
Thanks,
Ian


On 26. Jun 2019, at 17:14, Templin (US), = Fred L <Fred.L.Templin@boeing.com> wrote:
 
Hi Naveen,
 
Thanks for the draft = =E2=80=93 a quick question - what is meant by =E2=80=9CDHCPv6 relay = function is not co-located
with the DHCPv6 server function=E2=80=9D. = Does it mean =E2=80=9Cco-located=E2=80=9D as in within the same process, = within
the same virtual machine, within the same physical box, = within the same LAN, etc.?
 
RFC6221 allows for the = relay function to be in a separate process from the server function = but
within the same operating system instance. So, the two = processes share the same clock, IP
forwarding table, = system memory, etc. In such an arrangement, can it be said that the = DHCPv6
relay and server functions are in fact =E2=80=9Cco-located=E2=80= =9D even if they do not reside within the same
process = context?
 
Thanks - Fred
 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Naveen = Kottapalli
Sent: Tuesday, June 25, 2019 9:14 = AM
To: v6ops list <v6ops@ietf.org>; dhcwg@ietf.org
Cc: Martin Hunek <martin.hunek@tul.cz>
Subject: Re: [dhcwg] [v6ops] = Operational Headache: DHCP V6 Relay
 
Hello All,
 
A new draft on this = subject is submitted today.  Please go through the same in below = link and let us know your feedback.
 
----
 
A new version of I-D, = draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
has = been successfully submitted by Naveen Kottapalli and posted to the
IETF repository.

Name:  =         =  draft-fkhp-dhc-dhcpv6-pd-relay-requirements
Revision:       00
Title:          DHCPv6 Prefix = Delegating relay
Document date:  2019-06-25
Group:          Individual = Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-r= elay-requirements-00.txt
Status:    =      https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay= -requirements/
Htmlized:      =  https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requ= irements-00
Htmlized:      =  https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-= relay-requirements


Abstract:
   Operational experience = with DHCPv6 prefix delegation has shown that
  =  when the DHCPv6 relay function is not co-located with the = DHCPv6
   server function, issues such as timer = synchronization between the
   DHCP functional = elements, rejection of client's messages by the
  =  relay, and other problems have been observed.  These problems = can
   result in prefix delegation failing or = traffic to/from clients
   addressed from the = delegated prefix being unrouteable.  Although
  =  [RFC8415] mentions this deployment scenario, it does not = provide
   necessary detail on how the relay = element should behave when used
   with PD.

   This document describes = functional requirements for a DHCPv6 PD relay
  =  when used for relaying prefixes delegated by a separate DHCPv6
   server.
 
Yours,
Naveen.
 
 
On Mon, 1 = Apr 2019 at 18:34, <ianfarrer@gmx.com> wrote:
Hi Martin,

I would also = be interested in working on this as it=E2=80=99s a problem for us. = I=E2=80=99ve got something I wrote a while back. I=E2=80=99ll share it = as a starting point.

Cheers,
Ian

> On 1. Apr 2019, at = 11:31, Martin Hunek <martin.hunek@tul.cz> wrote:
> 
> Hi Fred,
> 
> I would = be interested to address this issue, as it is the one I'm also having. = But I would need some assistance, as I don't really know my ways around = IETF processes yet.
> 
> = Martin
> 
> Dne = p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a):
>> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-tele= kom-terastream/, slide 3-4
>> 
>> = What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal.
>> 
>> Any = takers?
>> = --------------------------------------------------------------------------= ------
>> The fact that there is a highway to hell = and a stairway to heaven is an interesting comment on projected traffic = volume...
>> 
> 
> = _______________________________________________
> 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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --Apple-Mail=_0DE89014-5978-4B39-A631-D933BA0D324E-- From nobody Wed Jun 26 08:54:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0403712029D; Wed, 26 Jun 2019 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 4tS19d-PLqED; Wed, 26 Jun 2019 08:54:01 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E911202D6; Wed, 26 Jun 2019 08:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x5QFrunD015059; Wed, 26 Jun 2019 11:53:57 -0400 Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x5QFrt7h014925 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 11:53:55 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 26 Jun 2019 08:53:54 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Wed, 26 Jun 2019 08:53:54 -0700 From: "Templin (US), Fred L" To: "ianfarrer@gmx.com" CC: Naveen Kottapalli , v6ops list , "dhcwg@ietf.org" , Martin Hunek Thread-Topic: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay Thread-Index: AQHVK3EUciY/hggKEUyles3tiq6GiaauCx7wgAB5MAD//4rxUIAAeboA//+K53A= Date: Wed, 26 Jun 2019 15:53:53 +0000 Message-ID: <9b9924f3ef0a4b2c8d48c86a652d957e@boeing.com> References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> In-Reply-To: <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: B0B3B01797F6ECA13AD81E2F27710CF0D3F5390282C1BC03CC1DC58D289BA7252000:8 Content-Type: multipart/alternative; boundary="_000_9b9924f3ef0a4b2c8d48c86a652d957eboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:54:06 -0000 --_000_9b9924f3ef0a4b2c8d48c86a652d957eboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNlcnZlciBhbmQgcmVsYXkgcnVuIGluIHRoZSBzYW1lIG9wZXJhdGluZyBzeXN0ZW0gaW5z dGFuY2UsIGJ1dCBpbiB0d28gc2VwYXJhdGUgcHJvY2Vzcw0KY29udGV4dHMg4oCTIGNhbGwgdGhl bSDigJhyZWxheWTigJkgYW5kIOKAmHNlcnZlcmTigJkuDQoNCuKAmHJlbGF5ZOKAmSByZWNlaXZl cyBhIGNsaWVudCBwcmVmaXggZGVsZWdhdGlvbiByZXF1ZXN0IHRoZW4gcHJlcGFyZXMgYSDigJhS ZWxheS1mb3J3YXJk4oCZIG1lc3NhZ2UNCmFuZCBzaGlwcyBpdCB0byDigJhzZXJ2ZXJk4oCZIG92 ZXIgYSBsb2NhbCBsb29wYmFjay4gV2hlbiDigJhzZXJ2ZXJk4oCZIHNlbmRzIGJhY2sgdGhlIOKA mFJlbGF5LXJlcGx54oCZDQooYWdhaW4gb3ZlciB0aGUgbG9vcGJhY2spLCDigJhyZWxheWTigJkg aW5qZWN0cyBhIHJvdXRlIGludG8gdGhlIHJvdXRpbmcgc3lzdGVtIGFuZCBzZW5kcyBhDQpzdWl0 YWJsZSByZXBseSB0byB0aGUgY2xpZW50Lg0KDQpUaGUgb25seSByZWFzb24gd2UgZG8gaXQgdGhp cyB3YXkgaXMgYmVjYXVzZSB0aGUgY2xpZW50IGNhbm5vdCBzcGVhayBkaXJlY3RseSB0byDigJhz ZXJ2ZXJk4oCZDQphbmQgaXQgd291bGQgYmUgZGlmZmljdWx0IHRvIG1lcmdlIOKAmHJlbGF5ZOKA mSBhbmQg4oCYc2VydmVyZOKAmSBpbnRvIGEgc2luZ2xlIHByb2Nlc3MgY29udGV4dC4gQnV0LA0K ZXZlcnl0aGluZyBlbHNlIGlzIGNvb3JkaW5hdGVkIHdpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcg c3lzdGVtIGluc3RhbmNlLg0KDQpGcmVkDQoNCkZyb206IGlhbmZhcnJlckBnbXguY29tIFttYWls dG86aWFuZmFycmVyQGdteC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjYsIDIwMTkgODoz OSBBTQ0KVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Pg0KQ2M6IE5hdmVlbiBLb3R0YXBhbGxpIDxuYXZlZW4uc2FybWFAZ21haWwuY29tPjsgdjZvcHMg bGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBkaGN3Z0BpZXRmLm9yZzsgTWFydGluIEh1bmVrIDxtYXJ0 aW4uaHVuZWtAdHVsLmN6Pg0KU3ViamVjdDogUmU6IFtkaGN3Z10gW3Y2b3BzXSBPcGVyYXRpb25h bCBIZWFkYWNoZTogREhDUCBWNiBSZWxheQ0KDQpIaSBGcmVkLA0KDQpXaWxsIGRvLg0KDQpJIGhh dmVu4oCZdCB0cmllZCB0aGF0IHBhcnRpY3VsYXIgZGVwbG95bWVudCBzY2VuYXJpby4gSSBzdXBw b3NlIHRoYXQgaWYgdGhlIHJlbGF5IGFuZCBzZXJ2ZXIgcHJvY2Vzc2VzIGRpZG7igJl0IHNoYXJl IGFueSBzdGF0ZSBpbmZvcm1hdGlvbiB0aGVuIHlvdSBjb3VsZCBzZWUgdGhlc2UgcHJvYmxlbXMu IElzIHRoZXJlIGEgY2FzZSBmb3IgcnVubmluZyBib3RoIHNlcnZlciBhbmQgcmVsYXkgZnVuY3Rp b25zIG9uIHRoZSBzYW1lIGJveCwgcmF0aGVyIHRoYW4ganVzdCB0aGUgc2VydmVyIChhcyBhIGRl bGVnYXRpbmcgcm91dGVyKT8NCg0KVGhhbmtzLA0KSWFuDQoNCg0KT24gMjYuIEp1biAyMDE5LCBh dCAxNzoyNywgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208 bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCg0KSGkgSWFuIOKAkyB5 ZXMsIGEgY2xhcmlmaWNhdGlvbiBvZiDigJxjby1sb2NhdGVk4oCdIHdvdWxkIGJlIGdyZWF0LiBT b3VuZHMgbGlrZSB0aGVyZSBpcw0Kbm90IGEgY29uY2VybiB3aGVuIHRoZSByZWxheSBhbmQgc2Vy dmVyIGFyZSBpbiB0aGUgc2FtZSBib3ggb3IgVk0sIHJpZ2h0Pw0KDQpUaGFua3MgLSBGcmVkDQoN CkZyb206IGlhbmZhcnJlckBnbXguY29tPG1haWx0bzppYW5mYXJyZXJAZ214LmNvbT4gW21haWx0 bzppYW5mYXJyZXJAZ214LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNiwgMjAxOSA4OjIy IEFNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208 bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+Pg0KQ2M6IE5hdmVlbiBLb3R0YXBhbGxp IDxuYXZlZW4uc2FybWFAZ21haWwuY29tPG1haWx0bzpuYXZlZW4uc2FybWFAZ21haWwuY29tPj47 IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+OyBkaGN3 Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+OyBNYXJ0aW4gSHVuZWsgPG1hcnRpbi5o dW5la0B0dWwuY3o8bWFpbHRvOm1hcnRpbi5odW5la0B0dWwuY3o+Pg0KU3ViamVjdDogUmU6IFtk aGN3Z10gW3Y2b3BzXSBPcGVyYXRpb25hbCBIZWFkYWNoZTogREhDUCBWNiBSZWxheQ0KDQpIaSBG cmVkLA0KDQpJbiB0aGlzIGluc3RhbmNlLCB3ZSBhcmUgdGFsa2luZyBhYm91dCBiZWluZyBpbiBh IHNlcGFyYXRlIHBoeXNpY2FsIGJveCwgb3IgVk0uIFRoZSBwcm9ibGVtcyBJ4oCZdmUgb2JzZXJ2 ZWQgYXJlIHdpdGggIEwzIGVkZ2Ugcm91dGVycyB3aXRoDQp0aGUgcmVsYXkgZnVuY3Rpb24gaW4g dGhlIGFjY2VzcyBuZXR3b3JrIHdpdGggYSBjZW50cmFsaXNlZCBESENQdjYgc2VydmVyLiBXZSBj YW4gY2xhcmlmeSB0aGlzIGJldHRlciBpbiB0aGUgbmV4dCB1cGRhdGUuDQoNClRoYW5rcywNCklh bg0KDQoNCg0KT24gMjYuIEp1biAyMDE5LCBhdCAxNzoxNCwgVGVtcGxpbiAoVVMpLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+PiB3cm90ZToNCg0KSGkgTmF2ZWVuLA0KDQpUaGFua3MgZm9yIHRoZSBkcmFmdCDigJMgYSBx dWljayBxdWVzdGlvbiAtIHdoYXQgaXMgbWVhbnQgYnkg4oCcREhDUHY2IHJlbGF5IGZ1bmN0aW9u IGlzIG5vdCBjby1sb2NhdGVkDQp3aXRoIHRoZSBESENQdjYgc2VydmVyIGZ1bmN0aW9u4oCdLiBE b2VzIGl0IG1lYW4g4oCcY28tbG9jYXRlZOKAnSBhcyBpbiB3aXRoaW4gdGhlIHNhbWUgcHJvY2Vz cywgd2l0aGluDQp0aGUgc2FtZSB2aXJ0dWFsIG1hY2hpbmUsIHdpdGhpbiB0aGUgc2FtZSBwaHlz aWNhbCBib3gsIHdpdGhpbiB0aGUgc2FtZSBMQU4sIGV0Yy4/DQoNClJGQzYyMjEgYWxsb3dzIGZv ciB0aGUgcmVsYXkgZnVuY3Rpb24gdG8gYmUgaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIGZyb20gdGhl IHNlcnZlciBmdW5jdGlvbiBidXQNCndpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lzdGVtIGlu c3RhbmNlLiBTbywgdGhlIHR3byBwcm9jZXNzZXMgc2hhcmUgdGhlIHNhbWUgY2xvY2ssIElQDQpm b3J3YXJkaW5nIHRhYmxlLCBzeXN0ZW0gbWVtb3J5LCBldGMuIEluIHN1Y2ggYW4gYXJyYW5nZW1l bnQsIGNhbiBpdCBiZSBzYWlkIHRoYXQgdGhlIERIQ1B2Ng0KcmVsYXkgYW5kIHNlcnZlciBmdW5j dGlvbnMgYXJlIGluIGZhY3Qg4oCcY28tbG9jYXRlZOKAnSBldmVuIGlmIHRoZXkgZG8gbm90IHJl c2lkZSB3aXRoaW4gdGhlIHNhbWUNCnByb2Nlc3MgY29udGV4dD8NCg0KVGhhbmtzIC0gRnJlZA0K DQpGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBOYXZlZW4gS290dGFwYWxsaQ0KU2VudDogVHVlc2RheSwgSnVuZSAyNSwgMjAxOSA5OjE0IEFN DQpUbzogdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj47 IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCkNjOiBNYXJ0aW4gSHVuZWsg PG1hcnRpbi5odW5la0B0dWwuY3o8bWFpbHRvOm1hcnRpbi5odW5la0B0dWwuY3o+Pg0KU3ViamVj dDogUmU6IFtkaGN3Z10gW3Y2b3BzXSBPcGVyYXRpb25hbCBIZWFkYWNoZTogREhDUCBWNiBSZWxh eQ0KDQpIZWxsbyBBbGwsDQoNCkEgbmV3IGRyYWZ0IG9uIHRoaXMgc3ViamVjdCBpcyBzdWJtaXR0 ZWQgdG9kYXkuICBQbGVhc2UgZ28gdGhyb3VnaCB0aGUgc2FtZSBpbiBiZWxvdyBsaW5rIGFuZCBs ZXQgdXMga25vdyB5b3VyIGZlZWRiYWNrLg0KDQotLS0tDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYXZlZW4gS290dGFwYWxsaSBhbmQgcG9z dGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtZmto cC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KUmV2aXNpb246ICAgICAgIDAwDQpU aXRsZTogICAgICAgICAgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW5nIHJlbGF5DQpEb2N1bWVudCBk YXRlOiAgMjAxOS0wNi0yNQ0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6ICAgICAgICAgIDEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVu dHMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2 LXBkLXJlbGF5LXJlcXVpcmVtZW50cy0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJl cXVpcmVtZW50cw0KDQoNCkFic3RyYWN0Og0KICAgT3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRo IERIQ1B2NiBwcmVmaXggZGVsZWdhdGlvbiBoYXMgc2hvd24gdGhhdA0KICAgd2hlbiB0aGUgREhD UHY2IHJlbGF5IGZ1bmN0aW9uIGlzIG5vdCBjby1sb2NhdGVkIHdpdGggdGhlIERIQ1B2Ng0KICAg c2VydmVyIGZ1bmN0aW9uLCBpc3N1ZXMgc3VjaCBhcyB0aW1lciBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiB0aGUNCiAgIERIQ1AgZnVuY3Rpb25hbCBlbGVtZW50cywgcmVqZWN0aW9uIG9mIGNsaWVu dCdzIG1lc3NhZ2VzIGJ5IHRoZQ0KICAgcmVsYXksIGFuZCBvdGhlciBwcm9ibGVtcyBoYXZlIGJl ZW4gb2JzZXJ2ZWQuICBUaGVzZSBwcm9ibGVtcyBjYW4NCiAgIHJlc3VsdCBpbiBwcmVmaXggZGVs ZWdhdGlvbiBmYWlsaW5nIG9yIHRyYWZmaWMgdG8vZnJvbSBjbGllbnRzDQogICBhZGRyZXNzZWQg ZnJvbSB0aGUgZGVsZWdhdGVkIHByZWZpeCBiZWluZyB1bnJvdXRlYWJsZS4gIEFsdGhvdWdoDQog ICBbUkZDODQxNV0gbWVudGlvbnMgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvLCBpdCBkb2VzIG5v dCBwcm92aWRlDQogICBuZWNlc3NhcnkgZGV0YWlsIG9uIGhvdyB0aGUgcmVsYXkgZWxlbWVudCBz aG91bGQgYmVoYXZlIHdoZW4gdXNlZA0KICAgd2l0aCBQRC4NCg0KICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgZm9yIGEgREhDUHY2IFBEIHJlbGF5DQog ICB3aGVuIHVzZWQgZm9yIHJlbGF5aW5nIHByZWZpeGVzIGRlbGVnYXRlZCBieSBhIHNlcGFyYXRl IERIQ1B2Ng0KICAgc2VydmVyLg0KDQpZb3VycywNCk5hdmVlbi4NCg0KDQpPbiBNb24sIDEgQXBy IDIwMTkgYXQgMTg6MzQsIDxpYW5mYXJyZXJAZ214LmNvbTxtYWlsdG86aWFuZmFycmVyQGdteC5j b20+PiB3cm90ZToNCkhpIE1hcnRpbiwNCg0KSSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4g d29ya2luZyBvbiB0aGlzIGFzIGl04oCZcyBhIHByb2JsZW0gZm9yIHVzLiBJ4oCZdmUgZ290IHNv bWV0aGluZyBJIHdyb3RlIGEgd2hpbGUgYmFjay4gSeKAmWxsIHNoYXJlIGl0IGFzIGEgc3RhcnRp bmcgcG9pbnQuDQoNCkNoZWVycywNCklhbg0KDQo+IE9uIDEuIEFwciAyMDE5LCBhdCAxMTozMSwg TWFydGluIEh1bmVrIDxtYXJ0aW4uaHVuZWtAdHVsLmN6PG1haWx0bzptYXJ0aW4uaHVuZWtAdHVs LmN6Pj4gd3JvdGU6DQo+DQo+IEhpIEZyZWQsDQo+DQo+IEkgd291bGQgYmUgaW50ZXJlc3RlZCB0 byBhZGRyZXNzIHRoaXMgaXNzdWUsIGFzIGl0IGlzIHRoZSBvbmUgSSdtIGFsc28gaGF2aW5nLiBC dXQgSSB3b3VsZCBuZWVkIHNvbWUgYXNzaXN0YW5jZSwgYXMgSSBkb24ndCByZWFsbHkga25vdyBt eSB3YXlzIGFyb3VuZCBJRVRGIHByb2Nlc3NlcyB5ZXQuDQo+DQo+IE1hcnRpbg0KPg0KPiBEbmUg cMOhdGVrIDI5LiBixZllem5hIDIwMTkgNjozNzoyNSBDRVNULCBGcmVkIEJha2VyIG5hcHNhbChh KToNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDQtdjZvcHMt ZGV1dHNjaGUtdGVsZWtvbS10ZXJhc3RyZWFtLywgc2xpZGUgMy00DQo+Pg0KPj4gV2hhdCBkbyB3 ZSB3YW50IHRvIHNheSBhYm91dCBESENQdjYgaXNzdWVzIGluIHZlbmRvciBwcm9kdWN0IGFuZC9v ciBzZXJ2aWNlcz8gVGhpcyBoZWFkYWNoZSBkb2Vzbid0IGhhdmUgYW4gb2J2aW91cyBkcmFmdC4g SSB0aGluayB0aGF0IHByb2JhYmx5IGNhbGxzIGZvciBhIHBlcnNvbiBvciBkZXNpZ24gdGVhbSB0 byBjcmVhdGUgc3VjaCBhIGRyYWZ0IGZvciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBpbiBN b250cmVhbC4NCj4+DQo+PiBBbnkgdGFrZXJzPw0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+IFRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhlbGwgYW5kIGEgc3RhaXJ3 YXkgdG8gaGVhdmVuIGlzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgb24gcHJvamVjdGVkIHRyYWZm aWMgdm9sdW1lLi4uDQo+Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmc8bWFp bHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5n IGxpc3QNCmRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0K --_000_9b9924f3ef0a4b2c8d48c86a652d957eboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBzZXJ2ZXIgYW5k IHJlbGF5IHJ1biBpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lzdGVtIGluc3RhbmNlLCBidXQgaW4g dHdvIHNlcGFyYXRlIHByb2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Y29udGV4dHMg4oCTIGNhbGwg dGhlbSDigJhyZWxheWTigJkgYW5kIOKAmHNlcnZlcmTigJkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJhyZWxheWTigJkgcmVjZWl2ZXMgYSBjbGllbnQgcHJl Zml4IGRlbGVnYXRpb24gcmVxdWVzdCB0aGVuIHByZXBhcmVzIGEg4oCYUmVsYXktZm9yd2FyZOKA mSBtZXNzYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCBzaGlwcyBpdCB0byDigJhzZXJ2ZXJk4oCZ IG92ZXIgYSBsb2NhbCBsb29wYmFjay4gV2hlbiDigJhzZXJ2ZXJk4oCZIHNlbmRzIGJhY2sgdGhl IOKAmFJlbGF5LXJlcGx54oCZPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihhZ2FpbiBvdmVyIHRoZSBsb29w YmFjayksIOKAmHJlbGF5ZOKAmSBpbmplY3RzIGEgcm91dGUgaW50byB0aGUgcm91dGluZyBzeXN0 ZW0gYW5kIHNlbmRzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c3VpdGFibGUgcmVwbHkgdG8gdGhlIGNs aWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBvbmx5 IHJlYXNvbiB3ZSBkbyBpdCB0aGlzIHdheSBpcyBiZWNhdXNlIHRoZSBjbGllbnQgY2Fubm90IHNw ZWFrIGRpcmVjdGx5IHRvIOKAmHNlcnZlcmTigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YW5kIGl0IHdv dWxkIGJlIGRpZmZpY3VsdCB0byBtZXJnZSDigJhyZWxheWTigJkgYW5kIOKAmHNlcnZlcmTigJkg aW50byBhIHNpbmdsZSBwcm9jZXNzIGNvbnRleHQuIEJ1dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXZl cnl0aGluZyBlbHNlIGlzIGNvb3JkaW5hdGVkIHdpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lz dGVtIGluc3RhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IGlhbmZhcnJlckBnbXguY29tIFttYWlsdG86aWFuZmFycmVyQGdteC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDI2LCAyMDE5IDg6MzkgQU08 YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmF2ZWVuIEtvdHRhcGFsbGkgJmx0O25hdmVl bi5zYXJtYUBnbWFpbC5jb20mZ3Q7OyB2Nm9wcyBsaXN0ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7 IGRoY3dnQGlldGYub3JnOyBNYXJ0aW4gSHVuZWsgJmx0O21hcnRpbi5odW5la0B0dWwuY3omZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVh ZGFjaGU6IERIQ1AgVjYgUmVsYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBGcmVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2lsbCBkby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBoYXZlbuKAmXQgdHJpZWQgdGhhdCBwYXJ0aWN1bGFyIGRlcGxveW1l bnQgc2NlbmFyaW8uIEkgc3VwcG9zZSB0aGF0IGlmIHRoZSByZWxheSBhbmQgc2VydmVyIHByb2Nl c3NlcyBkaWRu4oCZdCBzaGFyZSBhbnkgc3RhdGUgaW5mb3JtYXRpb24gdGhlbiB5b3UgY291bGQg c2VlIHRoZXNlIHByb2JsZW1zLiBJcyB0aGVyZSBhIGNhc2UgZm9yIHJ1bm5pbmcgYm90aCBzZXJ2 ZXIgYW5kIHJlbGF5IGZ1bmN0aW9ucyBvbiB0aGUNCiBzYW1lIGJveCwgcmF0aGVyIHRoYW4ganVz dCB0aGUgc2VydmVyIChhcyBhIGRlbGVnYXRpbmcgcm91dGVyKT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNi4gSnVuIDIwMTksIGF0IDE3OjI3 LCBUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSBJYW4g4oCTIHllcywgYSBjbGFyaWZpY2F0aW9uIG9mIOKAnGNv LWxvY2F0ZWTigJ0gd291bGQgYmUgZ3JlYXQuIFNvdW5kcyBsaWtlIHRoZXJlIGlzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5vdCBhIGNvbmNlcm4gd2hlbiB0aGUgcmVsYXkgYW5k IHNlcnZlciBhcmUgaW4gdGhlIHNhbWUgYm94IG9yIFZNLCByaWdodD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86aWFuZmFycmVyQGdteC5jb20iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmlhbmZhcnJlckBnbXguY29tPC9zcGFuPjwvYT48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzpp YW5mYXJyZXJAZ214LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmlhbmZh cnJlckBnbXguY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEp1bmUgMjYsIDIwMTkgODoyMiBB TTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5GcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OYXZlZW4gS290dGFwYWxsaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5hdmVlbi5zYXJtYUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm5hdmVlbi5zYXJtYUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs7IHY2b3Bz IGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+djZvcHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaGN3Z0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGhjd2dAaWV0Zi5vcmc8L3NwYW4+ PC9hPjsNCiBNYXJ0aW4gSHVuZWsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaHVuZWtAdHVs LmN6Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYXJ0aW4uaHVuZWtAdHVsLmN6PC9zcGFu PjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVh ZGFjaGU6IERIQ1AgVjYgUmVsYXk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGcmVkLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gdGhpcyBpbnN0YW5jZSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYmVpbmcg aW4gYSBzZXBhcmF0ZSBwaHlzaWNhbCBib3gsIG9yIFZNLiBUaGUgcHJvYmxlbXMgSeKAmXZlIG9i c2VydmVkIGFyZSB3aXRoICZuYnNwO0wzIGVkZ2Ugcm91dGVycyB3aXRoPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUg cmVsYXkgZnVuY3Rpb24gaW4gdGhlIGFjY2VzcyBuZXR3b3JrIHdpdGggYSBjZW50cmFsaXNlZCBE SENQdjYgc2VydmVyLiBXZSBjYW4gY2xhcmlmeSB0aGlzIGJldHRlciBpbiB0aGUgbmV4dCB1cGRh dGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklhbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjYuIEp1biAyMDE5LCBhdCAxNzoxNCwgVGVtcGxpbiAo VVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9z cGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkhpIE5hdmVlbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGRyYWZ0IOKAkyBhIHF1aWNrIHF1ZXN0aW9uIC0g d2hhdCBpcyBtZWFudCBieSDigJxESENQdjYgcmVsYXkgZnVuY3Rpb24gaXMgbm90IGNvLWxvY2F0 ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aCB0 aGUgREhDUHY2IHNlcnZlciBmdW5jdGlvbuKAnS4gRG9lcyBpdCBtZWFuIOKAnGNvLWxvY2F0ZWTi gJ0gYXMgaW4gd2l0aGluIHRoZSBzYW1lIHByb2Nlc3MsIHdpdGhpbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGUgc2FtZSB2aXJ0dWFsIG1hY2hpbmUs IHdpdGhpbiB0aGUgc2FtZSBwaHlzaWNhbCBib3gsIHdpdGhpbiB0aGUgc2FtZSBMQU4sIGV0Yy4/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SRkM2MjIxIGFs bG93cyBmb3IgdGhlIHJlbGF5IGZ1bmN0aW9uIHRvIGJlIGluIGEgc2VwYXJhdGUgcHJvY2VzcyBm cm9tIHRoZSBzZXJ2ZXIgZnVuY3Rpb24gYnV0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPndpdGhpbiB0aGUgc2FtZSBvcGVyYXRpbmcgc3lzdGVtIGluc3Rh bmNlLiBTbywgdGhlIHR3byBwcm9jZXNzZXMgc2hhcmUgdGhlIHNhbWUgY2xvY2ssIElQPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZvcndhcmRpbmcgdGFi bGUsIHN5c3RlbSBtZW1vcnksIGV0Yy4gSW4gc3VjaCBhbiBhcnJhbmdlbWVudCwgY2FuIGl0IGJl IHNhaWQgdGhhdCB0aGUgREhDUHY2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPnJlbGF5IGFuZCBzZXJ2ZXIgZnVuY3Rpb25zIGFyZSBpbiBmYWN0IOKAnGNv LWxvY2F0ZWTigJ0gZXZlbiBpZiB0aGV5IGRvIG5vdCByZXNpZGUgd2l0aGluIHRoZSBzYW1lPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByb2Nlc3MgY29u dGV4dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kaGN3Zw0KIFs8YSBocmVmPSJt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5OYXZlZW4gS290dGFw YWxsaTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBKdW5lIDI1LCAyMDE5IDk6MTQgQU08YnI+DQo8Yj5Ubzo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnY2b3Bz IGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+djZvcHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaGN3Z0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGhjd2dAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+TWFydGluIEh1bmVrICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmh1bmVr QHR1bC5jeiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFydGluLmh1bmVrQHR1bC5jejwv c3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW2RoY3dnXSBbdjZvcHNdIE9wZXJhdGlvbmFs IEhlYWRhY2hlOiBESENQIFY2IFJlbGF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmV3IGRyYWZ0IG9uIHRoaXMgc3ViamVjdCBp cyBzdWJtaXR0ZWQgdG9kYXkuJm5ic3A7IFBsZWFzZSBnbyB0aHJvdWdoIHRoZSBzYW1lIGluIGJl bG93IGxpbmsgYW5kIGxldCB1cyBrbm93IHlvdXIgZmVlZGJhY2suPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAu dHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYXZlZW4gS290dGFw YWxsaSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpO YW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZmtocC1k aGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50czxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBESENQdjYgUHJlZml4IERlbGVnYXRpbmcgcmVsYXk8YnI+DQpEb2N1bWVudCBkYXRl OiZuYnNwOyAyMDE5LTA2LTI1PGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDEwPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDAu dHh0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxh eS1yZXF1aXJlbWVudHMtMDAudHh0PC9zcGFuPjwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMvIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50 cy88L3NwYW4+PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ma2hwLWRoYy1kaGNwdjYt cGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZraHAtZGhjLWRo Y3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMtMDA8L3NwYW4+PC9hPjxicj4NCkh0bWxpemVkOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50 cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5 LXJlcXVpcmVtZW50czwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0K Jm5ic3A7ICZuYnNwO09wZXJhdGlvbmFsIGV4cGVyaWVuY2Ugd2l0aCBESENQdjYgcHJlZml4IGRl bGVnYXRpb24gaGFzIHNob3duIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7d2hlbiB0aGUgREhDUHY2 IHJlbGF5IGZ1bmN0aW9uIGlzIG5vdCBjby1sb2NhdGVkIHdpdGggdGhlIERIQ1B2Njxicj4NCiZu YnNwOyAmbmJzcDtzZXJ2ZXIgZnVuY3Rpb24sIGlzc3VlcyBzdWNoIGFzIHRpbWVyIHN5bmNocm9u aXphdGlvbiBiZXR3ZWVuIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtESENQIGZ1bmN0aW9uYWwgZWxl bWVudHMsIHJlamVjdGlvbiBvZiBjbGllbnQncyBtZXNzYWdlcyBieSB0aGU8YnI+DQombmJzcDsg Jm5ic3A7cmVsYXksIGFuZCBvdGhlciBwcm9ibGVtcyBoYXZlIGJlZW4gb2JzZXJ2ZWQuJm5ic3A7 IFRoZXNlIHByb2JsZW1zIGNhbjxicj4NCiZuYnNwOyAmbmJzcDtyZXN1bHQgaW4gcHJlZml4IGRl bGVnYXRpb24gZmFpbGluZyBvciB0cmFmZmljIHRvL2Zyb20gY2xpZW50czxicj4NCiZuYnNwOyAm bmJzcDthZGRyZXNzZWQgZnJvbSB0aGUgZGVsZWdhdGVkIHByZWZpeCBiZWluZyB1bnJvdXRlYWJs ZS4mbmJzcDsgQWx0aG91Z2g8YnI+DQombmJzcDsgJm5ic3A7W1JGQzg0MTVdIG1lbnRpb25zIHRo aXMgZGVwbG95bWVudCBzY2VuYXJpbywgaXQgZG9lcyBub3QgcHJvdmlkZTxicj4NCiZuYnNwOyAm bmJzcDtuZWNlc3NhcnkgZGV0YWlsIG9uIGhvdyB0aGUgcmVsYXkgZWxlbWVudCBzaG91bGQgYmVo YXZlIHdoZW4gdXNlZDxicj4NCiZuYnNwOyAmbmJzcDt3aXRoIFBELjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBm b3IgYSBESENQdjYgUEQgcmVsYXk8YnI+DQombmJzcDsgJm5ic3A7d2hlbiB1c2VkIGZvciByZWxh eWluZyBwcmVmaXhlcyBkZWxlZ2F0ZWQgYnkgYSBzZXBhcmF0ZSBESENQdjY8YnI+DQombmJzcDsg Jm5ic3A7c2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdXJzLDxicj4NCk5hdmVlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCAxIEFwciAyMDE5IGF0IDE4OjM0LCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlhbmZhcnJlckBnbXguY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aWFuZmFycmVyQGdteC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgTWFydGluLDxicj4NCjxicj4NCkkgd291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIHdvcmtp bmcgb24gdGhpcyBhcyBpdOKAmXMgYSBwcm9ibGVtIGZvciB1cy4gSeKAmXZlIGdvdCBzb21ldGhp bmcgSSB3cm90ZSBhIHdoaWxlIGJhY2suIEnigJlsbCBzaGFyZSBpdCBhcyBhIHN0YXJ0aW5nIHBv aW50Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpJYW48YnI+DQo8YnI+DQomZ3Q7IE9uIDEuIEFw ciAyMDE5LCBhdCAxMTozMSwgTWFydGluIEh1bmVrICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGlu Lmh1bmVrQHR1bC5jeiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1hcnRpbi5odW5la0B0dWwuY3o8L3NwYW4+PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IEhp IEZyZWQsPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQomZ3Q7IEkgd291bGQgYmUgaW50ZXJlc3RlZCB0byBhZGRyZXNzIHRoaXMg aXNzdWUsIGFzIGl0IGlzIHRoZSBvbmUgSSdtIGFsc28gaGF2aW5nLiBCdXQgSSB3b3VsZCBuZWVk IHNvbWUgYXNzaXN0YW5jZSwgYXMgSSBkb24ndCByZWFsbHkga25vdyBteSB3YXlzIGFyb3VuZCBJ RVRGIHByb2Nlc3NlcyB5ZXQuPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IE1hcnRpbjxicj4NCiZndDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBEbmUgcMOh dGVrIDI5LiBixZllem5hIDIwMTkgNjozNzoyNSBDRVNULCBGcmVkIEJha2VyIG5hcHNhbChhKTo8 YnI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9zbGlkZXMtMTA0 LXY2b3BzLWRldXRzY2hlLXRlbGVrb20tdGVyYXN0cmVhbS8iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9z bGlkZXMtMTA0LXY2b3BzLWRldXRzY2hlLXRlbGVrb20tdGVyYXN0cmVhbS88L3NwYW4+PC9hPiwN CiBzbGlkZSAzLTQ8YnI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyBXaGF0IGRvIHdlIHdhbnQgdG8gc2F5IGFi b3V0IERIQ1B2NiBpc3N1ZXMgaW4gdmVuZG9yIHByb2R1Y3QgYW5kL29yIHNlcnZpY2VzPyBUaGlz IGhlYWRhY2hlIGRvZXNuJ3QgaGF2ZSBhbiBvYnZpb3VzIGRyYWZ0LiBJIHRoaW5rIHRoYXQgcHJv YmFibHkgY2FsbHMgZm9yIGEgcGVyc29uIG9yIGRlc2lnbiB0ZWFtIHRvIGNyZWF0ZSBzdWNoIGEg ZHJhZnQgZm9yIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYW5kIGluIE1vbnRyZWFsLjxicj4NCiZn dDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCiZndDsmZ3Q7IEFueSB0YWtlcnM/PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7Jmd0OyBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGlnaHdheSB0byBo ZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBjb21tZW50IG9u IHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgdjZvcHMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52Nm9wc0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52Nm9wc0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZSI+ZGhjd2dAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RoY3dnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9b9924f3ef0a4b2c8d48c86a652d957eboeingcom_-- From nobody Wed Jun 26 08:56:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99D1202E5; Wed, 26 Jun 2019 08:56:52 -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_HELO_NONE=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 nyn-_MWiIc65; Wed, 26 Jun 2019 08:56:50 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0D112003E; Wed, 26 Jun 2019 08:56:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x5QFukvV004332; Wed, 26 Jun 2019 11:56:47 -0400 Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x5QFubVf002744 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 26 Jun 2019 11:56:37 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 26 Jun 2019 08:56:36 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Wed, 26 Jun 2019 08:56:36 -0700 From: "Templin (US), Fred L" To: v6ops list , 6man <6man@ietf.org> Thread-Topic: RFC4861 question - short prefixes in PIOs Thread-Index: AdUsMmrDTybnqCimSw+vUa2pQYzWEw== Date: Wed, 26 Jun 2019 15:56:36 +0000 Message-ID: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 2598C4F5B3DB5AF477AE552F0AC5A0B28F03625FB207A311AF2C3C05EBB6168A2000:8 Content-Type: multipart/alternative; boundary="_000_729f46ec4a8b419797e15bbdcac3e549boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:56:52 -0000 --_000_729f46ec4a8b419797e15bbdcac3e549boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGFuIFJGQzQ4NjEgcXVlc3Rpb24gKHNldmVyYWwgYWN0dWFsbHkpIG9uIHNob3J0IHBy ZWZpeGVzIGluIFJBIFBJT3M6DQoNCg0KDQoxKSBJZiBhIFBJTyBpbmNsdWRlcyBhIHByZWZpeCB3 aXRoIGxlbmd0aCBsZXNzIHRoYW4gNjQgKGUuZy4sIDIwMDE6ZGI4OjovMzIpIGFuZCB3aXRoIEw9 MSwgZG9lcyBpdA0KDQptZWFuIHRoYXQgMjAwMTpkYjg6Oi8zMiBzaG91bGQgYmUgYWRkZWQgdG8g dGhlIGludGVyZmFjZSBwcmVmaXggbGlzdD8NCg0KDQoNCjIpIElmIHllcyB0byAxKSwgZG9lcyBp dCBtZWFuIHRoYXQgcGFja2V0cyBmb3J3YXJkZWQgdG8gdGhlIGludGVyZmFjZSBmb3IgYW55IGRl c3RpbmF0aW9uIGNvdmVyZWQNCg0KYnkgMjAwMTpkYjg6Oi8zMiB3aWxsIHRyaWdnZXIgQWRkcmVz cyBSZXNvbHV0aW9uIGluc3RlYWQgb2YgZm9yd2FyZGluZyB0byBhIGRlZmF1bHQgcm91dGVyPw0K DQoNCg0KMykgSWYgdGhlIFBJTyBpbnN0ZWFkIGhhcyBMPTAsIGRvZXMgaXQgbWVhbiB0aGF0IDIw MDE6ZGI4OjovMzIgaXMg4oCcYXNzb2NpYXRlZOKAnSB3aXRoIHRoZSBsaW5rIGJ1dA0KDQpub3Qg bmVjZXNzYXJpbHkg4oCcb24tbGlua+KAnT8NCg0KDQoNCjQpIElmIHllcyB0byAzKSwgZG9lcyBp dCBtZWFuIHRoYXQgMjAwMTpkYjg6Oi8zMiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIElQdjYgZm9y d2FyZGluZyB0YWJsZQ0KDQphcyBhIOKAnHJvdXRlLXRvLWludGVyZmFjZeKAnSB3aXRoIHRoZSBy ZWNlaXZpbmcgaW50ZXJmYWNlIGFzIHRoZSBuZXh0IGhvcD8NCg0KDQoNCjUpIERvZXMgQT0xIGhh dmUgYW55IG1lYW5pbmcgZm9yIHByZWZpeGVzIHdpdGggbGVuZ3RoIGxlc3MgdGhhbiA2ND8gT3Is IG11c3QgcHJlZml4ZXMgd2l0aA0KDQpsZW5ndGggbGVzcyB0aGFuIDY0IHNldCBBPTA/DQoNCg0K DQpUaGFua3MgLSBGcmVkDQo= --_000_729f46ec4a8b419797e15bbdcac3e549boeingcom_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhhdmUgYW4gUkZDNDg2MSBxdWVzdGlv biAoc2V2ZXJhbCBhY3R1YWxseSkgb24gc2hvcnQgcHJlZml4ZXMgaW4gUkEgUElPczo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MSkgSWYgYSBQSU8gaW5jbHVkZXMgYSBwcmVmaXggd2l0 aCBsZW5ndGggbGVzcyB0aGFuIDY0IChlLmcuLCAyMDAxOmRiODo6LzMyKSBhbmQgd2l0aCBMPTEs IGRvZXMgaXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm1lYW4gdGhh dCAyMDAxOmRiODo6LzMyIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgaW50ZXJmYWNlIHByZWZpeCBs aXN0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yKSBJZiB5ZXMgdG8gMSksIGRvZXMg aXQgbWVhbiB0aGF0IHBhY2tldHMgZm9yd2FyZGVkIHRvIHRoZSBpbnRlcmZhY2UgZm9yIGFueSBk ZXN0aW5hdGlvbiBjb3ZlcmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5ieSAyMDAxOmRiODo6LzMyIHdpbGwgdHJpZ2dlciBBZGRyZXNzIFJlc29sdXRpb24gaW5zdGVh ZCBvZiBmb3J3YXJkaW5nIHRvIGEgZGVmYXVsdCByb3V0ZXI/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjMpIElmIHRoZSBQSU8gaW5zdGVhZCBoYXMgTD0wLCBkb2VzIGl0IG1lYW4gdGhh dCAyMDAxOmRiODo6LzMyIGlzIOKAnGFzc29jaWF0ZWTigJ0gd2l0aCB0aGUgbGluayBidXQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm5vdCBuZWNlc3NhcmlseSDigJxv bi1saW5r4oCdPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij40KSBJZiB5ZXMgdG8gMyks IGRvZXMgaXQgbWVhbiB0aGF0IDIwMDE6ZGI4OjovMzIgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBJ UHY2IGZvcndhcmRpbmcgdGFibGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPmFzIGEg4oCccm91dGUtdG8taW50ZXJmYWNl4oCdIHdpdGggdGhlIHJlY2VpdmluZyBpbnRl cmZhY2UgYXMgdGhlIG5leHQgaG9wPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij41KSBE b2VzIEE9MSBoYXZlIGFueSBtZWFuaW5nIGZvciBwcmVmaXhlcyB3aXRoIGxlbmd0aCBsZXNzIHRo YW4gNjQ/IE9yLCBtdXN0IHByZWZpeGVzIHdpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmxlbmd0aCBsZXNzIHRoYW4gNjQgc2V0IEE9MD88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_729f46ec4a8b419797e15bbdcac3e549boeingcom_-- From nobody Wed Jun 26 23:35:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B081200DB; Wed, 26 Jun 2019 23:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 7avrMCXXDdvI; Wed, 26 Jun 2019 23:35:23 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B941200B6; Wed, 26 Jun 2019 23:35:23 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id x15so4474695wmj.3; Wed, 26 Jun 2019 23:35:23 -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=3EycOkvhlS3bCy1rQsi79MXYDKUc8rf9TrHnaiQyzvM=; b=qdCpmMFBSy7hHWQ0M5e2ceu4s4uOflvjbj3BZRX2KfqolgeRTquw111xCnJP93Vg+J 3Qng4dBT6PyOwiBwSOFvEzqZuGdxXhBGXQ9xtIWONCdhuzYhxmNMN2e/8wsvd+5elFI8 1ot22MgMbRr/6wpwnvMws2GZ/1prdVFAA5Ze35Dzwpa8pHNLoBB2fwgOd7h997z0PEnw TrCyHf0yDbfJ8jWeE3ZIrpGG4rz6pCUOeem8R2okK+UteisLAetvCetMNOfw0vHeJOT6 PB45+bhanK5RUQaNS1QN3LH8Ok6ufzdw8iMJZmVnFELgRFprQYHTaYkN0aF827IQcp9U UwsA== 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=3EycOkvhlS3bCy1rQsi79MXYDKUc8rf9TrHnaiQyzvM=; b=nj0RJ1APPsird27fh0gyCxlyDaXVFYtCInyTCCv46ZM8+C5sUlxjOlz/nBJwuit//j Pj0UfB63eL4ImiYtqAOd2fB13PNsEt/vNjTXRhuyHGK+hd0fZNZBArqhuQoF4F3gwEhi p+El3qEu8lCkvPzHhDYzG0OZeMqcPplj24o/I8d2E9b2FWD+S20aHPurB8/axPsTGnm3 55UMU50bstqV9AwJV1NsApvbVJQRCMVNqUFp5T2xRa67sX0m64JQV/vUN0qp1d7D2yPX pwEsGRycOzxojl6QKorhapN9vxYlT2aRuuphd47U/wO97dvgTF5hAObCx4vILI+j1NGy G/pw== X-Gm-Message-State: APjAAAU8RaDGHA0NnGgyaqhiZ9At7BRZZdP8NL/Tsg8l50rkYq6SiXuY dWDQ2ZzNPAFvnVen9O3mgs0= X-Google-Smtp-Source: APXvYqweJyBCmDHFXWStrpHwz0TVh5kKNoGiuaQ2QD18sYgwi2QXRcWFeVWPTq6OAn5I0CMAYPi2/Q== X-Received: by 2002:a1c:7d4e:: with SMTP id y75mr1859739wmc.169.1561617321704; Wed, 26 Jun 2019 23:35:21 -0700 (PDT) Received: from [10.196.220.133] (9-197.icannmeeting.org. [199.91.197.9]) by smtp.gmail.com with ESMTPSA id j7sm1092169wru.54.2019.06.26.23.35.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 23:35:20 -0700 (PDT) From: Fred Baker Message-Id: <218CA62E-75FC-462A-A04E-7B3377631F5E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C2874D58-8ABF-421C-8C04-8569D5CBC00D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 07:35:18 +0100 In-Reply-To: <9b9924f3ef0a4b2c8d48c86a652d957e@boeing.com> Cc: "ianfarrer@gmx.com" , "dhcwg@ietf.org" , v6ops list To: Fred Templin References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> <9b9924f3ef0a4b2c8d48c86a652d957e@boeing.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 06:35:26 -0000 --Apple-Mail=_C2874D58-8ABF-421C-8C04-8569D5CBC00D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don't see a prohibition of this sort of design, but it seems = unnecessarily complex. The relay protocol is designed to communicate = from a relay to another relay or to a server. Adding a relay process = just to communicate with the server process via localhost seems an = unnecessary step. > On Jun 26, 2019, at 4:53 PM, Templin (US), Fred L = wrote: >=20 > The server and relay run in the same operating system instance, but in = two separate process > contexts =E2=80=93 call them =E2=80=98relayd=E2=80=99 and = =E2=80=98serverd=E2=80=99. >=20 > =E2=80=98relayd=E2=80=99 receives a client prefix delegation request = then prepares a =E2=80=98Relay-forward=E2=80=99 message > and ships it to =E2=80=98serverd=E2=80=99 over a local loopback. When = =E2=80=98serverd=E2=80=99 sends back the =E2=80=98Relay-reply=E2=80=99 > (again over the loopback), =E2=80=98relayd=E2=80=99 injects a route = into the routing system and sends a > suitable reply to the client. >=20 > The only reason we do it this way is because the client cannot speak = directly to =E2=80=98serverd=E2=80=99 > and it would be difficult to merge =E2=80=98relayd=E2=80=99 and = =E2=80=98serverd=E2=80=99 into a single process context. But, > everything else is coordinated within the same operating system = instance. >=20 > Fred >=20 > From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com] > Sent: Wednesday, June 26, 2019 8:39 AM > To: Templin (US), Fred L > Cc: Naveen Kottapalli ; v6ops list = ; dhcwg@ietf.org; Martin Hunek > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay >=20 > Hi Fred, >=20 > Will do. >=20 > I haven=E2=80=99t tried that particular deployment scenario. I suppose = that if the relay and server processes didn=E2=80=99t share any state = information then you could see these problems. Is there a case for = running both server and relay functions on the same box, rather than = just the server (as a delegating router)? >=20 > Thanks, > Ian >=20 >=20 > On 26. Jun 2019, at 17:27, Templin (US), Fred L = wrote: >=20 > Hi Ian =E2=80=93 yes, a clarification of =E2=80=9Cco-located=E2=80=9D = would be great. Sounds like there is > not a concern when the relay and server are in the same box or VM, = right? >=20 > Thanks - Fred >=20 > From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com] > Sent: Wednesday, June 26, 2019 8:22 AM > To: Templin (US), Fred L > Cc: Naveen Kottapalli ; v6ops list = ; dhcwg@ietf.org; Martin Hunek > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay >=20 > Hi Fred, >=20 > In this instance, we are talking about being in a separate physical = box, or VM. The problems I=E2=80=99ve observed are with L3 edge routers = with > the relay function in the access network with a centralised DHCPv6 = server. We can clarify this better in the next update. >=20 > Thanks, > Ian >=20 >=20 >=20 > On 26. Jun 2019, at 17:14, Templin (US), Fred L = wrote: >=20 > Hi Naveen, >=20 > Thanks for the draft =E2=80=93 a quick question - what is meant by = =E2=80=9CDHCPv6 relay function is not co-located > with the DHCPv6 server function=E2=80=9D. Does it mean = =E2=80=9Cco-located=E2=80=9D as in within the same process, within > the same virtual machine, within the same physical box, within the = same LAN, etc.? >=20 > RFC6221 allows for the relay function to be in a separate process from = the server function but > within the same operating system instance. So, the two processes share = the same clock, IP > forwarding table, system memory, etc. In such an arrangement, can it = be said that the DHCPv6 > relay and server functions are in fact =E2=80=9Cco-located=E2=80=9D = even if they do not reside within the same > process context? >=20 > Thanks - Fred >=20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Naveen = Kottapalli > Sent: Tuesday, June 25, 2019 9:14 AM > To: v6ops list ; dhcwg@ietf.org > Cc: Martin Hunek > Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay >=20 > Hello All, >=20 > A new draft on this subject is submitted today. Please go through the = same in below link and let us know your feedback. >=20 > ---- >=20 > A new version of I-D, = draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt > has been successfully submitted by Naveen Kottapalli and posted to the > IETF repository. >=20 > Name: draft-fkhp-dhc-dhcpv6-pd-relay-requirements > Revision: 00 > Title: DHCPv6 Prefix Delegating relay > Document date: 2019-06-25 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requir= ements-00.txt > Status: = https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requiremen= ts/ > Htmlized: = https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00= > Htmlized: = https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requi= rements >=20 >=20 > Abstract: > Operational experience with DHCPv6 prefix delegation has shown that > when the DHCPv6 relay function is not co-located with the DHCPv6 > server function, issues such as timer synchronization between the > DHCP functional elements, rejection of client's messages by the > relay, and other problems have been observed. These problems can > result in prefix delegation failing or traffic to/from clients > addressed from the delegated prefix being unrouteable. Although > [RFC8415] mentions this deployment scenario, it does not provide > necessary detail on how the relay element should behave when used > with PD. >=20 > This document describes functional requirements for a DHCPv6 PD = relay > when used for relaying prefixes delegated by a separate DHCPv6 > server. >=20 > Yours, > Naveen. >=20 >=20 > On Mon, 1 Apr 2019 at 18:34, wrote: > Hi Martin, >=20 > I would also be interested in working on this as it=E2=80=99s a = problem for us. I=E2=80=99ve got something I wrote a while back. I=E2=80=99= ll share it as a starting point. >=20 > Cheers, > Ian >=20 > > On 1. Apr 2019, at 11:31, Martin Hunek wrote: > > > > Hi Fred, > > > > I would be interested to address this issue, as it is the one I'm = also having. But I would need some assistance, as I don't really know my = ways around IETF processes yet. > > > > Martin > > > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker = napsal(a): > >> = https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr= eam/, slide 3-4 > >> > >> What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal. > >> > >> Any takers? > >> = --------------------------------------------------------------------------= ------ > >> The fact that there is a highway to hell and a stairway to heaven = is an interesting comment on projected traffic volume... > >> > > > > _______________________________________________ > > 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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_C2874D58-8ABF-421C-8C04-8569D5CBC00D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0UY6YACgkQEhdRnd2G P+Bo+RAAnGYktAJug3UFiF2eVgkO0XkL5IYuc4N69tVUYrKxtHrmHb7JOD9jqZGz w+6KGxFSXJBPG2t0vQvJ+sosb6Ki0KXds1a67AQxBWU2YGzb6mlY86xZkiPfaAow kQAFfvApdiaT1eLsiU7+VoW9ayZon8WHAYTHOKwk1IkIswFRw9gFTPD8z6XGahfY /AsbWRz7NRjGyT3F8q/DfFxHneA7RiDpyTPLQk2Z92JjkirfvKAfLwhoX+7HR5EY WnDcT7PSATc6Q6bAezcEdhwLXFQtexs6c4+66iottD9q6mvXwsbqgQ5V3X9lqhjT pv9Om/NOSprPdKSKAvD0P37K2lpi1FfFBGP9tyGkYwoaHwqRjU76oj0s3QSArpw4 ZVX8THclur1skiV6j263RY4L7c/pu+ZtDpr2R5VvszuUFzBNSDZA599HAkEg9YmM HJzmYJ6iH3CCsOPE4Dl4rkT4d6AlljKmxQgMctd0Pz0Nhfn4Jg1HoF75WHNgPM9x u6pBhKlm/JiJwRNKonyr3x06e9AIKXyiehWgr+9c9WHOcgjqQCNnLcQeioYkn4sQ xInUGgHvm7SQ35zl0o0pFMwE6MW0YLHGdDAUevc4WE27UH+7CmkDCvM6uaZybrWc VLybQ9hWIzy0cOhIo+zS+KBXh7s0U421uFnmC6a2p5tUgIi7dx0= =Z5kp -----END PGP SIGNATURE----- --Apple-Mail=_C2874D58-8ABF-421C-8C04-8569D5CBC00D-- From nobody Thu Jun 27 06:58:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692141200B1; Thu, 27 Jun 2019 06:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 R3SBRx32P_yo; Thu, 27 Jun 2019 06:58:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371321200B9; Thu, 27 Jun 2019 06:58:40 -0700 (PDT) Received: from [192.168.100.20] (unknown [160.176.180.63]) (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 14BD38DFB9; Thu, 27 Jun 2019 15:58:32 +0200 (CEST) To: V6Ops Chairs , IPv6 Operations References: From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 27 Jun 2019 14:54:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 13:58:44 -0000 On 25/6/19 05:02, Fred Baker wrote: > Ron and I have posted a preliminary agenda at https://datatracker.ietf.org/doc/agenda-105-v6ops/. > > There is space for additional drafts, if they are posted before the repository closes on July 8 and we see email list commentary supportive of their having agenda time. FWIW, we're editing the document draft-gont-6man-slaac-renum, essentially targetting an operational recommendations by v6ops. Goal is to post the document no later than this weekend. If possible, we'd like to have agenda time. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Thu Jun 27 07:16:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2893E1200B1; Thu, 27 Jun 2019 07:16: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, SPF_HELO_NONE=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=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 kPKxs9ZmYbvn; Thu, 27 Jun 2019 07:16:16 -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 5B72912003E; Thu, 27 Jun 2019 07:16:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 783214B; Thu, 27 Jun 2019 16:16:06 +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=1561644963; bh=UIzUt7NvrVIC1GNSfyE C52Uk1AKf41STcLHo7YTsAQU=; b=XyQw8iD8E90Lo1GIYSMvoWOcuoelyur1ZpL Nf26AymJsuMqH6SDLUstlbu4jFNZ0QFGSSR9PWNoelQwyYtINO6doihvBEgoj/RT TWKXzTj40kqkci5++3ttorslYq/i82UW0q73ln0pn8ce9Dupomb2oAxEBEwItL4E Fq+0UAAA= 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 kUDreYUCVwfI; Thu, 27 Jun 2019 16:16:03 +0200 (CEST) Received: from [IPv6:2a02:a213:a300:ce80:6861:12d9:5824:3e4f] (unknown [IPv6:2a02:a213:a300:ce80:6861:12d9:5824:3e4f]) (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 DB4AB4A; Thu, 27 Jun 2019 16:16:02 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <1905B5DD-1352-411D-8EA8-A0D88AC2377E@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_9A62DD5C-5CDB-489D-80BF-1FDA886556D3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 16:16:02 +0200 In-Reply-To: <218CA62E-75FC-462A-A04E-7B3377631F5E@gmail.com> Cc: Fred Templin , "dhcwg@ietf.org" , v6ops list To: Fred Baker References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> <9b9924f3ef0a4b2c8d48c86a652d957e@boeing.com> <218CA62E-75FC-462A-A04E-7B3377631F5E@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 14:16:18 -0000 --Apple-Mail=_9A62DD5C-5CDB-489D-80BF-1FDA886556D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, > I don't see a prohibition of this sort of design, but it seems = unnecessarily complex. The relay protocol is designed to communicate = from a relay to another relay or to a server. Adding a relay process = just to communicate with the server process via localhost seems an = unnecessary step. When implementing DHCPKit I implemented it in roughly the same way = (although I did it inside a single process). Wrapping every incoming = message inside a relay message makes it possible to handle layer-2 = information uniformly. The process/function that listens on the multicast address generates an = internal relay message with all relevant information (interface, mac = address, source link-local address etc) and sends that to the main = server to be processed. The server can then always get all relevant = information from the DHCPv6 packet stack, independent of how it was = received. Otherwise you'd have to have an extra channel to communicate = all that metadata to the server process. Cheers, Sander --Apple-Mail=_9A62DD5C-5CDB-489D-80BF-1FDA886556D3 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----- iQEzBAEBCAAdFiEE9VC3eloaasvH0nE1oC0DsP4kE7kFAl0Uz6IACgkQoC0DsP4k E7mA6Qf/Y9TQXCDOqqF5TZbnnnMiUB0MPB8XNLKp462QgYXEdt/CDAlGcz2K4izU MItwTsaFjMbzFJWMbY5fHydee6Nl6uQBv4zVQjmX9rvO1dAQYR53oWzxN6Y0OIZs MvMAG8Zwmg/H2ppdgfRYpEXeGcT28Kne1fqAmNDGgRcXi/CegCass6qjb2f75zQo +HdsUxWyedKoYenK/OW3lIsbTMiPPmGseEb5sY3t8bJUT58eIdZAPWg6SPVIAamb /I/gSzuLbWo8DMzQE2kUKtMYZmgcRCLQz9RhgaWWqhJEYydtkjd9oDhe32lC4Yj0 9bc/Nm8r0qfJomkXRmgRJEOaK9Zzhg== =iGLv -----END PGP SIGNATURE----- --Apple-Mail=_9A62DD5C-5CDB-489D-80BF-1FDA886556D3-- From nobody Thu Jun 27 07:51:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5C3120172 for ; Thu, 27 Jun 2019 07:51:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCwoMqHtqrpm for ; Thu, 27 Jun 2019 07:51:04 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A6A120183 for ; Thu, 27 Jun 2019 07:50:54 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id c66so6033478wmf.0 for ; Thu, 27 Jun 2019 07:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=toNnePb11ocC8B/+uM563jV/1zOJG7d+qQg26tKCtd4=; b=QMc6cQ8yjUEgL6GYPoY9OeJRAOoyIjV1ciaKgxM/20re2383252ER1OnHMhpSO6Kdz uh0PM/snxLnNWHByqJ7m7XsoToizqrnP7Cit93wSxEQv619GpJde/GPTq/i5eVSPPJk2 PIeQaIo1y5wE6UIeIwBVMgJXoQfEJQldum6W0jBPuhtuULXIoR62UD0fVlwhZyY3OnaM MSoSSAKEXMlKZY9DE3S/SXAMaNRopWA9M6DVyLcUEsdEiP8siG75YZ+x927hfD5cQCpl /Tg1R/j2bq3Hlu/ZsPUpIz8GZ2I4HJFKzjkwp9kFqtXtgCMiKzDe5xAVGuNT3TuRSdOq oOfQ== 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=toNnePb11ocC8B/+uM563jV/1zOJG7d+qQg26tKCtd4=; b=T8eCQe7/iJpitVK1B4Y3ZHqfszWLdabSqaRC/Ec6avhCh7A0A2pybgMv1aRqBTbjKt NRbY/dqtCLLiG36hyxj9lAYxN35JBQBzSd0Ug4VPiqYbHzM02bhPxr0gqR1eMfFwa7Tf 6Uuyd4/xfUM0D4x9p1g/t18caaolGI9cXGmlorsXfLezUTloBtJhKtofZ19GxLitzSdG 4EbVLksXcQA29h/KC7od/ND+A3VbRHfTSe6a6hc7qCSN/J2WHlTokaLCy8HqXKx2mhi3 3TPGKbHs17eKou+MpUNW6V2/fZhCaqYDixXRBfiHWQKNwyaAUP7+GJFkvnIFnT0v4CV7 7PNA== X-Gm-Message-State: APjAAAXTecAX1u1yZuwiPh2k/MESzfdH3DXBIWLtD7kfDMaArUl+H6bv hZpUEod+JOdvVBRQCiB3At4= X-Google-Smtp-Source: APXvYqw4HuXrmYmG6al9zQVrA4+A6Ts2DZX0TFGBiv7/P6G2HzzaprVa3b/b1s+i4jTid+OHvV7vqg== X-Received: by 2002:a7b:c310:: with SMTP id k16mr3307878wmj.133.1561647052849; Thu, 27 Jun 2019 07:50:52 -0700 (PDT) Received: from [10.196.220.133] (9-197.icannmeeting.org. [199.91.197.9]) by smtp.gmail.com with ESMTPSA id q10sm2887204wrf.32.2019.06.27.07.50.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 07:50:51 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_47061E52-0893-4E28-B505-53B34AB73784"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 15:50:50 +0100 In-Reply-To: Cc: IPv6 Operations To: Fernando Gont References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [v6ops] Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 14:51:06 -0000 --Apple-Mail=_47061E52-0893-4E28-B505-53B34AB73784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 27, 2019, at 2:54 PM, Fernando Gont = wrote: >=20 > FWIW, we're editing the document draft-gont-6man-slaac-renum, > essentially targetting an operational recommendations by v6ops. Is it going to be discussed in 6man? I'm not sure I see what multiple = presentation slots gets you, given that you already presented to v6ops. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_47061E52-0893-4E28-B505-53B34AB73784 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0U18oACgkQEhdRnd2G P+D6dg/9HVSAtMhswdJfpdE4vzasPBcO2ELj6vtyExBwAE7DsM6uQPAK6O9sqoE7 PeBw9WA61k25whIHyH3YoK7wsHii31le/AQjBOq0OVbBWDspi9xHkF4d+dhF7/Fx 6EyxyHPIIz6NuXT4PWKcW+uNZn2RbF+2PTYH+JcWct1mCtvonuikPz+mRKkyLBbg VzInAvikpOEO/FoOwLTBbu3PD5FTEkbk44D2tD9z5azdMY49eujkdI6zBssOVXNV fPmmZBqHbZodUi20VKz8RcEdJ73UPlSGsOLWmZ8BDf+wghNGxGzW1M2AqU1r+jpw u/uORlFDTYC4lc0biz5OjvVgrtbT8A7aC07MLvsxkRX2+O1bhppMlNJ9484n/hOy ImCPABkL2cWX16OyXI0CGNB4JVJqrhdrVNDhJrnJrb3wuUBag8nmQm+G+zn796q8 JhOvqyFbyJq1krfGWF4qy91IEIgPFvX3Y8NX3+l5s36i3l25nVkdX5JDddrlDovb b88G3aEJpBkFJjEO70ULAh16Fdi6huHT6dnzn43YN7wgC8CCP58cPNuS4LA4UhQ8 C93dA6s+ZSmi5RG1aCszRp3Dg7LRmAj8ZO1AYaeiGp+XtNpb6XXtgu52ZKUWnPo5 ouAjE5dEM7KWA2MRLh/U0NUMfYsY/2EQQX8UAwstYitI+svsjHo= =3Vk5 -----END PGP SIGNATURE----- --Apple-Mail=_47061E52-0893-4E28-B505-53B34AB73784-- From nobody Thu Jun 27 14:40:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903312023E; Thu, 27 Jun 2019 14:40:37 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 LvhEefiAEDVi; Thu, 27 Jun 2019 14:40:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041511201C9; Thu, 27 Jun 2019 14:40:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 47C7638183; Thu, 27 Jun 2019 17:38:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 899BF61; Thu, 27 Jun 2019 17:40:34 -0400 (EDT) From: Michael Richardson To: "Templin \(US\)\, Fred L" cc: v6ops list , 6man <6man@ietf.org> In-Reply-To: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 21:40:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Templin (US), Fred L wrote: > 3) If the PIO instead has L=3D0, does it mean that 2001:db8::/32 is > =E2=80=9Cassociated=E2=80=9D with the link but not necessarily =E2=80= =9Con-link=E2=80=9D? As others have said, and I find the RFC rather obtuse in this way, I think that only thing one can say is that if L=3D1, then devices in that indicated PIO can be found using ND (appropriately multicast). I think that when it is associated with the link, one can use SLAAC to assi= gn interfaces, but can't use ND to find neighbours. Hairpin'ing all traffic through the advertising router when L=3D0 seems like the only general solution. But, I can imagine many situations where if a Neighbour Cache entry somehow existed, then it could be used. I think that hairpin'ing all traffic has many interesting uses when it comes to providing firewalling (such as RFC8520) between devices. > 4) If yes to 3), does it mean that 2001:db8::/32 should be added to t= he > IPv6 forwarding table > as a =E2=80=9Croute-to-interface=E2=80=9D with the receiving interfac= e as the next hop? I don't think so. That would imply it was on-link, and L=3D0 means it isn't. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0VN9IACgkQgItw+93Q 3WWjSwf/bWslXQsPlaRP2WrTm8zlXNz4XE4OSJVjVSzxNL+xZUYLuw7Tokf7JZKE PzIEsFceJAz+v6X0ZDNiwRpTNDKOXrnKTsn7Qe1Mm4oDF07Kfb33uzYES7uoRvWR 31JJxr6Nma+Vlv/ItGR42pBAd6Jz+fKqBGYAvd3m0IuhrFeH0sGhOX7nmJwXno8H grndQ/qZueZpQMhq1abo6WYLhsXvbsqNsOzHO0HGZ3R/pyWTo31v+URan+DJDgKc 4+uNBowGywl2T10nfbupyacsjFyAN30YbQz1lbEfWBuYZ8CLkGObD5H5E4SNdoJx 8l0OZhWE9XWVFfpGyW+G85k9vLAH5w== =/7PR -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 27 21:25:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AA12013E; Thu, 27 Jun 2019 21:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.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.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 zh-Q5L4_1Y1J; Thu, 27 Jun 2019 21:25:18 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543D412004E; Thu, 27 Jun 2019 21:25:18 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id o101so4346338ota.8; Thu, 27 Jun 2019 21:25:18 -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=g5eBJUOr/nR1sr5t2BOb2QQKWuSxF9SQOMTsmRJ3U+s=; b=kRDGxWW4P6ing9xuTQdnR6BcwMS4UAc6qiqARPl1ldiIMHq6oEARHKBtG+F5nuvAm6 lQHbqJhkUMfJkQtgF9OD+M4ZMFYVxQpQ8haoEZnC1OrbHiaWYDOro7SypVhCKtXMFKRv Z/6SwHlPkKek4a4cL/6cYKuzb3YtrU3V7AHOy5peHGd8D9osLOMQvOBVetnXyvP0PtXP WPfTyR6uLfaZ3AuMk4USD3aM044LHsMRWomDEdo0pJkQRpgmui59Bk2FQs6L7qFS/yks zz9CZdRSxUuRXixYUVlNK7tLRmLXgF7tIipfh9+Hrp9WIgU0E57aYB5AQmwwFzVT0osv N+5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g5eBJUOr/nR1sr5t2BOb2QQKWuSxF9SQOMTsmRJ3U+s=; b=rUC98KM3XJvuygZddiCLSMQiHU7OLBTEAeXu9uHtEXCjLsJfEP0ljmuEJM0fhCRJ1c 4s94JoCi4xwVdO5bOsUK+3Xq9OkS9phOfUebH9OAYjXVL8J4YZj7OmyavE4U+1+lynjH L7JdLZlnZOJ5igupoKcSapSgMMiiQF1Bi4NtMZBJR0efOEhZWE5tkqARQj/cd8bT/6xy Oy4f0wAjIrpouyTI6q9v4/vNQyKwGU4VRFWLgztTNZ+jvzpe7G1EgTmgEBILxygStilQ a7Zi4CczvFB/LQTqC6qa0GFecbSlIVPxXjO/Nuf/n0APl6Y7hWQzuNw885nGEq8jGyke OmiQ== X-Gm-Message-State: APjAAAU13O0LPtIIOe0QGIEgPkq2epIRqO7DBZNYBVG0tcfOrJJMCcqw bXRzNNPGbHpqucR1d09d+VT/WybHSYyYzOvGo6c= X-Google-Smtp-Source: APXvYqzhjHmcjlahEDOhMwJxo9N7pjxgPL+0la0Byt+C4RGCu/ND9S9RqIfsJFkcDxfpQF+AWoZbsXPlBIR+pGTXm9g= X-Received: by 2002:a9d:65da:: with SMTP id z26mr6107471oth.257.1561695917649; Thu, 27 Jun 2019 21:25:17 -0700 (PDT) MIME-Version: 1.0 References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> <4615.1561671634@localhost> In-Reply-To: <4615.1561671634@localhost> From: Mark Smith Date: Fri, 28 Jun 2019 14:24:51 +1000 Message-ID: To: Michael Richardson Cc: "Templin, Fred L" , v6ops list , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000006b3316058c5aaa37" Archived-At: Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 04:25:21 -0000 --0000000000006b3316058c5aaa37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri., 28 Jun. 2019, 07:41 Michael Richardson, wrote: > > Templin (US), Fred L wrote: > > 3) If the PIO instead has L=3D0, does it mean that 2001:db8::/32 is > > =E2=80=9Cassociated=E2=80=9D with the link but not necessarily =E2= =80=9Con-link=E2=80=9D? > > As others have said, and I find the RFC rather obtuse in this way, I thin= k > that only thing one can say is that if L=3D1, then devices in that indica= ted > PIO can be found using ND (appropriately multicast). > > I think that when it is associated with the link, one can use SLAAC to > assign > interfaces, but can't use ND to find neighbours. > I see it as three separate things: 1. During IP address planning, assign a quantity of address space (prefix) to the link. 2. if SLAAC is to be used within that prefix, A=3D1 (the RFC 4861 default). 3. if hosts are to consider addresses within the link's address space/prefix to be directly reachable over the link, then L=3D1 (the RFC 48= 61 default). > > Hairpin'ing all traffic through the advertising router when L=3D0 seems l= ike > the only general solution. You can't hairpin literally all traffic via a router using the PIO L=3D1 or= 0 mechanism, because the Link-Local prefix has L=3D1 set in all hosts per RFC 5942, and it isn't currently possible to change it. This can cause problems as it conflicts with IPv6 address selection, which says LLs are preferred over GUA/ULA addresses. So if a host was presented with a set of DAs that includes LLs and GUA or ULAs, the LL would be preferred and fail, while if it chose a GUA or ULA DA it would work. Some might argue that's good for security, however I think LLs are more secure and reliable addresses for applications to use over GUAs and ULA addresses. I think that is why LLs are preferred in IPv6 default address selection. But, I can imagine many situations where if a > Neighbour Cache entry somehow existed, then it could be used. > > I think that hairpin'ing all traffic has many interesting uses when it > comes > to providing firewalling (such as RFC8520) between devices. > Per-device traffic accounting performed by a router could be another use case e.g. BRAS exporting that information via RADIUS accounting. > > 4) If yes to 3), does it mean that 2001:db8::/32 should be added to > the > > IPv6 forwarding table > > as a =E2=80=9Croute-to-interface=E2=80=9D with the receiving interf= ace as the next > hop? > > I don't think so. > That would imply it was on-link, and L=3D0 means it isn't. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000006b3316058c5aaa37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri., 28 Jun= . 2019, 07:41 Michael Richardson, <mcr+ietf@sandelman.ca> wrote:

Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:<= br> =C2=A0 =C2=A0 > 3) If the PIO instead has L=3D0, does it mean that 2001:= db8::/32 is
=C2=A0 =C2=A0 > =E2=80=9Cassociated=E2=80=9D with the link but not neces= sarily =E2=80=9Con-link=E2=80=9D?

As others have said, and I find the RFC rather obtuse in this way, I think<= br> that only thing one can say is that if L=3D1, then devices in that indicate= d
PIO can be found using ND (appropriately multicast).

I think that when it is associated with the link, one can use SLAAC to assi= gn
interfaces, but can't use ND to find neighbours.
<= br>
I see it as three separate things:

1= . During IP address planning, assign a quantity of address space (prefix) t= o the link.

2. if SLAAC is to be used within that = prefix, A=3D1 (the RFC 4861 default).

3. if hosts = are to consider addresses within the link's address space/prefix to be = directly reachable over the link, then L=3D1 (the RFC 4861 default).

=C2=A0

Hairpin'ing all traffic through the advertising router when L=3D0 seems= like
the only general solution.

You can't ha= irpin literally all traffic via a router using the PIO L=3D1 or 0 mechanism= , because the Link-Local prefix has L=3D1 set in all hosts per RFC 5942, an= d it isn't currently possible to change it.=C2=A0

<= div>This can cause problems as it conflicts with IPv6 address selection, wh= ich says LLs are preferred over GUA/ULA addresses. So if a host was present= ed with a set of DAs that includes LLs and GUA or ULAs, the LL would be pre= ferred and fail, while if it chose a GUA or ULA DA it would work.
=C2=A0
Some might argue that's good for security, howeve= r I think LLs are more secure and reliable addresses for applications to us= e over GUAs and ULA addresses. I think that is why LLs are preferred in IPv= 6 default address selection.


=C2=A0 But, I can imagine many situa= tions where if a
Neighbour Cache entry somehow existed, then it could be used.

I think that hairpin'ing all traffic has many interesting uses when it = comes
to providing firewalling (such as RFC8520) between devices.

Per-device traffic accounting performed by a router co= uld be another use case e.g. BRAS exporting that information via RADIUS acc= ounting.



=C2=A0 =C2=A0 > 4) If yes to 3), does it mean that 2001:db8::/32 should = be added to the
=C2=A0 =C2=A0 > IPv6 forwarding table
=C2=A0 =C2=A0 > as a =E2=80=9Croute-to-interface=E2=80=9D with the recei= ving interface as the next hop?

I don't think so.
That would imply it was on-link, and L=3D0 means it isn't.

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



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
--------------------------------------------------------------------
--0000000000006b3316058c5aaa37-- From nobody Fri Jun 28 05:12:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4F1200BA for ; Fri, 28 Jun 2019 05:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 YK_6hlZQdSPo for ; Fri, 28 Jun 2019 05:12:53 -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 42E7F120179 for ; Fri, 28 Jun 2019 05:12:53 -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 x5SCCpdT026218 for ; Fri, 28 Jun 2019 14:12:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3CABA202BAB for ; Fri, 28 Jun 2019 14:12:51 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 30AED202AD3 for ; Fri, 28 Jun 2019 14:12:51 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5SCCpsG003264 for ; Fri, 28 Jun 2019 14:12:51 +0200 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> Date: Fri, 28 Jun 2019 14:12:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A9A8EC857190BA644A1D255C" Content-Language: fr Archived-At: Subject: [v6ops] RFC that explains that interco links with LL only, are possible X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 12:12:55 -0000 This is a multi-part message in MIME format. --------------A9A8EC857190BA644A1D255C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit What is the RFC of v6ops WG that explains that it is possible to use link-local addresses (only LL, no GUA, no ULA) on a interco between routers, yet all other subnets use GUAs, and they do see each other? This is a fundamental concept used for car-to-car communicaitons (the link outside is LL-only, and all PCs in the cars use ULAs and can see each other). In a private converrsation I am asked how can this possible, and I want to redirect to that RFC. Alex --------------A9A8EC857190BA644A1D255C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

What is the RFC of v6ops WG that explains that it is possible to use link-local addresses (only LL, no GUA, no ULA) on a interco between routers, yet all other subnets use GUAs, and they do see each other?

This is a fundamental concept used for car-to-car communicaitons (the link outside is LL-only, and all PCs in the cars use ULAs and can see each other).

In a private converrsation I am asked how can this possible, and I want to redirect to that RFC.

Alex

--------------A9A8EC857190BA644A1D255C-- From nobody Fri Jun 28 05:23:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187912007C for ; Fri, 28 Jun 2019 05:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 krfRaZ4uOXRN for ; Fri, 28 Jun 2019 05:22:59 -0700 (PDT) Received: from mail.nytt.no (poseidon.nytt.no [178.62.243.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE5B12009E for ; Fri, 28 Jun 2019 05:22:58 -0700 (PDT) Received: from olen-jobb.nlogic.no (cm-84.208.27.142.getinternet.no [84.208.27.142]) (authenticated bits=0) by mail.nytt.no (8.15.2/8.15.2) with ESMTPSA id x5SCLugR029250 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 28 Jun 2019 14:21:56 +0200 To: v6ops@ietf.org References: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> From: Ola Thoresen Message-ID: <4c916aa6-7292-801e-a185-74de45442f66@nlogic.no> Date: Fri, 28 Jun 2019 14:21:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> Content-Type: multipart/alternative; boundary="------------97D7538FDA83C95E79C902D4" Content-Language: en-US Archived-At: Subject: Re: [v6ops] RFC that explains that interco links with LL only, are possible X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 12:23:01 -0000 This is a multi-part message in MIME format. --------------97D7538FDA83C95E79C902D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 28.06.2019 14:12, Alexandre Petrescu wrote: > > What is the RFC of v6ops WG that explains that it is possible to use > link-local addresses (only LL, no GUA, no ULA) on a interco between > routers, yet all other subnets use GUAs, and they do see each other? > This is how routing protocols like OSPF or IS-IS works. You can start here https://tools.ietf.org/html/rfc5340 in Section 2.1. Rgds. Ola Thoresen --------------97D7538FDA83C95E79C902D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 28.06.2019 14:12, Alexandre Petrescu wrote:

What is the RFC of v6ops WG that explains that it is possible to use link-local addresses (only LL, no GUA, no ULA) on a interco between routers, yet all other subnets use GUAs, and they do see each other?


This is how routing protocols like OSPF or IS-IS works.

You can start here https://tools.ietf.org/html/rfc5340 in Section 2.1.


Rgds.

Ola Thoresen


--------------97D7538FDA83C95E79C902D4-- From nobody Fri Jun 28 05:41:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1297612004A for ; Fri, 28 Jun 2019 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 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_HELO_NONE=0.001, 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 eiqmb6upnZXB for ; Fri, 28 Jun 2019 05:41:07 -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 DA984120073 for ; Fri, 28 Jun 2019 05:41:06 -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 x5SCf5e7007265 for ; Fri, 28 Jun 2019 14:41:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11E63202AD3 for ; Fri, 28 Jun 2019 14:41:05 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 07EF3201D14 for ; Fri, 28 Jun 2019 14:41:05 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5SCf42u022437 for ; Fri, 28 Jun 2019 14:41:04 +0200 To: v6ops@ietf.org References: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> <4c916aa6-7292-801e-a185-74de45442f66@nlogic.no> From: Alexandre Petrescu Message-ID: Date: Fri, 28 Jun 2019 14:41:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <4c916aa6-7292-801e-a185-74de45442f66@nlogic.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] RFC that explains that interco links with LL only, are possible X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 12:41:09 -0000 Thanks for the reference. But there was an RFC independent of the routing protocol. It was deployment guidelines for IPv6, or something like that. Le 28/06/2019 à 14:21, Ola Thoresen a Êcrit : > On 28.06.2019 14:12, Alexandre Petrescu wrote: >> >> What is the RFC of v6ops WG that explains that it is possible to use >> link-local addresses (only LL, no GUA, no ULA) on a interco between >> routers, yet all other subnets use GUAs, and they do see each other? >> > > This is how routing protocols like OSPF or IS-IS works. > > You can start here https://tools.ietf.org/html/rfc5340 in Section 2.1. > > > Rgds. > > Ola Thoresen > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jun 28 06:37:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798B212014A; Fri, 28 Jun 2019 06:37:06 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 DiKYJbp6WBQI; Fri, 28 Jun 2019 06:37:03 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC02F120146; Fri, 28 Jun 2019 06:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x5SDax6C026384; Fri, 28 Jun 2019 09:36:59 -0400 Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x5SDapvA025358 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Jun 2019 09:36:51 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 28 Jun 2019 06:36:50 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Fri, 28 Jun 2019 06:36:50 -0700 From: "Templin (US), Fred L" To: Fred Baker CC: "ianfarrer@gmx.com" , "dhcwg@ietf.org" , v6ops list Thread-Topic: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay Thread-Index: AQHVLbaKIkva3ZqBik6ZCflKosB0cw== Date: Fri, 28 Jun 2019 13:36:50 +0000 Message-ID: <98da70c65eb64f12a4e46be2948f452f@boeing.com> References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> <3ad799f39ebb41e4a4435a7fdfcc41d0@boeing.com> <1353329E-9AD5-49D0-B82B-423719DA148E@gmx.com> <59CA5FD7-6161-4D6D-A810-5D17BCC11893@gmx.com> <9b9924f3ef0a4b2c8d48c86a652d957e@boeing.com> <218CA62E-75FC-462A-A04E-7B3377631F5E@gmail.com> In-Reply-To: <218CA62E-75FC-462A-A04E-7B3377631F5E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 3D57FD75EBB5D390EAB6C5BEBEE35191D1351CFA41F634AF1193F987352DB10D2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 13:37:07 -0000 U29ycnkgaWYgeW91IGRvbid0IGxpa2UgaXQgRnJlZCwgYnV0IHRoYXQgaXMgdGhlIHB1cnBvc2Ug b2YgUkZDNjIyMS4gSWYgeW91IHdhbnQgbW9yZQ0KZGV0YWlscyBvZiB3aGF0IHdlIGFyZSBkb2lu ZyBhbmQgd2h5IGl0IG1ha2VzIHNlbnNlIHRvIHVzIGxldCBtZSBrbm93Lg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEZyZWQgQmFrZXIgW21haWx0bzpmcmVkYmFrZXIu aWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNiwgMjAxOSAxMTozNSBQ TQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ DQo+IENjOiBpYW5mYXJyZXJAZ214LmNvbTsgZGhjd2dAaWV0Zi5vcmc7IHY2b3BzIGxpc3QgPHY2 b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBbZGhjd2ddIE9wZXJhdGlvbmFs IEhlYWRhY2hlOiBESENQIFY2IFJlbGF5DQo+IA0KPiBJIGRvbid0IHNlZSBhIHByb2hpYml0aW9u IG9mIHRoaXMgc29ydCBvZiBkZXNpZ24sIGJ1dCBpdCBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBs ZXguIFRoZSByZWxheSBwcm90b2NvbCBpcyBkZXNpZ25lZCB0byBjb21tdW5pY2F0ZQ0KPiBmcm9t IGEgcmVsYXkgdG8gYW5vdGhlciByZWxheSBvciB0byBhIHNlcnZlci4gQWRkaW5nIGEgcmVsYXkg cHJvY2VzcyBqdXN0IHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHNlcnZlciBwcm9jZXNzIHZpYSBs b2NhbGhvc3Qgc2VlbXMgYW4NCj4gdW5uZWNlc3Nhcnkgc3RlcC4NCj4gDQo+ID4gT24gSnVuIDI2 LCAyMDE5LCBhdCA0OjUzIFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBUaGUgc2VydmVyIGFuZCByZWxheSBydW4gaW4g dGhlIHNhbWUgb3BlcmF0aW5nIHN5c3RlbSBpbnN0YW5jZSwgYnV0IGluIHR3byBzZXBhcmF0ZSBw cm9jZXNzDQo+ID4gY29udGV4dHMg4oCTIGNhbGwgdGhlbSDigJhyZWxheWTigJkgYW5kIOKAmHNl cnZlcmTigJkuDQo+ID4NCj4gPiDigJhyZWxheWTigJkgcmVjZWl2ZXMgYSBjbGllbnQgcHJlZml4 IGRlbGVnYXRpb24gcmVxdWVzdCB0aGVuIHByZXBhcmVzIGEg4oCYUmVsYXktZm9yd2FyZOKAmSBt ZXNzYWdlDQo+ID4gYW5kIHNoaXBzIGl0IHRvIOKAmHNlcnZlcmTigJkgb3ZlciBhIGxvY2FsIGxv b3BiYWNrLiBXaGVuIOKAmHNlcnZlcmTigJkgc2VuZHMgYmFjayB0aGUg4oCYUmVsYXktcmVwbHni gJkNCj4gPiAoYWdhaW4gb3ZlciB0aGUgbG9vcGJhY2spLCDigJhyZWxheWTigJkgaW5qZWN0cyBh IHJvdXRlIGludG8gdGhlIHJvdXRpbmcgc3lzdGVtIGFuZCBzZW5kcyBhDQo+ID4gc3VpdGFibGUg cmVwbHkgdG8gdGhlIGNsaWVudC4NCj4gPg0KPiA+IFRoZSBvbmx5IHJlYXNvbiB3ZSBkbyBpdCB0 aGlzIHdheSBpcyBiZWNhdXNlIHRoZSBjbGllbnQgY2Fubm90IHNwZWFrIGRpcmVjdGx5IHRvIOKA mHNlcnZlcmTigJkNCj4gPiBhbmQgaXQgd291bGQgYmUgZGlmZmljdWx0IHRvIG1lcmdlIOKAmHJl bGF5ZOKAmSBhbmQg4oCYc2VydmVyZOKAmSBpbnRvIGEgc2luZ2xlIHByb2Nlc3MgY29udGV4dC4g QnV0LA0KPiA+IGV2ZXJ5dGhpbmcgZWxzZSBpcyBjb29yZGluYXRlZCB3aXRoaW4gdGhlIHNhbWUg b3BlcmF0aW5nIHN5c3RlbSBpbnN0YW5jZS4NCj4gPg0KPiA+IEZyZWQNCj4gPg0KPiA+IEZyb206 IGlhbmZhcnJlckBnbXguY29tIFttYWlsdG86aWFuZmFycmVyQGdteC5jb21dDQo+ID4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDI2LCAyMDE5IDg6MzkgQU0NCj4gPiBUbzogVGVtcGxpbiAoVVMpLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4gQ2M6IE5hdmVlbiBLb3R0YXBh bGxpIDxuYXZlZW4uc2FybWFAZ21haWwuY29tPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+ OyBkaGN3Z0BpZXRmLm9yZzsgTWFydGluIEh1bmVrDQo+IDxtYXJ0aW4uaHVuZWtAdHVsLmN6Pg0K PiA+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gT3BlcmF0aW9uYWwgSGVhZGFjaGU6IERI Q1AgVjYgUmVsYXkNCj4gPg0KPiA+IEhpIEZyZWQsDQo+ID4NCj4gPiBXaWxsIGRvLg0KPiA+DQo+ ID4gSSBoYXZlbuKAmXQgdHJpZWQgdGhhdCBwYXJ0aWN1bGFyIGRlcGxveW1lbnQgc2NlbmFyaW8u IEkgc3VwcG9zZSB0aGF0IGlmIHRoZSByZWxheSBhbmQgc2VydmVyIHByb2Nlc3NlcyBkaWRu4oCZ dCBzaGFyZSBhbnkgc3RhdGUNCj4gaW5mb3JtYXRpb24gdGhlbiB5b3UgY291bGQgc2VlIHRoZXNl IHByb2JsZW1zLiBJcyB0aGVyZSBhIGNhc2UgZm9yIHJ1bm5pbmcgYm90aCBzZXJ2ZXIgYW5kIHJl bGF5IGZ1bmN0aW9ucyBvbiB0aGUgc2FtZSBib3gsIHJhdGhlcg0KPiB0aGFuIGp1c3QgdGhlIHNl cnZlciAoYXMgYSBkZWxlZ2F0aW5nIHJvdXRlcik/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gSWFu DQo+ID4NCj4gPg0KPiA+IE9uIDI2LiBKdW4gMjAxOSwgYXQgMTc6MjcsIFRlbXBsaW4gKFVTKSwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIElh biDigJMgeWVzLCBhIGNsYXJpZmljYXRpb24gb2Yg4oCcY28tbG9jYXRlZOKAnSB3b3VsZCBiZSBn cmVhdC4gU291bmRzIGxpa2UgdGhlcmUgaXMNCj4gPiBub3QgYSBjb25jZXJuIHdoZW4gdGhlIHJl bGF5IGFuZCBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGJveCBvciBWTSwgcmlnaHQ/DQo+ID4NCj4g PiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPiBGcm9tOiBpYW5mYXJyZXJAZ214LmNvbSBbbWFpbHRv OmlhbmZhcnJlckBnbXguY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNiwgMjAxOSA4 OjIyIEFNDQo+ID4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPg0KPiA+IENjOiBOYXZlZW4gS290dGFwYWxsaSA8bmF2ZWVuLnNhcm1hQGdtYWlsLmNv bT47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgZGhjd2dAaWV0Zi5vcmc7IE1hcnRpbiBI dW5law0KPiA8bWFydGluLmh1bmVrQHR1bC5jej4NCj4gPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBb djZvcHNdIE9wZXJhdGlvbmFsIEhlYWRhY2hlOiBESENQIFY2IFJlbGF5DQo+ID4NCj4gPiBIaSBG cmVkLA0KPiA+DQo+ID4gSW4gdGhpcyBpbnN0YW5jZSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYmVp bmcgaW4gYSBzZXBhcmF0ZSBwaHlzaWNhbCBib3gsIG9yIFZNLiBUaGUgcHJvYmxlbXMgSeKAmXZl IG9ic2VydmVkIGFyZSB3aXRoICBMMyBlZGdlIHJvdXRlcnMNCj4gd2l0aA0KPiA+IHRoZSByZWxh eSBmdW5jdGlvbiBpbiB0aGUgYWNjZXNzIG5ldHdvcmsgd2l0aCBhIGNlbnRyYWxpc2VkIERIQ1B2 NiBzZXJ2ZXIuIFdlIGNhbiBjbGFyaWZ5IHRoaXMgYmV0dGVyIGluIHRoZSBuZXh0IHVwZGF0ZS4N Cj4gPg0KPiA+IFRoYW5rcywNCj4gPiBJYW4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiAyNi4gSnVu IDIwMTksIGF0IDE3OjE0LCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBOYXZlZW4sDQo+ID4NCj4gPiBUaGFua3MgZm9y IHRoZSBkcmFmdCDigJMgYSBxdWljayBxdWVzdGlvbiAtIHdoYXQgaXMgbWVhbnQgYnkg4oCcREhD UHY2IHJlbGF5IGZ1bmN0aW9uIGlzIG5vdCBjby1sb2NhdGVkDQo+ID4gd2l0aCB0aGUgREhDUHY2 IHNlcnZlciBmdW5jdGlvbuKAnS4gRG9lcyBpdCBtZWFuIOKAnGNvLWxvY2F0ZWTigJ0gYXMgaW4g d2l0aGluIHRoZSBzYW1lIHByb2Nlc3MsIHdpdGhpbg0KPiA+IHRoZSBzYW1lIHZpcnR1YWwgbWFj aGluZSwgd2l0aGluIHRoZSBzYW1lIHBoeXNpY2FsIGJveCwgd2l0aGluIHRoZSBzYW1lIExBTiwg ZXRjLj8NCj4gPg0KPiA+IFJGQzYyMjEgYWxsb3dzIGZvciB0aGUgcmVsYXkgZnVuY3Rpb24gdG8g YmUgaW4gYSBzZXBhcmF0ZSBwcm9jZXNzIGZyb20gdGhlIHNlcnZlciBmdW5jdGlvbiBidXQNCj4g PiB3aXRoaW4gdGhlIHNhbWUgb3BlcmF0aW5nIHN5c3RlbSBpbnN0YW5jZS4gU28sIHRoZSB0d28g cHJvY2Vzc2VzIHNoYXJlIHRoZSBzYW1lIGNsb2NrLCBJUA0KPiA+IGZvcndhcmRpbmcgdGFibGUs IHN5c3RlbSBtZW1vcnksIGV0Yy4gSW4gc3VjaCBhbiBhcnJhbmdlbWVudCwgY2FuIGl0IGJlIHNh aWQgdGhhdCB0aGUgREhDUHY2DQo+ID4gcmVsYXkgYW5kIHNlcnZlciBmdW5jdGlvbnMgYXJlIGlu IGZhY3Qg4oCcY28tbG9jYXRlZOKAnSBldmVuIGlmIHRoZXkgZG8gbm90IHJlc2lkZSB3aXRoaW4g dGhlIHNhbWUNCj4gPiBwcm9jZXNzIGNvbnRleHQ/DQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ ID4NCj4gPiBGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBOYXZlZW4gS290dGFwYWxsaQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIw MTkgOToxNCBBTQ0KPiA+IFRvOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IGRoY3dnQGll dGYub3JnDQo+ID4gQ2M6IE1hcnRpbiBIdW5layA8bWFydGluLmh1bmVrQHR1bC5jej4NCj4gPiBT dWJqZWN0OiBSZTogW2RoY3dnXSBbdjZvcHNdIE9wZXJhdGlvbmFsIEhlYWRhY2hlOiBESENQIFY2 IFJlbGF5DQo+ID4NCj4gPiBIZWxsbyBBbGwsDQo+ID4NCj4gPiBBIG5ldyBkcmFmdCBvbiB0aGlz IHN1YmplY3QgaXMgc3VibWl0dGVkIHRvZGF5LiAgUGxlYXNlIGdvIHRocm91Z2ggdGhlIHNhbWUg aW4gYmVsb3cgbGluayBhbmQgbGV0IHVzIGtub3cgeW91ciBmZWVkYmFjay4NCj4gPg0KPiA+IC0t LS0NCj4gPg0KPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ma2hwLWRoYy1kaGNwdjYt cGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTmF2ZWVuIEtvdHRhcGFsbGkgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiBJRVRG IHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOiAgICAgICAgICAgZHJhZnQtZmtocC1kaGMtZGhj cHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPiA+IFJldmlzaW9uOiAgICAgICAwMA0KPiA+IFRp dGxlOiAgICAgICAgICBESENQdjYgUHJlZml4IERlbGVnYXRpbmcgcmVsYXkNCj4gPiBEb2N1bWVu dCBkYXRlOiAgMjAxOS0wNi0yNQ0KPiA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gPiBQYWdlczogICAgICAgICAgMTANCj4gPiBVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1y ZWxheS1yZXF1aXJlbWVudHMtMDAudHh0DQo+ID4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZraHAtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1 aXJlbWVudHMvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ma2hwLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLTAwDQo+ID4gSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt ZmtocC1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPiA+DQo+ID4NCj4gPiBBYnN0 cmFjdDoNCj4gPiAgICBPcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggREhDUHY2IHByZWZpeCBk ZWxlZ2F0aW9uIGhhcyBzaG93biB0aGF0DQo+ID4gICAgd2hlbiB0aGUgREhDUHY2IHJlbGF5IGZ1 bmN0aW9uIGlzIG5vdCBjby1sb2NhdGVkIHdpdGggdGhlIERIQ1B2Ng0KPiA+ICAgIHNlcnZlciBm dW5jdGlvbiwgaXNzdWVzIHN1Y2ggYXMgdGltZXIgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhl DQo+ID4gICAgREhDUCBmdW5jdGlvbmFsIGVsZW1lbnRzLCByZWplY3Rpb24gb2YgY2xpZW50J3Mg bWVzc2FnZXMgYnkgdGhlDQo+ID4gICAgcmVsYXksIGFuZCBvdGhlciBwcm9ibGVtcyBoYXZlIGJl ZW4gb2JzZXJ2ZWQuICBUaGVzZSBwcm9ibGVtcyBjYW4NCj4gPiAgICByZXN1bHQgaW4gcHJlZml4 IGRlbGVnYXRpb24gZmFpbGluZyBvciB0cmFmZmljIHRvL2Zyb20gY2xpZW50cw0KPiA+ICAgIGFk ZHJlc3NlZCBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGJlaW5nIHVucm91dGVhYmxlLiAgQWx0 aG91Z2gNCj4gPiAgICBbUkZDODQxNV0gbWVudGlvbnMgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlv LCBpdCBkb2VzIG5vdCBwcm92aWRlDQo+ID4gICAgbmVjZXNzYXJ5IGRldGFpbCBvbiBob3cgdGhl IHJlbGF5IGVsZW1lbnQgc2hvdWxkIGJlaGF2ZSB3aGVuIHVzZWQNCj4gPiAgICB3aXRoIFBELg0K PiA+DQo+ID4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZnVuY3Rpb25hbCByZXF1aXJlbWVu dHMgZm9yIGEgREhDUHY2IFBEIHJlbGF5DQo+ID4gICAgd2hlbiB1c2VkIGZvciByZWxheWluZyBw cmVmaXhlcyBkZWxlZ2F0ZWQgYnkgYSBzZXBhcmF0ZSBESENQdjYNCj4gPiAgICBzZXJ2ZXIuDQo+ ID4NCj4gPiBZb3VycywNCj4gPiBOYXZlZW4uDQo+ID4NCj4gPg0KPiA+IE9uIE1vbiwgMSBBcHIg MjAxOSBhdCAxODozNCwgPGlhbmZhcnJlckBnbXguY29tPiB3cm90ZToNCj4gPiBIaSBNYXJ0aW4s DQo+ID4NCj4gPiBJIHdvdWxkIGFsc28gYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIHRoaXMg YXMgaXTigJlzIGEgcHJvYmxlbSBmb3IgdXMuIEnigJl2ZSBnb3Qgc29tZXRoaW5nIEkgd3JvdGUg YSB3aGlsZSBiYWNrLiBJ4oCZbGwgc2hhcmUgaXQgYXMgYSBzdGFydGluZw0KPiBwb2ludC4NCj4g Pg0KPiA+IENoZWVycywNCj4gPiBJYW4NCj4gPg0KPiA+ID4gT24gMS4gQXByIDIwMTksIGF0IDEx OjMxLCBNYXJ0aW4gSHVuZWsgPG1hcnRpbi5odW5la0B0dWwuY3o+IHdyb3RlOg0KPiA+ID4NCj4g PiA+IEhpIEZyZWQsDQo+ID4gPg0KPiA+ID4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGFkZHJl c3MgdGhpcyBpc3N1ZSwgYXMgaXQgaXMgdGhlIG9uZSBJJ20gYWxzbyBoYXZpbmcuIEJ1dCBJIHdv dWxkIG5lZWQgc29tZSBhc3Npc3RhbmNlLCBhcyBJIGRvbid0IHJlYWxseSBrbm93DQo+IG15IHdh eXMgYXJvdW5kIElFVEYgcHJvY2Vzc2VzIHlldC4NCj4gPiA+DQo+ID4gPiBNYXJ0aW4NCj4gPiA+ DQo+ID4gPiBEbmUgcMOhdGVrIDI5LiBixZllem5hIDIwMTkgNjozNzoyNSBDRVNULCBGcmVkIEJh a2VyIG5hcHNhbChhKToNCj4gPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9z bGlkZXMtMTA0LXY2b3BzLWRldXRzY2hlLXRlbGVrb20tdGVyYXN0cmVhbS8sIHNsaWRlIDMtNA0K PiA+ID4+DQo+ID4gPj4gV2hhdCBkbyB3ZSB3YW50IHRvIHNheSBhYm91dCBESENQdjYgaXNzdWVz IGluIHZlbmRvciBwcm9kdWN0IGFuZC9vciBzZXJ2aWNlcz8gVGhpcyBoZWFkYWNoZSBkb2Vzbid0 IGhhdmUgYW4gb2J2aW91cyBkcmFmdC4gSQ0KPiB0aGluayB0aGF0IHByb2JhYmx5IGNhbGxzIGZv ciBhIHBlcnNvbiBvciBkZXNpZ24gdGVhbSB0byBjcmVhdGUgc3VjaCBhIGRyYWZ0IGZvciBkaXNj dXNzaW9uIG9uIHRoZSBsaXN0IGFuZCBpbiBNb250cmVhbC4NCj4gPiA+Pg0KPiA+ID4+IEFueSB0 YWtlcnM/DQo+ID4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+PiBUaGUgZmFjdCB0 aGF0IHRoZXJlIGlzIGEgaGlnaHdheSB0byBoZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBp cyBhbiBpbnRlcmVzdGluZyBjb21tZW50IG9uIHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLg0K PiA+ID4+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+ID4gdjZvcHNAaWV0Zi5v cmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4g PiBkaGN3Z0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGhjd2cNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGlnaHdheSB0 byBoZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBjb21tZW50 IG9uIHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLg0KDQo= From nobody Fri Jun 28 06:54:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EF512004A for ; Fri, 28 Jun 2019 06:54:51 -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_HELO_NONE=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 0RWowMJdYIZu for ; Fri, 28 Jun 2019 06:54:49 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1141200B5 for ; Fri, 28 Jun 2019 06:54:48 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id f15so6429568wrp.2 for ; Fri, 28 Jun 2019 06:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=bNbiq0lflAObp/QwRana86ZeymZVNpobNnr9nLT1Tao=; b=lzLxQbZWR3PVCmE5B4CCpMa4qWnUQtr8yNJwMhJe1dfh5jSqsxrMqMO4F13rdDdbbO +1Vjjp6qfA2Hu8ZOPoA107S5xyvzuwMoS4ZkNoeetYB7nupBLzoQo9xGzgswuTuOHxJA HvXG5hjF9bsHRrev7rol3hmFkBVXbs5dccOl+M3itqTnMtcDY7Q8EwJfBpkmbOjqmoMv 0/C4bMEwV4e4pYaN94zMIC8mTswIoltmPYvDS4yZ+TBNL6KOW76zdoGP+v2qKehuUeNW /8z3Lv025usxG/DmBAi24StHpU4Qqq2wi2mrt2alTd64bZzzJF2fZZzeF/vzQzi1AfCE A8Iw== 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:date :subject:message-id:references:in-reply-to:to; bh=bNbiq0lflAObp/QwRana86ZeymZVNpobNnr9nLT1Tao=; b=HhJvUtWmrerqNeQRCP3jhsNXmWrDxkkfhXbolC8YDHahhqn7IRmk684T/th3nzG2T+ FPpb/T8HUKzVXtJtYO17cT68BQAXddtt5pBzKYbg1oXz+nlCrEH73gFlk75GpN8iD0rh ywURjROxfy0QggeW0EpU698xYU4WlrP+aNb9ozQSmGjWOvmy9g6Q7Zj9/qobgF9e2ETg cJnKhqsH+L+E1AevEZJtpaPmbvxpBvbDbrLzbJlA2IRyeA+hEVmzMeUtBdJen0GdaqZM EKdyFrOVszv1blCmEoqWr3X4YrNM+wb75bRB31WVAjHPvKr3KkK9riyYXH5BWr1lgpuE aMYQ== X-Gm-Message-State: APjAAAXYtaziStPiRHeUJLGb9mekgNaYR0FrN1Lr/hmJyB5WJVgNDbmI 2uBjpJBz6GnY98aO+8ML9JeqBJkl+/4= X-Google-Smtp-Source: APXvYqyupdgqstdiqGOLMWWVSLm+RH/sqA1YygirfAz250jSvFZjBQju8OueV9vv0SzUU+blNPrdng== X-Received: by 2002:adf:f951:: with SMTP id q17mr7855259wrr.173.1561730086766; Fri, 28 Jun 2019 06:54:46 -0700 (PDT) Received: from [10.137.140.201] ([104.244.9.242]) by smtp.gmail.com with ESMTPSA id f204sm2986808wme.18.2019.06.28.06.54.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 06:54:45 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-955DD965-E372-447D-9816-3439A1B0779E Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Fri, 28 Jun 2019 14:54:44 +0100 Message-Id: References: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> In-Reply-To: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> To: v6ops@ietf.org X-Mailer: iPad Mail (16G5046d) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 13:54:51 -0000 --Apple-Mail-955DD965-E372-447D-9816-3439A1B0779E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m reading through this draft, and feel some comments are in order o= n the issues marked =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99m writing= as an individual. In the general problem and proposed solutions, I agree that the problem stat= ement makes sense (it is comparable to the problem statement in SIIT-DC), an= d section 4.2 (also comparable to SIIT-DC) seems to present the solution wit= h the least impact on the network and its surrounding devices. A few thoughts: > The information in the EAMT MUST be kept timely-synchronized with the > AAAA records TTL's. In order to achieve that, each EAMT entry MUST > update with each A query, the TTL of the relevant AAAA record. > Update of RFC7757 ? TBD. I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I need t= o understand how this changes 7757 to agree that it updates it. > SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be > updated by this document so the CLAT has a MUST for EAM support. THe fact that you want it for this use case doesn=E2=80=99t mean that it is r= equired by all use cases. I=E2=80=99d want to hear that argument before agre= eing to =E2=80=9CMUST=E2=80=9D. And in any event, what is the argument for 2119 language in an informational= document? This is beginning to sound more like a Proposed Standard... > TBD. Should we recommend having A "null" records for IPv6-only > services in Internet? A web page IPv4-only hosted by IETF(?) showing > "sorry this web page/service is only available from IPv6 enabled > operators"? I=E2=80=99m very concerned about requiring something that is not going to be= DNSSEC-compatible, which it seems such a =E2=80=9Cnull=E2=80=9D record has t= o be. I=E2=80=99m also concerned about something that forces a change to DNS= implementations, as a change to the interpretation of an A resource record s= eems likely to do. An A resource record advertises an IPv4 address that one c= an expect to work under some set of conditions, and a =E2=80=9Cnull=E2=80=9D= record seems to advertise an address whose set of conditions for validity w= ould be null. So this is something I would be concerned to find, and would e= xpect to require dnsop support for before I was willing to accept it. > TBD. Other risks to consider ? If a CE is misconfigured, even a > small percentage of broken CEs may bring the content providers to > switch back to IPv4-only. So possible failure cases need to be > carefully considered for every possible solution approach. >=20 > TBD. Should a way to manually exclude EAMT entries be considered? > May be a manual config in the CPE and by means of operator config. > This is way-out to ensure nothing is broken by surprise and is not > solvable. I=E2=80=99m not an operator. I would expect any operator reading this to say= =E2=80=9Cheavens no, no manual or specific configurations. Make this just f= all out of normal operations.=E2=80=9D=20 Operators, please feel free to agree or disagree, and say why. > This document does not have any new specific security considerations. The question about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a security= consideration. In what way might they be misconfigured, and what would the e= ffect be?= --Apple-Mail-955DD965-E372-447D-9816-3439A1B0779E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m reading through this draft, and= feel some comments are in order on the issues marked =E2=80=9CTBD=E2=80=9D.= In this case, I=E2=80=99m writing as an individual.

In t= he general problem and proposed solutions, I agree that the problem statemen= t makes sense (it is comparable to the problem statement in SIIT-DC), and se= ction 4.2 (also comparable to SIIT-DC) seems to present the solution with th= e least impact on the network and its surrounding devices.

A few thoughts:
  The information in t= he EAMT MUST be kept timely-synchronized with the
  AAAA records TTL's.  In order t= o achieve that, each EAMT entry MUST
  update wit= h each A query, the TTL of the relevant AAAA record.
 =  Update of RFC7757 ? TBD.

<= div>I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I n= eed to understand how this changes 7757 to agree that it updates it.
  SIIT already= has a SHOULD for EAM support.  TBD. 464XLAT may be
  updated by this document so the CLAT has a MUST for=
 EAM support.

THe fact tha=
t you want it for this use case doesn=E2=80=99t mean that it is required by a=
ll use cases. I=E2=80=99d want to hear that argument before agreeing to =E2=80=
=9CMUST=E2=80=9D.

And in any event,=
 what is the argument for 2119 language in an informational document? This i=
s beginning to sound more like a Proposed Standard...
  TBD. &n= bsp;Should we recommend having A "null" records for IPv6-only
  services in Internet?  A web page IPv4-only hosted by IE= TF(?) showing
  "sorry this web page/service is o= nly available from IPv6 enabled
  operators"?

I=E2=80=99m very concerned abo= ut requiring something that is not going to be DNSSEC-compatible, which it s= eems such a =E2=80=9Cnull=E2=80=9D record has to be. I=E2=80=99m also concer= ned about something that forces a change to DNS implementations, as a change= to the interpretation of an A resource record seems likely to do. An A reso= urce record advertises an IPv4 address that one can expect to work under som= e set of conditions, and a =E2=80=9Cnull=E2=80=9D record seems to advertise a= n address whose set of conditions for validity would be null. So this is som= ething I would be concerned to find, and would expect to require dnsop suppo= rt for before I was willing to accept it.

  TBD.  Other risks to consider ? If= a CE is misconfigured, even a
  small percentage= of broken CEs may bring the content providers to
 &nb= sp;switch back to IPv4-only.  So possible failure cases need to be
  carefully considered for every possible solution ap= proach.

  TBD.  Should a wa= y to manually exclude EAMT entries be considered?
 &nb= sp;May be a manual config in the CPE and by means of operator config.=
  This is way-out to ensure nothing is broken by surpri= se and is not
  solvable.

I=E2=80=99m not an operator. I would expect any op= erator reading this to say =E2=80=9Cheavens no, no manual or specific config= urations. Make this just fall out of normal operations.=E2=80=9D 
=

Operators, please feel free to agree or disagree, and sa= y why.

 &nbs= p;This document does not have any new specific security considerations.

The question about =E2=80=9Cbroken C= Es=E2=80=9D seems to point to a security consideration. In what way might th= ey be misconfigured, and what would the effect be?
= --Apple-Mail-955DD965-E372-447D-9816-3439A1B0779E-- From nobody Fri Jun 28 08:10:15 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46557120380 for ; Fri, 28 Jun 2019 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, SPF_HELO_NONE=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=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 tUP9H3mQqRFC for ; Fri, 28 Jun 2019 08:10:10 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1889B1203A0 for ; Fri, 28 Jun 2019 08:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1561734605; x=1562339405; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=IEn7irwGoUb+SMZfy1xFP81ofNH/juVOUG fTt33U5SM=; b=RuiI5Nu/bhMmLwVCqwm6fNPTJdsy8JqxsP/zYPZov2MtC7zgzK XB+lYNKKSFGGCphlf8bgpJOtFyce7zWnDz9knaEBJvPoScvPIuuCYS1SRrm4DR2k w6IxY+be4MVjdaUTpy1ijUks1gZgFvpGHibtbuLNrW61+4bU9zVSaF4Z8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 28 Jun 2019 17:10:05 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 28 Jun 2019 17:10:04 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006309653.msg for ; Fri, 28 Jun 2019 17:10:04 +0200 X-MDRemoteIP: 2001:470:1f09:495:addf:cf46:c341:2b76 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Fri, 28 Jun 2019 17:10:04 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1082f5fe0e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Fri, 28 Jun 2019 17:10:02 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches References: <291EE30B-D299-4EA1-8C8B-53F4BE6A9B07@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3644586602_225166835" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 15:10:14 -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_3644586602_225166835 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fred, =20 Thanks for your inputs. =20 Responses, below, in-line. =20 Regards, Jordi @jordipalet =20 =20 =20 El 28/6/19 15:55, "v6ops en nombre de Fred Baker" escribi=C3=B3: =20 I=E2=80=99m reading through this draft, and feel some comments are in order= on the issues marked =E2=80=9CTBD=E2=80=9D. In this case, I=E2=80=99m writ= ing as an individual. =20 Sometimes I use the TBD, not necessarily because that need to be completed,= but to make sure that I double think on that for the next version. =20 In the general problem and proposed solutions, I agree that the problem sta= tement makes sense (it is comparable to the problem statement in SIIT-DC), = and section 4.2 (also comparable to SIIT-DC) seems to present the solution = with the least impact on the network and its surrounding devices. =20 A few thoughts: The information in the EAMT MUST be kept timely-synchronized with the AAAA records TTL's. In order to achieve that, each EAMT entry MUST update with each A query, the TTL of the relevant AAAA record. Update of RFC7757 ? TBD. =20 I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I need= to understand how this changes 7757 to agree that it updates it. =20 Section 6 of RFC7915 has a SHOULD for EAM. I think this is right, but I see= that RFC6877 (464XLAT), should get it as a MUST. =20 Similarly, my question about RFC7757, is if it is useful that each entry in= the EAMT also needs to have a TTL, or this is exclusive for our optimizati= on case (this ID) ? =20 SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be updated by this document so the CLAT has a MUST for EAM support. =20 THe fact that you want it for this use case doesn=E2=80=99t mean that it is= required by all use cases. I=E2=80=99d want to hear that argument before a= greeing to =E2=80=9CMUST=E2=80=9D. =20 I think it makes sense that 464XLAT is *always* optimized, so that=E2=80=99= s why I think it requires to be updated by this document. =20 And in any event, what is the argument for 2119 language in an informationa= l document? This is beginning to sound more like a Proposed Standard... =20 Actually we have got this request already many times when having the IESG r= eview. I=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D language in the = recent RFC8585, and I was asked to just use the RFC2119 one. =20 However, I also believe that this document, if we agree that 464XLAT must b= e always optimized, then this ID is an opportunity for killing two birds wi= th a stone: 1) Updating RFC6877 to include the optimization always. 2) It doesn=E2=80=99t make senses (we talked already some time ago abo= ut this), that MAP-E/T, DS-Lite and lw4o6 are standards, and 464XLAT which = is the mechanism that have =E2=80=9Cmore=E2=80=9D users in the world (even = compared to all the others together), is just informational. So this ID may= be a proposed standard covering both aspects. =20 TBD. Should we recommend having A "null" records for IPv6-only services in Internet? A web page IPv4-only hosted by IETF(?) showing "sorry this web page/service is only available from IPv6 enabled operators"? =20 I=E2=80=99m very concerned about requiring something that is not going to b= e DNSSEC-compatible, which=20 =20 =E2=80=9Cnull=E2=80=9D maybe not the best wording here, so may not break DN= SSEC. I mean using an IPv4 address that is not actually configured in the s= erver that the has the AAAA. I think it makes sense that this address is a = public one defined by the IETF, which we may use for a special page (or not= use at all, but still a special one). =20 it seems such a =E2=80=9Cnull=E2=80=9D record has to be. I=E2=80=99m also c= oncerned about something that forces a change to DNS implementations, as a = change to the interpretation of an A resource record seems likely to do. An= A resource record advertises an IPv4 address that one can expect to work u= nder some set of conditions, and a =E2=80=9Cnull=E2=80=9D record seems to a= dvertise an address whose set of conditions for=20 =20 Clearly, I confused using the =E2=80=9Cnull=E2=80=9D wording. Is a real add= ress (so no change at all in DNS implementations), but this address is not = actually configured in the interface of the server (because it is IPv6-only= ). =20 validity would be null. So this is something I would be concerned to find, = and would expect to require dnsop support for before I was willing to accep= t it. TBD. Other risks to consider ? If a CE is misconfigured, even a small percentage of broken CEs may bring the content providers to switch back to IPv4-only. So possible failure cases need to be carefully considered for every possible solution approach. TBD. Should a way to manually exclude EAMT entries be considered? May be a manual config in the CPE and by means of operator config. This is way-out to ensure nothing is broken by surprise and is not solvable. =20 I=E2=80=99m not an operator. I would expect any operator reading this to sa= y =E2=80=9Cheavens no, no manual or specific configurations. Make this just= fall out of normal operations.=E2=80=9D=20 =20 I think again is a matter of wording. Many CEs have lots of options that us= ually operators don=E2=80=99t use. But if they need to use they can configu= re them remotely, or because they get from the vendor a default =E2=80=9Cfa= ctory=E2=80=9D config. However, in some cases, those configs are also manag= ed by =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an example, i= s most of the time an expert user). =20 Operators, please feel free to agree or disagree, and say why. This document does not have any new specific security considerations. =20 The question about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a securit= y consideration. In what way might they be misconfigured, and what would th= e effect be? =20 Again, I need to change the wording here. The CE is not actually broken. Th= e complete paragraph =E2=80=9CTBD. Other risks to consider ? =E2=80=A6=E2= =80=9D was more a way to remind muself to work on that. The point is that i= f we have this optimization, we need to make sure to double-check with CDNs= that it doesn=E2=80=99t create a trouble for them, because in those cases = they see the =E2=80=9CCE as broken for IPv6=E2=80=9D and they prefer to dis= able IPv6 for the entire ISP that has the =E2=80=9Cbroken CEs=E2=80=9D. =20 Is that clearer now? =20 I will definitively improve the wording for the next version, so those poin= ts don=E2=80=99t create confusion. =20 =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3644586602_225166835 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Fred,

 

Thanks for your inputs.

&= nbsp;

Responses, below, in-line.

 

Regards,<= /span>

Jor= di

@jordipalet

 

 

 =

El 2= 8/6/19 15:55, "v6ops en nombre de Fred Baker" <v6ops-bounces@ietf.org en nombre de fredbaker.ietf@gmail.com> escri= bi=C3=B3:

 

I=E2=80=99m reading through this draft, and feel some com= ments are in order on the issues marked =E2=80=9CTBD=E2=80=9D. In this case= , I=E2=80=99m writing as an individual.

=  

Sometimes I use the TB= D, not necessarily because that need to be completed, but to make sure that= I double think on that for the next version.

&nbs= p;

In the general problem and proposed solutions, I agree that the proble= m statement makes sense (it is comparable to the problem statement in SIIT-= DC), and section 4.2 (also comparable to SIIT-DC) seems to present the solu= tion with the least impact on the network and its surrounding devices.=

 = ;

A f= ew thoughts:
  The information in the EAMT MUST be kept timely-sync= hronized with the

  AAAA records TTL's.  In order to achieve that, each EAMT= entry MUST
  update with each A query, the TTL of the relevan= t AAAA record.
  Update of RFC7757 ? TBD.

=

&n= bsp;

= I don=E2=80=99t view this as changing 6145/7915=E2=80=99s algorithm. I need= to understand how this changes 7757 to agree that it updates it.

 

S= ection 6 of RFC7915 has a SHOULD for EAM. I think this is right, but I see = that RFC6877 (464XLAT), should get it as a MUST.

 

Similar= ly, my question about RFC7757, is if it is useful that each entry in the EA= MT also needs to have a TTL, or this is exclusive for our optimization case= (this ID) ?

 

  SIIT already has a SHOULD = for EAM support.  TBD. 464XLAT may be

  updated by this document so the CLAT=
 has a MUST for EAM support.
 
THe fact that you want it for this use case doesn=
=E2=80=99t mean that it is required by all use cases. I=E2=80=99d want to h=
ear that argument before agreeing to =E2=80=9CMUST=E2=80=9D.
 
I think it makes sense that 464XLAT is *always* optimize=
d, so that=E2=80=99s why I think it requires to be updated by this document=
.
 
And in any event, what is the ar=
gument for 2119 language in an informational document? This is beginning to=
 sound more like a Proposed Standard...
 
Actually =
we have got this request already many times when having the IESG review. I=
=E2=80=99ve used RFC7084 =E2=80=9Cspecial=E2=80=9D language in the recent R=
FC8585, and I was asked to just use the RFC2119 one.
 
However, I also believe th=
at this document, if we agree that 464XLAT must be always optimized, then t=
his ID is an opportunity for killing two birds with a stone:
1)      Updating RFC6877 to include the optimizatio=
n always.
2) &nbs=
p;    It doesn=E2=80=99t =
make senses (we talked already some time ago about this), that MAP-E/T, DS-=
Lite and lw4o6 are standards, and 464XLAT which is the mechanism that have =
=E2=80=9Cmore=E2=80=9D users in the world (even compared to all the others =
together), is just informational. So this ID may be a proposed standard cov=
ering both aspects.
 
  TBD.  Should we recommend having A "null&qu=
ot; records for IPv6-only
  services in Internet?  A web =
page IPv4-only hosted by IETF(?) showing
  "sorry this we=
b page/service is only available from IPv6 enabled
  operators=
"?
 
I=E2=80=99m very concerned about requiring some=
thing that is not going to be DNSSEC-compatible, which 
 
=E2=80=9Cnull=E2=80=9D maybe not the best wording here, so may not break =
DNSSEC. I mean using an IPv4 address that is not actually configured in the=
 server that the has the AAAA. I think it makes sense that this address is =
a public one defined by the IETF, which we may use for a special page (or n=
ot use at all, but still a special one).
 
it seems such a =E2=80=9Cn=
ull=E2=80=9D record has to be. I=E2=80=99m also concerned about some=
thing that forces a change to DNS implementations, as a change to the inter=
pretation of an A resource record seems likely to do. An A resource record =
advertises an IPv4 address that one can expect to work under some set of co=
nditions, and a =E2=80=9Cnull=E2=80=9D record seems to advertise an address=
 whose set of conditions for 
 
Clearly, I confused using the =
=E2=80=9Cnull=E2=80=9D wording. Is a real address (so no change at all in D=
NS implementations), but this address is not actually configured in the int=
erface of the server (because it is IPv6-only).
 
validity would be null. So this is something I would be con=
cerned to find, and would expect to require dnsop support for before I was =
willing to accept it.


  TBD.  Other risks to consider ? If a CE is misconfigur=
ed, even a
  small percentage of broken CEs may bring the cont=
ent providers to
  switch back to IPv4-only.  So possible=
 failure cases need to be
  carefully considered for every pos=
sible solution approach.

  TBD.  Should a way to manu=
ally exclude EAMT entries be considered?
  May be a manual con=
fig in the CPE and by means of operator config.
  This is way-=
out to ensure nothing is broken by surprise and is not
  solva=
ble.
 
I=E2=80=99m not an operator. I would expect any op=
erator reading this to say =E2=80=9Cheavens no, no manual or specific confi=
gurations. Make this just fall out of normal operations.=E2=80=9D 
 =
;
I think again is a matter of wording. Many CEs have lots of optio=
ns that usually operators don=E2=80=99t use. But if they need to use they c=
an configure them remotely, or because they get from the vendor a default =
=E2=80=9Cfactory=E2=80=9D config. However, in some cases, those configs are=
 also managed by =E2=80=9Cexpert=E2=80=9D users (and today a gamer, just an=
 example, is most of the time an expert user).
<=
div>
 

Operators, please feel free to agree or disagree, and say why.



  This document does= not have any new specific security considerations.

 

The ques= tion about =E2=80=9Cbroken CEs=E2=80=9D seems to point to a security consid= eration. In what way might they be misconfigured, and what would the effect= be?

 

Again, I need to change the wording here. The CE is not a= ctually broken. The complete paragraph =E2=80=9CT= BD.  Other risks to consider ? =E2=80=A6=E2=80=9D was more a way to re= mind muself to work on that. The point is that if we have this optimization= , we need to make sure to double-check with CDNs that it doesn=E2=80=99t cr= eate a trouble for them, because in those cases they see the =E2=80=9CCE as= broken for IPv6=E2=80=9D and they prefer to disable IPv6 for the entire IS= P that has the =E2=80=9Cbroken CEs=E2=80=9D.

 

Is that clearer now?

 

I will definitiv= ely improve the wording for the next version, so those points don=E2=80=99t= create confusion.

 

 

_______________________________________________ v6ops mailing list v6o= ps@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /p>
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3644586602_225166835-- From nobody Fri Jun 28 08:23:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134CF1202CA for ; Fri, 28 Jun 2019 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=HZNhp2KF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vAqzQFO1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIYkJ6_1oIAS for ; Fri, 28 Jun 2019 08:23:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0C3120256 for ; Fri, 28 Jun 2019 08:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5955; q=dns/txt; s=iport; t=1561735410; x=1562945010; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sMWySc39pwJSnBz/55f/oWOSFvzl0ehFPMh0WERs/Fk=; b=HZNhp2KFaWgigEhw1jOvzb48kjoLxuPvR9oimyJc7f2Otv8sNFlOyia5 XmNtDy+9hdENJephwDkXSbiUylE0P3+lnfFbcODaH7T4N0GKiAPHKU9XJ I6wkWtkKX971U9Or8L/2EnwphP+2L6Y+VLwkNu+Z1aixqH7lw5u1+TZuQ w=; IronPort-PHdr: =?us-ascii?q?9a23=3ANvr8+hY8FE4c2zgZfYEiPl3/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavncT08F8dPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAACoMBZd/4MNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRQvUANqVSAECyiEHINHA4RSiguCNiWJS4klhFSBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBLQIBAYRAAheCaSM0CQ4BAwEBBAEBAgEFbYo3DIVKAQEBBBIRHQE?= =?us-ascii?q?BOA8CAQgRAwECKwICAh8RHQgCBAESIoMAAYEdTQMdAQKcLgKBOIhgcYEygnk?= =?us-ascii?q?BAQWCR4JIDQuCEQmBNAGLXheBQD+BOAwTgkw+ghqCSoJqMoImjmCEfJYUQAk?= =?us-ascii?q?CghaQCINxG5djjS2JKY14AgQCBAUCDgEBBYFQOIFYcBVlAYJBgkGDcYpTcoE?= =?us-ascii?q?pjx4BAQ?= X-IronPort-AV: E=Sophos;i="5.63,428,1557187200"; d="scan'208,217";a="295930534" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2019 15:23:29 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x5SFNTXh011026 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2019 15:23:29 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 10:23:28 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 11:23:27 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 28 Jun 2019 10:23:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=iI5ly03ndZ8Qxu27gmOLQ0rXiy6UPEx+h4TjbkiRlBRvb3ofapTLko087uLCEVIejDJ+X7K3zt2Tdp/l9dJdaJbWJYB5WDrdxKp9hqr5h60H+0O8Cz7nz0y7F2CArTXzzKSkhqkR9O6NaqMnu0TXqM0Nfu927qfgPRt1kFZUJ1I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sMWySc39pwJSnBz/55f/oWOSFvzl0ehFPMh0WERs/Fk=; b=rtIqwoWbCooJQdJJB1XH3EejY9ap21hPW/ErvOs+2OMH8OQ/vZweYa1WaJ7KGEyEJg/7UgVgQudb5TyeeDffkvB9sxDtx8I8jbluoUhzJ2j58tJKUBGv+F7VnB3OgXDjMwgZA0pAYVnT5e7tr/Mz+/viFygCmeGNX608ndP48Fw= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sMWySc39pwJSnBz/55f/oWOSFvzl0ehFPMh0WERs/Fk=; b=vAqzQFO1isIjgWSPxp5c9knvzXCV7jsO67Ag6+ZGM6cFhG7vONj8y71rg83bATxENh3j+AjhWps+TnMgK5fJQ8OhGW2k23l3EEcbacowg/HQdqzpSaCm+jR0TSFjGwZPvO55D78BQ2p7QN7Hzf8X2LTHHec5OR+4BPEcgX+mbhc= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3917.namprd11.prod.outlook.com (10.255.180.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 15:23:26 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2008.019; Fri, 28 Jun 2019 15:23:26 +0000 From: "Eric Vyncke (evyncke)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] RFC that explains that interco links with LL only, are possible Thread-Index: AQHVLarnPhTwiO5+/0+qwWYSu4eFf6axUQyA Date: Fri, 28 Jun 2019 15:23:26 +0000 Message-ID: References: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> In-Reply-To: <63917e52-db92-a9d6-d7c7-0fa3d73dde27@gmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c0:1001::28e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 324349a0-58e0-464e-af9e-08d6fbdc9117 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3917; x-ms-traffictypediagnostic: MN2PR11MB3917: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(189003)(199004)(186003)(7736002)(46003)(73956011)(6486002)(66476007)(66446008)(316002)(110136005)(66556008)(8676002)(64756008)(6512007)(6306002)(81156014)(86362001)(58126008)(4744005)(71200400001)(81166006)(8936002)(33656002)(99286004)(229853002)(76116006)(54896002)(6116002)(6506007)(68736007)(5660300002)(53546011)(91956017)(478600001)(2616005)(476003)(71190400001)(14454004)(102836004)(256004)(6436002)(2501003)(66946007)(2906002)(53936002)(25786009)(446003)(6246003)(11346002)(36756003)(76176011)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3917; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jnDfGmGOydIK3JUEuLVtdVAdPAEuGx3oYzHMMvVUJI6D02U3cKtjinrygqg2h+L0VVEaJc/O9gRCFpNlux9gBwhQU/fBZxX1+4cm5hSZu+YHoY0b/zeNnOclM7TvQeXmb+STYmoqqLdOayqb3YP8v3fDj6nYWu9Zw1i+N6VrpwClnSseiCsCZjyhAzD3Jk2WK3Ra6PaeayzHtEkte10RpGU0L53q/ZBNsINbezdM7+FamiVInnxlUYCuyEFLryJ//3sirieEXRi2Fj5TTh9pYns9/q89Lm2Zh3/3XOjE/fjMQBH/UoPPu41I0Jxqbsj3pOCPFE7CYMiMPcew9/XPqSZUG1GtrL+aQRlGdHu/r7BHfsPTTGmqGBpfmKRAsFJfplNNvJhmO6sjEQMyzTE7bfvnuE9hiVNRNURveOdEjOI= Content-Type: multipart/alternative; boundary="_000_C747546C085341D9AD122DC1BBEFCB36ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 324349a0-58e0-464e-af9e-08d6fbdc9117 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 15:23:26.4249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3917 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [v6ops] RFC that explains that interco links with LL only, are possible X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 15:23:33 -0000 --_000_C747546C085341D9AD122DC1BBEFCB36ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 77u/UkZDIDc0MDQgOy0pDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwu Y29tPg0KRGF0ZTogRnJpZGF5LCAyOCBKdW5lIDIwMTkgYXQgMTQ6MTMNClRvOiAidjZvcHNAaWV0 Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFt2Nm9wc10gUkZDIHRoYXQgZXhwbGFp bnMgdGhhdCBpbnRlcmNvIGxpbmtzIHdpdGggTEwgb25seSwgYXJlIHBvc3NpYmxlDQoNCg0KV2hh dCBpcyB0aGUgUkZDIG9mIHY2b3BzIFdHIHRoYXQgZXhwbGFpbnMgdGhhdCBpdCBpcyBwb3NzaWJs ZSB0byB1c2UgbGluay1sb2NhbCBhZGRyZXNzZXMgKG9ubHkgTEwsIG5vIEdVQSwgbm8gVUxBKSBv biBhIGludGVyY28gYmV0d2VlbiByb3V0ZXJzLCB5ZXQgYWxsIG90aGVyIHN1Ym5ldHMgdXNlIEdV QXMsIGFuZCB0aGV5IGRvIHNlZSBlYWNoIG90aGVyPw0KDQpUaGlzIGlzIGEgZnVuZGFtZW50YWwg Y29uY2VwdCB1c2VkIGZvciBjYXItdG8tY2FyIGNvbW11bmljYWl0b25zICh0aGUgbGluayBvdXRz aWRlIGlzIExMLW9ubHksIGFuZCBhbGwgUENzIGluIHRoZSBjYXJzIHVzZSBVTEFzIGFuZCBjYW4g c2VlIGVhY2ggb3RoZXIpLg0KDQpJbiBhIHByaXZhdGUgY29udmVycnNhdGlvbiBJIGFtIGFza2Vk IGhvdyBjYW4gdGhpcyBwb3NzaWJsZSwgYW5kIEkgd2FudCB0byByZWRpcmVjdCB0byB0aGF0IFJG Qy4NCg0KQWxleA0K --_000_C747546C085341D9AD122DC1BBEFCB36ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJFbWFpbFN0eWxlMTkiPu+7v1JG QyA3NDA0IDstKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj52Nm9wcyAmbHQ7djZvcHMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEFsZXhhbmRyZSBQZXRyZXNjdSAmbHQ7YWxleGFuZHJl LnBldHJlc2N1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCAyOCBKdW5l IDIwMTkgYXQgMTQ6MTM8YnI+DQo8Yj5UbzogPC9iPiZxdW90O3Y2b3BzQGlldGYub3JnJnF1b3Q7 ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3Y2b3BzXSBSRkMg dGhhdCBleHBsYWlucyB0aGF0IGludGVyY28gbGlua3Mgd2l0aCBMTCBvbmx5LCBhcmUgcG9zc2li bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoYXQgaXMgdGhl IFJGQyBvZiB2Nm9wcyBXRyB0aGF0IGV4cGxhaW5zIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gdXNl IGxpbmstbG9jYWwgYWRkcmVzc2VzIChvbmx5IExMLCBubyBHVUEsIG5vIFVMQSkgb24gYSBpbnRl cmNvIGJldHdlZW4gcm91dGVycywgeWV0IGFsbCBvdGhlciBzdWJuZXRzIHVzZQ0KIEdVQXMsIGFu ZCB0aGV5IGRvIHNlZSBlYWNoIG90aGVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIGlzIGEgZnVuZGFtZW50YWwgY29u Y2VwdCB1c2VkIGZvciBjYXItdG8tY2FyIGNvbW11bmljYWl0b25zICh0aGUgbGluayBvdXRzaWRl IGlzIExMLW9ubHksIGFuZCBhbGwgUENzIGluIHRoZSBjYXJzIHVzZSBVTEFzIGFuZCBjYW4gc2Vl IGVhY2ggb3RoZXIpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbiBhIHByaXZhdGUgY29udmVycnNhdGlvbiBJIGFtIGFza2Vk IGhvdyBjYW4gdGhpcyBwb3NzaWJsZSwgYW5kIEkgd2FudCB0byByZWRpcmVjdCB0byB0aGF0IFJG Qy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+QWxleDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_C747546C085341D9AD122DC1BBEFCB36ciscocom_-- From nobody Fri Jun 28 09:32:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96222120250; Fri, 28 Jun 2019 09:32:33 -0700 (PDT) X-Quarantine-ID: <0KYJszyHnLgQ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KYJszyHnLgQ; Fri, 28 Jun 2019 09:32:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76041202E8; Fri, 28 Jun 2019 09:32:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hgtnL-0000JLC; Fri, 28 Jun 2019 18:32:15 +0200 Message-Id: To: v6ops@ietf.org Cc: Michael Richardson Cc: 6man <6man@ietf.org> From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> <4615.1561671634@localhost> In-reply-to: Your message of "Thu, 27 Jun 2019 17:40:34 -0400 ." <4615.1561671634@localhost> Date: Fri, 28 Jun 2019 18:32:14 +0200 Archived-At: Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 16:32:34 -0000 >Hairpin'ing all traffic through the advertising router when L=0 seems like >the only general solution. But, I can imagine many situations where if a >Neighbour Cache entry somehow existed, then it could be used. Note that the router may send redirects. So in theory it is only the first packet to a neighbor that needs to go through the router. From nobody Fri Jun 28 15:58:20 2019 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 43B7A12030B; Fri, 28 Jun 2019 15:57:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: v6ops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176266927.11015.2471421694134379549.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:49 -0700 Archived-At: Subject: [v6ops] v6ops - Requested session has been scheduled for IETF 105 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:57:49 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00 requested) Monday, 22 July 2019, Afternoon Session II 1550-1750 Room Name: Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/v6ops.ics Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: 6man intarea tsvwg suit rtgwg opsec grow People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 28 17:50:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9F5120968; Fri, 28 Jun 2019 17:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.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.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Rpg_f7R6mKyl; Fri, 28 Jun 2019 17:49:50 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECAC3120965; Fri, 28 Jun 2019 17:49:49 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id b7so7759516otl.11; Fri, 28 Jun 2019 17:49:49 -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=Ygf+DGXY5UyfxJcw/nm1giwugrrxPmy+LvqW+J8cHB4=; b=PXsfNHGrRufCbGBrDCPDtPDNDtCXKh7JfbfxtBnrCRwrRlq7XHgAVMOVL27sQGiUUZ 4Ho3/ZyDumdLf84Ys8Xvm6Rd1NuSQctiS+GH6lrGgnOKmpM3rLjadciEc83radIK90Mt TvmY+8D8b8N5lgO35XjR3MKxZnFFn6iA4M6kTqOrGTZF/beLJ3NoCdZ+xwL0Ek4B4hUB ePoQg0RmwSgVRXBSKvTK6jYdMde8/D4glL8hPbl/FhRG5tJ9GDzsF5wziMmF4xMn2gnB qAKHKEoTj8LcSKZSo4BzewuSGGCwaViPaQrIsCkbJrGXcu7bGnCw5NG8h7Gj+TGDm2df k/Qw== 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=Ygf+DGXY5UyfxJcw/nm1giwugrrxPmy+LvqW+J8cHB4=; b=nID0/AJ8qp549iygQTVH8MXys6YPYHBWZXeNqM7pcbx3RqcgP44M/l4txSeU0HbL6u TB9Ryk9ckwhJpPDN3CUzSPBWYqgGp860fQkeUKQoC8aCsCLmi6CVg8cIvNvATVDScUKl fRu2NdO1Kv6fvQfhzpSwn9ek5fLCdpU1BEtPSVJXBfm4ZvkeGRs2EuhoZ2wZx/j0pTnE Sk1LCuT22lNZTK9l3/6ivvlEYw2g7OdBI6T2b55NwNi6Mvk1CDDO5b+c/8lSUeAK3oqt XOBLMteeUYLI22KQ7Fnmn7ucf2Fs1Wh9kB/p6gBKooBxbGzTLgWMoZuvkHoSjoueAqEH DwaA== X-Gm-Message-State: APjAAAVqwchDvMQVi8kKeEThl5ox2nZ8ByNBd5tmY49JMYcWWBWpzyW3 OzrQgSxaFkmSiWRJacGGhHNO/QNvECSxKt+KpQkZ8w== X-Google-Smtp-Source: APXvYqwUu9lDfT56YyLX0n2z3Umt3Zz3G2heRW3CDNvXv2RFLTAakcOF+jwwFaibUovAbJnsiQQX4u+uIvhgLLyCt8Q= X-Received: by 2002:a9d:65da:: with SMTP id z26mr10007976oth.257.1561769389236; Fri, 28 Jun 2019 17:49:49 -0700 (PDT) MIME-Version: 1.0 References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> <4615.1561671634@localhost> In-Reply-To: From: Mark Smith Date: Sat, 29 Jun 2019 10:49:37 +1000 Message-ID: To: Philip Homburg Cc: v6ops list , Michael Richardson , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000aaa5d8058c6bc56c" Archived-At: Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 00:49:52 -0000 --000000000000aaa5d8058c6bc56c Content-Type: text/plain; charset="UTF-8" On Sat., 29 Jun. 2019, 02:32 Philip Homburg, wrote: > >Hairpin'ing all traffic through the advertising router when L=0 seems like > >the only general solution. But, I can imagine many situations where if a > >Neighbour Cache entry somehow existed, then it could be used. > > Note that the router may send redirects. So in theory it is only the > first packet to a neighbor that needs to go through the router. > You'd have to switch them off in this case,. That has also been a common thing to do in IPv4 in general. I can't exactly remember why, because it is so long ago that I learned to do it, however I expect it is to stop packets being punted to the control plane for redirect generation. Non-optimal forwarding or dropping, in particular in forwarding hardware, is cheaper than optimal forwarding and control plane load of generating redirects. It also probably creates a control plane DoS attack vector. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000aaa5d8058c6bc56c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sat., 29 Jun. 2019, 02:32 Philip Homburg, <pch-v6ops-9@u-1.phicoh.com>= wrote:
>Hairpin'ing all tra= ffic through the advertising router when L=3D0 seems like
>the only general solution.=C2=A0 But, I can imagine many situations whe= re if a
>Neighbour Cache entry somehow existed, then it could be used.

Note that the router may send redirects. So in theory it is only the
first packet to a neighbor that needs to go through the router.


You'd have to switch them off in this case,.

That has also been a common thing = to do in IPv4 in general. I can't exactly remember why, because it is s= o long ago that I learned to do it, however I expect it is to stop packets = being punted to the control plane for redirect generation. Non-optimal forw= arding or dropping, in particular in forwarding hardware, is cheaper than o= ptimal forwarding and control plane load of generating redirects. It also p= robably creates a control plane DoS attack vector.



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
--------------------------------------------------------------------
--000000000000aaa5d8058c6bc56c-- From nobody Fri Jun 28 22:05:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557921202DD; Fri, 28 Jun 2019 22:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=TASe9xkS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wQU+fYVv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg8fzoS_1jVH; Fri, 28 Jun 2019 22:05:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBBE1202DA; Fri, 28 Jun 2019 22:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10091; q=dns/txt; s=iport; t=1561784700; x=1562994300; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2m9qHUlhjV7MgKKzK0a4nxax5az2OgTQJqyE6FXQPck=; b=TASe9xkS+GlqoM0525HyUDwUsNKSFZSmGjXyoSEFJdChx5fToKflZiP5 ngaAfc8BDe2pMYO4/qEMGOl8vncgLG/SW8AUnk1HdheDdlNKWP1gsdy5N 3GHBZEdhR5UdCtxjS62q8TU3qyG4aZ7+r2Lbj4b+rHj+tSti8nQu2COec Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A1RgFEhLiqI7fsGj7ANmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAABt8BZd/5tdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUNQA2pVIAQLKAqEE4NHA4RSiguCNiWJS4klhFSBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBGAEKCgIBAYRAAheCaSM0CQ4BAwEBBAEBAgEFbYo3DIVLAQEEAQE?= =?us-ascii?q?QER0BASwLAQ8CAQgYJwMCAgIfBgsUEQEBBA4FGweDAAGBHU0DHQECAQubEAK?= =?us-ascii?q?BOIhgcYEygnkBAQWFEQ0LghEDBoE0AYRxhCSCSReBQD+BEScME4JMPoEEgRZ?= =?us-ascii?q?HAQGCDoJdgliMEoJPhHyWFUAJAoIWkAiDchuCK4cajh6EEJJJjXgCBAIEBQI?= =?us-ascii?q?OAQEFgVA4gVhwFTsqAYJBgkEYg1mFFIU/coEpjWABgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,430,1557187200"; d="scan'208,217";a="572650737" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2019 05:04:58 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x5T54wHp004354 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 29 Jun 2019 05:04:58 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 29 Jun 2019 00:04:58 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 29 Jun 2019 01:04:50 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 29 Jun 2019 00:04:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=DgMgN4K5mlwXm/jk7zalhxMaJlwHLy/CIq63GO/zAUdFmlAJyPE31t4c6PoPVYQoM4+WaLY/UfVol/9gmD3vpfS4798+UWPsR3sVSTXqra7iiggv7oEkjLSNnP0Yn0gwt+bOwOkEvLt4EAUMDOZguMP3/FcKDGLKKn+7+zkPXAk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2m9qHUlhjV7MgKKzK0a4nxax5az2OgTQJqyE6FXQPck=; b=QQHcgn7fqQ4Wiq37hjvWlpqlt4wJNGRaHX/9c0mqhvkEyYV9YH4A+t+iWFN+sgPSdYulCyJZCX9IuGUdm3gwfwQxLEBX14/SKf6R8pvwbvUN7PEpWUHKTmsSDZORstSX7qrIEpHdtPt2Ny4oDzK0lRUJar//tx9YeI/qdDYySjk= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2m9qHUlhjV7MgKKzK0a4nxax5az2OgTQJqyE6FXQPck=; b=wQU+fYVv1qqh2zAHFIv48eNOTwDmdn2+M0fdOsTONjfBq9sV3OK32DgF0SYxL2MhQf3mmegTeQpZVXG/p5fqT0n5uBbqfJBErqiMb7DaMSzBdjmtUEu4sHYeUXEHtJ5huDj4KZ1uY86wZ3EUCC1sgSNQ1UOvMqeySkNFB+7ci5M= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3584.namprd11.prod.outlook.com (20.178.251.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Sat, 29 Jun 2019 05:04:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.018; Sat, 29 Jun 2019 05:04:48 +0000 From: "Pascal Thubert (pthubert)" To: Mark Smith CC: Philip Homburg , Michael Richardson , v6ops list , 6man <6man@ietf.org> Thread-Topic: [v6ops] RFC4861 question - short prefixes in PIOs Thread-Index: AdUsMmrDTybnqCimSw+vUa2pQYzWEwA/oh8AACeRagUAEVNtgAAI6X7x Date: Sat, 29 Jun 2019 05:04:48 +0000 Message-ID: <6CDE2EF9-9106-45E6-BB87-209345898FBB@cisco.com> References: <729f46ec4a8b419797e15bbdcac3e549@boeing.com> <4615.1561671634@localhost> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f967ab36-5eaa-40a9-2509-08d6fc4f4f9d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3584; x-ms-traffictypediagnostic: MN2PR11MB3584: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0083A7F08A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(346002)(136003)(396003)(54014002)(189003)(199004)(54896002)(236005)(6306002)(7736002)(6512007)(6116002)(256004)(54906003)(6436002)(86362001)(966005)(3846002)(186003)(229853002)(8936002)(6486002)(68736007)(4326008)(14454004)(6916009)(14444005)(25786009)(486006)(2906002)(33656002)(66066001)(91956017)(446003)(11346002)(53936002)(476003)(81156014)(81166006)(6246003)(478600001)(2616005)(1411001)(66476007)(64756008)(36756003)(66556008)(76176011)(316002)(66446008)(66946007)(6506007)(606006)(73956011)(71190400001)(71200400001)(99286004)(26005)(8676002)(5660300002)(76116006)(66574012)(102836004)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3584; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jRAm/c2vtiZ4/LrMu0gsjSVHVtZun4U5/o86qKA2div1/LCnsPTU1YsAPEY1ievV/wtEjBwNwt8MPFRg9qzXXFT8t+DvWIcYKw5NqcLHmkdFYVK++L5iGbo4Y6wabdGJM0kIfO3/qjlmBOfQjhRIB8A9RZhjbEJLp2Ucd0fLkbmr/LJWdlMK8RVc59RsO3XD2YEuELbBsz1rVTArE0OnneUiMkMv8uVVOOhRe3pkQfXs46j/W2ziyrahUdvdzjWD0Em92nHCmfV+lrGvx+dgFyNCvjroCcXNp8oMTQiGtPxArG+l0Tyg5snRZ7Cyb5As0xgYS0ATYhfE7/CuHIMHNHda0kdvRASvrZ9ONCsEOm0dQ3mAkFSrLYx0yIsNbp0ETJskQUlAdrzzJZPcJesJ5P0xgFcv6ip1sLM7ibtA1zU= Content-Type: multipart/alternative; boundary="_000_6CDE2EF9910645E6BB87209345898FBBciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f967ab36-5eaa-40a9-2509-08d6fc4f4f9d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2019 05:04:48.4670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3584 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [v6ops] RFC4861 question - short prefixes in PIOs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 05:05:03 -0000 --_000_6CDE2EF9910645E6BB87209345898FBBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFyaw0KDQpQbGVhc2Uga2VlcCBpbiBtaW5kIHRoZSB1c2UgY2FzZSBpcyB3aXJlbGVz cyAoODAyLjExT0NCKSBhbmQgdGhlIHJvdXRlciBpcyBhIEwzIEFQLiBUbyB5b3VyIHBvaW50Og0K DQpPbiAuMTEgdGhlIG9ubHkgZGlyZWN0IGNvbm5lY3Rpdml0eSB0aGF0IGlzIGtub3duIGlzIFNU QSB0byBBUC4gQSBTVEEgbWF5IG9yIG1heSBub3QgYmUgcmVhY2hhYmxlIGZyb20gYW5vdGhlciBT VEEgYXQgdGhlIFBIWSBsYXllciBkZXBlbmRpbmcgb24gdGhlaXIgcmVsYXRpdmUgbG9jYXRpb24u IEluIHVzdWFsIC4xMSB0aGV5IHdpbGwgbm90IGhhdmUgdW5pY2FzdCBrZXlzIHRvIHRhbGsgdG8g b25lIGFub3RoZXIgYW55d2F5LiBUaGUgTDMgQVAgTVVTVCBOT1QgdXNlIHJlZGlyZWN0cy4NCg0K T24gT0NCIGluIHBhcnRpY3VsYXIgdGhlcmUgaXMgbmVpdGhlciBMMiBhc3NvY2lhdGlvbiBub3Ig TDIgc2VjdXJpdHkuIFRoZSBvbmx5IHdheSBmb3IgYSBMMyBBUCB0byBrbm93IHdob+KAmXMgdGhl cmUgaXMgdGhlIEwzIGFzc29jaWF0aW9uIChha2EgcmVnaXN0cmF0aW9uLCBSRkMgODUwNSkuDQoN CkEgZml4ZWQgTDMgQVAgKGFuIFJTVSBpbiBPQ0IpIG1heSBwcm92aWRlIEwzIGNvbm5lY3Rpdml0 eSB0byB2ZWhpY2xlcy4NCg0KSWYgdGhlIHZlaGljbGUgbW92ZXMgdGhlbiBpdCBuZWVkcyBoZXVy aXN0aWNzIHRvIGZpZ3VyZSB0aGUgYmVzdCByb3V0ZXIgZS5nLiwgdGhlIG1vc3QgcmVjZW50bHkg c2Vlbi4gV2hlbiBJIGltcGxlbWVudGVkIE1vYmlsZSBJUCBhbmQgTkVNTyBpbiBvdXIgcm91dGVy cyBzb21lIDE1IHllYXJzIGFnbyBJIGhhZCB0byBwbGFjZSBhIG51bWJlciBvZiBub24tc3RhbmRh cmQgaGV1cmlzdGljcyBpbiBORCB0byBtYWtlIHRoYXQgd29yay4gT25lIG9mIHRoZW0gd2FzIHRv IHVzZSB0aGUgcm91dGVyIHRoYXQgZXhwb3NlcyBhIFBJTyBhcyBHVyBmb3IgcGFja2V0cyB0aGF0 IGFyZSBzb3VyY2VkIG9uIHRoZSBwcmVmaXggaW4gdGhlIFBJTy4NCg0KSSBzdGFydGVkIGFuIElQ djYgb3ZlciB3aXJlbGVzcyBkcmFmdC4gVGhlcmXigJlzIGEgbG90IHRoYXQgbmVlZHMgc2F5aW5n IGluIHRoZXJlLg0KDQpBbGwgdGhlIGJlc3QsDQoNClBhc2NhbA0KDQpMZSAyOSBqdWluIDIwMTkg w6AgMDI6NTAsIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb208bWFpbHRvOm1hcmt6 enpzbWl0aEBnbWFpbC5jb20+PiBhIMOpY3JpdCA6DQoNCg0KDQpPbiBTYXQuLCAyOSBKdW4uIDIw MTksIDAyOjMyIFBoaWxpcCBIb21idXJnLCA8cGNoLXY2b3BzLTlAdS0xLnBoaWNvaC5jb208bWFp bHRvOnBjaC12Nm9wcy05QHUtMS5waGljb2guY29tPj4gd3JvdGU6DQo+SGFpcnBpbidpbmcgYWxs IHRyYWZmaWMgdGhyb3VnaCB0aGUgYWR2ZXJ0aXNpbmcgcm91dGVyIHdoZW4gTD0wIHNlZW1zIGxp a2UNCj50aGUgb25seSBnZW5lcmFsIHNvbHV0aW9uLiAgQnV0LCBJIGNhbiBpbWFnaW5lIG1hbnkg c2l0dWF0aW9ucyB3aGVyZSBpZiBhDQo+TmVpZ2hib3VyIENhY2hlIGVudHJ5IHNvbWVob3cgZXhp c3RlZCwgdGhlbiBpdCBjb3VsZCBiZSB1c2VkLg0KDQpOb3RlIHRoYXQgdGhlIHJvdXRlciBtYXkg c2VuZCByZWRpcmVjdHMuIFNvIGluIHRoZW9yeSBpdCBpcyBvbmx5IHRoZQ0KZmlyc3QgcGFja2V0 IHRvIGEgbmVpZ2hib3IgdGhhdCBuZWVkcyB0byBnbyB0aHJvdWdoIHRoZSByb3V0ZXIuDQoNCg0K WW91J2QgaGF2ZSB0byBzd2l0Y2ggdGhlbSBvZmYgaW4gdGhpcyBjYXNlLC4NCg0KVGhhdCBoYXMg YWxzbyBiZWVuIGEgY29tbW9uIHRoaW5nIHRvIGRvIGluIElQdjQgaW4gZ2VuZXJhbC4gSSBjYW4n dCBleGFjdGx5IHJlbWVtYmVyIHdoeSwgYmVjYXVzZSBpdCBpcyBzbyBsb25nIGFnbyB0aGF0IEkg bGVhcm5lZCB0byBkbyBpdCwgaG93ZXZlciBJIGV4cGVjdCBpdCBpcyB0byBzdG9wIHBhY2tldHMg YmVpbmcgcHVudGVkIHRvIHRoZSBjb250cm9sIHBsYW5lIGZvciByZWRpcmVjdCBnZW5lcmF0aW9u LiBOb24tb3B0aW1hbCBmb3J3YXJkaW5nIG9yIGRyb3BwaW5nLCBpbiBwYXJ0aWN1bGFyIGluIGZv cndhcmRpbmcgaGFyZHdhcmUsIGlzIGNoZWFwZXIgdGhhbiBvcHRpbWFsIGZvcndhcmRpbmcgYW5k IGNvbnRyb2wgcGxhbmUgbG9hZCBvZiBnZW5lcmF0aW5nIHJlZGlyZWN0cy4gSXQgYWxzbyBwcm9i YWJseSBjcmVhdGVzIGEgY29udHJvbCBwbGFuZSBEb1MgYXR0YWNrIHZlY3Rvci4NCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRm Lm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_6CDE2EF9910645E6BB87209345898FBBciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBNYXJrDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2Uga2VlcCBpbiBtaW5kIHRo ZSB1c2UgY2FzZSBpcyB3aXJlbGVzcyAoODAyLjExT0NCKSBhbmQgdGhlIHJvdXRlciBpcyBhIEwz IEFQLiBUbyB5b3VyIHBvaW50OjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gLjEx IHRoZSBvbmx5IGRpcmVjdCBjb25uZWN0aXZpdHkgdGhhdCBpcyBrbm93biBpcyBTVEEgdG8gQVAu IEEgU1RBIG1heSBvciBtYXkgbm90IGJlIHJlYWNoYWJsZSBmcm9tIGFub3RoZXIgU1RBIGF0IHRo ZSBQSFkgbGF5ZXIgZGVwZW5kaW5nIG9uIHRoZWlyIHJlbGF0aXZlIGxvY2F0aW9uLiBJbiB1c3Vh bCAuMTEgdGhleSB3aWxsIG5vdCBoYXZlIHVuaWNhc3Qga2V5cyB0byB0YWxrIHRvIG9uZSBhbm90 aGVyIGFueXdheS4gVGhlIEwzDQogQVAgTVVTVCBOT1QgdXNlIHJlZGlyZWN0cy4mbmJzcDs8L2Rp dj4NCjxkaXY+PGJyPg0KT24gT0NCIGluIHBhcnRpY3VsYXIgdGhlcmUgaXMgbmVpdGhlciBMMiBh c3NvY2lhdGlvbiBub3IgTDIgc2VjdXJpdHkuIFRoZSBvbmx5IHdheSBmb3IgYSBMMyBBUCB0byBr bm93IHdob+KAmXMgdGhlcmUgaXMgdGhlIEwzIGFzc29jaWF0aW9uIChha2EgcmVnaXN0cmF0aW9u LCBSRkMgODUwNSkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIGZpeGVkIEwzIEFQ IChhbiBSU1UgaW4gT0NCKSBtYXkgcHJvdmlkZSBMMyBjb25uZWN0aXZpdHkgdG8gdmVoaWNsZXMu Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGUgdmVoaWNsZSBtb3Zl cyB0aGVuIGl0IG5lZWRzIGhldXJpc3RpY3MgdG8gZmlndXJlIHRoZSBiZXN0IHJvdXRlciBlLmcu LCB0aGUgbW9zdCByZWNlbnRseSBzZWVuLiBXaGVuIEkgaW1wbGVtZW50ZWQgTW9iaWxlIElQIGFu ZCBORU1PIGluIG91ciByb3V0ZXJzIHNvbWUgMTUgeWVhcnMgYWdvIEkgaGFkIHRvIHBsYWNlIGEg bnVtYmVyIG9mIG5vbi1zdGFuZGFyZCBoZXVyaXN0aWNzIGluIE5EIHRvIG1ha2UgdGhhdCB3b3Jr LiBPbmUNCiBvZiB0aGVtIHdhcyB0byB1c2UgdGhlIHJvdXRlciB0aGF0IGV4cG9zZXMgYSBQSU8g YXMgR1cgZm9yIHBhY2tldHMgdGhhdCBhcmUgc291cmNlZCBvbiB0aGUgcHJlZml4IGluIHRoZSBQ SU8uPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JIHN0YXJ0ZWQgYW4gSVB2NiBvdmVyIHdpcmVsZXNzIGRyYWZ0LiBUaGVyZeKAmXMgYSBsb3Qg dGhhdCBuZWVkcyBzYXlpbmcgaW4gdGhlcmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KQWxs IHRoZSBiZXN0LDxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpMZSAyOSBqdWluIDIwMTkgw6AgMDI6NTAsIE1hcmsg U21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tIj5tYXJrenp6 c21pdGhAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PGJyPg0KPGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU2F0LiwgMjkgSnVuLiAyMDE5LCAwMjozMiBQ aGlsaXAgSG9tYnVyZywgJmx0OzxhIGhyZWY9Im1haWx0bzpwY2gtdjZvcHMtOUB1LTEucGhpY29o LmNvbSI+cGNoLXY2b3BzLTlAdS0xLnBoaWNvaC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KJmd0O0hh aXJwaW4naW5nIGFsbCB0cmFmZmljIHRocm91Z2ggdGhlIGFkdmVydGlzaW5nIHJvdXRlciB3aGVu IEw9MCBzZWVtcyBsaWtlPGJyPg0KJmd0O3RoZSBvbmx5IGdlbmVyYWwgc29sdXRpb24uJm5ic3A7 IEJ1dCwgSSBjYW4gaW1hZ2luZSBtYW55IHNpdHVhdGlvbnMgd2hlcmUgaWYgYTxicj4NCiZndDtO ZWlnaGJvdXIgQ2FjaGUgZW50cnkgc29tZWhvdyBleGlzdGVkLCB0aGVuIGl0IGNvdWxkIGJlIHVz ZWQuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoZSByb3V0ZXIgbWF5IHNlbmQgcmVkaXJlY3RzLiBT byBpbiB0aGVvcnkgaXQgaXMgb25seSB0aGU8YnI+DQpmaXJzdCBwYWNrZXQgdG8gYSBuZWlnaGJv ciB0aGF0IG5lZWRzIHRvIGdvIHRocm91Z2ggdGhlIHJvdXRlci48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPllvdSdkIGhhdmUgdG8gc3dpdGNo IHRoZW0gb2ZmIGluIHRoaXMgY2FzZSwuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9k aXY+DQo8ZGl2IGRpcj0iYXV0byI+VGhhdCBoYXMgYWxzbyBiZWVuIGEgY29tbW9uIHRoaW5nIHRv IGRvIGluIElQdjQgaW4gZ2VuZXJhbC4gSSBjYW4ndCBleGFjdGx5IHJlbWVtYmVyIHdoeSwgYmVj YXVzZSBpdCBpcyBzbyBsb25nIGFnbyB0aGF0IEkgbGVhcm5lZCB0byBkbyBpdCwgaG93ZXZlciBJ IGV4cGVjdCBpdCBpcyB0byBzdG9wIHBhY2tldHMgYmVpbmcgcHVudGVkIHRvIHRoZSBjb250cm9s IHBsYW5lIGZvciByZWRpcmVjdCBnZW5lcmF0aW9uLiBOb24tb3B0aW1hbA0KIGZvcndhcmRpbmcg b3IgZHJvcHBpbmcsIGluIHBhcnRpY3VsYXIgaW4gZm9yd2FyZGluZyBoYXJkd2FyZSwgaXMgY2hl YXBlciB0aGFuIG9wdGltYWwgZm9yd2FyZGluZyBhbmQgY29udHJvbCBwbGFuZSBsb2FkIG9mIGdl bmVyYXRpbmcgcmVkaXJlY3RzLiBJdCBhbHNvIHByb2JhYmx5IGNyZWF0ZXMgYSBjb250cm9sIHBs YW5lIERvUyBhdHRhY2sgdmVjdG9yLjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4N CjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3Jl ZmVycmVyIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiIHJlbD0i bm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L3NwYW4+PGJyPg0KPHNwYW4+SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0 PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGll dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj5BZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Ij4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48L3NwYW4+PGJyPg0KPHNw YW4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6CDE2EF9910645E6BB87209345898FBBciscocom_-- From nobody Sun Jun 30 23:30:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FB712024B for ; Sun, 30 Jun 2019 23:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, 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_HELO_NONE=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 xlo4bxomZZNt for ; Sun, 30 Jun 2019 23:29:31 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0960712021C for ; Sun, 30 Jun 2019 23:29:30 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id z23so12287223ote.13 for ; Sun, 30 Jun 2019 23:29:30 -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=ErlnbdgSu45sKWPXYtDBfXGciOeZwDWz0M13BaGgj4A=; b=fXyc2hGnVJ4CRdPIGEHMFob3Ocmfxe05mk5Lgd68G8OSmCZs1/pshQYajrLHR96OOM TbTYcXLE6MIfwNw/EUcb0R38niBFwX4HnBYzcqCJYuXAoMCewjuXkx4dTMZjMkBrT5Y4 Y4xuziPyDg1zeq7mFnKbw0PnzsJfTWO038ar7Rmp5Vt8ILFsKEsX2MImApYYH/VHKdsV L4roxJouclLupOGwpkhErdqu+QsVw2sh2vWSMeRZiI0zhPTAR7o/EmKoVB2iuSP49OLq 1gLbTIaWkM7t/2jpky7U+Yo6Q2Us0KALcuWFNAOrKGGFgv8zJ29I6Zgkn8YiBf0q/4yz BYTQ== 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=ErlnbdgSu45sKWPXYtDBfXGciOeZwDWz0M13BaGgj4A=; b=cbBa3xqxwoyro2cHRtX1hYEcvkP3lDj9yMe24Gt7pb8UaOITvAnT8F4WE4MAP2LAFz Mo3tt5Bp3zi8rAtYEI3MtWrUXkXNhoSjeIAPc46B5Rf5qVaLC4qSs+rhH4/ntn/kBha4 XjG36RK4ZPpDmzjjsUdijpsrmkR6mcOSf4+PW2EzqN1UiOfzWUUN3C2R22Nia1m+qHGQ 3NDLe0gqHuAzD5tFplt4BU19GsQM5IyVHPPyNGwK0xjqAT/E5/TV6WzENL5E31Uc5Lsy T2KXP1lFNI7iY8EFABOfK1ABQ+mQH4/g6CWC2Bhr29bF9drabJ/CSbucL6ncx/hoXA2T 43nw== X-Gm-Message-State: APjAAAXxAfZYvbOzIe9Py93Ktb8wAwSFYouK071uJ29Tor3DFffdQbID HUPuvKqdVWyDoZBHMGtZDsX5l3fm X-Google-Smtp-Source: APXvYqyRJ843MntVTesZgRfIxga0QztSCoS3uDy3XuE7/9kHoaWg/j7Ok4t6mWKT06Ih/RdBbvQdvQ== X-Received: by 2002:a9d:19e5:: with SMTP id k92mr11762790otk.65.1561962570185; Sun, 30 Jun 2019 23:29:30 -0700 (PDT) Received: from ?IPv6:2600:8802:5903:df16::1019? ([2600:8802:5903:df16::1019]) by smtp.gmail.com with ESMTPSA id a20sm3658725otl.44.2019.06.30.23.29.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 23:29:29 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_0658E93A-EF66-4FC2-9DDF-9083A63B8728"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <92DC4FA9-3B1C-4B82-84B9-CF639E368E79@gmail.com> References: To: IPv6 Operations Date: Sat, 29 Jun 2019 12:40:22 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [v6ops] Fwd: Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 06:29:38 -0000 --Apple-Mail=_0658E93A-EF66-4FC2-9DDF-9083A63B8728 Content-Type: multipart/alternative; boundary="Apple-Mail=_12853077-F04D-4078-A8FB-934CB9E65ABB" --Apple-Mail=_12853077-F04D-4078-A8FB-934CB9E65ABB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI - I am putting Eric on the agenda for an opec draft. He's looking = forward to operational WGLC comments in opsec. > Begin forwarded message: >=20 > From: "Eric Vyncke (evyncke)" > Subject: Re: [v6ops] Preliminary Agenda > Date: June 28, 2019 at 11:28:48 AM EDT > To: Fred Baker , "rbonica@juniper.net" = , "furry13@gmail.com" > Cc: "merike@doubleshotsecurity.com" , = "erey@ernw.de" , "kk.chittimaneni@gmail.com" = >=20 > Fred >=20 > As OPSECv6 was never presented at V6OPS (as far as I remember) and we = intend to publish a version in the coming days before going WGLC, this = would be nice to collect V6OPS feedback before/during the OPSEC WGLC and = before the IETF LC >=20 > We/I would require 10-20 minutes of air time >=20 > -=C3=A9ric > = --------------------------------------------------------------------------= ----- The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_12853077-F04D-4078-A8FB-934CB9E65ABB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI = - I am putting Eric on the agenda for an opec draft. He's looking = forward to operational WGLC comments in opsec.

Begin = forwarded message:

From: = "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Subject: = Re: [v6ops] = Preliminary Agenda
Date: = June 28, 2019 at 11:28:48 AM = EDT
To: = Fred Baker <fredbaker.ietf@gmail.com>, "rbonica@juniper.net" = <rbonica@juniper.net>, "furry13@gmail.com" = <furry13@gmail.com>
Cc: "merike@doubleshotsecurity.com" <merike@doubleshotsecurity.com>, "erey@ernw.de" <erey@ernw.de>, "kk.chittimaneni@gmail.com" <kk.chittimaneni@gmail.com>

Fred

As OPSECv6 was never = presented at V6OPS (as far as I remember) and we intend to publish a = version in the coming days before going WGLC, this would be nice to = collect V6OPS feedback before/during the OPSEC WGLC and before the IETF = LC

We/I would require 10-20 minutes of air = time

-=C3=A9ric
---------------------------------------------------------------= ----------------
The fact that = there is a highway to hell and a stairway to heaven is an interesting = comment on projected traffic volume...

= --Apple-Mail=_12853077-F04D-4078-A8FB-934CB9E65ABB-- --Apple-Mail=_0658E93A-EF66-4FC2-9DDF-9083A63B8728 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl0XlHYACgkQEhdRnd2G P+D+GQ/+OSo9D03WGF8UyhRdtoQbEAE4MuFEQaYGfj8YsOkPE61tJFCg6BCBF09J oHv3RnBeXZfD+S7wZIP3tEomOqYDAFG3VQCF1VhhgarQrisPDvO+rIwBf4mObyzL N9zBHCj0T1R9ZM45r3YbUldwN6nrcYRoiQ0zE6XQ2VVFeW6xkbw9YGdSFh5y+W9l 99zKDbSuVgj7w6D111owqSdChPGTbCs1l9nMbXXMATzgkc8Qt+J/2IxPa8fwCAda NwM3c0vLco3VNfMhtXO0nQMcVvPBIXmFYoJwnVk14VS9zW3ACtQheYAXa7QcRiSz GRHUT4bUHFCMzSeori5iS0iGd9DV+hyFRst66MTohOwJ7wTu7mDZsLqf4T3/b32Y CYC6UrmWlceisxmtoSne0MqKZ//74UQml7VkKVKqb3F3ISblKxTX0asrLDU/bBna JDE77urjO/9Qn7ZDmOi9NIPeSvfeyHAlYIpyoXXG3yMsluj9xEUPI/WTxqYB9mEd Dwka6xexe1J4GlLgO4FtiMlrndyA0FIaYNTukQXJRLt52qPkukP0NBJcm07N6qqK Gmyde0r2i1Rpb06sRKMl4gitfSMgZ0fVt2JtK4Jrabg+BEH+qP7q6VOmVCNbxxPM L1FjPnGPi0yqNg2JXHCOj1Rt4alkhWo1j1Hjncf5Qc7lga9m8jE= =5NIM -----END PGP SIGNATURE----- --Apple-Mail=_0658E93A-EF66-4FC2-9DDF-9083A63B8728--